OLPC: Open Organized Transparent

[Garrett Goebel]

I'm not the best person with words. But here goes anyway...

Yes, the OLPC project is an open source project, but in practice the
project itself suffers from being closed, disorganized, and opaque in
its operations.

We (if you're reading this, I mean you) need to put aside all this
personal "One True Way" axe grinding, do a little individual
introspection, and try to focus on the common factors which bring
people together in this endeavor. We're all here with different
personalities, ideals, expertise, and axes to grind. The one thing we
all have in common is a desire to provide educational opportunity to
children. OLPC is an Education Project.

There is enough room at the table for each of us to bring a different
set if ideals and ideas on the means of achieving it. The current
problem, appears to be that the project isn't effectively organized
and it isn't optimized to embrace the varying perspectives and develop
a large community of open source developers.

Many decisions are made behind closed doors. And decisions once made
aren't very well communicated. It isn't just that the outside
developer community doesn't feel like anyone is listening. There is a
real sense that upper management is out of touch with its own
employees.

The Cambridge Lab staff ought to do a little self-examination. Because
they would never guess how much to us outsiders they resemble their
upper management. I can't tell you how often these smart mostly male
MIT types turn a deaf ear or return a derisive holier than thou email
to the outsiders and developer community they will ultimately be
dependent upon growing in order to succeed.

None of this is remotely surprising in a startup. And frankly, it
wouldn't be all that surprising to encounter in a software development
department of any organization. But it is suicide for an Open Source
project.


On Thu, May 15, 2008 at 8:57 PM, info at olpc-peru.info
<info at olpc-peru.info> wrote:
> I think the way to "protect" Sugar and to take a step further in the
> whole project is giving one step back: Sugar must be able to
> run on any Linux distro.  I know that it is hard... but IF we are able
> to take this step back then Sugar (and many
> other things) will be in better competitive position.

I think the project needs to take another step back. The education
project is both a hardware and a software project. The best way to
insure the success of the project is to divide the project into its
constituent sub-projects and let each sink or swim based on their
relative merit and the resources they can attract to achieve their
goals.

The OLPC needs to reorganize to embrace the "There Is More Than One
Way To Do It" philosophical perspective which will allow us to
collectively take advantage of the synergies which exists where our
ideas intersect.

Getting Sugar running on any Linux distribution isn't enough.


1) Unbundle the hardware and the software projects.

We should allow the educational organizations footing the bill to
define their own requirements. Whether that means an XO running
something other than Sugar, Sugar running on something other than an
XO, or even Sugar running on something other than Linux. Perfect is
the enemy of good enough. Let us be willing to accept getting any
combination of XO, Linux, and Sugar into the hands of children as an
improvement over the status quo.


2) Seed the developer community

The OLPC ought to give XO's away to the lead developers of every open
source project on which the reference platform has an underlying
dependency. And XO's should be made _easily_ available at cost to
developers from other open source projects and developers of
proprietary software, operating systems, and hardware devices.

I think the OLPC's decision to sell XO's only in large quantities and
only top down to educational institutions is wrong. I know the stated
reason of discouraging theft from children. And the unstated reason of
avoiding the additional cost of providing customer service and
support.

Both are short sighted and wrong. The economies of scale that could be
achieved increasing sales might actually make the realization of a
$100 laptop possible. Include the cost of customer support in the sale
of individual XO's. Let it pay for the customer service infrastructure
for servicing organizations in developing countries as well. The XO is
designed for children. Most adults wouldn't use one if you gave it to
them. The firmware with security enabled should provide a cost
effective deterrent to theft.


3) There Is More Than One Way To Do It

The Cambridge Labs should continue to coordinate the development,
testing, and release of reference platforms which provide a stable
base and showcase the various hardware and software innovations. "The
One True Way" currently appears to be XO, Fedora Linux, Sugar, and
Python. The one true way should change to a tried, tested, and
supported reference platform.

However, the driving mindset should be cross platform compatibility at
all levels. This doesn't mean dumbing everything down to the lowest
common denominator. But making the design decisions and providing the
detailed specifications an common interfaces to allow alternative
implementations.

No one should expect the Cambridge Labs to develop alternative
implementations of Sugar or XO operating system distributions, but it
ought to encourage and embrace them. It ought to provide the gamut of
irc channels, mailing lists, source code revision control
repositories, and build and test automation infrastructure to support
them.