This email from Mike C. Fletcher was original published on the OLPC Developers listserv and is republished here with Mike's permission as more OLPC News commentary on the WSJ article.

Obviously conflict sells stories best, so I won't attack the [Wall Street Journal] author for playing it up. That said, there were issues brought up that we should discuss rather than simply dismissing because the person bringing it up (in this case) had to sell a few papers. The best friend you have in a design project is the harshest critic available. As long as their critique is fair, we should listen carefully to it.

Much of the stuff I'm discussing below has already been started, or is under-way. I'm just suggesting that we keep it in mind a few things that the article points out...

It's not About the Hardware:

The XO hardware is wonderful, but in the end, it's not the key thing. While it may be able to go into areas that another machine can't go, there are lots of areas that any machine can go into. We are an educational project, and while the screen makes a superlatively good textbook reader, the case is reasonably weather-resistant, and the battery life is good (but not yet so good that it's a killer feature), it is not true that every ministry of education will choose to go with "our" hardware.

Our hardware may have advantages, but it is just a (fairly generic) vehicle for accessing software, content and people, and if countries want to choose another project's hardware, more power to them.[As Nicholas has explicitly stated on a number of occasions.]

If we are serious in our goal of educating children, we need to do a few things, and some of this requires a readjustment and a detachment from the question of which hardware goes where. Does the hardware matter? Sure, there are areas where the XO is a better choice because of some metric, but if a country wants to choose Classmates or EEEs, that's fine, we still want to help educate those children.

Sure the segmentation of the market means that we can't hit the economies of scale we want, that sucks for us and means that our children will be getting less for their money. That sucks, and we'd like to get to the point of selling lots and lots of the XOs to make it as cheap and useful as possible, so we're going to continue to try to get more "sales".

By the time we're looking at a 'generation two' of the XO we would like to be able to order the hardware off-the-shelf to our spec and have companies produce dozens of different models. To make that happen we need to reach out to the hardware developers already working in this space and make shipping our software and content a no-brainer decision when they are selling into the educational market.

Addressing the Issue:

• We should port to the other inexpensive laptops, if a country decides to go with EEEs or Classmates, we should be in there offering an EEE or Classmate-optimised Sugar + Activities + Content that they can load onto those machines
1. we should also port to the thin-client-style setups seen in e.g. Canonical's deployments of computing labs in the developing world
• we need to make use on multi-user machines easy, where Sugar is just a desktop manager session that is run just as one would run KDE or Gnome (so that computing lab situations can let children use Sugar's safe, rich without giving up the ability to run KDE/Gnome)
• we need to get our installation requirements on non-Fedora Linux down to a package-level installation
1. (and have this be supported and maintained (preferably internally))
2. (also very useful for encouraging developers)

If we are serious about educating children, and we truly believe that the software and content we are creating is key to allowing children to learn well, then we need to make that software and content available for all of the projects that are sending computers out in the service of educating children.

We need to see ourselves, and communicate our vision of, being an educational project which is trying to grant access to children. Selling our particular hardware is useful because it has a few features that make it uniquely suited to many areas, but we need to expand our vision to achieve the goal IMO.

Standardisation and Application Availability:

We aren't shipping Windows. If countries want to use "the standard", our hardware likely isn't going to be chosen, and we likely cannot convince them to change (sure we can run Windows, but our hardware isn't a great choice for that). So for the countries whose goal is simply to enable their population to run Windows, well, they're basically lost, no need to worry about them.

For the other countries, we need to address their concerns. It seems that at least some of the concern is because we have introduced a huge barrier to entry for application porting. That means we have a pool of dozens of applications instead of hundreds or thousands of activities/applications. Even compared to other Linux-based solutions, we have a tiny pool of available applications, many of which are still in reasonably early stages of development.

We are missing whole classes of application/activity. We do not currently have usable vector or raster graphics, spreadsheet, generic IM or PIM clients, and countries are wondering when/if those are going to show up. With a "regular Linux" (or Windows) machine, a child can readily install an application that does those tasks and have it "simply work".

Sugar, by contrast, is being perceived as a "toy" environment. While that's good (we are a toy environment in the sense of an environment that helps one learn by playing), we need to address the pejorative of that view as well.

Addressing the Issue:

• we need some way for a regular, non-Sugar-fied application to be installed (easily) and run (with reasonable support) on a Sugar desktop. We should at least have the application-depth of a Linux desktop available to our students.
1. Even if they don't integrate nicely and they have file dialogues instead of Journal dialogues (so you'll have to switch to the Journal and add the file manually)... practicality beats purity
• we need mechanisms that allow application developers to quickly package an existing application as an activity
1. without a recompile (i.e. from an rpm or the like, just with some external metadata describing the activity's operation)
2. with only a recompile to get basic Journal-triggering functionality (i.e. just substituting GTKFileDialogue with GTKJournalTriggeringFileDialogue)
3. with just a few code changes (i.e. replacing menus with sugar-style tabbed toolbar-menus and the like)

Work on easing this kind of integration is ongoing in Sugar (changelog from yesterday mentioned some of the work to make regular X apps work more naturally), but we probably need to make this kind of "yes, but I need it today" adaptation a priority.

Maintenance and Support:

One of the other quoted reasons is that countries are worried about ongoing support and maintenance. Far from being a "scary question", this should be seen as a strength. We need to make sure that people understand this as a strength and discuss it as such.

Addressing the Issue:

• we should be documenting the setup at the Galadima "Hospital"
• we should be documenting how the high-school students in Peru are maintaining the laptops there
• we should be turning these children's experiences into a manual for use by other schools and districts

Making the maintenance local is part of the process of enabling people and educating the populace. Some fraction of the populace will learn how to maintain computers, it's a useful skill that is readily marketable in a society with computer access. If you rely on an external group for maintenance you're pretty much up a creek when that group raises the prices or goes out of business.

Some country or project level maintenance needs to be part of the system, and we need to make sure that people are understanding that, and understanding the level of commitment required (including the need for a parts warehouse and a few techs to do more involved repairs). Again, the point is that this is not a product being sold, but a process that advances the country.

We need to make sure that the process is clear, straightforward and understood as part of the advantage of choosing open hardware. That said, even with the closed hardware, we want to encourage the countries to see themselves as part of the lifecycle of the educational technologies they are purchasing, and to demand access to maintain the machines themselves.

If you are a client nation for some technology, your resources are being drained. If you are a participant nation, your resources are being developed. The second and third tier support infrastructure needs to be modeled and documented too. Countries would like to see a manual that they can translate to give to their workers in their regional/country-level support centres.

Teacher Training:

Again, a quoted problem is teacher training concerns. Peru did an intensive program in the pilot programme where teachers were given one-on-three training by the deployment team. Uruguay AFAIK just handed the laptops out. Nepal has a teacher training programme under development AFAIK. Experience seems to suggest that the students are learning the machines reasonably quickly with other students leading the way, but that's no reason not to make materials available.

Addressing the Issue:

• We need to have the Teacher Training documented as it is done
1. What was done
2. What was covered o Where did teachers have problems
3. How long did the training need
4. Where were teachers starting from
• In effect, we need to collect together a model training curriculum for teachers that countries can use as a starting point
1. yes I'm aware of the implications of cultural imperialism here, but again, we offer a model that can be adapted, used or rejected

We should probably also be asking Teachers and Countries to share their class plans and curricula so that other teachers and countries can see what's involved in the integration effort.

Anyway, just don't want us to throw away a chance to improve ourselves... we are an education project and should take every opportunity that presents itself to learn.

This email from Mike C. Fletcher was original published on the OLPC Developers listserv and is republished here with Mike's permission as more OLPC News commentary on the WSJ article can be found here.