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.
Sugar development maze
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.
A lunatic development stance?
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.
I don't think this represents any serious constituency on the project:
"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."
In particular, this would be practically the antithesis of a "constructivist" approach to computing. It is, in fact, what we've got in the vast majority of US schools right now -- Office & IE -- and this was never the vision for OLPC.
I certainly hope the Update.1 changes to Sugar won't break existing activities! I had enough trouble getting my StarChart activity to work with Sugar as it is.
PyDoc is *not* sufficent for an outsider trying to write code for the XO. Somebody needs to stop hacking code and go write an API manual.
I don't see anything in the linked article that suggests that OLPC is against outside developed Activities running on the XO. What OLPC doesn't seem particularly interested in is making easy for programs NOT designed for the XO to run.
It's basically the age-old question that when developing a new OS or GUI, whether the weight of making existing programs compatible should be on the program developers or the system developers. For example, is it the responsibility of Linux to create compatibility with Windows apps (via WINE), or is it the application programmers' responsibility to make a Linux version?
The decision to run Sugar differently from other GUIs has existed for a long time, so this stance that Activity programmers need to conform to Sugar, and not the other way around, has existed for a long time too. And in a way, it makes sense. Those that have "hacked" plain Linux programs to run on the XO have noticed a lot of issues with dealing with files created by Sugar Activities, and vice-versa. If these apps were instead actually PORTED to Sugar, then cross-compatibility between Activites wouldn't be an issue.
Backwards compatibility within itself is another issue (and separate from the posts' "backwards compatibility" that refers to other Linux distros). Depending on how widespread/accepted the platform is, backwards compatibility with previous versions becomes more and more an issue, since there'd be a lot of applications designed with the previous version in mind. The XO is so new, however, that updating the few actual existing activities at this point isn't really an issue. However, if changes are made to Sugar, these changes should be documented and made readily available to developers. The main problem doesn't seem to be that Sugar is still shifting, but that the shifts aren't given proper notice, making it hard to update outside activities for it.
However, I don't see a problem in the Sugar wrapper breaking, since that's what the wrapper was specifically designed FOR:
http://wiki.laptop.org/go/Pygame_wrapper#Strategic_Rationale
Another consideration is potentially security issues. I seem to recall that forcing applications to inter-operate with the Journal imposes security restrictions on them as well. I'm all for requiring a bit of pain to keep the overall structure.
"This software all rigorously implements the constructivist approach and imposes a view of what constitutes education on the user."
Seems to me to be a contradiction in terms, however. Is constructivism not meant to promote exploration and deconstruction by the students? This strict approach would seem to hamper that among the very user base they're targeting.
Actually, Albert Cahalan has been working on an automatic Sugarizer that makes it possible to wrap almost any application in Python for Sugar. It doesn't make a single-user app do Telepathy (activity sharing) but a Sugarized app runs and behaves itself, showing the standard toolbar, putting its icon in the donut, and so on.
So when the Sugar API changes, Albert can change the glue code in his Sugarizer, and Bob's your uncle!
http://wiki.laptop.org/go/Sugar_Factory
For programs that want to integrate more tightly with Sugar, we will discuss on the OLPC-Devel mailing list how to simplify the process for the <200 current activities. For example, all of the GCompris programs were Sugarized in much the same way, so whatever changes are needed can be applied to all of them at the same time. Etoys is tightly integrated into Sugar, and the code to do it is on the Wiki.
So I will say it again: Is it better to curse the darkness, or to teach people to make candles? There will always be problems. We can wring our hands, or we can jump in and fix them. And by 'we' I mean not only the thousands currently developing hardware and software and content and training, but the millions of children who will be learning Python, Smalltalk, and other means of programming in the next few years. And you, too, Wayan, unless you find complaining more gratifying than contributing, or showing people how to contribute.
In fact, the next time you think you have a complaint, run it by me first. I may already know the answer.
Jay G.
In the full post, Mike gives a number of examples of OLPC choosing not to implement industry-standard processes that would help outside developers code new Activities for the XO - like working & documented API's, for example. In this situation, inaction is a form of active discouragement.
Now the PyGame wrapper to which you refer is one example of the developer community building a bridge to Sugar to overcome the lack of a process. Should we expect that anyone who develops for the XO take on this responsibility? If so, the developer community & resulting outside Activities will be shrinking rapidly - the very outcome that Mark suggests is a goal of "key members of the project."
Ed,
And Wiki History is my cousin. From what I can tell, you just put up the Sugar Factory post today and yet it was dated December 2007. From an email I suppose.
Is this what developers are using now? If so, why was Mike so annoyed that API's for Sugar were broken? He, of all people, should be in the know on the topic.
i've been using the loadable library and the wrapper shell script trick from here: http://lists.laptop.org/pipermail/devel/2008-January/009387.html
for some time, quite successfully.
but more to the point, i've seen absolutely nothing on the developer lists to suggest that existing applications will "break". what _will_ happen is that they will move, from /usr/share/activities to /home/olpc/Activities. there are scripts to help with this -- see walter's most recent community news note for info about "update-activities.py".
To the extent there aren't stable and documented API's, it isn't a strategy, it is simply a sign of the immaturity of Sugar. It just needs more time, there's really no getting around that reality.
Tom's got it. Sugar is new. It's not fully baked. Retaining backwards compatibility will make it take longer to get baked. So the developers have a choice: take longer, or break compatibility. Frankly, too many times developers prefer compatibility over speed, and the result is very slow progress towards a mediocre result. So personally I applaud the Sugar developers for being brave enough to break compatibility. I know it's a pain, but the end result will be much better.
Wayan,
Documenting the APIs is an important step, and one I already acknowledged in my post. However, I don't see the lack of documentation as a sign of "active discouragement," but rather, as Tom and Ted pointed out, a sign of a relatively new and not fully formed GUI being worked on by a limited staff. One of the reasons Ivan Krstic pulled out in support of XP on the XO was the fact that Microsoft was paying for someone to work at OLPC and produce documentation on the XO that is publicly available. So OLPC certainly isn't against outside documentation, and would probably offer additional developers the same option if they chose. With Sugar, it's a bit of a question of "should we write documentation now on an ever developing GUI, where the documents produce may not be of any use in a few months/weeks/days, or should we finish the GUI and THEN produce the necessary documentation?
As for the APIs being "broken," from the article it seems more of a matter of difference in opinion than actual functionality. Every "broken" aspect of the API's Mike mentions revolve around the use of DBUS, although it's not clear if Mike wants OLPC to eliminate DBUS or just abstract it more for the end developer. It again boils down to whether one thinks it's OLPC's responsibility to make programing for or porting to the XO as accommodating to other platform programing styles as possible, or whether it's the developers' responsibility to learn the new interfaces the XO and Sugar use (like DBUS).