OLPC, OpenMoko and GNOME Mobile

11:43 am gnome, maemo, marketing

Some recent stories have started raising brows among some comentators on GNOME Mobile (see the comments in particular):

  • OLPC figurehead Nicolas Negroponte announces that they will be installing Windows on the XO laptops, and porting Sugar to Windows
  • OpenMoko project lead Michael Shiloh announces that future versions of the platform will have Enlightenment as the windowing system and Qtopia apps by default

Both of these stories are not complete abandonments of GTK+ or the GNOME platform. Sugar will still be GTK+ based, and OpenMoko will continue to support GTK+ in the platform, and the previously developed GTK+ applications.

But it would be disingenuous to suggest that these announcements don’t represent a cooling towards the GNOME platform on the part of both organisations.

So what happened? There are two plausible explanations:

  • Bad tools – the GNOME platform is not suitable to the applications, or it’s difficult to develop with, there is a shortage of development tools,Ā  books, or maybe the platform itself has quality or performance issues – perhaps the organisations had trouble hiring hackers with GTK+ experience
  • Bad workmen – the projects over-reached, had unreasonable schedule expectations, were not sufficiently planned, and were poorly executed, due to poor management or weak team members – the choice of technology is irrelevant to the failures of the projects to deliver on expectations in terms of schedule, functionality and quality, perhaps the projects had poor or inconsistent focus and vision

The truth is probably somewhere in the middle.

I think most people who have tried would say that software development with GTK+ in C is hard, development in C++ or Java is quicker and less painful. A case, if one needed to be made, for focussing more than ever on gtkmm and java-gnome, and ensuring that these bindings are promoted, and as high-quality as possible.

But if you look at the goals of OLPC, their goal was to completely rewrite the graphical interface to the OS to be completely focused on the educational paradigm they were aiming for. This is a huge task, and it seems clear (in hindsight) that the enormity of it was underestimated. Free software is not the cure to all ills, things don’t go quicker just because you chose a free software licence for your project. The reality of the project’s status didn’t keep up with schedule pressures and marketing, to thepoint where the project’s credibility has been damaged by theGive One Get One and some high-profile withdrawls from the program.

The same thing goes for OpenMoko. Looking in from the outside, the technical management of the project has not been consistent from the beginning, partly because unreasonable expectations at the beginning led to impatience when early objectives weren’t being met. With objectives unmet, band-aids were plastered on band-aids, the direction changed, and now the OpenMoko platform has three competing application frameworks supported – QT, GTK+ and EFL.

It may be, and I hope it is, that both these projects survive their current difficulties and go on to be great successes. I’m sure that there are lessons to be learned for us in their stories.

But people who announce that this means the end of GNOME Mobile are quite obviously over-reacting.

We have several high-profile participants, including Nokia and ACCESS, committed to using GTK+ in their platforms. Important components of the GNOME Mobile stack area key part of the moblin platform, and are included in the LiMo reference platform (PDF). Devices such as those announced recently by Verizon, and the 18 phones announced by LiMo earlier this year, are based on this platform, so it seems clear that we are going to be a player in the mobile device space for many years. Success stories like the Vernier LabQuest and the iRex e-book reader show that we can be a compelling option in niche devices with custom interfaces.

With the current work of the initiative following on from the Austin summit last month, which includes creating a GNOME Mobile release set for release with GNOME 2.24, and raising awareness of what we’re up to, you should be seeing some interesting news over the coming months. The GNOME Mobile initiative is more necessary and useful now than ever.

13 Responses

  1. Frank Says:

    I think Vala and Mono/C# is the best way out!

  2. Cypher Says:

    Do you remember the acquisition of TrollTech by Nokia ? Are you really expecting Nokia to use anything else than Qt ?
    Anyway, I’m glad to see Qt being supported in OpenMoko, as in my opinion, it is far superior to GTK+.

  3. apan Says:

    One of the major reasons people are moving to QT on limited devices are probably because it performs much better. I prefer C/Vala over C++ any day so I hope the performance issues will be dealt with.

  4. Khertan Says:

    Anyway, Iā€™m glad to see Gnome is supported in Maemo, as in my opinion, it is far superior to QT.

    “Are you really expecting Nokia to use anything else than Qt ?”
    Yes … Maemo will still use mainly GTK+.

    Look at what zaurus application look like … this is what u want in your mobile … ? (Zaurus use qtopia).

  5. Dave Neary Says:

    Of course I noticed that.

    I also noticed Nokia committing to a Hildon/GTK+ interface for the next version of their tablet software, and keeping the Hildon/GTK+ platform through the following version of the software – that means that GTK+ is still present for at least 2 years in Nokia’s product roadmap.

    So to answer your question, yes, I think that Nokia will continue to use GTK+ for at least another 2 years.

  6. Alex Says:

    Without wanting to promote Mono/C#, using Monodevelop and Stetic to develop an app for embedded hardware has been an almost entirely pleasurable experience. Gtk+ in C is much more painful, even after using Gtk# (my Gtk+ knowledge in general is low).

    I’m not sure language/platform is the answer, but better developer tools surely is. It comes down to the apps, and how quickly they can be created and advanced.

    It does seem to me like the “problem” with mobile isn’t a mobile only thing; it’s a general thing about getting up to speed on the GNOME/Gtk+ platform in general.

  7. Peteris Krisjanis Says:

    Correction: OLPC doesn’t “go” Windows and still there is no certain answer that Sugar will be ported to Windows. All OLPC plans to do for now is to offer Windows XP “Uberlight” to countries which want them.

    It is easy to get confused with so many myths and simple misinformations, but that’s why fact checking is a must with these days internet information stream šŸ™‚

  8. Alan Wallcraft Says:

    I was surprised to see the iRex iLiad mentioned as a success. It is the only “open” e-book reader and does use GTK+, but it does not support most recent GTK+ applications. In part because of severe resource limitations. It would be great if Gnome Mobile could run on the iLiad or at least allow more apps to run.

  9. tuXXX Says:

    Vala looks nicer to me than gtkmm šŸ™‚

  10. gpoo Says:

    This is not a rant. Just are questions that I have made to myself.

    IMVHO, it is not a matter of language. It is a matter of what we offer to develop applications.

    Do we really have a (complete) development platform for any interested developer?

    How many new cool applications are being developed lately?

    How many developers are excited about “Gnome tecnologies”?

    How much time takes to start a very simple application? Even if written in a dynamic language like Python.

    How much time the developer must waste connecting signals, adding UI Manager, figure out how to connect its custom widgets and so on?

    For instance, we have Gtk UI Manager. But, it must be written in code because the UI designer doesn’t support UI Manager. Also, libglade doesn’t support UI Manager.

    Gazpacho has some support for UI Manager, but it has its problems and doesn’t have the same support for the same things as Glade.

    So, we can say “we offer to developers different choices”. But, more accurate will be “we offer to developers different incomplete choices”.

    We stopped to offer high level widgets that allow to developers to say “To start just I can plug this and this and its done”.

    Developing applications with Gnome must be fun!

    So, I wonder: How fun is start and Gnome application from scratch?

    We have a plaftorm good enough for ourselves, but it is not ready for conquest the world.

    (ok, we have limited man/hour resources. But that’s not the point).

  11. Soeren A. Says:

    “So what happened? There are two plausible explanations:”

    How about “GTK just didn’t fit the requirements”? GTK’s tools are fine in my opinion and Openmoko’s project management wasn’t all that bad either. However, GTK’s utterly limited theming abilities along with bad performance on embedded hardware are the culprits in my opinion.
    Mobile interfaces *need* to be snappy and have almost instantenous responses, which GTK didn’t provide for Openmoko – unfortunately.

    Thus, instead of making things even slower by promoting Java, I’d suggest focusing on making GTK truly themeable and be faster overall. Example: no one I talked to could tell me how to prevent GTK from redrawing all visible UI elements while I was adding UI elements in code. The result was that the entire UI was dynamically adapted and redrawn for every single UI element I added, making the entire app take ages to load.

  12. Steve Says:

    GNOME Mobile? now that is something I would like to see.

    ________________
    http://www.FreeOpenMoko.com

  13. Dave Neary Says:

    @Alan Wallcraft: iRex is a nice example of what I called a niche single-use device – it’s a good eBoox reader, but is only an eBook reader.

    @Soeren A: Doesn’t “tool doesn’t fit requirement” fit into “Bad tools”? And partly into “Bad workmen” (for choosing that tool)?

    @gpoo: I think you’re asking the right questions, and the answers probably aren’t obvious. We need a list of changes we can make to improve things, rather than “it’s not fun” or “it’s too hard”, but that list isn’t easy to come by.