My article discussing why open source subscriptions should not be procured with the same assumptions and procedures as proprietary software is now available in the Essays section.
Filed under: Procurement, Webmink | Tagged: Subscriptions | Comments Off on ☂ Subscriptions Article Available
Filed under: Copyright, Webmink | 2 Comments »
Filed under: Links | Comments Off on ☞ Dead Lines
While OpenLogic understandably has an interest in promoting their services to companies engaged in the development of commercial software, I’d suggest their implication that open source is in some way a special case here is over-stated. Any product that’s built using input software written by others needs attentive management of the terms under which the copyright is licensed.
That needs careful management processes which are applicable regardless of whether the software is licensed bilaterally under proprietary terms or multilaterally under open source terms. Thus though it’s not stated this way, they seem to be asserting that the new smartphone market includes a lot of inexperienced developers who don’t realise that.
It’s surely more a function of the immaturity of the market and its participants than specifically of open source, which is really only implicated here because it’s really not about open source but about OpenLogic’s business, their marketing stunt and the community transparency they are exploiting.
Also:
Filed under: Links | 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 »
In the future, where will most of the patents that patent trolls use come from? Find out in my article today on ComputerWorldUK.
Filed under: ComputerWorldUK | Tagged: Patent troll | Comments Off on ☝ Parallel Filing
The Freedom Box project will succeed or fail on whether it works “without sysadmin”. If only trained sysadmins can figure out how to be free, the society won’t be free. It’s like the early days of the telephone, when they couldn’t figure how to scale up the system without having every third person be a trained “Operator”.
While I am very much a supporter of Freedom Box as an initiative (I’ve even made a modest contribution to it), this comment is spot on.
The resulting consumer dilemma is a ubiquitous experience in medium and low-income countries but one that confronts the American or European reader (or the media company employee conjured up by the commercial reader license) much less frequently and with much less intensity. The global market is made for those consumers. It is priced and distributed for them. They are rarely faced with what they experience as ridiculous pricing for a DVD or book–or seriously disadvantaged by differential pricing.
Fascinating experiment to create for westerners the same experience that causes unauthorised use of copyright materials in other places round the world. I expect the report is interesting too, but I doubt I’ll be reading it!
Filed under: Links | Comments Off on ☞ Keys To Freedom
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: FSF | Comments Off on ☆ FSF Leadership Change
Also:
Filed under: Links | Comments Off on ☞ Responses
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: Crowdsourcing, Kickstarter | 1 Comment »
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 