LibreOffice
So the news yesterday was that The Document Foundation has been set up by a consortium of interested parties who are unimpressed with Oracle’s stewardship of the OpenOffice.org codebase and project. In short, the project has forked. This isn’t the first time a prominent open source project has decided as a community that the direction of a controlling company is not they way they want to go. In 2005 Mambo was an up and coming web content management system, but there were issues in the community and the strategy of the company. It forked. A foundation was set up, OpenSourceMatters and the codebase was forked into Joomla! So taking a lesson from history, what happened next to the two halves of the fork? Well I find Google Trends illustrates it rather well. Mambo is the blue line, Joomla! is the red line. If the fork had not happened would the blue line continued to a higher point today than the red line? Hard to say, in the bigger picture it looks like forking it was a setback, but it is clear that the fork managed by the foundation quickly gained more popular relevance (and no, this is not very scientific) than the one managed by a single company.
Lets have a look at OpenOffice.org vs LibreOffice. Clearly not much on the chart yet for LibreOffice except for a media spike at the end, it will be interesting to look at this chart in a year or so and see when the red line crosses the blue line.
Hopefully MySql will follow suit
they kind of did already, but in a very different way https://launchpad.net/maria
[…] This post was mentioned on Twitter by Planet Ubuntu and Arjan Waardenburg, Zuissi. Zuissi said: Ubuntu: Alan Bell: LibreOffice: So the news yesterday was that The Document Foundation has been set up by a consor… http://bit.ly/cg2NVR […]
[…] Bell sees correlation with the previous fork of Joomla from Mambo and has illustrated the potential impact that forking a project can have with a Google Trends chart, where Mambo is the […]
The Joomla/Mambo history is much more interesting than that. The non-profit Mambo Foundation was also constructed in 2005 to shepherd the Mambo side of the forked codebase. It’s not the foundation status that matters. It’s the details of copyright assignment policy that does.
OpenSourceMatters current policy does not require copyright ownership assignment for contributed code. This is very independent developer friendly. Everyone contributing to the codebase is on an equal footing and noone can just take the codebase and run away with it.
The Mambo Foundation currently requires joint copyright ownership which gives the Mambo Foundation the ability to proprietarily re-license contributed code. This policy is hostile to independent developers and gives Mambo Foundation and its preferred partners advantages in terms of code use.
OpenSourceMatters appears to have a draft contributor agreement from Feb 2010 which does require “limited” assignment, and which explicitly limits what licenses OpenSourceMatters can use when relicensing. Such explicit limitations explicitly prevent OpenSourceMatter from relicensing contributed code proprietarily. But to my knowledge I do not think it is currently required for Joomla contribution.
With all this in mind… can you suggest a reason to me as to why Canonical feels its necessary to require copyright assignment for the code it sponsors? I’ve yet to find a good example of copyright assignment to a for-profit entity resulting in a codebase with a healthy and vibrant developer community. Mambo is just another example of it going wrong.
-jef
interesting comment Jef, firstly, no I have no idea why Canonical insists on copyright assignment. I don’t think they are wrong to do so, I just don’t see why it is necessary in all instances. For some things like the new font, where the licensing status has a stated intention of changing in the future I can totally see that a single copyright holder is a benefit. Other than that, you would have to ask Canonical.
The main point is this…how important was the lack of copyright assignment requirement to the Joomla contributor community when Joomla when OpenSourceMatters was formed? How important is the lack of copyright assignment in the case of the formation of LibreOffice? I can not find a single historical instance where a contributor community did not benefit from a removal of a copyright assignment that allowed proprietary re-licensing.
There are ways to provide for re-licensing powers that are still held within limits to provide a legal mechanism to fight future abuse. Read Aaron Seigo’s blog on his personal difficult with Canonical’s assignment policy as an external contributor.
http://aseigo.blogspot.com/2010/09/copyright-assignments-gone-wild-or-why.html
He goes it to some detail on how assignment can be done such that good faith open re-licensing is possible but still prevents proprietary overreach. OpenSourceMatters’ draft contributor agreement from earlier this year is also a good read and follows a lot of the suggestions that Aaron talks about in his post and the tag along discussion he has with a Canonical employee in the comments.
Copyright assignment is a real barrier to entry for skilled contributors. It was in the case of Mambo leading to Joomla. It was in the case of OpenOffice.org leading to LibreOffice. It’s also been cited more recently in statements made about the formation of the OpenStack project as a problem with how Eucalyptus development is managed.
-jef
What is the relationship between LibreOffice Go-OO.org and the much smaller neo-office?
[…] is an important cause at this particular stage, primarily because of Oracle. The goal it to override OpenOffice.org (notice how it came from proprietary StarOffice to dual with OpenOffice.org and now all the way to […]
Counterpoint: LibreOffice/OpenOffice still does not support KDE/Qt.
How about some commitment from LibreOffice to provide a version with reasonable KDE or Qt integration?
I believe OpenSuSe has at least some of the code or patches required. Why not use conditional compilation to make a KDE build of LibreOffice that can pick up KDE themes/styles/icons and use KDE dialogs?
If a variant build was targeted at Qt rather than KDE, then that variant could support Meego as well as KDE desktops.
In fact, making Qt a target for LibrOffice would considerably simplify cross-platform support in general.