Summary of GNOME Mobile GUADEC BOF

[Dave Neary <bolsh gnome org>]

Hi all,

Still clearing up loose GUADEC ends while on my way to OSCon.

I don't have my notes with me right now, so this is from memory. If I
get something wrong, or miss something important, please someone else
post corrections/improvements. I may even be correcting myself next week ;)

I don't remember names for all the attendees off the top of my head -
I'll add this when I get home on the 28th.

We had a short agenda, and we managed to stick to it pretty well.

1. Austin Actions: Status & next steps
 - Technical
 - Non-technical

2. Recent news around the GNOME platform (specifically: Nokia buys
Trolltech, sets up Symbian Foundation, OpenMoko moves away from GTK+ as
primary platform, OLPC appears to be having problems delivering software
product to required quality on-time, moves towards shipping windows on XO)

Ross gave a status report on the short term technical goals, which was
excellent, to the point, seemed to be what people are expecting, and got
no questions.

There is a jhbuild module set for GNOME Mobile 2.24, which has been in
the nightly build system for some time. Ross reckons that we can have a
Poky image available with the release set at 2.24, as well as an Ubuntu
Mobile VM image. Other GNOME Mobile based VM images are welcome, the
goal is to provide a variety of platforms that people can play with, and
develop against. Having something concrete like this will go a long way
to making GNOME Mobile seem more real to people.

We didn't discuss the more weighty issue of a mobile roadmap, areas of
collaboration, or attacking key features that we identified in Austin as
needing love. Frankly, I think that is the kind of thing that could
happen on this list.

Non-technical actions from Austin is a less rosy story. The website
still hasn't been updated, we don't have a list of GNOME Mobile
participants up there (even though the list exists now), and we haven't
moved any further on the GNOME Mobile badging scheme.

Yet again, we had a "What is GNOME Mobile? Who is it for?" discussion. I
remember one sound-bite in particular from Mark Shuttleworth: "Right now
we can aim wherever we like, but we're not holding a very big gun". It
was underlined that from the point of view of participants, not much is
happening in GNOME Mobile, thus people are reluctant to invest in it
(vicious circle, anyone?). I would like to point out that lots is
happening around GNOME in the mobile world, but GNOME Mobile as a
communication channel and forum for collaboration among participants
hasn't really lived up to expectations.

To get past this, there was some agreement that we need to work on both
image and substance. We need to refresh our web presence, add more meat
on the bones, publicise GNOME Mobile stories - successful device
time-to-market and cost-to-market stories. The idea of having a GNOME
Mobile special edition of the Linux Journal came up, and several
participants agreed to write articles for it - I recall Rob McQueen &
Paul Cooper in particular agreeing to do human interest "Collabora &
GNOME Mobile" and "OpenedHand and GNOME Mobile" stories (perhaps about
the companies, or perhaps about successful client stories that they
might have).

In addition, to show to people that GNOME Mobile is worth engaging, we
probably need a good collaboration story to tell, a technology win which
came out of the initiative. More on that later...


The third part of the meeting was a fairly wide-ranging discussion on
GNOME's place in the industry, particularly in light of recent "bad
press" (or, at least, potential bad press). Chris Blizzard suggested
that if Nokia were to change its licencing policy for QT that GNOME
would then have some hard choices to make - a business friendly QT
licence could help them supercede GTK+ as the toolkit of choice (Mark
Shuttleworth supported this & added to it that he felt it would be
entirely possible to have a GNOME experience built on QT if the
licencing were right).

There seemed to be some agreement that individually, OLPC and OpenMoko
were both cases of projects which had larger problems than the toolkit -
ever-changing direction, difficult competitive environment, ill-defined
problem set - which were working against them. A few people (myself
included, and Mark Shuttleworth) said that while it was tempting to
discount these stories, that it would be a missed opportunity of taking
a long hard look at the GNOME platform, and seeing what problems people
are having with it, and work to fix it.

Unfortunately (from my point of view) we didn't get a huge amount of
traction on that discussion. Something to take up with the GNOME ISV
community at large, perhaps? The basis for a roadmap for the platform?

(Aside: From a personal point of view, laying things out with Glade is a
nightmare - GtkHBoxes inside VBoxes inside HBoxes... a nice flexible
canvas with some HIG aware development tools for placing widgets like
they have on the Mac would be wonderful. I know GObject used to hurt my
brain too back in the day. But I haven't done enough development with
the GNOME platform to comment on the ease of use of things like
Telepathy, GStreamer, D-Bus, GConf, GTK+, ...)

One thing that was said is that the bindings (Python, Mono & Java were
mentioned explicitly) suffer from leaky abstractions, and have both
performance & quality issues. And a lack of binding-specific
documentation. Currently you have to guess the names of methods &
classes from the C namespace, more or less.

On a positive note: it was reiterated that the GNOME platform has been
extremely successful in being adopted - it's part of maemo, Ubuntu
Mobile, LiMo, moblin, ALP, and is already being used and deployed in
devices by a wide range of companies including Vernier, iRex, Garmin,
Nokia, OpenMoko, OLPC (who haven't abandoned Sugar), and others I'm
forgetting. We have an opportunity to communicate about GNOME Mobile
being the common platform for a whole range of devices and initiatives,
to show the world (press & application developers) that mobile linux
isn't as fragmented as it might appear. And we have some new
technologies like Clutter arriving which have tremendous potential to
provide a rich 2.5D and 3D application framework to developers.

In terms of concrete "stuff" that came out of the meeting:

Lefty will get access to the website, and will help update it.
Dave, Paul, Rob, and Rob (at least - there are others too) will contact
their clients & possible clients to communicate about GNOME Mobile, get
new participants, collect success stories we can use.

Plan to work on a GNOME (Mobile) Journal edition to coincide with the
GNOME Mobile release set. This is more than release notes - we want to
show how GNOME Mobile is being used, and how it's being improved,
through compelling, user-significant, stories.

That's all from memory. As I said, updates & improvements greatly
appreciated.

One more thing - I will mail separately about this, but to help provide
that technical win I mentioned, Nokia have offered to host (alongside
the Maemo Summit) a GNOME Mobile hackfest in Berlin, on the two days
following OSiM World, the 19th and 20th of September. This happens the
weekend before the final GNOME 2.24 release, which also gives us an
opportunity to have a GNOME Mobile release party a couple of days early ;)

To have a successful hackfest, you need:
 - A tightly defined agenda (one or two problems to solve - see
introspection in GTK+ as a good example from the GTK+ summit)
 - The right people present
 - Focus on results, few distractions (what comes out of the meeting at
the end?)

It mighht be useful, if we're working on API, to have some application
developers consuming the API present, as well as the people working on
the library itself. It might also be useful to have someone from the
layer below the library there. One example that comes to mind (and which
was suggested by Quim) is GStreamer. It would make sense to have at
least one or two GStreamer "consumers" there, and perhaps someone from
the ALSA or PulseAudio projects too.

So - there lies the idea - gather a small group of people, focussed on a
specific problem that is fixable (or, at least, which can be worked to a
proof-of-concept design & code) after a 2 day hackfest. Ideas, suggestions?

Cheers,
Dave.

-- 
Dave Neary
GNOME Foundation member
bolsh gnome org