Over on the RedMonk blog, there's an entertaining post by James Governor on the subject of forks, prompted by the imminent arrival of a major new version of Android, version 3.0, code-named "Honeycomb", designed with tablets in mind:
conventional wisdom states that developers don't want to target multiple environments. Yeah – that was the wisdom that got us a decade of Java uber alles thinking, and a 20 years of Oracle-for-everything architectural decision making. The truth is Android so far has been been pretty decent on phones. I really like my HTC Desire. I am also lucky enough to have a Dell Streak loaner to play with; another solid device, that makes for a great armchair TV companion. But Android wasn't designed for a bigger form factor, like Apple's 10 inch iPad, at least in its early versions.
And as he notes:
All software companies have to manage multiple code bases – particularly on the enterprise side. If one company is managing both code bases is that really a fork at all?
I'd say it's more of an issue of fragmentation, and that we see this all the time – in Android itself, in Windows, say, and in the world of GNU/Linux through hundreds of distros, each with different versions and configurations. Nothing really new there.
Real forks are relatively few and far between precisely because of the differences between forking and fragmentation. The latter may or may not be inconvenient, but it's rarely painful in the way that a fork can be. Forks typically tear apart coding communities, demanding that programmers take sides.
That's what makes the appearance of LibreOffice so interesting: it is a real fork, with real, painful decisions that need to be made by coders about where there stand. And unlike fragmentation, which often just happens, and then carries on for a variety of largely trival factors, forks require a lot of work to sustain. As a result, many forks fail, since it's often easier to stick with or go back to the original project, rather than fight to establish and push forward a new one.
Against that background, the recent release of LibreOffice 3.3 is a significant milestone, not least for what it's managed to achieve already:
The Document Foundation launches LibreOffice 3.3, the first stable release of the free office suite developed by the community. In less than four months, the number of developers hacking LibreOffice has grown from less than twenty in late September 2010, to well over one hundred today. This has allowed us to release ahead of the aggressive schedule set by the project.
Clearly, gaining developers is a crucial test of whether the fork is likely to survive and even thrive. These are important too:
the developer community has been able to build their own and independent process, and get up and running in a very short time (with respect to the size of the code base and the project's strong ambitions);
thanks to the high number of new contributors having been attracted into the project, the source code is quickly undergoing a major clean-up to provide a better foundation for future development of LibreOffice;
That is, LibreOffice has moved beyond just a bold idea to doing stuff, including boring stuff like setting up infrastructure to carry the project forward. The significance of this goes beyond the fact that it provides users with a free alternative to OpenOffice (which has also just released its latest version.) Choice lies at the heart of free software, so that's certainly good news, not least because of the way LibreOffice handles copyright, which I discussed previously.
But I think that LibreOffice possesses an additional importance because it represents a conscious strike against Oracle's handling of its open source portfolio. Sadly, the discontent that drove people to make that stand extends well beyond those working in the field of office suites.
As is becoming apparent, Oracle's behaviour towards the open source community seems to be going from bad to worse. This is nicely summed up in this characteristic post from Marc Fleury. As the founder of Jboss, and one of the real innovators in terms of business models based around open source, he certainly knows what he is talking about when it comes to managing open source coders in a corporate context, which makes comments like these particularly significant – and ominous for Oracle:
First there has been the Open Office/Libre Office fiasco, where Open Office was essentially forked by its own community. Then there was the Java/JCP tantrum thrown by Apache, where Apache noisily left the JCP over spats with OSS licenses for the JVM (Harmony). And lately there are more, notably one with NetBeans. But one that is closer to home (and my wallet) involves a project led by an employee of Cloudbees.
Basically, if I understand the situation correctly the lead developer was a Sun employee when he started Hudson. So Oracle claims they own IP and brand, which very frankly is completely irrelevant since the license is OSS and the guys at Cloudbees can continue their work un-encumbered. And there is one thing left to do, which is basically to fork the project. And so it is... a lot of the OSS community is flipping the bird to Oracle.
What LibreOffice has shown (so far, at least) is that in such circumstances, there is indeed life after Oracle, that people will join, not shun, a fork and that work can move forward to produce substantial improvements. It's true that this is only a single data point, and it would be a foolhardy pundit to attempt to extrapolate from that. But it still stands as an important and tempting inspiration for unhappy coders groaning under the Oracle yoke. After all, as LibreOffice's name emphasises, this isn't just about code, it's about freedom too.