☝ OpenOffice.Org and the LibreOffice Imperative

Posted on June 14, 2011 by Simon Phipps

As expected, the Apache Software Foundation took the first steps to admitting the OpenOffice.org project to the Apache community, following Oracle’s IBM-designed proposal. It now faces a time of maturing and proving in Apache’s Incubator.

I’ve avoided publishing articles here during the Apache discussion as I have both a history and strong views. But with the end of voting, it’s time to document the story so far. You can read my views over on ComputerWorldUK.

If that’s TL;DR, here’s a summary:  The best thing end-users can do is ignore OpenOffice.org at Apache, and switch to LibreOffice instead until the dust settles and we can all see a better path forward.

Filed under: ComputerWorldUK, LibreOffice, ODF | Tagged: | 8 Comments »

☝ OO.o, TDF and CLAs

Posted on May 20, 2011 by Simon Phipps

Yesterday I read LWN’s (paywalled but accessible from here) interview with Mark Shuttleworth, where he is quoted as saying that the formation of The Document Foundation (TDF) and its launch of LibreOffice “led Oracle to finally decide to stop OpenOffice development and lay off 100 employees.”  Mark says this in the context of his new campaign as an apologist for Contribution Licensing Agreements, about which I have written extensively.

I felt that Mark’s use of OpenOffice.org as an argument in favour of CLAs was jaw-dropping, so I wrote a response on the plane home today. You can read it now behind LWN’s paywall using my special link.

Filed under: Copyright, LibreOffice, LWN | Tagged: , , | 1 Comment »

☆ Document Foundation Member

Posted on April 24, 2011 by Simon Phipps

Having applied for membership as soon as the process was announced, I’m honoured to have been accepted today as a Member of The Document Foundation. Having been associated with OpenOffice.org for over a decade in a variety of capacities, I have a deep appreciation of what has been achieved both technically in creating a cross-platform productivity suite and politically in challenging what looked like an entrenched monopoly.

Today, LibreOffice and ODF have a maturity and global acceptance that even those of us imagining the possibilities at the start of the previous decade could not have anticipated. I look forward to working with the Steering Committee and the rest of the community to continue the amazing achievements to date.

Filed under: LibreOffice, Webmink | Tagged: , , | Comments Off on ☆ Document Foundation Member

☝ Open Source Landmark

Posted on April 20, 2011 by Simon Phipps

News just broke jointly from the US Department of Justice and the German Federal Cartel Office that they have directed CPTN to change the way they acquire Novell’s software patents so that the open source community is protected, just as OSI and FSFE requested

Read my views  on CWUK.

Filed under: ComputerWorldUK, Open Source | Comments Off on ☝ Open Source Landmark

☆ Balancing Transparency and Privacy

Posted on April 11, 2011 by Simon Phipps

Beautiful WindowOne of the keys to a successful open source community is appropriate transparency. A community with strong values around transparency will also be likely to respect its participants privacy. Such a community will also be unlikely to have a copyright assignment benefiting a commercial party. Here’s why.

An open source community arises from the synchronization of the individual interest of many parties. Each person:

  • comes to the community at their own (or their employer’s) expense,
  • seeks to derive from the commons at its heart software that fulfils their individual interest and
  • freely brings with them their own abilities and contributions.

No-one is owed a living by anyone else – communities do not have business models, only the participants gathering in them do. Participants with a business interest in the code express that interest elsewhere, if it’s a truly open community.

To create an environment where people are willing to synchronize their individual interests and collaborate over code, there has to be transparency. But that doesn’t have to extend to the lives of the participants themselves. Your motivations for being involved in the community are of no relevance to my life because our relationship in the community depends on code. The code, the community and how they interact are transparent, but motivations for participating in it are opaque. My reasons are up to me alone and yours up to you. They’re private and irrelevant because the code speaks for itself. And by implication, you have no right to force acceptance of your business model on me.

Thus in a healthy open source community, I’m free to maintain my privacy around my motivations and how I’m funding my involvement if I wish. On the other hand, I’m able to work in an environment of transparency where all the code is known, all its origins are known, all its defects are potentially known.

That combination of transparency with privacy is, in my opinion, a primary characteristic of an open-by-rule open source community. Communities without the rule “if it didn’t happen as a matter of open record, it didn’t happen” are closed, regardless of the software license. Open source is about transparency at the community level but also about the privacy of the individuals involved.

The interface between the two is where a formal community/contribution agreement is relevant. To maintain trust, enable development transparency and permit individual privacy, it’s reasonable to ask every participant to sign an agreement promising to stick to community norms, especially with respect to the originality of contributions and the possibility that they are associated with parallel-filed patents.

But it’s not reasonable to give any one participant the exclusive advantage of aggregated copyright for them to use privately. Doing so breaches the transparency-privacy boundary, damages trust by enabling opaque behaviour with the community commons and introduces private business-model reasoning into the community where it doesn’t belong.

I’ve heard arguments such as “we have to be able to make a profit” or “we contributed the original code” to justify copyright assignments, but these are personal not community arguments. Your need for profit is yours, not the community’s, and if you didn’t have it nailed before you started the community and irreversibly licensed the code under an OSI-approved license, that’s your problem. Your business need is no reason for me to surrender my copyright to you, so please don’t demand it. There is no amount of contribution on your part that permits you to demand anything from me.

That’s why, as a participant in Project Harmony, I’m only interested in the variants that grant equal rights to everyone. There will be more news about this soon – watch out for it.

[Expanded from a comment I made in FLOSS Weekly 39.  A helpful research paper on this subject is The Role of Participation Architecture in Growing Sponsored Open Source Communities]

Filed under: Open Source | Tagged: , , | 1 Comment »

☝ OSI Governance Landmark

Posted on March 17, 2011 by Simon Phipps

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.

Filed under: Governance, OSI | 1 Comment »

☆ 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 »

☆ FSF Leadership Change

Posted on March 8, 2011 by Simon Phipps

I got a call on Friday evening from Peter Brown, the Executive Director of the Free Software Foundation (FSF). It’s been my great pleasure to know and work with Peter over the last five years or so. While I was at Sun I liaised with him over the GPLv3 process, to arrange for Richard Stallman’s video about OpenJDK and then later when Sun resumed its donations to FSF as a Corporate Patron.

More recently, as a director of the Open Source Initiative (OSI), I have had the pleasure of working with him on joint FSF-OSI projects. The most public was the joint position our two organisations took over the acquisition of Novell’s patents by the Microsoft-initiated CPTN consortium, but we have also ensured the two organisations stay in sync over various issues during the last year including our mutual opposition to software patents. For example, the FSF’s support for LibreOffice was triggered by a conversation Peter and I had about the OSI’s support for the project.

While the FSF and OSI have clear philosophical differences, both are committed to software freedom and it makes sense to collaborate on the many issues where our conclusions match. Peter has been instrumental in that rapprochement, providing a “friendly user interface” to the FSF that I, among many others, have greatly appreciated.

Peter’s call was to tell me the news that he has decided to step down from his job at FSF, while remaining committed to and involved in the organisation. He said that his replacement is John Sullivan previously the FSF’s operations manager and the brains behind many of the FSF’s campaigns. The FSF announced the news on Monday.. I very much look forward to working with John and continuing the relationship with the FSF that Peter facilitated. My warm thanks to Peter and a warm welcome to John!

[Also posted to the OSI web site on the Board’s behalf]

Filed under: Open Source | Tagged: | Comments Off on ☆ FSF Leadership Change

☆ Crowdsourced is not Open Source

Posted on March 7, 2011 by Simon Phipps

I’ve heard quite a few conversations that treat open source interchangeably with crowdsourcing. Despite sounding the same they are very different, most importantly in the ownership of the outcome.

Open source describes a pragmatic projection of the four software freedoms – to use, study, modify and distribute software for any purpose. As I have explained before, people who find value from the software synchronise the fragment of their activities which relates to the software in question in a community of others with related fragmentary needs (but without a necessarily related motivation behind it). The community is of equal peers, with no one participant necessarily benefiting more than any other. True open source communities are “open-by-rule” – they have a governance that ensures no single community member can exploit the others.

Crowdsourcing describes the leveraging of the marginal interest and free time of a large group of people to complete a task that otherwise could not be economically completed. The result typically benefits the initiator hugely, without significantly compensating the participants. It’s one of the examples of crowd behaviour James Surowiecki cites in his very interesting book The Wisdom of Crowds.

The new US web phenomenon Kickstarter is a modern example of crowdsourcing. It allows entrepreneurs to pitch their wild idea on the web site, and then offer token rewards in return for donating money to pay for bootstrapping – or in some cases fully executing – the business in question. The web site’s denizens pledge relatively small amounts of money and in return get token items – in some cases samples of the product to be created, in others just mementos – in the event that the project is fully funded. Importantly, they get no stake in the business that’s created. They are not “investors” – they are instead crowdsourced donors, not even benefiting as much as sharecroppers.

This is not to say I think crowdsourcing in general is a bad thing. For example I was pleased to pledged a small amount towards Christopher Salmon in getting fully funded for his proposal to create an animated version of Neil Gaiman’s “The Price” because I’d like to see it exist. But it’s not the same thing as open source, where a community comes together for their collective mutual benefit and remain co-equal stakeholders.

As Henrik Ingo explains more colourfully, there are some businesses that don’t understand this, and exploit community for their sole benefit in the name of open source. But you may by now have figured I don’t have a high opinion of that approach!

 

[An earlier version appeared on ComputerWorld UK]

Filed under: Open Source | 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 »

« Previous Page — Next Page »

  • Sponsor

    Meshed Insights - Open Source Management Consulting

  • TwitterMink

  • FlickrMink

    Valbonne Winter SunsetPXL_20251116_111501279PXL_20251116_111408325
    More Photos

  • Top Mink

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

    Join 283 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.