WSJ

[Mike C. Fletcher]

Eric wrote:
> The WSJ article and video post were what one would expect from them:
> focused on the financial, and not cultural or societal, aspects of the
> project.  The thrust seemed to be how it would affect the Intel and/or
> AMD stock price, and the implication was that since the XO price is
> NOW not "$100" the project has somehow failed.  Pure bullsh*t from a
> reporter that clearly doesnt get the larger context.
Obviously conflict sells stories best[1], so I won't attack the 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.[2]

    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
              o 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
              o (and have this be supported and maintained (preferably
                internally))
              o (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.
              o 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
              o without a recompile (i.e. from an rpm or the like, just
                with some external metadata describing the activity's
                operation)
              o with only a recompile to get basic Journal-triggering
                functionality (i.e. just substituting GTKFileDialogue
                with GTKJournalTriggeringFileDialogue)
              o 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
              o What was done
              o What was covered
              o Where did teachers have problems
              o How long did the training need
              o 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
              o 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.
Mike

[1]
http://online.wsj.com/article/SB119586754115002717.html?mod=googlenews_wsj
[2] As Nicholas has explicitly stated on a number of occasions.

-- 
________________________________________________
  Mike C. Fletcher
  Designer, VR Plumber, Coder
  http://www.vrplumber.com
  http://blog.vrplumber.com