OpenOffice.org Tipping Point?
By webmink on Oct 03, 2007
I've been engaged with the OpenOffice.org community for a number of years, and I'm as aware as anyone that it has had some historic issues with its contribution processes. However, all the signs I see suggest those have been or are being addressed - most notably via the Engineering Steering Committee, but with a number of other important changes (including huge improvements in responsiveness on patch integration in response to earlier complaints). I hear there's more to come, too - Jim Parkinson, the VP who employs all Sun's contributors to OpenOffice.org, has a blog on the blocks about a new OpenOffice.org Advisory Board.
The result has been a fresh start over the last six months, with both IBM and Red Flag 2000 choosing to participate for the first time alongside Sun, Novell and others, and with a fresh road map and new ideas. I'm sure there remain issues to address, but what with all this improvement as well as the strength of the ODF community, OpenOffice.org is on the up-tick. As I said on the panel at OOoCon, we're reaching a tipping point for ODF and OpenOffice.org that is making the opposing forces sit up at think.
In the midst of all this, I see my friend Michael Meeks has been challenging Sun in a creative way - it even made Slashdot today. I remember the days when Michael used to enthusiastically encourage OpenOffice.org community members to sign the contributor agreement, as recently as last December...
Thing is, there's way more to it than Michael is discussing. It seemed to me that Michael has been looking for an excuse to publicly challenge Sun for ages, and finally found his excuse in some well-meaning actions by his employee Kohei. There are two independent issues here that Michael appears to be intentionally confusing in order to make his competitor look bad.
The first is an attack on community norms. It's tempting to use a real-life example but here's a work of my imagination. Let's detach the Novell-Sun competitive issue and work by analogy. Imagine you decide you want to work on Apache Roller, their great new blog server project. You create a fantastic new capability that, when people see it, they realise it needs to be part of Roller - just like you hoped.
You tell them "look, I'd love to contribute it. I have put it under the Apache v2 license. Please accept my contribution." They say to you "well, that's great, but it's a community norm that we ask people to sign Apache's contributor agreement" (yes, that is an Apache requirement in this sort of case). You say "no way Jose" and the Roller guys say "well, we can't accept your contribution until you do". This goes on for a while and it's clear you're not going to budge. All the same, the users make it clear that the feature you are implementing (which is just like one we all saw in WordPress) is just going to have to get implemented.
Finally, some other guys on Roller decide they are going to reluctantly do an independent implementation of the same function. It will use none of your code, and probably work rather differently, but it will make sure Roller gets that feature that Wordpress has too. It's a waste of everyone's time, but Apache has those rules to protect all the members as well as their own administrative functions.
Despite Michael's framing, this is the same situation he describes. An existing community, with existing and well-understood norms, is approached by an enthusiastic developer who breaks the community rules and refuses to accept the correction he receives. The rules were not made to thwart Kohei - they have been there for years.
The second issue is the subject of contributor agreements. They are very common - the FSF has one, so does Apache, and so do projects like MySQL and even, I believe, some of Novell's own projects. There are several reasons to have them:
- They act as an assertion of originality. By saying you grant rights to another party, you implicitly but demonstrably assert you have the rights to begin with. That means the community can have greater confidence that there are no submerged rights issues waiting for the future.
- They allow the copyright steward to act on behalf of the community in the event of any license violation. FSF has done this before now, and Sun is more than ready to defend the projects where it is steward in this way.
- They allow maintenance of the license in the future. Without aggregated copyright, a switch from v1 to v2 of a license (for example) involves locating every single contributor and getting their agreement to the change. If any of them decline or even ignore the request, the code will need re-implementing. It took Mozilla two years to complete this when they re-licensed. The only cases where this isn't necessary are those that have what I call "class A licenses" (like MIT or BSD - more in my white paper).
- More controversially, it allows dual-licensing to parties (such as corporations) who are too worried about open source to work only under an open source license but are willing to work through a mediator.
- In many cases (including some very well-known open source projects) it also allows the original donor to offer commercial offerings, thus ensuring the project continues to have engagement funded by its major participants.
The Sun Contributor Agreement is in my view the best there is. Sadly the OpenOffice.org community doesn't appear to be using the latest, much-improved version - maybe that's the problem? We've been evolving it to have some very desirable community attributes:
- It does not require the contributor to surrender their copyright. They share their rights instead and retain the freedom to do whatever they want with the code contribution.
- It has several layers of agreement, so that if one proves to be unenforceable in some jurisdiction, there are other layers to ensure the community still has aggregated rights.
- There is an "open source covenant" - Sun promises that any contributions that get used will always remain as Free software wherever else they may end up, so that proprietary-only forks are impossible.
It's a shame Michael has chosen now - a turning point in OpenOffice.org and a moment when Sun has radically improved the SCA in response to broad feedback from many communities - as a time to mount a fresh challenge to Sun that by implication also harms OpenOffice.org. And when you distill out all the details, that's what this turns out to be even by Michael's admission - a competitive issue, not a community one.
Update Oct-17: Someone pointed out to me that Novell demands copyright assignment on Evolution and on Mono, and what's more the agreement they require involves giving Novell the copyright, not sharing it, and includes the same language Michael criticises as inadequate about subsequent open source licensing. What gives, guys? You criticise Sun for doing the same thing Novell requires of contributors? Right in the area where you work?