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.
Filed under: Governance, InfoWorld | Comments Off on MariaDB Foundation
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.
Filed under: Governance, InfoWorld, OpenSolaris | Tagged: GitHub, OmniOS, OpenStack | Comments Off on Influence vs Control
There 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.
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.
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.
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.
Filed under: Governance | 3 Comments »
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.
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?
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.
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]
Filed under: ComputerWorldUK, Governance | 4 Comments »
You’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.
Filed under: Governance, OSI | 1 Comment »
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 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 |
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 | 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: Apache, Open-By-Rule | 1 Comment »
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 | 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 | 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 | 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 | 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: Firefox, Mozilla, Open-By-Rule | 4 Comments »
The Open-By-Rule Benchmark I talked about recently has now had several workouts, and there are a number more under review ready for future posting. So far, it seems to be working out well, with projects receiving scores that (to my eyes at least) are an accurate reflection of the openness. It’s been clear that every project has it’s strengths and weaknesses and that there’s no perfect model. I like the way the benchmark allows for this; as the dial I’m displaying suggests, I think an overall score below -2 suggests a closed project, a score over +2 suggests an open project and in between is a twilight zone.
While this is very satisfying, there’s certainly a need to do more work. I think I should revise the Benchmark in the light of experience (for example to make it clearer how scores work), but before doing that I’d like to rank a few more projects with it – preferably smaller than the ones ranked so far. I’d welcome your submission – just follow the instructions.
If you’ve not been following the process so far, take a look at the project scorecards to date:
Filed under: Governance | Comments Off on ☆ OBR Progress Report
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: GNOME, Open-By-Rule | 3 Comments »
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 | 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 | 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 | 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: Eclipse, Open-By-Rule | 14 Comments »
Meshed Insights - Open Source Management Consulting
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.
Wild Webmink 