From the beginning, I've been impressed with the idea of the Sugar User Interface. Like I've said before, Sugar a beautiful redesign. It doesn't feel like Windows, Mac, or even Linux. But that doesn't make it easy to develop for.
I've heard from others with way more developer skills than I, that Sugar is intrinsically difficult to work with due to the Journal implementation. In fact, a standard Linux software application also needs a special Sugar "wrapper" to make it work on the XO.
Even more annoying, there is some discussion that Update 1, a forthcoming upgrade to Sugar, will break all existing wrappers, and current Activities will need to be re-coded and re-wrapped.
I was surprised that an Open Source project would be so casual with all the efforts of the wider development community until I read Mike C. Fletcher's OLPC at PyCon Wrap-up where he explained a driving force in Sugar development:
Half of the project seems to think that what is being produced is an "educational appliance" that runs a very small suite of custom designed software. This software all rigorously implements the constructivist approach and imposes a view of what constitutes education on the user.
The suite of software is limited (potentially) to a web-browser, a word processor and a spread sheet (in one dev's view). In this view, there is a very small set of core software which is important, and is small enough a set that a small group could write it. All other software is non-essential.
For those with this view, externally developed software is of far lesser importance than the few core Activities. This view of the machine is one of a closed-door platform where you can break backward compatibility (i.e. with all existing Linux systems) without consequences and can assume that all developers are dedicated to the platform 100% of their time.
This approach revels in the idea of not needing to worry about backward compatibility. (We've had a large number of pronouncements along this line from key members of the project.) The advocates see letting "regular" Linux applications run as a problem, something to be avoided if at all possible. They want anyone working on the platform to dedicate most or all of their efforts to the task of developing for the platform specifically.
I can understand a need for OLPC's internal developers to focus on core activities, especially improving Sugar. I can also see the reluctance to leave the XO open for just about any program - Doom as an Activity was a whole conversation in itself. But isn't being so close-minded on the wrong end of the brilliance-arrogance scale?
Or as Mike concludes about the OLPC developer community:
They want to have the core activities be powerful and simple, covering the basics of educational requirements; but they also want the machines to be flexible and functional, with a wide range of Activities..
In particular, we came to a loose agreement at the conference that, even if the end goal is an embedded approach with only a handful of activities, the practicality of what is needed today means that we will need to open the platform to "external" applications in the short term at least.