We did 3.5 days of sprinting at PyCon with ~12 people (the GASP folks were sort-of part of our sprint, as they are targeting the laptop, and we worked with them). Mostly we worked on games, with Tony leading a smaller group working on accessibility tools.

We had most people (basically all those using Win32 or Ubuntu) set up with a development environment within a few minutes. That's a great improvement from last year having 5 of us spending 4 days to not-quite get a working development environment.

I spent pretty much the entire time on management, mentoring, and general coaching of the team. Didn't write much code, and what little I did get done didn't have much visible effect (code cleanup, and a single new GUI control). Spent some time on OLPCGames here and there.

Had a number of developers work through the "big" tutorial, altering the text to answer the questions they brought up. Also sat with Phil as he ported a couple of his games to document the process and imposed upon him to give the GASP and OLPC folks a tutorial on how to structure UDP networking for games.

We didn't have anyone at the conference who still works for the OLPC (there were 4 of us who used to work for them). That seems like a large opportunity cost for the project. It's the largest collection of Python programmers on the planet and it only happens once per year. It seems that there should have been someone there from 1CC, next year they really need to make that happen (I realize they are busy, but this is the group that could help them become less busy by sharing out the work).

Probably the most frequent question I got asked was "What's wrong with the project?" Obviously that's a question someone from 1CC should have been there to answer, rather than me. Developers at the conference were seriously concerned that the project has lost its way and is apparently incapable of, or uninterested in, supporting external developers.

By the time the first few days were through I was pretty horse from ranting :) . The hardware is a stunning achievement. The project looks like it will accomplish the task set out, to help educate children in large numbers. What we need to do now is to focus on efficiency and effectiveness, to stop burning up our developer good-will. Interestingly, toward the end of the conference I finally found two people willing to advocate for the other side of the big issues, I've tried to outline their positions below.

The project is complex, and I can't claim to have any insight about what goes on at 1CC (never having been there or met anyone from there other than Noah and Mel), but here's my view from the outside...


1) Embedded Systems Mentality

We had at least a few major discussions about this, so I can't claim this is an agreed-upon problem, but I consider it a major one, so I'll just go ahead and describe it.

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.

In such a view, you can use development systems (such as sugar-jhbuild) which impose extremely high costs on new developers, anyone working on the platform will set up once and then work for many months or years on the platform. Similarly, you can break APIs with aplomb, as all developers are actively maintaining their activities and will adapt to the new APIs. This allows for creating (what is perceived internally as) very clean APIs, innovative solutions, game-changing designs.

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.

The other half of the project seems to think that we are producing a general computing device, a flexible, adaptable machine which is intended to allow children and communities to make of the machine what they need. While they are willing to suggest and demonstrate constructivist approaches, they are not wedded to the idea that without constructivist redesign a piece of software should not run on the platform.

These people see the machine as having a core set of tools, but want to see the toolbox expanded to include as many useful hammers and nails as possible, so that the platform can be adapted as much as possible. They tend to want the platform to be easy to port software to, to be easy to program for, to be approachable, and generally to allow the children as broad of access as possible.

Realistically, most people are in the middle of the two mind-sets. 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.

2) Hype and Snipers

In case you missed it, this project is rather visible. Every little sneeze, every cough, is used by people standing on the sidelines to declare the death of the project. There are commentators who take every opportunity to seem supportive, while attempting to twist in a knife, cackling in schadenfreude and veiling all of their potentially useful critiques in a veil of false friendship.

The effects of that toxic critique is to shut down the channels of communication, so that all external critique is rejected far too easily. External developers and commentators who are not universally positive are seen as, at best, not "getting it", and at worst, as being intent upon derailing the project via false motives. The project needs some way to separate out the critiques intended to derail it from those intent on righting the path.

It is hard to imagine the project succeeding without the media circus that has drummed up such a huge amount of developer and general public good will. Still, the hype around the project means that the people within the project will need to be able to deal with the effects, from the overt enemies, to the choruses of well-meaning and supportive people who believe they have a silver-bullet solution that must be listened to today.

Managing to create a real community in such an environment is a non-trivial undertaking. Actively managing outreach to the community, creating mechanisms that let meaningful signal rise above the noise, is needed.

Part of that is going to be the OLPC project getting beyond jumping at critical individuals as soon as they dare to raise a question. Thoughtful, caring commentators are not speaking up, or not speaking up loudly enough, for fear of being lumped into the "against" camp by those at 1CC (e.g. Titus' talk at PyCon pulled a lot of punches that should not have been pulled IMO, and should have served as a wake-up call, were there anyone there from 1CC to hear it).


On a lower level, in terms of the stuff that is broken at a technical level, here's a short list of things that are frustrating external developers. You will notice that a lot of this stuff sounds like it lands firmly in the "flexibility" camp. External developers are mostly part of that camp, but these particular points would also make custom development easier. Having a non-standard API may keep people from porting things you consider "inferior" easily, but having a *broken* non-standard API keeps people from writing for it at all:

3) Broken Journal API

DBUS should not be required for file-storage. Use either an inotify mechanism to produce an out-of-band index (like every other search/journal system on Linux), or write a file-system to catch the file read/write operations. Make a simple file-based API for metadata storage (e.g. you can see a file-system level one in Reiser-4, and a simple mechanism such as a .metadata file would seem reasonable as a first crack).

Allow an *optional* mechanism for suppressing indexing for a given area. Preferably use an overlay-based file-system so that activities can write to their "normal" locations. That link is to a (now rather old) write-up on how such an API would look.

Do not copy/move files just to have them in a new location. Assume that a file which is written to a given location should remain in that location. Allow for multiple files per session, allow sessions to be composed and decomposed (see the previous link for lots of discussion on that).

Use simple

myapp myfile

launching to start a new activity with a file. Don't require DBUS events just to get access to the data-file identity. Do not assume DBUS processing for basic behaviour.

4) Broken Windowing API

Do not require DBUS handling for such basic things as setting up an activity-to-window correspondence (luckily that has been somewhat mitigated, but in a way that requires either a low-level hack or operations well below most GUI library's level of abstraction (i.e. raw X11 window property setting)).

The result of the current design is that every single activity has to have embedded within it a part of the GUI shell (the Activity class for Python activities, a heck of a lot of code for anything else). That requirement means that every time the fragment that is embedded in the activities changes the activities need to be revised and re-released.

There are dozens (maybe hundreds) of GUI shells for Linux that are able to observe the opening of a new top-level window and use it to track the window, switch to it, close it, and generally manage it. They provide activity launching, network management (normally with a plug-in), running-activity management, and work robustly and simply. Sugar's functional differences from a normal shell are pretty trivial. Choose one of them, create a Sugar "skin" for it and move forward. Provide a backward-compatible API for the current activities.

5) Security API

Same thing, don't require DBUS just to launch a new constrained context. If you want to use DBUS under the covers, that's fine, but make the standard API for wrapping a security context around an activity look something like:

start_security_context myapp myfile

where myapp is a path to an executable.

6) Developer Program Machines

Developers need access to the hardware. I had a (rather privileged) developer who had a B4 machine (which is all most have) complaining that he wasn't able to properly test on a B4, and that as a result he felt he was owed a final machine to be able to "properly" test.

I'm afraid I come down on the "suck it up" side for that particular case. Still, it highlights that developers do need some way to access the hardware for testing. G1G1 obviously got a lot more machines out there, but the Developer's program is still a key requirement. Machines need to be allocated to the program again and distributed to the developers who are working on the platform.

7) Testing

See Titus' presentation at PyCon.

8) Packaging and Developer Setup

This is where I got on the train 21 months ago, and what originally got me hired... and its still a bit of a problem.

Jani's packages are the only realistic mechanism by which a developer can set up a development environment on their Linux box (without hours of setup time). That's ridiculous, there should obviously be Fedora packages available via yum, but for some reason they don't seem to be provided.

The emulation environments are working reasonably well these days, with the Win32 Quicker Start seeming like a well done package. That makes the setup process easy and fast.

Still, all of those are largely unsupported projects. Jani's packages are around 3 months old now. The Win32 Quicker Start is much more recent, but seems to have some Joyride build that breaks all Activities (at least, with some core functionality broken, i.e. the sugar_activity_root being an invalid directory).

9) API Stabilization

Yes, I do mean this. Yes, we need to fix the broken APIs described above, but we need to provide backward compatible support for the current activities. I resurrected OLPCGames in November/December so that we would have at least one working Python development stack. The purpose of that was to allow people to develop to one API and have that API abstract away the underlying chaos of the ever-changing PyGTK-based stack.

Particularly for novice and occasional programmers, having an ever-changing API based on a poorly-documented GUI library and largely undocumented services makes for a hopelessly complex development environment. Those novice programmers can produce a new activity with significant educational benefit in a couple of days if they are working in a well-documented environment that abstracts away the complexities of the platform.

It took a few minutes to take one developer through how to do Telepathy when run through the OLPCGames wrapper (good job Noah). Her eyes just glazed over and dropped focus when I tried to run through all the machinery underneath... every PyGTK developer is being asked to work that complexity into every activity they develop (99% are just copying boilerplate verbatim with no idea what they're doing, of course, and no way of knowing how to fix it when it breaks).


Yes, I did debate with myself and a few others for a few days about whether to post this. In the end, while it may not be particularly effective to post it here, I'm hoping maybe it will help. There are lots of other little things, such as the amount of boilerplate required to create an activity, but the big points we discussed at PyCon are outlined above.

I'm rather encouraged by the proposed "Mini Conference" topics, which seem to address a few of the technical issues outlined above. Hopefully we'll see some significant progress toward a developer-friendly environment as we move forward.