Be the signal

Note: This post is part six of a series of thoughts on the relationship between Canonical and GNOME.

I was incredibly tempted to entitle this post, “Pushing your turds into GNOME’s immaculate and exalted vessel”, but thought it might be taken seriously. After all, everyone knows GNOME developers believe they’re inviolably perfect, right? 🙂

All Changes Great and Small

Software development is an immature branch of the discipline known as “change management”. The weapons are different, but the war is the same: Improvement generally requires change, but change involves investment and risk. So we invent convoluted schemes, tools and rituals to make change easy, but not dangerous.

FLOSS projects in particular must make change easy, because people are their most valuable resource, and change is the process through which new contributors become familiar with a project and subsequently — hopefully! — become involved.

It’s pretty simple: Contributors are your participants. If there is nothing to contribute, you have no participants. If you have no participants, you barely even have a project, let alone co-development! For FLOSS projects, change has an incentive beyond improving the software.

Readability is the key to creating code that others will use. Because in the end? We can scale silicon, but carbon? People are much harder to scale.

— Brian Aker, Drizzle goes GA, From “What If”, to “What has”

Small Changes

By small, I don’t mean insignificant. A one-line patch can fix a crasher, resolve a terribly hard-to-find heisenbug, or launch a project-wide flame-war over its correctness. By small I refer to the risk/reward ratio, which will affect how easy it is to make a decision — with both social and technical influence — about the change.

Bug fixes: In the olden days, new contributors would file a bug and attach their patch, or send a patch to the project mailing list. In modern times, a new contributor would raise a merge request in the code review system from their own distributed revision control branch. The maintainer usually has a straightforward decision as to whether the bug fix is correct and appropriate… or not.

(Despite using distributed revision control, GNOME still mostly lives in the olden days, so patches are sometimes left to rot without review.)

Features: A larger change, adding functionality or behaviour. Most of the time these are best discussed with the project maintainer before starting work, as they’re likely to have a good idea about how they’d prefer it to be implemented, or may not want the feature at all.

In GNOME, the maintainer of a module is almost always the “architect” or “manager” of that code, and is responsible for making these decisions. If the maintainer is sceptical of your feature, then you’ll have to do some convincing. Co-development is as much a social endeavour as it is technical!

Settings: What if you want the software to behave one way, but your friend wants it to behave differently? Surely that’s reason enough to add a switch to choose between them? After all, software can do anything, and computers should adapt to our needs, right?

Most GNOME developers will look at this problem differently. You may occasionally hear the phrase “options are bad”, but that’s shorthand for a deeper philosophy: What if we could make that problem simply disappear, rendering the choice itself meaningless?

Switches like this increase the complexity of the code and the “surface area” of software machinery exposed to users. If we, as software developers (and UX designers), think a bit harder about the problem before foisting it on users, perhaps we can solve it… and if we get it wrong, it’s easy to fix.

That’s why “adding an option” involves more friction in the GNOME community that you are likely to find elsewhere. Of course, some developers hate that approach. Some users hate that approach. But others find it truly inspiring.

Applications or utilities: If you want to contribute an entirely new piece of software to GNOME, it must go through the Release Team’s module proposal process. As long as you meet the long list of conventions and standards upheld by the GNOME community, and your software is relevant, you’re pretty likely to get in. As of GNOME 3.0, it’s even easier, because the Release Team has split out recommended applications from the core components of the desktop user experience — panels, window manager, file manager, etc.

Large Changes

Cross-module changes: Sometimes you can’t surface a feature within the scope of a single module, so you have to convince a number of maintainers to not only accept the feature, but if required, agree on a way of sharing necessary information between their modules, and accepting the maintenance load of making sure cross-module integration continues to work.

A good example of this kind of change is the list of folders that are remembered and shown throughout your GNOME experience — in the “Places” menu in the panel, the sidebar of the file manager, in standard file dialogues, etc.

New APIs: Providing a new capability throughout GNOME, and perhaps to third party developers, usually means adding a function to an existing platform library, or for more involved capabilities, you might even need to write your own shared library and convince developers to use it.

Lots of mistakes can be made when it comes to APIs and shared libraries, and because the GNOME community wishes to provide a consistent, reliable platform, it is an area that involves a lot of rules and policies. Number one on that list is the commitment to API/ABI compatibility throughout GTK+ and GNOME’s major version releases. GTK+ 3.x involves the first significant, platform-wide API/ABI break in 8 years!

New APIs will often be adopted as copy’n’paste code from incubator modules like libegg. So rather than make new library developers worry about API/ABI compatibility during development, users of the new API can just copy the code. Once everyone’s happy, it can be deployed into an existing platform library (such as GTK+), or a new shared library.

Proposing a new shared library can be arduous. For the last 8 years, developers have been naturally wary of expanding the (sprawling) surface area of the developer platform, so your library would have to be incredibly convincing to begin with… even then, perhaps the new API would make more sense in an existing platform library.

Plus, it won’t land in the API/ABI stable developer platform or external dependency list straight away: That’s a very serious commitment. The community will need a chance to get comfy with the new API before taking any marriage vows!

User experience changes: Making GNOME itself — the fundamental user experience of the product — look or work differently can be the most challenging proposal of all.

On one hand, it’s an intensely social process, because you’ll probably find yourself trying to convince the entire project to accept your change. On the other hand, it is a technical issue, but very different to fixing a bug or adopting a library: Now you’re invoking huge questions about user experience, acceptance testing, user stories, who GNOME is for… if you don’t have the technical skills to make good decisions on all of those fronts, you’re in for a rough ride.

You just thought it might be nice to have two panels instead of one. Then everyone got all existential. Welcome to GNOME. 🙂

The Inevitable Linux Kernel Comparison

All of that sounds terribly difficult. “Why can’t GNOME be more like the Linux kernel?”

They’re not really that different. Two big ones: Linux ships as a single tarball, GNOME’s user interface has quite a different audience profile.

Linux still has plenty of components and subsystems, maintained by different people. A hardware driver might be a nicely contained chunk of work, but if you want to change the SCSI subsystem, you’ll have to convince a few people along the way. Want to make a big change? Ask for advice (a “Request For Comments”) before carpet-bombing lkml with your patch-set. Thoroughly unsurprising stuff for large-scale co-development.

Believe it or not, kernel maintainers are getting the “options are bad” religion. Yes, even in the kernel, settings and magic numbers can increase complexity of code and the “surface area” of software machinery for users — systems administrators — to deal with. Years after calling my friends and I “interface nazis”, Linus questions whether or not big chunks of the Linux kernel can “just work”. 🙂

You’ll definitely hear some developers whine that Linux doesn’t have stable internal APIs (one clear advantage to working in a flexible, monolithic codebase), but don’t get caught breaking the userland API/ABI…!

“We’re not so different, you and I.”

Technical Leadership

Every now and then, and quite a bit over the last week, someone will offer up the prize furphy that “GNOME does not have technical leadership“. This is poppycock, pure and simple.

It might not be immediately obvious. It might not be particularly efficient. It might not be convenient. But you know it exists… if only because trying to sneak past it will cause all hell to break loose.

What is it? A meritocracy, where legitimacy and influence is derived from contribution.

Becoming a Leader

Training and growing technical leaders in GNOME is not unlike other open, meritocratic, co-developing FLOSS projects.

You send a little patch, perhaps to fix a bug, and the maintainer accepts and commits the change. Encouraged, you fix more bugs, implement some minor features and send a patch for each change.

Eventually, you send enough good stuff that the maintainer wants you to commit directly (the lazy maintainer principle in action). You request an account, and the maintainer backs you up. Now you can commit to all the things!

Your changes still have to be accepted by the maintainer, but now she can ask you to commit directly instead of sending patches or merge requests.

(You submit a few changes elsewhere, and the other maintainers trust you that little bit more, because you already have an account on the GNOME revision control platform!)

After a while, the maintainer sees that you have a good understanding of the code, and in a moment of brilliant laziness says, “Hey, you don’t need me to review your changes now, I trust you.” Of course, you still talk about more controversial or difficult changes prior to committing.

Eventually you work well enough as a team, you’re blessed as a co-maintainer, and five minutes later the original maintainer announces she’s travelling around the world on a donkey. So now it’s up to you, co-maintainer for five whole minutes. Time to find some more contributors…

Maintainers

If there were an Arthurian round table of technical leadership in GNOME, it would be the motley group of developers who maintain all the modules in the various release sets: The Maintainers (it’s not a band).

But there are a few round tables — maintainers of the developer platform, the core user experience, the language bindings, etc. Each has more sway in certain decisions: Should libfoo be in the platform? Should gnome-baz be integrated into the default desktop UX? These are project-wide decisions for which maintainers often wield increased influence.

Day-to-day, a maintainer’s influence is generally limited to their own software module, defining the vision and architectural approach, deciding which patches to accept, etc.

GNOME Foundation

Founded in 2000, the GNOME Foundation was designed to serve the project by doing all the boring things — keep money, manage relationships, etc. It was also granted the task of defining GNOME as a product, largely because there were arguments about it at the time, and the big companies joining the community desired… clarity and stability.

Today, the democratically elected directors of the GNOME Foundation essentially form a community council. The power to “set the technical direction” was delegated to a newly-defined Release Team in 2001. But if you want to “deal with GNOME”, you speak to the Foundation. If there is a disagreement in the community, you go to the Foundation Board for mediation.

The GNOME Foundation Board of Directors is still called upon when big problems need solving, but does not play a role in the day-to-day technical decisions of the project.

Release Team

The Release Team maintains GNOME’s six-month time-based release process, and is responsible for defining the product in a broad sense, and ensuring that it continues to meet community-defined maintenance policies (stuff like API/ABI compatibility, where work is done, etc).

Like the maintainers of individual modules, it is not a democratically elected group. If a member should leave, the team will choose a successor — amusingly, this has often been done by following the advice of the departing member!

It may not be a democratically representative group, but because the Release Team is delegated by the GNOME Foundation to serve the project — not the other way around! –the developer community could easily overturn a bad decision by the Release Team. If the situation warranted it, the community could even ask the GNOME Foundation to replace the Release Team!

I can’t quite imagine that ever happening though, because members of the Release Team know that they serve the desires of the community, and practically every decision is made on the basis that it properly represents those desires.

Difficult Decisions

Sometimes the GNOME community has found itself unable to make a particular decision at all. This is less of a reflection of GNOME’s decision-making capacity in general — or lack of technical leadership to do so — than it is of the impossible decisions themselves.

For instance, despite the many years of flame-wars and criticism, there has never been a clear answer about Mono. The GNOME community doesn’t “support” it, but in large part, doesn’t want to shun it, either.

That was an impossible decision because it meant telling members of the community — friends! brothers and sisters in freedom! — that they were not wanted. For all the legal and technical arguments in the world, the haters never understood this simple problem.

Mono is still a special case. It’s still in limbo. Some decisions are impossible to make.

GNOME 3.0

How does the decision to take on a huge new release effort happen in a community that supposedly “has no technical leadership”?

What happens after that decision is made is an entirely different question — a whole community of individuals contributes a huge amount of work! — but what about the decision to make it happen in the first place?

A meritocratic project doesn’t make a decision like that at the drop of a hat. It would require lots of agitation and convincing, plenty of groundwork, heaps of preparation.

Remember, the GNOME community had been talking about GNOME 3.0 as a concept since at least 2005!

I believe we can credit much of that agitation, groundwork and preparation to the sheer dedication of a single person. It was, without a doubt, an incredible expression of open, meritocratic, technical leadership. It moved the needle.

He began, like everyone, without any involvement in GNOME at all. Today, he is what I would describe as the architect and father of GNOME 3.0.

He would ever so predictably deflect that praise on to the entire community who rallied around him.

Thank you, Vincent Untz.

Disclosure: I enjoyed working for Canonical from 2004-2006, and although I have occasionally been accused of shilling for Ubuntu since then, I suspect few at Canonical would regard me as their #1 fan at the moment. I haven’t been involved in GNOME for quite some time, and generally try to avoid thinking about it very often.

Note: This post is part five of a series of thoughts on the relationship between Canonical and GNOME.

Every now and then, the inexorable passage of time is rudely interrupted, and the natural path of history is changed before our very eyes. It is incredibly rare, I grant you, and most often involves a weapon of some description, but it happens.

In our story, that “moment” is the week starting Monday October 6, 2008.

Those of you who invest in the stock market will probably double-take, and believe I’m referring to Black Week, the stock market crash of 2008. Thankfully, no.

By curious coincidence, one of the most defining weeks in the entire history of GNOME — and a turning point for Canonical’s relationship with the project — happened to take place during a week-long stock market catastrophe.

But there’s a little prehistory to cover before we get there…

Prehistory

May 30, 2005: My presentation about GNOME 3.0 at GUADEC, now infamous for the attempt to recast growing discussion about GNOME 3.0 as Project Topaz — Three Point Zero — in order to avoid thinking in terms of version numbers, and… 10×10. 🙂

December 23, 2006: Conversation about GNOME 3.0 continues, to the point that a clarification is required: “There are no plans for a GNOME 3.0 release at this time.”

January 15-20, 2007: linux.conf.au 2007 in Sydney. The hottest piece of hardware at the conference is the OLPC XO. The Collabora guys run full-screen video chats between their OLPCs and laptops! The conference bag, designed in late 2006, is smaller than a laptop bag, but — just quietly — the perfect fit for a 12″ laptop.

June 7, 2007: Clearly inspired by the low-cost OLPC, ASUS announces the EeePC 701 at COMPUTEX. It is immediately blessed as “revolutionary”. It ships in October 2007 and as every other vendor follows, the EeePC defines the “netbook” market. All 800 lca2007 attendees look at their conference bag with fresh eyes… and fetch their credit cards. 🙂

April 15, 2008: Having facilitated a successful GTK+ hackfest, the GNOME Foundation Board decides this is a highly productive use of funds, and asks for more hackfest ideas.

June 3, 2008: Nine months after the EeePC ships, Canonical announces the Ubuntu Netbook Remix user interface and custom distribution for OEMs. Mark Shuttleworth writes about the release and says, “directly or indirectly Canonical will help to bring that innovation to KDE and GNOME and hence to the wider Linux ecosystem.”

❧

Permit me, for a moment, to effusively praise UNR. Although the design was not wildly different to other netbook user interfaces shipping at the time, the simple composition and execution were brilliant.

One standard GNOME Panel at the top of the screen. In the top left corner, a button to hide everything and show the full-screen launcher. Next to it was a window switching applet which made your windows look and work like tabs. Application windows were automagically maximised. Very little vertical space wasted.

From a GNOME perspective, the UI changes were tightly contained: Two new panel applets, a full-screen launcher, and a little daemon to do the windows maximisation.

I absolutely loved it back then (the screenshot below is from July 2008), and I still use some components of UNR on my laptops to this day!

Sadly, UNR was also Canonical’s first major upstream collaboration blunder.

None of the UNR components were proposed for inclusion in GNOME. No Canonical developer approached the GNOME community to say, “Hey, we built this cool netbook stuff, maybe it could form the basis of a new UI profile for GNOME!”

The UNR UX was built by Canonical in private, largely because it was commissioned by a third party. Most Open Source communities prefer that feature design be done “out in the open”. Bit of a problem there, but not insurmountable.

GNOME developers have a long history of dealing with corporate contributors and commercial realities such as this, so a quick explanation of the situation and a plan to transition to a community-developed model would most likely sort things out.

After all, the individual UNR components were small, simple, tightly defined and easily consumable. They weren’t libraries, they didn’t require API changes. Put together with standard GNOME components, they redefined the user experience… and beautifully so!

None of it happened.

❧

June 11, 2008: Greg Kroah-Hartman gives a Google TechTalk during which he claims that “Canonical does not give back to the community”.

Late June, 2008: The “Desktop Experience” team is created within Canonical, with Ted Gould and Mirco Mueller as the first members. The changes are more official as of July 3.

July 7-12, 2008: GUADEC in Istanbul, Turkey. Federico Mena-Quintero introduces Document-centric GNOME to much excitement and interest. A seed is planted for the future…

Recognising the growing desire to renew the GNOME developer platform by accepting the first API/ABI break in 6 years, and to encourage long term planning for future changes, the release team announce that the regular March 2010 release would simply be blessed as GNOME 3.0. The news is famously revealed as GNOME 2.30 = GNOME 3.0.

Vincent Untz, Federico Mena-Quintero and Owen Taylor approach the Foundation Board to suggest hosting a GNOME user experience hackfest.

July 30, 2008: Ted Gould blogs about putting a menu at the top right of the screen (replacing the big “off” button in Ubuntu’s panel), with IM presence, user switching and session management items in it. Work on a modified fast-user-switch-applet (FUSA) had already started privately in early July.

August 27, 2008: The modified FUSA package arrives in the Ubuntu development release, Intrepid.

September 10, 2008: Mark Shuttleworth announces the formation of the Canonical design and user experience team, saying:

We focus most of our effort on integration. Our competitors turn that into “Canonical doesn’t contribute” but it’s more accurate to say we measure our contribution in the effectiveness with which we get the latest stable work of upstream, with security maintenance, to the widest possible audience for testing and love. To my mind, that’s a huge contribution.

Increasingly, though, Canonical is in a position to drive real change in the software that is part of Ubuntu. If we just showed up with pictures and prototypes and asked people to shape their projects differently, I can’t imagine that being well received! So we are also hiring a team who will work on X, OpenGL, Gtk, Qt, GNOME and KDE, with a view to doing some of the heavy lifting required to turn those desktop experience ideas into reality.

Mark’s post does not go unnoticed. Although the GNOME community is understandably wary, it is widely regarded as an indication that Canonical would build their capacity to contribute upstream, particularly due to the reference to Greg K-H’s criticism that “Canonical doesn’t contribute”. The GNOME dudes employed by Canonical are as excited by the prospect as everyone else.

The very first commenter asks if Canonical would learn from the mistakes of the past, and opt to work closely with upstream projects. Mark responds, concluding with:

One can’t be an effective core contributor in hundreds of projects, so in a real sense it is “us and upstream”, as you describe it. The question is whether we can build a productive relationship, not whether we can be totally absorbed.

The commenter is… not totally convinced by Mark’s answer. He gets no response.

September 17, 2008: Greg Kroah-Hartman launches what can only be described as an ambush on Canonical during his keynote at the Linux Plumbers Conference. An entire hour is dedicated to support his conclusion that:

Canonical does not contribute to Linux plumbing. Companies who rely on Linux must contribute, or they are at the whim of others. Developers who are not allowed to contribute to Linux should change jobs.

This time, Matt Zimmerman replies, noting that while Ubuntu has lots of users, it simply does not have a lot of developers working on the kernel, let alone contributing upstream! He concludes:

To present his commentary in this way is indefensible.  LPC is promoted as a productive community event aimed at solving problems, and Greg has used his voice as a speaker to promote a much less honorable agenda.

(My view: Greg was wrong to present his concerns the way he did. His expectations were incredibly high for a four-year-old company with no kernel engineers. Yes, it would have been nice if Canonical contributed more, but if they don’t have the capacity to do so? One aspect of Greg’s criticism that was 100% spot-on was his implied concern about the free-rider problem.)

Update: So if you think these posts are just about me being anti-Canonical, know that in this section, I have been too fair… worse, I ought to know that Canonical had kernel engineers in 2008, because it did before I left in mid-2006! Thanks to Greg K-H for pulling me up in the comments.

That said, the kernel engineers were doing pretty much the same what Canonical was doing with GNOME prior to the DX team: Pulling together a kernel for each release, fixing bugs, minor integration work, etc. Greg’s expectation that Canonical contribute by way of major module maintenance and new code does not align with the company strategy, for better or worse.

September 18, 2008: Ted Gould blogs about the ongoing modified FUSA work in Right side status.

September 24, 2008: GNOME 2.24 ships. The new development series and module proposal period begins. Even though there are some technical barriers to contributing the modified FUSA directly, no attempt is made to bring those changes to the GNOME community in any form.

Had Canonical’s FUSA work been done upstream from the beginning, Ubuntu may not have had to swallow the GDM version skew it required. Ubuntu didn’t adopt the “new” GDM until Ubuntu 9.10.

(I half remember other issues delaying adoption of the new GDM as well, perhaps things like LTSP, but couldn’t find any documentation to jog my memory.)

October 1, 2008: Based on the announcement of the Canonical Desktop Experience Team, Vincent Untz reaches out to Mark Shuttleworth to invite Canonical to participate directly in GNOME 3.0 development.

The GNOME User Experience Hackfest 2008

October 6-10, 2008: A small group of GNOME technical and design leaders meet prior to the annual Boston Summit, to fundamentally re-imagine the GNOME user experience. It is arranged and led by Owen Taylor, Federico Mena-Quintero and Vincent Untz.

Key GNOME designers and developers are invited, including volunteers and employees of most contributing organisations. A couple of people decide to invite themselves. There is only one non-designer, non-developer, non-GNOME-participant, company CEO present.

❧

I will point out the peculiar circumstance of Red Hat’s desktop team. They just wound up the failed Online Desktop initiative. Remember Mugshot and Big Board?

They were Red Hat designed and developed projects, with some intent to be relevant to GNOME, but… even documented and developed on GNOME infrastructure, they… well, just weren’t.

By October 2008, the Red Hat desktop team had realised that their approach to planting the seeds of open innovation was not working. Closed ideation and design didn’t lead to community adoption. Such an ambitious project needed broad buy-in from the beginning.

Besides, GNOME clearly needed love, and was particularly receptive thanks to Vincent Untz’s leadership on GNOME 3.0. The Red Hat desktop team decided to refocus, spend time on GNOME itself, and hopefully by doing so, encourage other stakeholders.

❧

Everyone has ideas. No one arrives with a fully conceived plan, intending to impose their singular vision on GNOME. The open, group-defined agenda doesn’t suit such a dastardly plan, anyway.

The first two days are dedicated to “idea generation”, general discussion, and mind-expanding presentations. The rest of the week is dedicated to polishing the ideas, and turning them into something useful to GNOME. Vincent Untz writes on the final day:

So, since Wednesday, we’re working on the three topics that emerged during the first day: desktop shell, access to documents, and adding effects/animation to the desktop experience.

The output is fantastic. Each group produces a wiki page describing their discussions, all of which are detailed, thoughtful, and met with excitement:

• Effects and animations
• Desktop widgets (rethinking what we call applets in GNOME 2)
• Window management … and more (the latter includes awesome mockups)
• File management

It is understood that Red Hat will contribute developers to the effort. Other stakeholder companies are encouraged to invest resources.

Reports & Reactions

Neil Patel posts mockups of the desktop shell to the wiki page which describes the design.

Vincent Untz reports at length on the desktop shell sessions, saying:

I’m convinced that we should start prototyping those ideas so we can play with them, and see what feels good and what feels wrong. It will need testing. We will make errors. And maybe it’s a dead-end. But many people really liked this and I believe we reached consensus during the hackfest that we wanted to see this in action.

Federico Mena-Quintero writes about the file management sessions, concluding with a note that Seif Lotfy had been working on a journal in Mayanna, a maintained fork of the abandoned Gimmie project… “Seif and I have been talking about how to proceed.” By the end of October, the GNOME Journal project is born. Today it is known as Zeitgeist. 🙂

Jon McCann is excited about the outcome, and gives credit to Ted Gould and “the Ubuntu folks” for ideas such as showing presence, user switching and session termination actions in a panel menu (the modified FUSA applet work). He posts some of the sketches he drew during the hackfest.

Mark Shuttleworth writes, “The GNOME user experience hackfest in Boston was a great way to spend the worst week in Wall St history!”

Though there wasn’t a lot of hacking, there was a LOT of discussion, and we covered a lot of ground. There were at least 7 Canonical folks there, so it was a bit of a mini-sprint and a nice opportunity to meet the team at the same time. We had great participation from a number of organisations and free spirits, there’s a widespread desire to see GNOME stay on the forefront of usability.

He concludes by emphasising the file management discussions, “At the end of the day, bling is less transformational than a fundamental shift in content management. Kudos to the folks who are driving this!”

After the Show

October 29, 2008: Early private development begins on libindicate, a client library and applet for displaying persistent notifications in the form of a menu. No freedesktop.org specification exists for doing this in a cross-desktop manner.

October 30, 2008: On the cusp of the Ubuntu 8.10 release, Mark Shuttleworth blogs about user switching, presence and session termination in the new FUSA menu. He says:

This work was discussed at UDS in Prague with a number of members of the GNOME community. I was also very glad to see that there’s a lot of support for a tighter, simpler panel at the GNOME hackfest, an idea that we’ve championed.

…

In Jaunty, we’ll likely do some more work on the GNOME panel, building on the GNOME user experience discussions. There was a lot of discussion about locking down the panel more tightly, which we may pursue.

Ubuntu 8.10 ships later that day. At the time of release, both the System menu and FUSA menu display the session termination items. Had this work been done upstream…

October 31, 2008: Owen Taylor tells desktop-devel-list that the first code for the new “gnome-shell” has landed in Subversion:

OK, a little bit of code for gnome-shell now has hit SVN. It doesn’t do anything that interesting yet …. it’s just about caught up to gnome-0.9 or so: a gray rectangle with a clock.

The new project has a wiki page, IRC channel, mailing list and code repo. It’s a thing!

November 10, 2008: A DBus protocol is conceived for communication between the libindicate client library and the applet which displays the menus. It is not based on a freedesktop.org specification.

November 20, 2008: Private development begins on Notify OSD (codename: alsdorf), a replacement for notification-daemon which displays notification “bubbles” based on an unpublished Canonical design specification.

November 24, 2008: The GNOME 2.26 module proposal period closes.

December 5, 2008: Early private development begins on what will ultimately become the messaging and “me” menus, based on libindicate.

December 8-12, 2008: Ubuntu Developer Summit in Mountain View. The notification changes are discussed simply as a matter of integrating the DX team’s work. KDE doesn’t support the (Galago!) freedesktop.org notification spec, which will require more work.

December 11, 2008: Ted Gould writes about showing persistent notifications, without the clutter of notification icons. It is written in the form of an introduction to a new idea:

I think that a reasonable approach is to consolidate them into what I’m coining as a “messaging indicator.” The goal of the messaging indicator is provide a simple and clean way for messaging apps to provide the notification to the user that other people are trying to talk them while not having to put something in the notification area.

…

Here we’re seeing a IM message coming in. The notification disappears into the messaging icon and the message can be found underneath that icon. Nothing complex, but it allows the user to know that all of their messages are a single tidy place and there is only one graphic required on the panel for all messaging.

Sounds… familiar. 🙂

December 22, 2008: Mark Shuttleworth shares a flash demo of “proposals Canonical’s user experience design and desktop experience engineering teams” introduced at the Ubuntu Developer Summit: Notifications, indicators and alerts, saying:

Experiments are just that – experiments. They may succeed and they may fail. We should judge them carefully, after we have data. We are putting new ideas into the free desktop without ego.

The best ideas, and the best code, will ultimately form part of the digital free software commons and be shared by GNOME, KDE and every distribution.

So, for those folks who were upset that we might ship something other than a GNOME or KDE default, I would ask for your patience and support – we want to contribute new ideas and new code, and that means having some delta which can be used as a basis for discussions about the future direction of upstream.

None of this work is ever contributed upstream.

Revisionism

Since at least July 2010, Mark has made a number of claims about the User Experience Hackfest. They are all roughly of this form:

We had described the work we wanted to do (cleaning up the panel, turning panel icons into menus) to the Gnome Shell designers at the 2008 UX hackfest. McCann denies knowledge today, but it was a clear decision on our part to talk about this work with him at the time, it was reported to me that the conversation had happened, and that we’d received the assurance that such work would be “a valued contribution to the shell”.

My answer to this is very simple: It doesn’t matter in the slightest whether or not this discussion happened. As Mark has said while making similar accusations: “code talks“.

Lots of people come to FLOSS projects and excitedly promise to work on something. The promise is irrelevant. Good communication? Sure. But ultimately, what really matters is whether or not they deliver. I know this intimately because I have been on the giving and receiving end of it.

Only three Canonical-related modules have ever been proposed for inclusion in a GNOME release: evolution-couchdb (for 2.30), simple-scan (3.0) and libappindicator (3.0). Only one of those was related to panel menus — the libappindicator client library, proposed in February 2010, 16 months after Mark’s “commitment” — and it didn’t even include the relevant user interface components!

Each of the chunks of work we’ve taken on: notifications, indicators, the menus, and all the rest, could be valuable to GNOME and has been done with the intent that it be useful to GNOME. Our feeling is that base politics are playing a bigger role in the final decisions than they should, and we’re disgusted that that be the case.

Base politics? Disgusted? None of these things, in a useful form, were ever proposed for inclusion in GNOME. The facts simply do not support Mark’s extraordinary accusations.

Disclosure: I enjoyed working for Canonical from 2004-2006, and although I have occasionally been accused of shilling for Ubuntu since then, I suspect few at Canonical would regard me as their #1 fan at the moment. I haven’t been involved in GNOME for quite some time, and generally try to avoid thinking about it very often.

Note: This post is part three of a series of thoughts on the relationship between Canonical and GNOME.

Tensions rose this week as claims were made and refuted — mostly as comments on blog posts about entirely different issues! — about the collaboration and relationship between Canonical and GNOME.

After actively participating in much of that discussion, Mark Shuttleworth (founder of Canonical and Ubuntu) responded in a strongly-worded blog post on Thursday morning.

He made a range of claims, but in this part of the series I will focus on his response to the release team’s stated reasons for the rejection of libappindicator:

The premier reason given for the rejection of [Unity’s indicator] API’s is a reason that, as best we can tell, has never been used against an external dependency proposal before: “it’s different to Gnome”. At the heart of this statement is something deeper: “it’s competition with an idea someone in Gnome wants to pursue”.

…

Now, I can tell you that I was pretty disgusted with this result.

Please read Mark’s entire post to get a full appreciation for the depth, breadth and consequence of his criticism.

History

The history of “indicators” is quite long, but as that will be covered in the timeline for part four of this series, I will fast-forward to the introduction of libappindicator itself, during the Ubuntu Developer Summit for Lucid Lynx (UDS-Lucid).

November 18, 2009: Application Indicators are discussed at UDS, aiming to replace the notification area and present a single set of menus on the panel for consistency. The KNotificationItem specification is chosen as a basis for the protocol, but “the addition that we’ll need is the ability to define a menu”.

Actions include “develop the application library”, despite the fact that libappindicator development had already begun, privately, one month earlier (first commit: October 13, 2009). To be fair, it was still pretty raw immediately prior to UDS, but work had clearly begun.

December 3, 2009: The Ubuntu DX team’s ApplicationIndicators wiki page is created. One week later it is updated to include a very thorough set of use cases, architecture documents and a porting guide.

December 16, 2009: Canonical developer Ted Gould blogs about libappindicator, links to the StatusNotifier specification.

December 17, 2009: On the XDG mailing list, Canonical developer Aurélien Gâteau proposes the StatusNotifier specification, a reworking of the KNotificationItem spec first introduced as a draft on September 5, 2009.

January 13, 2010: Ted Gould emails GNOME’s desktop-developer-list (DDL) to request feedback on StatusNotifier. This is the first time libappindicator is raised on a GNOME mailing list. It is already too late to propose for inclusion in GNOME 2.30.

A few technical questions are asked about Canonical’s plan to port applications. Concluding the thread, Dan Winship states: “Anyway, we want a menubar-like tray for GNOME Shell too, and the new spec seems like a good plan.”

January 18, 2010: Dan Winship responds to the StatusNotifier proposal, raising his concerns about the specification, spawning a discussion almost exclusively with Aaron Seigo (which I will cover in another post).

(So rereading this, it comes across as kinda harsh, but it wasn’t supposed to be, so just add a “:-)” to the end of every line or something. 🙂

February 6-17, 2010: Canonical developers blog about Application Indicators — including Jorge Castro’s Application Indicator Update, Jono Bacon’s KDE Application Indicators in GNOME and (contractor) Jan Arne Petersen’s Application Indicators — all of which note that patches for application support are already being submitted upstream, ie. GNOME’s Bugzilla.

February 15, 2010: The new module proposals period opens for GNOME 3.0.

February 18, 2010: Colin Walters, a Red Hat developer working on GNOME Shell, raises Canonical’s application indicators work for discussion on DDL.

First, +5000 that this change is being driven by designers, and +1000 that new useful code is being written. There are definite problems being solved here.

His questions revolve around how applications should use it, how it might fit in with the design plans for GNOME Shell, and suggests that it would make sense for the API to live in GTK+ rather than a separate library.

Ted Gould and Jorge Castro participate in the resulting 11 post thread (there was another subthread, but irrelevant to the proposal itself). Matthias Clasen contributes two grumpy points about Canonical’s approach to collaboration (not designing in the open and asking GNOME developers to discuss API issues on the Ayatana list).

Roughly 6 hours after his last post in that thread, Ted Gould proposes libappindicator as an external dependency for GNOME 3.0, strongly emphasising that the discussion focus only on its inclusion as an external dependency. He includes the key question about the library, raised earlier: “Does this fit the the design goals for GNOME Shell?”

Olav Vitters of the release team suggests that question must be answered before the release team can make a decision. Ted replies, “Obviously that’s a question that I can’t answer. Though, one that I’d love an answer and a discussion about.”

A concern is raised about copyright assignment, and there’s a silly little subthread about versions of the GPL (much less likely to be a problem than the CLA).

The meat of the thread is a discussion about libappindicator’s use of GTK+ menu APIs, with suggestions from GTK+ developers for how to improve the libappindicator API.

Discussion peters out, without answers to the fundamental questions, with Ted Gould having sent a total of 5 emails to a 17 post thread. (Cody Russell also contributed, but not about technical issues.)

March & April, 2010: Two and a half months (Feb 19–May 6) pass without a single discussion about libappindicator on any GNOME mailing list.

❧

Intermission! Let’s take a moment to recall Mark Shuttleworth’s comments about why GNOME developers rejected libappindicator:

Much of the language, and much of the decision making I’ve observed within Gnome, is based on the idea that Unity is competition WITH Gnome, rather than WITHIN Gnome.

…

The premier reason given for the rejection of [Unity’s indicator] API’s is a reason that, as best we can tell, has never been used against an external dependency proposal before: “it’s different to Gnome”. At the heart of this statement is something deeper: “it’s competition with an idea someone in Gnome wants to pursue”.

What made this single statement heartbreaking for me to see was that it spoke clearly to the end of one of Gnome’s core values: code talks. Here we had API’s which were real, tested code, with patches to many Gnome apps available, that implemented a spec that had been extensively discussed on FreeDesktop.org. This was real code. Yet it was blocked because someone – a Gnome Shell designer – wanted to explore other ideas, ideas which at the time were not working code at all. There’s been a lot of commentary on that decision. Most recently, Aaron Seigo pointed out that this decision was as much a rejection of cross-desktop standards as it was a rejection of Canonical’s code.

…

It’s also saying that Unity is not “in GNOME”. Clearly, a lot of Unity work depends on the adoption of these API’s for a smooth and well-designed panel experience. So once again, we have a statement that Unity is “competition with Gnome” and not “competition within Gnome”.

Intermission over.

❧

May 6, 2010: Last call for comments on module proposals. Dan Winship, a Red Hat developer working on GNOME Shell, replies to the libappindicator proposal with the final word on its relevance to the new shell:

The system status area needs numerous features that aren’t available in libappindicator […] so libappindicator will not be useful here.

As for the trayicons in the message tray […] the StatusNotifier protocol that the appindicator work is built on is just… designed to solve some problem other than ours. I still think we don’t want libappindicator.

So while Dan doesn’t think libappindicator fits with GNOME Shell’s system status or notification goals, he doesn’t close the door entirely to StatusNotifier/dbusmenu (the XDG protocol guts wrapped by libappindicator):

And at any rate, since gdbus will be landing soon, if we did want to support the StatusNotifier/dbusmenu protocol, we could just add that to GtkTrayIcon now.

Ted Gould replies, “Not to criticize your decision, but just to correct a couple of factual details in your e-mail”, noting that dbusmenu is included in KDE and the StatusNotifier spec, and that libappindicator would be ported to gdbus soon. He doesn’t object to Dan’s decision. There is no further discussion.

May 10, 2010: Mark Shuttleworth reveals the Unity netbook user experience to the world during his opening “keynote” at UDS Maverick, and writes about it later that day:

Unity and Gnome Shell are complementary for the Gnome Project. While Gnome Shell presents an expansive view of how people work in complex environments with multiple simultaneous activities, Unity is designed to address the other end of the spectrum, where people are focused on doing one thing at any given time.

May 16, 2010: The GNOME release team meets, and based on the feedback received, decides to reject libappindicator for GNOME 3.0.

June 2, 2010: The release team announces new module decisions for GNOME 3.0, stating the reasons why libappindicator is rejected as an external dependency.

No Canonical developers reply.

Excluding vala-list discussions about wrapping the API, there is a grand total of five pages of Google results for “libappindicator” in the GNOME list archives.

Understanding the decision

Mark is not a day-to-day participant in the GNOME community (he does run a company, after all), so it’s easy to understand why he has so misunderstood the process and motivations of the community — through the lens of the release team’s rejection reasons.

Let’s go through them:

• it doesn’t integrate with gnome-shell

I hope I have demonstrated absolutely clearly in the timeline above that libappindicator was not rejected due to a sense of “competition” between Unity and GNOME Shell: The key advice to the release team was given four days before Unity was unveiled.

• probably depends on GtkApplication, and would need integration in GTK+ itself

Unfortunately, this point is badly written, but it’s related to the suggestion that the API should actually be in GTK+ rather than a separate library. It demonstrates that while the library — conceived and designed without technical or strategic advice from the GNOME community — was rejected, the ideas behind it were not. Mailing list discussions reflected the same view, as shown above.

It’s important to recognise that this is not the behaviour you would expect of those who would discriminate against Canonical, or who had already made up their minds a long time ago.

• we wished there was some constructive discussion around it, pushed by the libappindicator developers; but it didn’t happen

Mark’s response to this was, “We made the proposal, it was rejected.” Well, yes… but keep in mind that he is quoting the rejection itself! 🙂

I can tell you that the people who worked on the proposal consider themselves Gnome people, and they feel they did what was required, and stopped when it was clear they were not going to be accepted. I’ve had people point to this bullet and say “you should have pushed harder”.

I believe the timeline above clearly demonstrates that Canonical did not do “what was required”. Unpaid volunteers regularly do more to get their work into GNOME than Canonical did in this case. I can barely describe how little effort was invested pursuing this proposal.

Ted Gould is not at fault, by the way. If Canonical wanted it done, it could have assigned different people to the task, more people to the task, or anyone at all during March and April.

The flip side to this is that Aurélien Gâteau engaged with the KDE community early and often in his work to update specifications to reflect Canonical requirements, bring in dbusmenu support, etc. I don’t believe the key difference here is between GNOME and KDE, it is in Canonical’s approach to engagement, and its commitment of developers to the task.

• there’s nothing in GNOME needing it.

Mark’s response:

This is a very interesting comment. It’s saying “no Gnome apps have used these API’s”. But the Gnome apps in question were looking to this very process for approval of their desire to use the API’s. You cannot have a process to pre-approve API’s, then decline to do so because “nobody has used the API’s which are not yet approved”.

This is a simple misunderstanding: No process exists to “pre-approve APIs”. So that’s not the process libappindicator was submitted to… or rejected by.

Any GNOME module can add an optional (or “soft”) build dependency at any time. Jorge, Jono and Jan even blogged about libappindicator support patches being sent upstream… prior to the proposal!

An “external dependency” in GNOME release parlance describes a particular version of a library that is not maintained by the GNOME community, but acceptable as a required (or “hard”) dependency. DBus is a good example: it’s not a GNOME project, but we can rely on a particular version’s API, ABI and protocol being consistent.

The irony is: libappindicator did not need to be listed as an external dependency for Mark to have achieved his goals. Canonical needn’t have engaged at all! (Sure, that would have created all sorts of different problems…)

Conclusion

Mark’s extraordinary criticisms were made without understanding the process, without understanding the quotes he was using as evidence, and frankly, without understanding the GNOME community’s motivations or intentions.

Key points:

• Canonical barely made an effort to have libappindicator “accepted into GNOME” (which, in the context of his criticism, Mark believed was important or necessary)
• It did not even need to go through this process anyway, because it did not need to be an “external dependency” in order to achieve Mark’s stated goals (ie. application adoption of the API)
• So the rejection of libappindicator, for all the sturm und drang, is essentially meaningless — it had no bearing on the opportunity for collaboration between Canonical and GNOME
• Unity did not exist in the public sphere when libappindicator was declared irrelevant to GNOME Shell, and was not ever the reason why: (a) there wasn’t much interest in libappindicator, or (b) GNOME Shell developers decided they were on a different path
• Not proven in this part of the series, but worth noting: the person Mark specifically chose to attack, Jon McCann, did not decide to exclude libappindicator because — being a design contributor to GNOME Shell — he felt threatened by Unity. In fact, he had no part in the decision, and didn’t know Unity existed!

But libappindicator is just one chapter in a much longer story… see you in part four! 🙂

Disclosure: I enjoyed working for Canonical from 2004-2006, and although I have occasionally been accused of shilling for Ubuntu since then, I suspect few at Canonical would regard me as their #1 fan at the moment. I haven’t been involved in GNOME for quite some time, and generally try to avoid thinking about it very often.

Note: This post is part two of a series of thoughts on the relationship between Canonical and GNOME.

When you think about the huge mainstays of the Open Source world, GNOME is right up there with the likes of Mozilla, Apache, KDE, the Linux kernel and Debian.

These are the titans of Software Freedom. Massive teams of co-developers, who regard themselves as a family… including the occasional creepy uncle. Individual volunteers work alongside paid contributors with corporate affiliations. Structures are formed to deal with differences of opinion, and facilitate productive collaboration between different kinds of contributors — individuals, corporate stakeholders, hackers, designers. Small teams grow within the larger project. Conferences are established to bring everyone together. Eventually, you’ll even find cliques.

Such communities carry immense history beyond code, such as development tools and processes, community conventions, and as with any large team, the (“we should really document that”) unwritten wisdom of experience. And in-jokes. Always with the in-jokes.

It’s easy to find fault with GNOME. It is, after all, a massive, lumbering project.

Who leads GNOME? Originally, Miguel de Icaza founded and led the project as a benevolent dictator, with maintainers of individual pieces as trusted lieutenants. As GNOME transitioned from science project to core infrastructure, growth in stakeholders demanded more structured decision-making, which eventually led to the GNOME Foundation and then the Release Team.

Today, as in 2000, the Foundation supports the goals of the project, but does not provide technical leadership. Mostly it manages the resources available to the project, maintains relationships with organisational stakeholders and provides a venue to resolve disputes. It may intervene when the project is unable to make a decision or move forward — the most notable cases of that happening include the formation of the GNOME 2.0 release team in 2001, and instigation of a plan for GNOME 3 in 2008 and 2009.

The release team is delegated with a fairly narrow set of technical leadership responsibilities: what to ship and when. Everything else is up to the maintainers of individual GNOME components, and a lot — a lot — of negotiation on the unwieldy general discussion mailing lists. 🙂

GNOME has always been terrible at flag-posting places to pitch in. It’s difficult to figure out where and how to get involved, especially if you just “want to help”. Documentation of bite-sized, easy-fixes for new contributors is reliably miserable. Even with the rigorous release process, few developers write down their agenda for the next cycle, which makes it hard to know what they care about and how you might help.

The GNOME community is absolutely shithouse at mentoring and motivation. It takes a lot of perseverance and banging on doors to bring big new ideas to fruition, and most of it has to be done under your own motivational steam. Much of the time, this is is the result of process over people. The words GNOME people use to describe what’s “in” and “out”, “accepted” and “rejected” sound terrible.

There is a deep irony here, because GNOME was founded by the greatest Open Source motivator of all time, Miguel de Icaza. You could send Miguel a completely misguided and broken patch and he’d rewrite the whole damn thing, explain why (in the most encouraging of terms), tell you how much you rocked for contributing, and then… after all of that… he’d praise you effusively in the credits of the next release! Yes, I wish GNOME were more like its father. 🙂

There are people in GNOME who are difficult to approach. There are people in GNOME who are of a grumpy or abrasive disposition. There are people in GNOME who are jerks. But throw a brick at any large group of people and there’s a good chance you’ll hit a fuckwit. Of course, there are great people in GNOME too, as well as procedures to deal with problems.

Ideas that were once bold and terrifying have become assumptions, seeping into the DNA of the project. An example: Ten years ago the idea of a six-month, time-based release schedule was wildly controversial. Who doesn’t have a time-based release schedule today, and what are they smoking? GNOME is actually behind the curve now, because the wide adoption of time-based schedules and rise of agile development means “six months” sounds grandfatherly!

Since the beginning, most GNOME developers have regarded their creation as a coherent whole, in two pieces: a desktop user experience and a developer platform. This was practically written in stone during the process of creating GNOME 2.0, when we defined the separate “desktop” and “platform” release sets. GNOME is not a miscellany of parts, occasionally thrown over the fence — it is intended to be an integrated, considered stack. More than the sum of its parts. Decisions are made on this basis, which may sometimes be confusing to new contributors.

Since 2.0, a particular angle on usability took hold, which is loudly criticised as often as it is misunderstood. I don’t feel the need to defend it here, but must note the impact it has on recruitment and approachability. GNOME developers are more likely to reject a new option or feature (different things!) on the grounds of usability, applicability to vision, or consistency across broader goals than many other projects. Not only can that be difficult for contributors to understand, it can be challenging for GNOME developers to describe!

GNOME developers are more likely to take a long term view of improving infrastructure from the ground up than to accept a quick fix hack. Consider the range improvements to the entire Linux desktop network stack spawned by Network Manager. This is why, for much the same reason, Havoc Pennington founded FreeDesktop.org way back in 2000: To promote practical cross-desktop interoperability.

The funny thing is, despite external commentators suggesting that the GNOME community is unaware of or does not accept its faults, GNOME participants are painfully aware of them all. Conversations along these lines were rife long before and long after I was actively involved in the project. Some of these problems are merely a matter of manpower. Some of them involve big decisions being made. Some of them are the fundamental challenges of volunteer-driven and leaderless societies.

Assumptions calcify. Processes calcify. Code calcifies. You can fix a hardening of ideas, but it takes people to do so. Individuals or a small team. Getting involved. Defining a vision. Making decisions. Communicating and compromising. Pushing the needle. That’s how you get things done.

It’s hard work being a contributor, and GNOME sure has its fair share of quirks, but it’s not especially different to any other large FLOSS project with thousands of stakeholders, and most importantly, it’s an open, independent, meritocratic, co-development community.

GNOME is People.

Disclosure: I enjoyed working for Canonical from 2004-2006, and although I have occasionally been accused of shilling for Ubuntu since then, I suspect few at Canonical would regard me as their #1 fan at the moment. I haven’t been involved in GNOME for quite some time, and generally try to avoid thinking about it very often.

I can’t count the number of times over the last three years (!) that I have written and deleted a post about Canonical’s worsening relationship with GNOME. Having worked for Canonical and held a leadership role in GNOME, I’ve felt a weight of responsibility (probably unfounded) to contribute to this ongoing debate — and do so constructively.

My hope in finally publishing my thoughts is to raise the tone of the discussion, document what has happened over the last few years, illustrate why we’ve reached this low point in the relationship between Canonical and GNOME, and consider the options for resolution and next steps.

Unfortunately, what began as a short clarification has grown into a research project over the last few days, and is bordering on the length of a novel. So rather than deliver a single, epic post about everything — in dangerous TL;DR territory — I have decided to split my comments into a series of posts:

1. On the relationship between Canonical and GNOME (a series)
2. Thoughts on GNOME
3. The libappindicator Story (timeline)
4. Love flies under the radar
5. The Greatest Show on Earth (timeline)
6. Moving the needle in GNOME
7. It’s 2009… and they have a plan (timeline)
8. The timeline continues…
9. … TBD (still have to figure out how to split the rest of it!)

Enjoy!

Disclosure: I enjoyed working for Canonical from 2004-2006, and although I have occasionally been accused of shilling for Ubuntu since then, I suspect few at Canonical would regard me as their #1 fan at the moment. I haven’t been involved in GNOME for quite some time, and generally try to avoid thinking about it very often.

This is Po, celebrating his second birthday earlier tonight… he’s such a big boy now! Not quite as cute as his very young self, but still beautiful. 🙂

I had planned to celebrate with a big family dinner, but because Po didn’t want to make a big deal about getting older (typical two year old), he just ate a toothbrush instead.

What makes for a truly modern browser?

Check out the interactive browser release chart.

The chart illustrates the most significant releases of each browser, regardless of arbitrary major/minor/micro version number changes. For instance, minor version bumps such as Firefox 3.6 were as significant in the Firefox timeline as major bumps were in Chrome’s.

Two weeks ago I wrote about the unfortunate controversy and aftermath of a keynote speech given at linux.conf.au 2011. I am pleased and impressed by the Linux Australia statement, released today, which should put a lid on the distraction. Well, one can hope.

There were a couple of thoughts in the statement that I wanted to highlight:

“[Our] policies have enabled us to respond in a manner which we believe reinforces [our values and principles].”

and,

“Like the software that our community is founded on, our policies are works in progress and can always be improved.”

Great stuff. None of that senseless hooey people spout like “Open Source is about choice” or equating the “freedom” in Software Freedom with absence of rules, responsibility or respect.

At the outset, I must admit that I have no real interest in Nokia these days. What I can muster is entirely related to their impact on the FLOSS world, my friends who work there and at the various Open Source companies who do contract work for them.

So, because today’s announcement has consequences for a lot of great FLOSS people, I have felt guilty waiting to see what happens purely for entertainment value. A little bit guilty. Lord knows there’s a metric fuckton of kickarse Open Source jobs out there at the moment anyway! 🙂

The Elopocalypse

The gist of the Elopocalypse is that Nokia will team up with Microsoft to use Windows Phone 7 as its primary smartphone platform. No fucking around, Nokia is going all the way: Platform, developer tools, search, advertising, application marketplace, etc.

They are pissing practically everything away into the Microsoft hole. While Nokia has said this as a “new strategic direction”, I think it’s better described as “outsourcing”.

Let us recall the long line of successful and happy Microsoft platform development “strategic partners”: *crickets* (Update: Horace Dediu made a list! In memoriam: Microsoft’s previous strategic mobile partners.)

Under new leadership imported directly from Microsoft, Nokia has chosen the route most damaging to itself in the long term, and most advantageous to Microsoft in the short term.

Most importantly: Who has four fingers and desperately needs a major hardware vendor to ship his brand new smartphone platform? This guy!

MeeGo

What of their Open Source platform ambitions? According to the press release, Nokia intends to continue working on MeeGo and ship a product using it:

Under the new strategy, MeeGo becomes an open-source, mobile operating system project. MeeGo will place increased emphasis on longer-term market exploration of next-generation devices, platforms and user experiences. Nokia still plans to ship a MeeGo-related product later this year.

So it sounds like MeeGo will be used for tablets, mobile Internet devices (if that category even exists in 2011) and perhaps other form-factors… but then, check out the choice of words: “project”, “exploration”, “related product”. Elop all but confirmed the loose end nature of the project during the CEO Q&A.

There’s no commonality whatsoever between MeeGo and the Windows Phone 7 platform (unless Nokia do something very clever with Mono, but I can’t see Microsoft allowing it), so now Nokia has Symbian, MeeGo and Windows Phone 7 for different device profiles… a confusing story for developers, don’t you think?

I just buried the lede, didn’t I? Yes, you read that correctly: Nokia has added Windows Phone 7 without dumping any of its platforms, and will continue maintenance of — and ask developers to understand the difference between, and at least a subset of them to embrace — Symbian, MeeGo and Windows Phone 7.

What’s the app store strategy for Nokia MeeGo devices? It won’t be Microsoft’s Windows Phone Marketplace, that’s for sure!

Then you have to consider Nokia’s partners in the MeeGo project: Intel and the Linux Foundation.

Intel have lost their 800lb smartphone hardware gorilla… does it make sense to continue investing in MeeGo? Just for tablets or netbooks? Who else is going to jump on board, particularly since the HP webOS announcement this week?

… and what possessed the Linux Foundation to get into this mess in the first place? 🙂 So far, no response to Nokia’s announcement from the Linux Foundation, by the way.

Update: A quick thought from Ryan Paul:

I think the Linux Foundation can still salvage MeeGo by making it a generic upstream for low-level embedded Linux stack for set-tops, IVI, etc.

That would probably be worth it for Intel, too — consider Yocto and friends. They’re working hard to build great tools for embedded Linux developers.

Update: Jim Zemlin, Executive Director of the Linux Foundation has made a statement:

The Linux Foundation is disappointed in Nokia’s decision today to choose Microsoft as the primary platform for its mobile phones. Tough times give birth to difficult decisions that we don’t always agree with, but open source is — at its core — about choice. We believe that open source software is more than a sum of its parts, and the market is currently bearing that out. The Linux Foundation is here to enable collaboration among its members and the Linux community, and we invite participation in MeeGo and any of our other many projects and programs. In its 20th anniversary year, Linux is a significant underpinning in every computing segment. Full steam ahead.

(Yes, that’s the ED of LF saying “open source is about choice”… blërg.)

After not-so-quietly dumping the first MeeGo smartphone, I’ll wager the MeeGo device they’re talking about (rumoured to be shown for the first time at Mobile World Congress) releasing “later this year” will be closer to a “mobile internet device” and the N800 family than a smartphone, even if it can do 3G and voice.

Qt

Now we’re in bat country. Check out Nokia’s letter to developers:

Qt will continue to be the development framework for Symbian and Nokia will use Symbian for further devices; continuing to develop strategic applications in Qt for Symbian platform and encouraging application developers to do the same.

Extending the scope of Qt further will be our first MeeGo-related open source device, which we plan to ship later this year. […] That device will be compatible with applications developed within the Qt framework and so give Qt developers a further device to target.

So let’s get this straight: Symbian won’t be Nokia’s primary smartphone platform, but Qt will continue to be used on it, and (fuck knows why) Nokia still plans to ship Symbian devices. MeeGo won’t be Nokia’s primary smartphone platform (though will continue to be developed for future non-smartphone devices), but Qt will continue to be used on it, and Nokia still plans to ship at least one MeeGo-based device.

“Who’s on first?”

As part of its restructuring, Nokia has returned to having two phone-related divisions: Smart Devices (where the Windows Phone 7, Symbian and MeeGo stuff will happen) for smartphones and presumably other high-end devices of various form-factors and Mobile Phones for the historically large (but now-shrinking) dumbphone market.

There’s always the chance that Nokia takes MeeGo seriously, either as an escape route for the future or for new, non-smartphone devices. The “first MeeGo-related open source device” they plan to ship “later this year” sounds like a “keeping developers happy” play.

But Qt on Symbian might not be the inevitable deathmarch it sounds like… sure, Symbian won’t be the smartphone platform of choice, but it might play a role in Nokia’s attempts to take back the low-end market.

Then again, Nokia has announced that it will help bring Windows Phone 7 down to lower-end devices.

Bottom line for Qt: I would not like to be a Troll today. They’ll be facing layoffs, reduced investment, and for the foreseeable future, life in non-strategic-focus limbo. Unpleasant.

Other options: I can’t see Nokia selling off Trolltech while still relying on Qt for Symbian (although an ongoing development agreement could cheapen the deal). And anyway, who in the Open Source market would want to acquire or poach the core developers?

Intel? Only if their interest in MeeGo survives, and they could just as easily pivot back to GTK+ and/or Clutter (where they have development expertise) given that it was Nokia pushing Qt in the first place.

Canonical? Mark announced only very recently that they’d commit to better Qt support in Ubuntu, mostly for third-party application developers. I can’t see Canonical or any third-party developers being particularly encouraged by Nokia’s decision. I wouldn’t want to second-guess the range of bizarre avenues Mark might pursue, but shovelling money into Qt doesn’t sound like something he’d jump on.

It sounds like a shit sandwich, but there might be a silver lining in this for KDE: Despite never accepting the premise of the criticism, KDE has been stuck under the heel (and on the shifting sands) of Trolltech and Nokia for a long time… could Nokia’s Elopocalypse be KDE’s Independence Day?

Conclusion