(Reply to this) (Thread)

(Reply to this) (Parent)

(Reply to this)

I'm not sure I agree that "upstream everything" is the answer.

I'm working for another embedded systems company, one with sane and enlightened management (how nice!), and although they have a very similar "custom shell on top of base distro" architecture, they do *not* either have the support problems we had at OLPC *or* have everything upstreamed.

If anything, why it works it that it's so much easier *not* to upstream things. The base distro is more embedding-friendly, and there are a small number of dedicated engineers at the upstream distro working specifically on embedded builds. Whenever we get to a point where we need option X set to Y in our distro, we file an upstream bug with them and *we're done*. In their next release of the base system (to which we add our special sauce), option X is set to Y. We don't need to argue with them, we don't need to convince them that Y is the correct setting, or anything. It just gets done. Presumably, at the upstream distro, they can have their own internal discussions about whether our changes should go upstream and/or how, *but that's not our business*. From the client persepective, we just get the changes we need made. (Sometimes they'll suggest that setting X to Z would in fact be better/fit in with upstream or future development, or that upgrading package Q to version Frobnitz would also fix the problem, but they never tell us "No" or even "Not Yet", and they never make *us* maintain the fork.)

I really don't think it's the "non upstreamed code" which made OLPC's OS development so difficult. I think the real problems were:

• Ambitious directors with no experience cutting features to make release dates or planning incremental releases to reach the desired functionality (ie, management by the visionaries and engineers without proper release management, scheduling, or oversight),
• As Ivan says, the hardware was ambitious, and that means buggy -- again, we didn't have the resources to do "seven new things" all at once, and somehow it became OLPC's responsibility to make all the moving parts work, instead of the vendor's (if you take a brand-new never-been-debugged component with a *closed source* driver, you better have good contracts and management to ensure the vendor Makes It Work for you -- and we didn't), and
• A dysfunctional relationship with a poorly-matched upstream, who was unwilling to make the changes to their core product to make it work on OLPC's extremely atypical hardware or support OLPC's efforts to do so.

OLPC spent a lot of engineering cycles because it did not have the proper relations with (a) its OS upstream, (b) its hardware vendors, or (c) the country clients to make *them* shoulder appropriate portions of the costs of Making It Work. And it did not have the proper relationships because of failures of management. Engineers worked around management and communications problems by Just Doing It Themselves, as they are wont to do -- but that was ultimately unsustainable and inefficient. Better contracts and better partners should have been made/found.

This isn't really a knock at Red Hat -- I love you, I really do -- it's just that it was a poor fit for OLPC. Red Hat didn't have the code or the tools to do the sort of aggressive third-party development that OLPC wanted/needed to do. It's made a good effort in the past few years to grow these, but (from my first hand experience) it's still nowhere near what a certain South African company can do for embedded customers.

(Reply to this)