MariaDB Foundation

I was pleased yesterday to see the MariaDB community starting the process of creating a Foundation to host open collective governance for their community. I’ll be interviewing Monty on Monday in a live webcast at 5pm; watch my Google+ stream for the hangout. Meanwhile, I’ve written a short news item on InfoWorld about the Foundation.

Influence vs Control

My article for InfoWorld this week considers three different projects – OmniOS (derived from Illumos, the new name given to OpenSolaris), GitHub and OpenStack – and finds different attitudes towards corporate control giving different results.

☆ Foundations, Babies and Bathwater

Fallen Head, BonnThere was quite a reaction to my article about how the experience at Koha informs us on the need for “foundations” yesterday. Some considered the details of Koha’s experience, quite reasonably asking if I was aware that after the LibLime take-over the community had indeed established some fiduciary controls, notably asking Horowhenua Library Trust to act as steward for various marks. Take a look at the comments on the ComputerWorld article for more details, and consider donating some money to them.

Exploitable

More surprising was the continuing backlash against the very idea of the “foundation”. Mikeal Rogers has written a follow-up piece, The Value Of Institutions, and I suspect he and I are not far apart in our outlooks even if we express them differently. While MJ Ray has questioned the use of the word “foundation” to describe ways to do it, I continue to believe that when groups of developers come together to collaborate they need to consider the exploitable legalities as soon as possible.

But that’s not out of a love of institutions. If it were possible to be safe from corporate exploitation without any kind of association/co-op/trust/foundation/whatever-you-want-to-call-your-entity, that would be the ideal. As I said in an earlier article, “ultimately it’s about the project, not about the incorporation that encapsulates it.” Bradley Kuhn of the Software Freedom Conservancy has some helpful thoughts on this – he says:

Conservancy handles all the aspects of running a non-profit software project that don’t involve actually developing software. Conservancy’s service plan includes many things, from handling donations, reimbursing developers for conference travel, to holding domain names, copyrights, and trademarks, to enforcing those copyrights and trademarks, to basic legal services.

Gaming

Experience suggests that if your project is indeed awesome, people with less interest in code and fun and more interest in other people’s money will eventually come along and want to tell you what to do – I’ve seen quite a bit of that lately. That’s where another energetic contribution to the discussion from log4j founder Ceki Gülcü goes too far saying “if you are thinking of donating software to and joining a FOSS foundation but have not actually done so, don’t, joining is not worth the trouble.” There are definitely issues with the long-established entities that triage the engagement of corporations with communities, of which all the ones he mentions are examples.

But there is a severe risk that in throwing out this bathwater, several babies will also find themselves swimming helpless as well. The issues of provenance and the management of trademarks, copyrights and their licenses which he waves away so casually are serious pain points that have caused many projects heart ache. OK, keep the legal entity that’s protecting your collaboration away from the actual code (a very common policy for many open source entities), but don’t for a second think that trust alone is enough to weather the tides of greed that will drown the project in the future. You will get gamed or worse.

Choices

Mikeal is also right to say that starting your own non-profit is is less than trivial. Just ask the Document Foundation, whose founders have discovered that incorporating a non-profit in Germany has taken more than a year. But there are easier paths. Picking a jurisdiction where it’s easier is feasible. Deciding not to bother with non-profit status is another – your bylaws can still specify exactly the egalitarian basis you desire without it. Or consider  a holding entity like Software in the Public Interest and ask them to handle your non-code assets in trust for you. There are certainly no easy answers, but then this is the real world.

Mikeal says:

My solution was to focus on individual leadership among people in the community but I think Simon believes there is a future institution that can help us. I don’t know who is right, only time will tell.

I think both are correct. Open source is ultimately about individuals choosing to synchronise overlapping elements of their self-interest and collaborate. Protecting their collaboration can take the form of an umbrella institution they form/join or a helper like SPI. Whichever they do, leaving them empowered to collaborate is the key. The dead hand of corporate-friendly bureaucracy helps no-one.

Ultimately I think this controversy is about the passing-into-middle-age of certain venerable open source institutions. I think that’s the point of Ben Collins-Sussman’s posting about Apache. Let’s hope they get their mid-life-crises sorted out soon rather than just attacking all the messengers. While they do, please let’s not throw the baby out with the bathwater and behave as if there’s no role for administrative entities supporting open source. There is, and the need – and demand – today is greater than ever.

☆ How Many Foundations Do We Need?

One of the sessions at Transfer Summit concerned open source foundations. I made a comment during the Q & A that some people wanted recorded, so here it is!

Imagine you’re starting something new with a group of acquaintances. You join with them to do some new, brilliant and concrete thing.

You all trust each other, know how to work together and have the resources to make that thing happen.
To support, sustain and protect this vector of values, you decide to create a legal entity.
  • If the concrete thing is about making money together, you create a company;
  • If the concrete thing is about just your group making money separately, you create a trade association;
  • If the concrete thing is about enabling anyone to benefit, you create a charity.

That last one is what open source community members tend to label a “foundation”. And obviously I’m simplifying here, a lot.

So how many of those do we need, seriously?

No Quick Fix

You’ll note that each of these treating-groups-of-people-as-if-they-were-collectively-a-person – “incorporations” – encapsulates existing motivation, trust and treats the result as if it were independent of the individuals who originally came together. It’s important to realise that it does not bestow the vector of values.

If there’s no working community of trust, motivation and resource, creating a foundation will not magically cause it to come into existence. There is no point trying to create or join a foundation to solve absent community values. If you have problems, solve them before you incorporate, as incorporating will just make your problems permanent instead of curing them.

No Force Fit

Similarly, it’s also possible that attempting to join an existing foundation as a short-cut won’t work either. To succeed, the existing foundation’s well-established way of working will need to be compatible with the already-functioning vector of values of the group joining.

There’s thus no One Model To Rule Them All. The world is too diverse. No matter how effective a given structure may be for existing groups, there are in my experience always factors that differ. If those unique factors can’t be eliminated, the only answer will be a new incorporation. Given the bureaucracy involved in starting and sustaining a charity it’s worth avoiding it you can, but it’s better than force-fitting your community into the wrong structure.

So the answer is, we need as many foundations as there are sufficiently unique communities for them to encapsulate. Maybe we need some patterns for people to follow as they incorporate, maybe there will be plenty who fit an existing incorporation like Apache or Eclipse or Outercurve, but ultimately it’s about the project, not about the incorporation that encapsulates it.

[Also published on ComputerWorldUK]

☝ OSI Governance Landmark

OSI Board 2010-11You’ll recall about this time last year I was honoured to join the OSI Board and expressed hopes OSI could move towards representative governance. Well, I spent the weekend in San Francisco at an OSI Board face-to-face meeting (kindly hosted by the Wikimedia Foundation) where we finally agreed to move towards representative governance and also elected a stellar group of new Directors.

Read about it on ComputerWorldUK or the OSI Board Blog.

☆ Is Apache Open-By-Rule?

+10

Apache

The Apache Software Foundation is probably the most respected open source code community. Host to nearly 100 massively important projects like httpd, Subversion and Tomcat, it has thoughtfully and pragmatically built highly effective governance over a long period, tweaking its procedures so they work well without getting in the way of progress.

Many thanks to Jim Jagielski of the Apache Foundation for the data he provided for this evaluation. Unusually for these evaluations, I have not edited any of Jim’s text (apart from for layout) and agree with all his scores. It’s no surprise to me that Apache scores a perfect 10.

Rule Data Evaluation Score
Open, Meritocratic Oligarchy How Apache Works 

The Incubator

Committers

The so-called “Apache Way” has been sometimes characterized as “community over code” though that phrase is now deprecated. Instead, the ASF considers itself “community created code.” The main idea is that the creation and fostering of an open, healthy community will result in exceptional code. 

The ASF goes to great lengths to ensure that a project is seen, and actually is, a community project, and not lead by any single person. By being a purely meritocratic environment, developers are able to quickly prove themselves and obtain positions of responsibility and authority. However, development is all peer-based; for example, whether a committer has been part of the project for 5 years or 5 days, their votes are counted the exact same; no one’s opinion is “more important” than a peer’s. This level playing field makes it easier for new blood to join projects and feel as integral parts of the community.

At the core of the project is a group of individuals which are the PMC (Project Management Committee) members. This group has final authority over the direction and management of the project and the codebase. Due to the volunteer nature of the ASF, it is expected that this group will be transient in nature, and so the PMC will vote in new members based on merit and effort. The normal route is that new potential PMC members are first given commit priviledges (allowing them to actually commit code changes to the codebase), making them project contributors. After a period of time, as their merit and effort increase, they are recommended and voted on for PMC membership.

Code patches and development is dependent on the “3 +1 Rule” which means that at least 3 PMC members must agree with and approve a patch, feature, software update, etc… before it becomes part of the official codebase. The ASF also allows for vetoes (-1) which, when based on technical reasons, can not be over-ruled or ignored. These protections ensure a more comprehensive buy-in of effort while limiting the damage possible by “rogue committers” (those extremely rare individuals that are not acting in the best interests of the project, the community, and the ASF).

As noted below, the legal, corporate arm of the ASF (the board, the membership,…) does not control or direct the projects themselves.

+3
Modern license Apache License 2.0 The Apache License, a BSD derivative, is a modern, OSI-approved FOSS license. The AL places very few restrictions on the distribution of code, as compared to more “viral” licenses such as the GPL. The flexibility and freedoms offered by the AL allowed for more varied usage and distribution of the codebase, and allows for almost unfettered use in commerical and proprietary software. 

The AL is ideally suited for software that implements Open Standards and Open Protocols or software which is designed to be a foundation for more extensive development.

Software under the AL can be very easily used within software under just about any other license, open or otherwise.

+1
Copyright accumulation Individual Contributor License
 

Incubator Policy

The ASF does not require that the copyright holder assign copyright of the code or patch to the ASF or the project. Contributors are simply asked to signed an Individual Contributor License, which simply states that the person is authorized to provide the software to the ASF and the ASF can re-license the code. +1
Trademark policy Policy The ASF realizes that as a non-profit, public charity, our trademarks are important to the community and to the foundation itself, since they reflect the brand and the reputation of the projects. Because of this, there is a comprehensive, foundation-wide policy that all projects must enforce. This ensures that all communities are on equal footing and that all external agencies which may wish to use our marks (1) know the rules and (2) are treated equally. +1
Roadmap Contributors 

PMC

Voting rules

Release process

Release publishing

Projects are self-sustaining and self-directed entities. The “corporate” arm of the ASF provides no direction or influence over the directional roadmap of any ASF project. Also, since all developers operate as individuals, and not as representatives of their employers, no external agency (company, organization, etc…) can provide control or influence as well. 

The roadmap is derived from the needs and desires of the developer and user community. A common phrase is “scratching one’s itch”, which means that if a developer thinks a feature would be useful, and at least 2 other developers agree, the feature or capability becomes part of the official codebase.

There are no formal release schedules… if a project decides they want to create such a schedule, that is fine, but most projects operate under the ‘early and often’ rule. Of course, security patches are treated specially and will pretty much all the time trigger a release. There is a standard release process that all ASF Projects must adhere to.

The key aspects of how the ASF works is that any PMC member may be the release manager (RM), and they can create a release pretty much at any time. To ensure adequate oversight, releases require at least 3 +1s from other PMC members (binding votes). It is also important to note that releases may NOT be vetoed. Once someone has taken on the mantle of release manager for a release, the responsibility for that release lies completely on his/her shoulders. All of this is to make as few restrictions as possible on creating releases, so we can ‘release early andoften.’

Of course, most RMs will float the idea to the project first (“Hey, I’m thinking about doing a release next week”) to gauge support or get some feedback. Sometimes the RM will decide to postpone the release due to the feedback but, again, that is his/her prerogative.

All ASF projects use the normal X.Y.Z release numbering where X is a major release (not backwards compatible API-wise), Y is the minor release (API-compatible) and Z is the patch release. Some, such as Apache httpd and Apache APR also use a Minor Even=Official; Odd=Development numbering scheme (eg: 2.3.2 is a development version, whereas 2.4.3 is the “stable” branch).

+1
Multiple co-developers As noted, ASF projects are built around the realization that developers will come and go, based on the fact that their are all volunteers. The community focus ensures that projects will survive the absence of any single developer. Projects are also designed to not be dependent on any external “sponsor” for work or support. 

All ASF projects have seen this “ebb and flow” of developers and have handled that change.

+1
Forking feasible With the pragmatic Apache License, forking of any and all ASF code is extremely feasible. The open history of projects also ensure that the forked community has access to all the development knowledge throughout the history of the project at the ASF. +1
Transparency Mailing Lists All development of projects, including code votes, roadmap discussions and the like are done in the open, on archived public mailing lists. Other methods of collaboration, such as IRC, Wiki’s, etc are avoided and discouraged due to the time-sensitivity to this synchronous methods and the lack of archival-history capability. Within the ASF there is a phrase “if it didn’t happen on the mailing lists, it didn’t happen at all.” 

This openness makes it easier for new interested parties to jump in and get up to speed on a project. It’s creates a lower barrier-to-entry than other methods.

The ASF also feels that the more open a project is, the more welcoming it is; full transparency implies that there is nothing to hide. It also ensures the level playing field so crucial for the continued success of projects: nothing is more damaging to open source than decisions made behind closed-doors, especially regarding software development. It creates a wall between the existing developer community and both the user community and the new-potential-developer community.

+1
Summary (scale -10 to +10) +10

The full open-by-rule series is indexed on the Essays page.

☆ Is Mozilla Open-By-Rule?

+6

Mozilla

Host to the Firefox browser and the Thunderbird mail client among many other projects, the Mozilla Foundation is one of the largest and most significant open source projects. Long-term contributor and employee Gervase Markham has kindly provided the data for an open-by-rule scorecard for Mozilla.

The goal of the open-by-rule benchmark is not to judge the effectiveness or otherwise of any particular project. It is to examine the project governance and establish whether it is an example of good governance. A project may succeed despite flawed governance, with the good judgement and goodwill of participants overcoming possible opportunities for closed behaviour.

As usual, the data and draft text is contributed by a community insider who has made suggestions about scoring, but the score is mine and text that’s not in quote marks should be assumed to be mine too. Mozilla scores +6 on the scale -10 to +10 and is an open-by-rule community (as well as a functionally open community) despite some issues with closed overall leadership rules.

Rule Data Evaluation Score
Open, Meritocratic Oligarchy About Mozilla

Module Owners

Mozilla’s ultimate authority is a board of 5 people. This board is not elected, but was chosen by the senior group who set up the Foundation. They do not exercise day-to-day governance over the project but approve direction, big new initiatives, and budgets. Because they are not elected or subject to challenge, this is clearly not an open organisation. Score -1.

Mozilla’s day-to-day heads are Mitchell Baker on the organizational side, and Brendan Eich on the technical side (both are also on the board), and Mark Surman for the Foundation itself. Even when Netscape dominated the project and sacked Mitchell, she remained head of the project (rather to their consternation). People rise and fall in the organization based on merit, not employment – although the two are hard to separate, as meritorious people often get hired, and Mozilla hires already-meritorious people from other fields! Despite the big hiring budget leading to a preponderance of employees of Mozilla, it is still a meritocracy and there are plenty examples of leadership from outside the ranks of those employed by the Foundation, so this scrapes a +1.

Mozilla has strong leadership, with an appointed set of leaders (known as ‘module owners’) who have control in their areas, with the (very rarely exercised) right of appeal to Mitchell or Brendan. The clearest example of this is in the user interface, where the team spends a lot of its time saying “No” to other people. This is an oligarchy – leadership is exercised rather deferred to chatter or “democracy” by the masses – and scores +1 as a result.

The overall score of +1 reflects a somewhat closed leadership strategy for an organisation that’s otherwise so committed to inclusivity and transparency. It works, but it is in some part due to great people filling the leading roles and overcoming the challenge of the closed top-level leadership rules.

+1
Modern license The Mozilla License MPL 1.1+/GPL 2.0+/LGPL 2.1+, with the possibility in the future of switching to the MPL 2.0+ when it is released. (The MPL 2 is a modern license with inbuilt compatibility with the other two currently used.) All of these licenses have patent protection. Mozilla takes a lead role in writing and advising upon the writing of open source licenses. +1
Copyright accumulation Mozilla Committer Agreement Mozilla does not require copyright assignment. There is a Committers’ Agreement which requires people committing code to have the rights necessary to contribute it, or to investigate its provenance if they did not write it. But the copyright on all our code remains with the authors (or the Foundation for Mozilla employees). +1
Trademark policy Trademark Policy The Firefox and Mozilla trademarks are owned by the Mozilla Foundation, and carefully controlled to make sure that good uses are promoted and bad uses are not. However, what is “good” or “bad” is ultimately the Foundation’s decision, and other community members do not have trademark rights equal with the Foundation.

Gervase says: “I have publicly disagreed with Simon’s points here, but this is his set of criteria, not mine. I am scoring us as 0 because I think the trademark policy is not actively detrimental to the project, but Simon may wish to score it differently.”

Simon says: “Mozilla was a pioneer here and the policy does not actually privilege a community member above all others so actually I’m tempted to score it as +1, but there’s enough controversy around the subject to just about make me agree with Gervase’s score here. “

0
Roadmap Firefox Roadmap

Thunderbird Roadmap

Bugzilla Roadmap

Gervase says: “The Mozilla project is very open about its day-to-day procedures and planning, but the fast-moving nature of the field means that roadmaps which look even 6 months ahead tend to be very vague and aspirational. We also release “when it’s done” and so you won’t find a date-based release schedule either.”

Simon says: “The lack of a date-based release schedule is a concern. When releases are determined based on someone’s judgement that “they are ready” there is too much scope for abuse. It’s far better to have firm release dates and include or exclude features based on their owners’ public assessment of readiness (the “release train” pattern) as this is far harder for any individual to “game”.  However, the results are good so I’m scoring this as 0 and I gather there are moves afoot to start naming the next release date in advance which would roll the score over to +1.”

0
Multiple co-developers Developer Credits
(Not a comprehensive list, and not everyone on the list is still active.)
Gervase says: “Mozilla is one of the largest open source projects in the world. We employ (I think) over 400 people, and have several thousand more active volunteers. (Good community metrics are hard to come by, something we are working to change.)”

Simon says: “I’m actually concerned by the number of key contributors who are employed by the Foundation; an open-by-rule community should have greater diversity. All the same, my experience at Sun was that Mozilla was very happy for Sun staff to take key roles in Mozilla projects and as such I’d score it +1 for diversity based on that experience.”

+1
Forking feasible GNU IceCat

Songbird

Mozilla code is regularly forked to produce other browsers or related software, from the minor changes of GNU IceCat to the much larger changes of the Songbird media player. Some of these organizations or companies send back patches, some do not. There is even Mozilla code in competing browsers, e.g. Chrome on Linux uses NSS, the Network Security Services module. +1
Transparency Forums

Air

Bugzilla

Source

All project communication is done in the open, and all meetings are open for dial-in or to be viewed as streaming video on Air Mozilla. There are a wide range of forums, available via multiple access methods – email, news and web. There is a forum specifically for governance discussions.You can, of course, track all bugs and commits (with the exception of some information about security bugs, for a limited time) in Bugzilla and via our the SCM systems. +1
Summary (scale -10 to +10) +6

The full series of articles is summarised on the Essays page.

%d bloggers like this: