Examining MeeGo's openness and transparency

The MeeGo project is barely a year old, and in addition to the usual bootstrapping issues, it has had to deal with the headaches of merging two pre-existing, corporate-backed Linux distributions (Intel's Moblin and Nokia's Maemo), and spawning several independent target platforms: tablets, handhelds, netbooks, vehicles, and set-top boxes. At the MeeGo Conference in San Francisco, several speakers tackled the openness and transparency of the project head-on.

The elephant in the room at the event is Nokia's February announcement that it was backing off its own MeeGo Handset UX plans in favor of a deal with Microsoft for Windows Phone 7 devices. That event spawned a great public perception problem for MeeGo, in which many consumers — for whom MeeGo was synonymous with "Linux phone OS" — assumed the project was finished. Both the Maemo and Moblin sides of the MeeGo community are still extremely active, however. MeeGo's importance as an OEM platform seems solid (particularly in tablet space and in non-"consumer device" verticals such as set-top boxes and in-vehicle infotainment). The community seems resigned to the fact that until there is a phone on the market, many outsiders won't pay attention to the platform, but it appears to be undeterred.

Messaging

Carsten Munk is a veteran of the Maemo project and maintainer of the MeeGo port for Nokia's N900 phone. He also started the short-lived Mer project which sought to re-build an entirely community-maintained version of Maemo for officially unsupported devices. Thus, in spite of holding an official position in the MeeGo project, he has well-earned clout when it comes to the subject of openness. His talk on Monday afternoon was entitled "Transparency, Inclusion, and Meritocracy in MeeGo: Theory and Practice," and was a hard (but not disparaging) examination of how well the project is living up to its advertised principles.

The three factors Munk explored, transparency, inclusion and meritocracy, derive indirectly from the project's branding. The meego.com web site and MeeGo marketing materials mention meritocracy repeatedly as a core value, Munk said, but never define what the project thinks it means or how it works in practice. Digging further into the site, Munk turned up only one vague description of the project's governance as "based on meritocracy and the best practices and values of the Open Source culture" and scattered references to vendor-neutrality and community encouragement.

Searching with Google reveals what the broader public consensus is of open source's "best practices and values," he said, including transparent processes, peer review, and the absence of membership fees or contracts before getting involved. Thus, real transparency and real inclusiveness are prerequisites to a meritocracy culture, he argued: after all, how can one be meritocratic if one cannot see what is happening and actually participate.

The project is failing to define and argue for these core values to outsiders, he said, it needs to state them clearly and prominently both on the site and in its public relations campaigns. Without a clear message on these core values, he said, developers will eventually drift away to other projects: the meritocracy culture is what keeps volunteer developers coming back to donate their time.

Practice

Munk then turned to an examination of the MeeGo project's real-life processes and structures, measuring each on transparency, inclusion, and meritocracy. He came away with three recurring patterns of behavior he sees in MeeGo, and provided feedback on how to improve problem areas in each measured category.

The first pattern Munk explained was the "gatekeeper" pattern, in which a distinct team follows a transparent, well-defined process, but where all of the decisions are made by the team alone. Typically, the team uses transparent processes to interact with the larger project and community, but its internal discussions and decision-making are a black box. The intra-team black-box makes it difficult for non-team-members to get involved (a low inclusiveness quotient), and as a result, gatekeeper teams fall short on meritocracy -- even if, in theory, the team is receptive to ideas from outsiders.

Munk's primary example of the gatekeeper pattern is MeeGo's release engineering team, which he describes as perpetually operating out-of-sight. Most developers within the MeeGo project never see the release engineering team; they simply get an email from them when a release is ready. Other examples from around the project include the IT infrastructure team, legal services, the architecture team, the program- and product-management groups, and the Technical Steering Group (TSG). Fortunately, Munk said, improving on gatekeeper patterns is straightforward: simply having the team conduct its meetings and discussions in the open. There are always going to be areas where legal or security requirements dictate closing the meeting-room door, he said, but openness should be the default.

The second pattern is the "open office" pattern, typified by broad openness in discussions, communication tools, and meetings, placing all participants (core and casual) into one shared virtual space. Although this pattern scores extremely high on transparency, Munk said, it can actually cause unintentional harm on inclusiveness and meritocracy simply because the volume of information can create overload. Suggestions can be lost in the din, and individual contributions can be accidentally overlooked.

Munk's example open office team is the MeeGo Community Office, which incorporates forum, mailing list, wiki, and IRC communication channels, as well as community bug tracking and feedback. The MeeGo developer and user community can be large enough for individual contributions or comments to get lost in the crowd, and often includes almost disjoint sets of contributors (Dave Neary and Dawn Foster discussed that last issue in the "MeeGo Community Dashboard" talk: forum users and mailing list users represent largely non-overlapping communities, although both regularly contribute to IRC discussions). Some other MeeGo teams that operate using the open office pattern include the ARM/n900 team, the SDK team, QA and bug triage, the events team, and the internationalization team.

Munk's suggestions for improving the open office pattern's weak points include creating formal processes to separate out and recognize contributions, and subdividing teams that become too large. Recognizing individuals' contributions, of course, is necessary for inclusiveness, but in order to do it, the team needs to have a regular process in place to report and analyze community involvement. The MeeGo Community Office does have this, as Foster and Neary explained in their talk, although it still needs streamlining.

The third (and by far the most problem-ridden) pattern Munk identified is the "invisible effort," in which not only are a team's communication and processes closed to outside eyes, but even its membership and makeup is a mystery. In the worst case scenario, there is no public mailing list, wiki presence, bug tracker activity, source code repository, roadmap, or even documentation of the team's existence. Along with the complete lack of transparency, this pattern makes it impossible for the team to be inclusive (since it is impossible to contact a team whose identity is hidden), and impossible for it to be meritocratic.

MeeGo does have several invisible effort teams, Munk said, most notably the UI design team. No one on the public side of the project is sure who is on the design team, and their work remains undocumented and secret up until the moment it is revealed to the general public. Other examples include the MeeGo Bugzilla support team (who Munk said is invisible until a change to the project Bugzilla is rolled out), and teams responsible for the occasional "big reveal" announcements (which are typically product-related or reveal the involvement of new partners). There are also a few smaller MeeGo teams that are not formally defined, so they function similar to invisible efforts, albeit unintentionally.

On the plus side, Munk's "how to improve" list for this pattern is quite simple: "Anything!" From a complete lack of transparency, inclusiveness, and meritocracy, any step forward is welcome. Although, he said, improving on transparency is the obvious first step. Many of the invisible effort patterns arise because the team in question is not distributed, and instead is an internal office inside one vendor, which has never before had to interact with an open source project. It may be a radical change in mindset, but fixing the invisible effort team pattern is not optional just because the team has always done things its way.

Traps and pitfalls

In the final section of his talk, Munk outlined common traps and pitfalls that any team or individual might slip into, and which have a detrimental effect on transparency, inclusiveness, and meritocracy. The first is the CC List, in which an individual starts an important discussion outside of the public mailing list by including a long string of CC'ed addresses. This bypasses the transparency expected of the project, and is often a relic of corporate culture. The "big reveals" mentioned earlier fall into this category as well, as does the "BS bug", in which someone files a bug report or feature request that states unequivocally "MeeGo Needs X," without supporting evidence or discussion, then uses the bug report to urge action.

"Corporate nominations" are another trap, in which the TSG appoints someone from outside the MeeGo project to fill a new or important role, without discussion or an open nomination period. Often, the person so nominated does not have a publicly-accessible resume or known reputation to justify their new leadership role. Munk allowed that a certain amount of this was necessary in the early days of MeeGo, when there were not enough active contributors to fill every need, but said now that the project is no longer in "bootstrap" mode, the practice needed to end. He did not give examples of these nominations, but the audience seemed to concur that they have, in fact, happened.

In Monday's keynote, Imad Sousou touched on this same topic in reference to the TSG membership itself in response to an audience question about the TSG's makeup. Sousou said that the TSG's membership was open to the community, and anyone was welcome to make a nomination (including nominating themselves). I asked several community members about that comment after the keynote. All regarded it with disbelief, with several pointing out that there was no documented nomination or election process, nor a charter that spelled out the TSG's makeup at all.

The first few pitfalls were corporate-behavior-related, but Munk mentioned several common to the community side as well. The "loudest argument wins" trap is a common one, where one voice simply wears out all of the others (by volume or belligerence), by flooding lists or forums. This sidetracks meritocracy, because the discussion does not stick to debatable facts. A second pitfall is the "more talk / less doing" trap, which many in open source would recognize: someone who refuses to participate in the solution, but prolongs debate endlessly or repeatedly makes complaints. The third is the "information vampire" pitfall, which is often unintentional. In that trap, someone slows down a team or a process by making too many personal requests for information. The sheer "paperwork" of keeping a vampire satisfied detracts from a team's energy to push the project forward. Lest anyone think he was only out to point fingers, Munk identified himself as often being guilty of information vampirism.

In conclusion, Munk reiterated that the core values of transparency, inclusiveness, and meritocracy are not merely nice ideals, but are a practical "win" for everyone involved in MeeGo (or any other large open source effort). The three are interrelated, but all begin with transparency, he said. 100% transparency is not practical, but he encouraged the community to hold the MeeGo project to its advertised principles, for the benefit of all sides.

On the day after his talk, I asked Munk whether he had received any feedback since the talk, and he said that he obviously hadn't offended enough people, because so far no one had complained to him about what he said. Obviously he could have gone further had he wanted to, such as pointing out specific instances of the pitfalls and shortcomings he outlined in the session, but that would not have really changed the point. My impression of the MeeGo community is that everyone is well aware of what parts of the project are working smoothly and where there are hiccups, strained communications, and difficult processes. Fifteen months is not a lot of time to roll out a large, multi-faceted distributed project like MeeGo, especially one that targets multiple audiences (such as hardware makers, developers, and consumers).

Perhaps the best thing about Munk's talk was his ability to systematically break down the issues that various pieces of the MeeGo machine are struggling with. By shining some light directly on the problems, there is less chance of argument and more room for repairing the cracks — which is clearly what everyone wants. Other large projects could probably take a cue from Munk's taxonomy, and take a look at their own teams, subprojects, and processes: regardless of the target audience of the project, most in the free software world share the same set of goals.