Does openness warrant success?

Does openness warrant success? As part of the webinos project we researched many major open source projects and looked into the conditions that make a project a success. We set out to measure openness and see what are the best practices in making open source projects a success.

(in a rush? download the full Open Governance Index report here)

Licenses vs governance Use of open source software in the mobile space is now business as usual. Much has been written and debated regarding open source licenses – from the early days of the GPL license to the modern days of the Android platform.

Despite the widespread use of open source, from Android to WebKit, there is one very important aspect of open source projects that has been neglected: openness and how to measure it. Openness goes far beyond the open source license terms and into what is termed Governance.

While licenses determine the rights to use, copy and modify, governance determines the right to gain visibility, to influence and to create derivatives of a project, whether in the form of spin-offs, applications or devices.

The governance model used by an open source project encapsulates all the hard questions about a project: - Who decides on the project roadmap? - How transparent are the decision-making processes? - Can anyone follow the discussions and meetings taking place in the community? - Can anyone create derivatives based on the project? - What compliance requirements are there for creating derivative handsets or applications, and how are these requirements enforced?

Governance determines who has influence and control over the project or platform – beyond what is legally required in the open source license.

Governance = openness In today’s world of commercially-led mobile open source projects, it is not enough to understand the open source license used by a project. It is the governance model that makes the difference between an “open” and a “closed” project.

To quantify governance, we researched eight mobile open source projects: Android, MeeGo, Linux, Qt, WebKit, Mozilla, Eclipse and Symbian. We selected these projects based on breadth of coverage; we picked both successful (Android) and unsuccessful projects (Symbian); both single-sponsor (Qt) and multi-sponsor projects (Eclipse); and both projects based on meritocracy (Linux) and membership status (Eclipse).

Open Governance Index We quantified governance by introducing the Open Governance Index, a measure of open source project “openness”. The Index comprises thirteen metrics across the four areas of governance:

1. Access: availability of the latest source code, developer support mechanisms, public roadmap, and transparency of decision-making 2. Development: the ability of developers to influence the content and direction of the project 3. Derivatives: the ability for developers to create and distribute derivatives of the source code in the form of spin- off projects, handsets or applications. 4. Community: a community structure that does not discriminate between developers.
The Open Governance Index quantifies a project’s openness, in terms of transparency, decision- making, reuse and community structure.
Best practices of open governance Our research suggests that platforms that are most open will be most successful in the long-term. Eclipse, Linux, WebKit and Mozilla each testify to this. In terms of openness, Eclipse is by far the most open platform across access, development, derivatives and community attributes of governance. It is closely followed by Linux and WebKit, and then Mozilla, MeeGo, Symbian and Qt. Seven of the eight platforms we reviewed fell within 30 percentage points of each other. Our research identified certain attributes that successful open source projects have. These attributes are timely access to source code, strong developer tools, process transparency, accessibility to contributing code, and accessibility to becoming a committer. Equal and fair treatment of developers – “meritocracy” – has become the norm, and is expected by developers with regard to their involvement in open source projects. The Android Paradox Android ranks as the most closed project, with an Open Governance Index of 23%, yet at the same time is one of the most successful projects in the history of open source. Is Android proof that open governance is not needed to warrant success in an open source project? Android’s success may have little to do with the open source licensing of its public codebase. Android would not have risen to its current ubiquity were it not for Google’s financial muscle and famed engineering team. More importantly, Android would not have risen were it not for the billions of dollars that OEMs and network operators poured into Android in order to compete with Apple’s iconic devices. As Stephen Elop, Nokia’s CEO, said in June, 2011, “Apple created the conditions necessary for Android”. For the complete analysis of governance models and openness best practices, download the full Open Governance Index report here. - Andreas
7 comments
Till Jaeger
Till Jaeger

When setting up an Open Source Project, there are indeed not just legal questions to answer but also various economic and sociological aspects should be taken into consideration. According to our experience as lawyers dealing with OSS issues there is a significant difference between organizations in the United States of America and those in Europe: in the US, developers tend to have less of a problem with a strict regime determined by a company; in Europe on the other hand a rather "democratic" structure and participation is important in order to bind developers. I agree that apart from the license model many other factors play an important rule when initiating a successful project. However, the choice of the most useful license remains key. This choice is thereby always connected with the question to which extent proprietary software shall be permitted (the implementations on the fear of many companies of the GPL accurately address this important issue under "Open Source - Success Parameters"); this again depends on the technology that shall be implemented, as well as on the license policy. In any case it is advisable to spend enough efforts on contemplating different options before making decisions.

andreascon
andreascon

Hi Till,(sorry for empty reply earlier)Our experience with developers has been that regime-compliance not a question of region, but one of developer culture and position; for example the FSF movement to protect developers' rights began in the US, not Europe. And irrespective of region, established developer houses are more likely to accept an authoritarian regime by the platform vendor, as long as it meets their key goal, to make money.Regarding licenses, the choice of license remains cardinal. But what we found was although most projects in mobile open source use some form of permissive or weak copyleft license, they take very diverse approaches to the governance model. In other words, license choice is typically LGPL/EPL/MPL/BSD, whereas the choice of governance model varies widely, with Android to Eclipse being the two extremes we studied.

andreascon
andreascon

--Andreas Constantinou, Ph.D. |Managing DirectorVisionMobile | Distilling Market Noise Into Market SensePhone: +44 2033 844163 | web: visionmobile.com/blog

Jacek Chmielewski
Jacek Chmielewski

There is a slight error in the text. In the section "Open Governance Index" there is a phrase: "4. Community: a community structure that does not". It seems that the end of the phrase is missing.

Tom Gordon
Tom Gordon

Very interesting, even if I can't agree with the formula "governance = openness". Not all governance models are open, of course. Not by definition. the question is whether the governance of open source projects should be open or more open. That is, more democratic. I don't have a strong opinion about this issue yet. Don't get me wrong. I'm all in favor of more and better democratic processes in general, and trying to make this happen is one of the primary goals of my research on eParticipation and eDemocracy. But I'm happy that large companies like Google publish their source code using Open Source licenses and wonder if they would be willing to continue to do this if the price was giving up control. I'm also concerned about the quality of software and I'm not sure that democratic decision-making leads to the highest quality of engineering. Perhaps Eclipse and Linux are positive examples. But I am also aware of failed attempts, such as the standardization process of R6RS Scheme. At least in the area of programming languages, design by committee has a poor track record. Some of the best successful languages (e.g. Python, Ruby, Scala, Clojure) have been designed and managed by "benevolent dictators". Nonetheless, power is distributed, since developers and users can (and do) jump ship and choose to use another system if a better one comes along.

Andreas Constantinou
Andreas Constantinou

Tom, We believe that an open source project is open not just when it's open to use/modify, but also when it's decision making is open and democratic. By quantifying governance we tried to quantify and elucidate the political system by which decisions around open source projects are made. The quality of software is a multivariate problem. In open source it's generally higher not because of the open decision making, but because of the peer incentives (getting your code out means people will see it and its quality will reflect on you personally as a developer). Also - open source is not design by commitee - rather evolutionary design. Every party can take the code in the direction they like. And where there is an imbalance of contributors/committers, the company with the highest number of contributions/committers will become a natural "center of gravity" that others will swarm around.

Trackbacks

  1. [...] you miss the discussion about how openness warrant success? or maybe the follow-up discussion? Then here is an infographic measuring the relative openness of [...]

  2. [...] “The Open Governance Index”. Webinos.org. 2 August 2011. Retrieved 29 November [...]