[IAEP] Long-term development strategy (Was: New XO-1.5 10.2.0 build 119)

[Bernie Innocenti]

On Sat, 2010-04-10 at 13:29 -0700, Jon Nettleton wrote:

> Has there been any discussion on whether CentOS was an option as a
> base for the distro?  With RHEL/CentOS 6 hopefully within sight, that
> would give a nice target to provide both the combination of stability
> and long term support.

This comes up every once in a while. Frankly, I don't "believe" in the
value of enterprise Linux distributions; I've been stuck with them in a
couple of cases in the past, and they were always a support PITA even
for non-development usage: nobody in the community cares to help you
with debugging and back-porting recent versions of software becomes
increasingly painful over time.

Granted, frequently upgrading the OS also comes with its own aches too,
but these are amply compensated by useful new features and better
support from upstream.

We've been very lucky that Dan Williams was kind enough to spend some of
his time for helping us with critical bugs in NetworkManager 0.7. We've
not been equally lucky with udev and GStreamer, both of which have
unsolved issues in F11 for which we lack expertise.

Over the last 5 years, I've become a strong advocate of the
decentralized, community-driven development model. I do believe in it
because I've observed it at work for 15 years. Traditionally minded
managers are still looking at this enormous market value accumulated by
the open model as some sort of economic anomaly; some sort of prestige
trick which contradicts the rules of classic schoolbooks. Yet, an entire
industry of new businesses has grown out of free software and is
flourishing with it. Those who guessed its rules can play the game and
win.

As Martin and I discussed not long ago, our development model doesn't
have to directly affect end-users. Already released free software
doesn't have an expiration date. Conservative users can keep using Sugar
0.82 forever, if they really like it better than newer releases.
Bugfixes and new features could be back-ported from newer releases, of
course with increasing costs as time passes.

We OLPC & Sugar developers cannot effectively support the entire
codebase of an entire OS without strong backing from the larger Fedora
community and the even larger global Linux community.

In the past, Sugar and OLPC development was much hurt by its
disconnection from the rest of the free software ecosystem on which it
was built. We need to get much closer to our upstream projects, both in
time (by using current software) and in space (by not diverging our
codebase). It's not just a technological issue, it's a long-term
sustainability issue.

Before anyone yells "Yarr! Ye don't care about the children!", I'd like
to point out that I've been spending several months looking at problems
in the field, trying to fix some of them and, more importantly, trying
to build local capacity for fixing them autonomously. In my mind, this
is *the only* reasonable strategy to scale Sugar support up to the size
of an entire planet. Those who think it would be impossible for people
in developing nations to learn the technical skills needed for fixing
their software would be shocked to see what Nepal and Paraguay have been
able to achieve in just two years, with very little funding.

-- 
   // Bernie Innocenti - http://codewiz.org/
 \X/  Sugar Labs       - http://sugarlabs.org/