April 20, 2009
freesoftware
8 Comments
In an effort to further perturb the free software market which has been threatening its middleware, application server and database markets recently, the management in Oracle has come up with the masterly stroke of buying Sun Microsystems, and with it a chief competitor, MySQL.
Oracle had already announced their intention to undermine MySQL a few years ago when they bought InnoDB, the ACID database engine used by MySQL, just 18 months before their licensing agreement with the Swedes was due to expire. If you don’t understand why a licensing agreement was needed, you need to think about what licence MySQL was distributing InnoDB under when selling commercial MySQL licences.
My thought at the time was that Oracle could just refuse to renew the licensing arrangement, leaving MySQL without a revenue stream. The problem became moot when Sun bought MySQL, and less critical when MySQL announced they were working on an alternative ACID engine.
Oracle have been trying to undermine free software vendors for a while now, including its launch of Unbreakable Linux to compete directly with Red Hat. Red Hat had previously purchased JBoss, a product competing directly with WebLogic, Oracle’s application server product.
I figure that Oracle will do what some people were suggesting Sun should have done: wrap up Sun into three different entities: storage, servers and software. They have an interest in keeping the storage unit around – there’s considerable synergy possible there for a database company.
Within the software business unit, they will probably drop OpenOffice.org pretty quickly, and I can’t see them maintaining support for OpenSolaris or GNOME. They will keep selling and supporting Solaris as a cash cow for years to come, in the same way IBM did with the Informix database server some years ago, and Java will be a valuable asset to them.
I don’t think Oracle has a strategic interest in becoming a hardware vendor, however, and I can’t imagine a very big percentage of their client base is using SPARC systems these days, so I don’t see them keeping the server business around for long.
Interesting days ahead in the free software world! From the point of view of MySQL, it will be interesting to see if some ex-MySQL employees take the old GPL code and keep the project going under a different company & different name, or if Drizzle (or one of the other forks) gets critical mass as a community-run project to take over a sizeable chunk of the install base. For Oracle, it will be interesting to see if they start trying to move existing MySQL customers over to Oracle, or if they maintain both products, or if they EOL all support on MySQL altogether and force people into a choice. I imagine that the most likely scenario is that they will maintain support staff, cut development staff, and let the product die a slow and painful death.
April 15, 2009
gimp, inkscape, libre graphics meeting, scribus
No Comments
The Libre Graphics Meeting fundraiser has been inching higher in recent weeks, and we are very close to the symbolic level of $5,000 raised, with less than a week left in the fundraising drive.
I am sure we will manage to get past $5,000, but I wonder if we will do it today? To help us put on this great conference, and help get some passionate and deserving free software hackers together, you still have time to give to the campaign. (Update 2019-03-29: Pledgie is no more – for an explanation why, read this).
Thanks very much to the great Free Art and Free Culture community out there for your support!
Update: Less than 2 hours after posting, Mark Wielaard pushed us over the edge with a donation bringing us to exactly $5000. Thanks Mark! Next stop: $6000.
April 8, 2009
community, freesoftware, gnome
18 Comments
Daniel Chalef and Matthew Aslett responded to my suggestion at OSBC that copyright assignment was unnecessary, and potentially harmful, to building a core community around your project. Daniel wrote that he even got the impression that I thought requesting copyright assignment was “somewhat evil”. This seems like a good opportunity for me to clarify exactly what I think about copyright assignment for free software projects.
First: copyright assignment is usually unnecessary.
Most of the most vibrant and diverse communities around do not have copyright assignment in place. GIMP, GNOME, KDE, Inkscape, Scribus and the Linux kernel all get along just fine without requesting copyright assignment (joint or otherwise) from new contributors.
There are some reasons why copyright assignment might be useful, and Matthew mentions them. Relicencing your software is easier when you own everything, and extremely difficult if you don’t. Defending copyright infringement is potentially easier if there is a single copyright holder. The Linux kernel is pretty much set as GPL v2, because even creating a list of all of the copyright holders would be problematic. Getting their agreement to change licence would be nigh on impossible.
Not quite 100% impossible, though, as Mozilla has shown. The relicencing effort of Mozilla took considerable time and resources, and I’m sure the people involved would be delighted not to have needed to go through it. But it is possible.
There is another reason proponents say that a JCA is useful: client indemnification. I happen to think that this is a straw man. Enterprise has embraced Linux, GNOME, Apache and any number of other projects without the need for indemnification. And those clients who do need indemnification can get it from companies like IBM, Sun, Red Hat and others. Owning all the copyright might give more credibility to your client indemnification, but it’s certainly not necessary.
There is a conflation of issues going on with customer indemnification too. What is more important than the ownership of the code is the origin of the code. I would certainly agree that projects should follow decent due dilligence procedures to ensure that a submission is the submitter’s own work, and that he has the right or permission to submit the code under your project’s licence. But this is independent of copyright assignment.
Daniel mentions Mozilla as an example of a non-vendor-led-project requiring copyright assignment – he is mistaken. The Mozilla Committer’s Agreement (pdf) requires a new committer to do due dilligence on the origin of code he contributes, and not commit code which he is not authorised to do. But they do not require joint copyright assignment. Also note when the agreement gets signed – not on your first patch, but when you are becoming a core committer – when you are getting right to the top of the Mozilla food chain.
Second: Copyright assignment is potentially harmful.
It is right and proper that a new contributor to your project jump through some hoops to learn the ways of the community. Communities are layered according to involvement, and the trust which they earn through their involvement. You don’t give the keys to the office to a new employee on day one. What you do on day one is show someone around, introduce them to everyone, let them know what the values of your community are.
Now, what does someone learn about the values of your community if, once they have gone to the effort to modify the software to add a new feature, had their patch reviewed by your committers and met your coding standards, the very next thing you do is send them a legal form that they need to print, sign, and return (and incidentally, agree with) before you will integrate their code in your project?
The hoops that people should be made to jump through are cultural and technical. Learn the tone, meet the core members, learn how to use the tools, the coding conventions, and familiarise yourself with the vision of the community. The role of community members at this stage is to welcome and teach. The equivalent of showing someone around on the first day.
Every additional difficulty which a new contributor experiences is an additional reason for him to not stick around. If someone doesn’t make the effort to familiarise himself with your community processes and tools, then it’s probably not a big deal if he leaves – he wasn’t a good match for the project. But if someone walks away for another reason, something that you could change, something that you can do away with without changing the nature of the community, then that’s a loss.
Among the most common superfluous barriers to entry that you find in free software projects are complicated build systems or uncommon tools, long delays in having questions answered and patches reviewed, and unnecessary bureaucracy around contributing. A JCA fits squarely into that third category.
In a word, the core principle is: To build a vibrant core developer community independent of your company, have as few barriers to contributing as possible.
There is another issue at play here, one which might not be welcomed by the vendors driving the communities where I think a JCA requirement does the most harm. That issue is trust.
One of the things I said at OSBC during my presentation is that companies aren’t community members – their employees might be. Communities are made up of people, individual personalities, quirks, beliefs. While we often assign human characteristics to companies, companies don’t believe. They don’t have morals. The personality of a company can change with the board of directors.
Luis Villa once wrote “what if the corporate winds change? … At that point, all the community has is the license, and [the company]’s licensing choices … When [the company] actually trusts communities, and signals as such by treating the community as equals […] then the community should (and I think will) trust them back. But not until then.”
Luis touches on an important point. Trust is the currency we live & die by. And companies earn trust by the licencing choices they make. The Apache Foundation, Python Software Foundation and Free Software Foundation are community-run non-profits. As well as their licence choices, we also have their by-laws, their membership rules and their history. They are trusted entities. In a fundamental way, assigning or sharing copyright with a non-profit with a healthy governance structure is different from sharing copyright with a company.
There are many cases of companies taking community code and forking commercial versions off it, keeping some code just for themselves. Trolltech, SugarCRM and Digium notably release a commercial version which is different from their GPL edition (Update: Several people have written in to tell me that this is no longer the case with Trolltech, since they were bought by Nokia and QT was relicenced under the LGPL – it appeared that people felt clarification was necessary, although the original point stands – Trolltech did sell a commercial QT different from their GPL “community” edition).
There are even cases of companies withdrawing from the community completely and forking commercial-only versions of software which had previously released under the GPL. A recent example is Novell‘s sale of Netmail to Messaging Architects, resulting in the creation of the Bongo project, forked off the last GPL release available. In 2001, Sunspire (since defunct) decided to release future versions of Tuxracer as a commercial game, resulting in the creation of Planet Penguin Racer, among others, off the last GPL version. Xara dipped their toes releasing most of their core product under the GPL, but decided after a few years that the experiment had failed. Xara Xtreme continues with a community effort to port the rendering engine to Cairo, but to my knowledge, no-one from Xara is working on that effort.
Examples like these show that companies can not be trusted to continue developing the software indefinitely as free software. So as an external developer being asked to sign a JCA, you have to ask yourself the question whether you are prepared to allow the company driving the project the ability to build a commercial product with your code in there. At best, that question constitutes another barrier to entry.
At OSBC, I was pointing out some of the down sides of choices that people are making without even questioning them. JCAs are good for some things, but bad at building a big developer community. What I always say is that you first need to know what you want from your community, and set up the rules appropriately. Nothing is inherently evil in this area, and of course the copyright holder has the right to set the rules of the game. What is important is to be aware of the trade-offs which come from those choices.
To summarise where I stand, copyright assignment or sharing agreements are usually unnecessary, potentially harmful if you are trying to build a vibrant core developer community, by making bureaucracy and the trust of your company core issues for new contributors. There are situations where a JCA is merited, but this comes at a cost, in terms of the number of external contributors you will attract.
Updates: Most of the comments tended to concentrate on two things which I had said, but not emphasised enough. I have tried to clarify slightly where appropriate in the text. First, Trolltech used to distribute a commercial and community edition of QT which were different, but as the QT Software Group in Nokia, this is no longer the case (showing that licencing can change after an acquisition (for the better), as it happens. Second, assigning copyright to a non-profit is, I think, a less controversial proposition for most people because of the extra trust afforded to non-profits through their by-laws, governance structure and not-for-profit status. And it is worth pointing out that KDE eV has a voluntary joint copyright assignment for contributors that they encourage people to sign – Aaron Seigo pointed this out. I think it’s a neat way to make future relicencing easier without adding the initial barrier to entry.
April 1, 2009
gnome
1 Comment
Benjamin Otte’s post today asking how decisions get made (in the context of GNOME) made me think of something I remarked last week.
Last Friday, I attended Critical Mass in San Francisco with Jacob Berkman, and had a blast.
I'm forever blowing bubbles...
The observation I made was that Critical Mass’s decision making felt a little bit like GNOME’s.
We all met up around 18h on the Embarcadero, all with a common goal – cycle around for a few hours together. Different people had different motivations – for most it was to have fun and meet friends, for some, to raise awareness of cycling as a means to getting around, for others, a more general statement on lifestyle.
After a while standing around, you could feel the crowd getting antsy – people wanted to get underway, and they were just waiting for someone to show the way. For no particular reason, someone who was only a leader insofar as he was the first one to start cycling, we got underway.
After that, thing proceeded more or less smoothly, most of the time. But every now and again, at an intersection, the whole thing would just stop. A group at the front would circle to block the intersection, and those of us behind had no choice but to stop, and wait for someone to get us going again.
Eventually, with Jacob, Heewa and Marie-Anne, we went up to the front to avoid getting blocked up like this, and to set the pace a bit.
When we got to the front, we still stopped every now and again to let people catch up, to keep the group together, and then set off again. Sometimes, we were followed, and sometimes, we’d go 50 yards or so, and for no discernible reason, we were leaders without followers – just two guys out taking a walk. At one intersection, we were stopped for fully 20 minutes. On 3 or 4 different occasions, small groups set off to try to get things underway again, and yet they weren’t followed. Until finally, as if some secret handshake were made, we set off again.
This is the kind of decision making you get when you have a mob with no clearly identified leadership – the direction is set by those who take the lead, and sometimes the ones who take the lead don’t get followed.
It’ll be interesting to see, in the myriad of projects setting direction for the GNOME project at the moment, which group(s) impose their vision and get us cycling on another few blocks, until once again we find ourselves circling an intersection. Will it be Zeitgeist/Mayanna? GNOME Shell? Clutter? Telepathy? GNOME Online Desktop? Or some other small group that captures the imagination of a critical mass of people so that everyone else just follows along?
To be honest, I don’t know – I’m stuck before the intersection, waiting for people to follow somebody, anybody, and let me get moving again.
April 1, 2009
community, gnome, maemo
4 Comments
Way back in the Maemo Summit in September 08, Jay Sullivan put up a slide which talked about spheres of participation in Mozilla. I threw together a rough approximation of what was in that:
Spheres of participation
Communities are like onions or planets, with, at their core, the leaders who set the tone and direction for the community. Around this core,many more people contribute to the project with their time and energy, with code, artwork, translations, or with other skills. And beyond, we have forum members, mailing list participants, people on IRC, the people who gravitate to the community because of its vision and tone, and who make the project immeasurably better with their enthusiasm, but who individually don’t commit as much time, or feel as much ownership of the project, as those I mentioned before. Finally, the there is user community, the people who benefit from the work of the community, and which is orders of magnitude bigger.
The boundaries between these levels of involvement are diffuse and ill-defined. People move closer to the center or further away from it as time goes on. A core maintainer gets married, has a child, changes jobs, and suddenly he doesn’t have the time to contribute to the project and influence its direction. A young student discovers the community, and goes from newbie to core committer in a few months.
But the key characteristic to remember is that at the inside we have people who have gained the trust of a large part of the community, and significantly, of the other members of the community at the core. Contribution breeds trust, and trust is the currency upon which communities are built.
Last week as OSBC, I heard different companies claim that they had very large communities of developers, but when I asked about this, they meant people contributing translations, signed up to user forums, downloading SDKs, or developing plug-ins or extensions. When I bore down a little and asked how many were committers to the core product, the impression I got was always the same: very few – because these companies, built up around a niche product, build their business case around being the developer of the product, they require copyright assignment to the core, and becoming a core committer is difficult, if not impossible, if you don’t work for the company behind the project.
So I ask myself, what is the best way to count the size of your developer community? Do you include the orange ring, including translators, documenters, artists, bug triagers and developers who submit patches, but aren’t yet “core” developers? Just the red ring, including maintainers and committers to core modules? Or would you also include all those volunteers who give of their time to answer questions on forums and on mailing lists, who learn about and evangelise your product?
For a project like GNOME, I think of our community in the largest terms possible. I want someone who is a foundation member, who comes along to show off GNOME at a trade show, but has never developed a GNOME application, to feel like part of the GNOME community. I consider translators and sysadmins, board members and event organisers a vital part of the family. But none of these set the direction for the project – for that, we look to project maintainers, the release team, and the long-time leading lights of the project.
I think that you need to separate out the three distinct groups. Your core developers set the direction of the project. Your developer community might include extension developers, documenters, and other people who improve the project, but who do not set the direction for the core (some companies might call this their “ecosystem”). Finally, we have the contributor community, which includes people signed on to mailing lists and forums.
When considering how viable a community project is, calculate the bus factor for the red bit, your core developers. Is there one core maintainer? One company hiring all of the core developers? Then the risk involved in adopting the project goes up correspondingly. The breadth of your contributor community will not immediately fill the gap left if all the core developers disappear.
