☆ Is Apache Open-By-Rule?

Posted on March 11, 2011 by Simon Phipps
+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.

Filed under: Governance | Tagged: , | 1 Comment »

☆ Is Mozilla Open-By-Rule?

Posted on March 2, 2011 by Simon Phipps
+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.

Filed under: Governance | Tagged: , , | 4 Comments »

☆ Is GNOME Open-By-Rule?

Posted on February 21, 2011 by Simon Phipps
+8

The GNOME Project

Dave Neary has kindly agreed to supply data for an Open-By-Rule evaluation of the GNOME Project, which develops and maintains one of the two open source graphic desktop environments most widely used on UNIX and Linux systems as well as a diverse and growing range of other software including notably mobile software. The scores are mine, although they are largely based on Dave’s assessment.

GNOME easily scores +8 and is obviously open-by-rule.

Rule Data Evaluation Score
Open, Meritocratic Oligarchy The GNOME project is ostensibly led by the Release Team, an open body to which the remaining team members invite someone on merit when a seat opens. Each module in GNOME also has its own maintainer team which decides on the direction of the modules they maintain. The GNOME Foundation is governed by an elected board, elected for a term of 1 year. Newcomers to GNOME often have trouble figuring out who’s in charge. The Release Team is responsible primarily for the release process and has not traditionally set any strategic direction for GNOME, and individual module governance rules are varied. The foundation board is responsible primarily for maintaining the infrastructure of the foundation, and dealing with sponsors and benefactors, and does not set any technical direction.
Score: Governance is open, membership of the release team oligarchy is meritocratic – scoring zero for oligarchy because much of the governance is devolved to maintainers, making it hard to figure out how to accomplish project-wide change.		 +2
Modern license Applications are released under GPL v2+, development platform libraries are LGPL v2.1+ GPLv2 is widely regarded as providing contributor patent protection through implied licensing. Changing the licensing of GNOME to anything other than (L)GPL v3+ (which would not require the permission of all contributors) would be very difficult. +1
Copyright accumulation GNOME does not accumulate copyrights. Authors keep their own copyrights. Clearly scores +1. +1
Trademark policy Licensing Policy The GNOME Foundation has registered a small number of trademarks. The foundation has drafted “fair use” trademark guidelines, and a click-through trademark licence for a number of standard community activities – setting up a fan website or usergroup, printing GNOME merchandising, etc. All of GNOME’s trademarked artwork is available under a copyleft licence to anyone using the project. GNOME has entered into a number of legal agreements in a transparent manner (including publishing the trademark licenses afterwards) to allow companies to sell GNOME branded t-shirts & goodies. 

Score: Community-equal policy scores a clear +1.

 +1
Roadmap The marketing & release teams have worked for several release cycles to develop a community roadmap. The roadmap includes the plans of individual modules, and gives developers the opportunity to identify themes. However, the lack of a medium to long term vision of the project has often been cited as a failing. The move to GNOME Shell has given the project some forward-looking momentum. 

Score: Good start, will score +1 one day…

 0
Multiple co-developers The GNOME project has seen commits by over 3000 developers in its history. The project has vibrant co-operation among competitors, and a healthy mix of 30% paid developers and 70% unpaid contributors. Obviously excellent, +1. +1
Forking feasible GNOME is made up of hundreds of modules with a diverse developer community. The GNOME platform and applications have been used as the basis for projects including Maemo, Sugar, Moblin/MeeGo Netbook, and Ubuntu Netbook Remix. Forking GNOME completely would be a mammoth task. However, by taking a common set of core modules and differentiating only in the UI, a number of companies have created GNOME-based derivatives. Arguably, Canonical is doing this with Unity/Compiz being included in Ubuntu 11.04. So probably +1 score. +1
Transparency GNOME work is done on mailing lists, on IRC, in Bugzilla and in a public git repository While there have been some issues with discussions happening on IRC, or with colleagues working on features together before pushing them to public git, in general, the entire operation of the GNOME project happens in publicly archived mailing lists or in Bugzilla comments. 

Score: Given the controversy that has arisen in the past from the easy access to GNOME community’s dialogues on, for example, FSF affiliation, it clearly has to score +1.

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

Filed under: Governance | Tagged: , | 3 Comments »

☆ Is Eclipse Open-By-Rule?

Posted on February 16, 2011 by Simon Phipps

+8

The Eclipse Foundation is home to a family of projects related to enterprise software development. Its Executive Director Mike Milinkovic has very kindly supplied the data for an Open-By-Rule evaluation. In his submission Mike actually scored the first point higher and I reduced his +1 for “open” down to zero because the Board is controlled by paid seats, but otherwise I agree with his evaluation, giving an overall score of +8 on the -10 to +10 scale. Eclipse definitely qualifies as “open-by-rule” according to the benchmark.

Rule Data Evaluation Score
Open, Meritocratic Oligarchy Directors 

Architecture Council

Planning Council

 The Board of Directors is a mix of “Strategic Members” and elected members representing the community. There are a total of six elected representatives on a board of eighteen. There are no seats reserved for any company. Each Strategic Member company must re-commit both its dollar and headcount (8 FTE) commitments to Eclipse on an annual basis. Score 0 for pay-to-play-controlled Board that does no harm to the overall community. 

(Mike notes: “Although some may question the notion that there is a meritocracy involved where there Board has many corporate members who are there by virtue of their financial and resource commitment to the community, in practice this works extremely well. What we have ended up with is a mix of large and small companies who are strategically committed to the success of the community. This commitment is tangible and re-evaluated annually.” )

The Architecture and Planning Councils share a similar mix, but the vast majority of members are there by virtue of their activity or leadership of a Project Management Committee. In the case of the Architecture Council, the vast majority of members have been elected by the existing members based on clearly meritocratic basis. Score +1 for meritocratic, +1 for oligarchy,  in the technical leadership.

 +2
Modern license Eclipse Public License v1.0 The EPL is an OSI-approved license with a well-written patent license clause very similar to that of the ASL 2.0.  The EPL is a “weak copyleft” license and is particularly well suited as a license for a shared platform for an ecosystem that includes both open source and commercial adopters. +1
Copyright accumulation There are no copyright assignments at Eclipse at all. There are no copyright assignments at Eclipse at all. Every single contributor, no matter how large or small, makes their contributions under the EPL. We have complete symmetry between inbound and outbound licensing. +1
Trademark policy Please see the logo guidelines The trademarks policy keeps the Eclipse name, and the name of all of its projects and their namespaces in trust for the entire Eclipse community. No trademark using entity has any more rights than another. The Eclipse Foundation is a not-for-profit entity which has no commercial motive for the control or exploitation of any of its trademarks.  

(Mike adds: “Caveat: Prior to the creation of the Eclipse Foundation as an independent entity, IBM followed a laissez faire policy towards the Eclipse trademarks and the marks of the various projects inside the Eclipse community. As a result, there are uses of “Eclipse” and other marks which have been grandfathered which would otherwise be in violation of our trademark.”)

 +1
Roadmap Roadmap 

Indigo Plan

Helios Plan

 The Eclipse Foundation publishes an annual roadmap each year which pulls in the release plans of the vast majority of its projects.Each year the Eclipse community releases an annual release train combining the work of a significant subset of the Eclipse community’s projects. All of the requirements, planning and execution of the release train is done is done in an open and transparent manner. +1
Multiple co-developers Commits 

Active committers

Total committers

 Across the Eclipse community there is a very diverse collection of companies and individuals involved in projects.They also transparently publish all sorts of metrics regarding diversity and activity. +1
Forking feasible There are no licensing or copyright assignment barriers to forking. However, the continuing predominance of IBM committers on the Eclipse platform itself means that forking that particular piece of the Eclipse community would be difficult. 0
Transparency Minutes site (includes minutes for Board, Council and Membership meetings) Eclipse publishes minutes of all of its meetings.The Board operates under a mix of Chatham House rules and a requirement that not detailed personnel or financial information be published. All other minutes are made available. +1
Summary (scale -10 to +10) +8

I’m grateful to Mike for the work he’s contributed here – thanks! If you’d like to submit the data to help me test the benchmark on your community, please do.

Filed under: Governance, Links, Open Source | Tagged: , | 14 Comments »

☆ Is LibreOffice Open-By-Rule?

Posted on February 11, 2011 by Simon Phipps

+5Charles-H Schulz from The Document Foundation submitted the data for a benchmark evaluation of LibreOffice. I have read his evaluations and added scores, giving a current evaluation of +5 for LibreOffice (on a scale of -10 to +10). This would firmly identify LibreOffice as open-by-rule.

There is still some room for improvement, but that’s to be expected from a young organisation with ambitious goals. I look forward to being able to re-evaluate in a few months.

Rule Data Evaluation Score
Open, Meritocratic Oligarchy Community postings and
Bylaws		 While the LibreOffice project is only 4 months old both its development track and its community governance show a fast pace of developers’ growth and an open and meritocratic oligarchy. This last point is particularly reflected in its bylaws that emphasize the notion of openness, freedom and meritocracy. 

Score: +1 for open to all contributors, 0 for unproven meritocracy, +1 for structured leadership

 +2
Modern Licence Licensing Explanation LibreOffice inherits from the licensing of OpenOffice.org and the copyright assignment schemes from both Oracle and Sun Microsystems. This means that the bulk of the code, that stems today from OpenOffice.org shares the same license of its older brother (LGPL v3). Yet newly developed code done inside the LibreOffice project has a triple license: (L)GPL v3 + and MPL.  It is thus a situation where LibreOffice has no other choice than to deal with previous licensing choices, not to make new ones. 

Score: 0 for OSI-approved licensing not under the control of the community

 0
Copyright Accumulation Policy statement LibreOffice got rid of any copyright accumulation in the sense of copyright assignments to The Document Foundation and does not require a contributor agreement. +1
Trademark policy Draft trademark policy The trademark policy is almost finished at this point. It attempts to define specific allowed uses for logos, etc. without stumbling too much in certain GNU/Linux distributions’ own policies. While this is a big plus (these distributions’ developers are often part of the LibreOffice core team) it has been noted that the Trademark policy itself is sometimes complex to understand, especially for business uses. 

Score: 0 for trademark policy under community control (+1 once completed)

 0
Roadmap Release plan Efforts are made to make LibreOffice releases predictable and the plan looks good. However it does not mean we know what feature would be included for each release. 

Score: 0 for intent to have a schedule and roadmap, +1 once established

 0
Multiple co-developers List of contributors Contrary to OpenOffice.org, LibreOffice has always wanted to be a diverse community. At this stage the main contributors are Novell and Red Hat, followed by an impressive numbers of independent developers (patches between the “independent” and the corporate are about 50/50). Expect Canonical to ramp up its contributions with its new hire(s). +1
Forking feasible Developer how-to One can fork LibreOffice very easily. The problem is that it’s a very heavy application that has its own technologies and idiosyncrasies that most of developers would need to get really familiar with before trying to fork it. LibreOffice has already invested a lot of effort improving this situation and it will continue to be a priority, so this rule should eventually score +1. 0
Transparency Steering Committee While the Document Foundation is being set up not everything in its governance is fully enabled: for instance the Document Foundation still has to elect a full-fledged board, as the present Steering Committee is only an interim one. However significant efforts have been made to make the governance transparent. +1
Total +5

Many thanks to Charles for the submission. More submissions most welcome.

Filed under: Governance, Open Source | Tagged: , | 7 Comments »

☆ More Ratings Please

Posted on February 7, 2011 by Simon Phipps

Given the interest in my earlier article about a scorecard for open source and my own rough-and-ready benchmark proposal, I’d be interested in seeing how well the benchmark works at rating a variety of open source projects. If you’re familiar enough with a project to be willing to have your name associated with rating it, please complete the table below in the same style as my own evaluation of OpenJDK. Cut & paste into an e-mail and send the completed table to me.

I will review the information you’ve provided, possibly adjust your proposed scores a little to match the scoring style used for other evaluations and then I’ll publish all valid good-faith submissions on my blog.

Rule Data Evaluation Score
Instructions Provide sample extracts from public sources supporting your evaluation, together with links Read the Benchmark. Evaluate as objectively as possible, and conclude with a rationale for the score you are giving. Score -1 for a rule where the governance implementation detracts from open-by-rule; score 0 for implementations that have an overall neutral effect; score +1 for implementations that contribute positively to an open-by-rule community. “Open/Meritocratic/Oligarchy” scores between -3 and +3, evaluating for each word. I’ll review your submission before publication, so don’t worry too much 🙂
Open, Meritocratic Oligarchy +/-3
Modern license +/-1
Copyright accumulation +/-1
Trademark policy +/-1
Roadmap +/-1
Multiple co-developers +/-1
Forking feasible +/-1
Transparency +/-1
Summary (scale -10 to +10) +/-10
Project name
Project URL
Your name

Filed under: Governance | Tagged: | 2 Comments »

☆ Rating OpenJDK Governance

Posted on February 4, 2011 by Simon Phipps

I used to be a member of the Interim Governance Board for the OpenJDK project I helped Sun start to host an open source implementation of the Java platform under the GPL. For various reasons, the governance was never fully defined and the entire subject has been silent for over a year. There’s other context I assume most readers understand listed on CWUK. This week, news emerged that I am no longer a Board member (neither a surprise nor an issue for me), and that a governance proposal has been published.

How does the proposed OpenJDK governance fare when ranked against the open-by-rule benchmark I outlined earlier in the week? Scoring below involves +1 for each positive implementation of a rule, zero for each non-detrimental implementation or omission and -1 for each implementation that detracts from an open-by-rule governance.

Rule Data Evaluation Score
Open, Meritocratic Oligarchy “The Governing Board consists of five individuals:

  • The Chair, appointed by Oracle;
  • The Vice-Chair, appointed by IBM;
  • The OpenJDK Lead, appointed by Oracle; and
  • Two At-Large Members, nominated and elected as described below.”
 This is initially a closed plutocracy comprising mostly people who have never been involved in OpenJDK, as long-term Free Java leader Mark Wielaard has pointed out. The initial Board is all appointed by Oracle and IBM and they have picked only people they can trust to represent them and taken few risks (only Doug Lea has spoken out in the past, when he resigned from the JCP) and omitted key OpenJDK contributors Red Hat and Google (and recent joiner Apple). Future Boards will always comprise at least two Oracle staff and one IBM member. Interestingly, this is not conformant with the original OpenJDK Charter, which gave a majority of seats to elected representatives.

There is scope for the Board to be grown in the future and it’s theoretically possible eventually for the Board to have community-appointed members outnumbering the Oracle-IBM axis, but the rules are poorly defined and there’s undoubtedly scope for them to be gamed in order to maintain control.

Scoring 0 for closed/open given the benefit of doubt for the possible expansion process; -1 for non-meritocratic majority; -1 for non-representative oligarchy.

 -2
Modern license (not mentioned in governance) OpenJDK uses a complex licensing arrangement based on GPLv2 plus a variety of exceptions. GPLv2 has decent implied patent protection according to most legal sources I have consulted. It’s actually a good combination of licensing both for software freedom and as the basis for Oracle to build a business around the code, but it’s not mentioned anywhere in the governance so could presumably change at any time based solely on Oracle’s choices.

If the governance committed to maintaining GPL as the license I’d score this as +1 but the lack of mention makes it 0.

 0
Copyright aggregation “A Contributor is a Participant who has signed the Oracle Contributor Agreement or who works for an organization that has signed that agreement or its equivalent. Only a Contributor may submit anything larger than a simple patch.” Copyright is explicitly aggregated solely in Oracle’s hands. There are actually good historic reasons for this and without it I doubt that either IBM or Apple would be involved in OpenJDK since it would be impossible for Oracle to privately license the resulting Java implementation to them under terms they would accept (neither of them like GPL). Furthermore it allows the existing Java licensing arrangements to be sustained, meaning OpenJDK can be the locus of development for Java SE.

While I would rather see the overall copyright vested in a non-profit foundation, the pragmatic balance of factors means I score this as 0.

 0
Trademark policy (not mentioned in governance) The OpenJDK trademarks are all dealt with outside the scope of the governance and are the exclusive property of Oracle who even claim control of their use within the source, a context I’m surprised to see alleged trademark law is applicable. This clearly scores -1. -1
Roadmap “If a Governing Board member objects in good faith to a technical or release decision made by the OpenJDK Lead then that decision may be appealed via the following process.”

” JDK Release Projects may only be proposed by the OpenJDK Lead and may only be Sponsored by the Governing Board.”

“Every OpenJDK Member will have the opportunity to propose features for inclusion in JDK Release Projects, and decisions about which features to include will be made in a transparent manner.”

 Despite being intended to ensure “that sufficient infrastructure is available to Community members” there’s no mention of how releases will be conducted – there should at least be baseline principles. There’s an appeals process, but it is only open to Board members and there’s a clear intent that the roadmap is at Oracle’s sole discretion. This especially applies to JDK releases. The nod towards transparency is a positive sign but contradicted by the appeals process.
 

While this is all nothing new, it’s hardly “open-by-rule” so a clear -1.

 -1
Multiple co-developers There’s a cross-section at FOSDEM. OpenJDK is blessed with enthusiastic co-development from both independent community participants and from corporations like Red Hat, Google and now Apple. It’s a shame verging on an insult that they weren’t involved in creating or starting the governance, but overall this is OpenJDK’s biggest strength and a clear +1 score. +1
Forking feasible IcedTea, multiple co-developers, Classpath history The code is under the GPL, but the copyright is aggregated by Oracle and the trademarks all belong to them. There are enough co-developers outside Oracle to sustain a fork (after all, Classpath was a viable Java implementation before and IcedTea is still running). Chances are that IBM is subject to a no-forking agreement in return for lending its credibility to the governance. The documentation is subject to rules intentionally designed to prevent them being used on a fork.

Overall, this is a tough rule to score but on balance I think forking would be tough but possible. Given all the factors making it tough, I score this as 0.

 0
Transparency “I’m happy to report that, since last November, I’ve been doing just
that: Drafting a set of Community Bylaws in collaboration with John
Duimovich and Jason Gartner of IBM, Mike Milinkovich of Eclipse,
Prof. Doug Lea of SUNY Oswego, and Adam Messinger of Oracle.”		 Despite having roots in the work of the previous governance board (which also inherited ideas from OpenSolaris), the governance itself has come from nowhere and that bodes ill for future transparency, no matter how often the word is used in the document. The track record for OpenJDK has shown a mixed history for transparency. The corporate pressures are likely to mean lots of back-room dealings and the governance does little to prevent them.

Again, tough to score. I’m tempted to score this as -1 but the fact there’s  a public governance at all and that Mark promises there will be a ratification step (albeit undefined) makes me give the benefit of the doubt and thus a score of 0.

 0
Summary (scale -10 to +10) -3

-3That score isn’t as bad as it could be, but given that

“The goal of these Bylaws is to foster the long-term health and growth of the Community by enabling and encouraging its members to act in an open, transparent, and meritocratic manner.”

I think there’s still plenty of work required to make them fit for purpose. I’m offering these comments in the spirit of contribution and dialogue. I’d be pleased to help the OpenJDK project in any way I can if they wish during the drafting and ratification process. I’ll be at FOSDEM this weekend speaking on this subject in the Free Java DevRoom, so meet me there if you’d like to discuss anything.

I have hoped from the beginning that OpenJDK would be an open-by-rule community in which everyone with a commitment to Java can participate as equals. Let’s hope this new development can deliver on that vision.

Filed under: Governance, Java | Tagged: , , | 8 Comments »

  • Sponsor

    Meshed Insights - Open Source Management Consulting

  • TwitterMink

  • FlickrMink

    Memorial MagnoliaPXL_20240420_145319322.MPTravel breakfast
    More Photos

  • Top Mink

  • Enter your email address to subscribe to this blog and receive notifications of new posts by email.

    Join 9,344 other subscribers
  • Document Foundation Member

  • Legalese

    All views expressed on this blog are those of Simon Phipps and do not necessarily reflect the views of any other entity, including current and former employers and clients. See my full disclosure of interests.

    © 2010-23, Simon Phipps. All rights reserved, all wrongs righted. Unless otherwise credited all photographs, videos and other media are included in this statement. Some photographs are available for licensing via iStockPhoto. To contact the author, please use the e-mail form.