Forking Time

Off the Beat: Bruce Byfield's Blog
According to one theory of history, in the right circumstances, certain developments are inevitable. Given a few decades of an industrial revolution, half a dozen people will invent the steam engine. Given a few decades of biological studies, and theories of evolution start to emerge. If that is so, then for the last year or so in the history of the free and open source software community we have been in Forking Time -- and for the life of me, I can't decide whether this is a healthy development or not.
Certainly, there have been no shortages of recent forks although they do not always go by that name. In fact, those involved in forks often go to great lengths to deny that they are forking, perhaps to avoid being stigmatized as argumentative and uncooperative.
MySQL alone has had at least four forks (Percona, Our Delta, MariaDB, and Drizzle). Recently, LibreOffice, an offshoot of OpenOffice.org, was announced. So was Trinity KDE, which exists to continue development of the KDE 3 release series rather than working with the current KDE 4 series. Ubuntu's innovations on the GNOME desktop are also looking increasingly like a fork, since they are not being contributed (or, perhaps, accepted) into the main GNOME project.
And these are just the first that occur to me. There are almost certainly others that do not spring readily to my mind.
Where forks originate
However, sticking just to these examples, two points seem obvious.
First, many of these forks seem motivated by dis-satisfaction with the stewardship of the projects. A distrust of Sun Microsystems' dedication to FOSS is responsible for MariaDB, and, since MySQL was handed over to Oracle along with the rest of Sun, the project may seem even more attractive. Similarly, LIbreOffice is also due to a distrust of Oracle, and seems partly a rebranding of Go-oo, which was originally founded out of dis-satisfaction with Sun's handling of OpenOffice.org.
In much the same way, many Trinity KDE supporters feel that, in KDE 4, KDE has embraced changes that are of more interest to developers than to users. As for Ubuntu, its insistence on internal development suggests that Canonical, its commercial arm, feels that lobbying within the GNOME project for the acceptance of its innovations is too slow for it to meet its self-imposed deadlines.
Second, many of these forks are about the directions that projects are taking. Several of the MySQL forks began long before Sun or Oracle acquired MySQL, born of the desire to take the code in a different direction. Go-oo was begun for much the same reason.
In much the same way, Trinity KDE supporters believe that the KDE 3 series is superior to the KDE 4 releases, while Ubuntu and Canonical, its commercial arm, are plainly determined to have their own code implemented according to their own schedule.
Forks are far from unknown in smaller projects, of course. But these common characteristics make me wonder if forks may sometimes be the result of problems with scaling. Perhaps if a FOSS project grows large enough or influential enough, it becomes likely that decisions and directions will be decided by a relatively small group of insiders. Perhaps equally inevitably, those who are not part of this inner circle are going to feel that they have lost their voice in the project. They might come to distrust the insiders and increasingly question the decisions being made.
In a commercial software project, such a division might be unimportant. Such projects are generally more hierarchical than any FOSS project to start with, and the outsiders can at least console themselves with the fact that they are being paid. But in a FOSS project, the centralization of authority is going to seem to both contributing individuals and companies as a betrayal of community ideals -- and, since the association is voluntary to start with, the outsiders can simply walk away and start a new project.
In other words, if the number of forks is increasing in large projects, perhaps their proliferation is a price that FOSS has to pay for its success. Perhaps, sooner or later, a fork becomes inevitable in a large project.
Pro or con?
All of which raises the question: are these forks a good sign, or not? On the one hand, choice is a central value of FOSS. From this perspective, the forks are a sign that FOSS values are alive and well. Forks should result in more choice,and help ensure that FOSS continues to have something for everyone.
On the other hand, forks can leave bad feelings, which could reduce the amount of code-sharing between forks and the projects they split from. If so, then forks represent a duplication and a waste of effort that slow the evolution of FOSS as a whole -- to say nothing of the failure of core members to communicate with the rest of the project.
But, however forks affect the community, one thing is clear: we are stuck with them. In theory, project insiders could prevent a fork by changing work methods and organization to include more outsiders, but, in practice, if they were capable of doing that, then the circumstances that produce forks would not exist. And perhaps the problem is not individuals so much as the limits of communication within an organization.
At any rate, I can think of only one organization that has attempted the kind of reform that might prevent forks -- and that is Debian, in which several attempts at greater democracy have been presented over the years. And perhaps these efforts have not succeeded. Conceivably, the high number of Debian-derivatives simply give Debian discontents a place to go. For better or worse, we may have reached Forking Time, and, as other projects reach a certain size, we will be seeing more forks than ever.
Comments
comments powered by DisqusSubscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Subscribe to our ADMIN Newsletters
Support Our Work
Linux Magazine content is made possible with support from readers like you. Please consider contributing when you’ve found an article to be beneficial.

News
-
Plasma 6.3 Now Available
Plasma desktop v6.3 has a couple of pretty nifty tricks up its sleeve.
-
LibreOffice 25.2 Has Arrived
If you've been hoping for a release that offers more UI customizations, you're in for a treat.
-
TuxCare Has a Big AlmaLinux 9 Announcement in Store
TuxCare announced it has successfully completed a Security Technical Implementation Guide for AlmaLinux OS 9.
-
First Release Candidate for Linux Kernel 6.14 Now Available
Linus Torvalds has officially released the first release candidate for kernel 6.14 and it includes over 500,000 lines of modified code, making for a small release.
-
System76 Refreshes Meerkat Mini PC
If you're looking for a small form factor PC powered by Linux, System76 has exactly what you need in the Meerkat mini PC.
-
Gnome 48 Alpha Ready for Testing
The latest Gnome desktop alpha is now available with plenty of new features and improvements.
-
Wine 10 Includes Plenty to Excite Users
With its latest release, Wine has the usual crop of bug fixes and improvements, along with some exciting new features.
-
Linux Kernel 6.13 Offers Improvements for AMD/Apple Users
The latest Linux kernel is now available, and it includes plenty of improvements, especially for those who use AMD or Apple-based systems.
-
Gnome 48 Debuts New Audio Player
To date, the audio player found within the Gnome desktop has been meh at best, but with the upcoming release that all changes.
-
Plasma 6.3 Ready for Public Beta Testing
Plasma 6.3 will ship with KDE Gear 24.12.1 and KDE Frameworks 6.10, along with some new and exciting features.
Forking - The mutation
See the case of Drizzle: the MySQL fork, it is very much modular and satisfies this 21st century needs.
Even in beta, it is much more attractive than MySQL (from a DBA point of view).
Duh!
Small projects don't fork, someone else just starts from scratch. Big projects can't often afford to do that, they evolve. There is an awkward size where working big lacks critical mass but working small can't quite deliver. If forking had a better name, more of these projects could achieve critical mass.
Uncertainty and doubt over the ethics and practicalities of forking breeds fear and that, by any other name, is FUD.
Survival of the fittest
This is not necessarily a good or a bad thing, but it is a much truer reflection of true competition than proprietary software, where monopolies tend to arise, which stifles innovation. Therefore I think that while forks still have a stigma, they are essential to innovation. This is why Linus' git is so popular, it actively encourages you to fork the code and experiment with it.
In doing this, FOSS has quite literally taken on a life of its own, and ensured its own survival. The only question is whether proprietary software is going to be able to keep up.
Yet again, Bruce says something controversial to prove he doesn't get it....
Trinity KDE not exactly a fork
As such it's more of a "passing the baton to continue the race" than a "fork in the road in different directions", at least imho.
As for why it has the name Trinity, it's to avoid confusion over the idea that KDE (the community) itself is arranging these ongoing releases. One of the side effects of having called everything "KDE" in the past.
Forking around