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
-
Canonical Bumps LTS Support to 12 years
If you're worried that your Ubuntu LTS release won't be supported long enough to last, Canonical has a surprise for you in the form of 12 years of security coverage.
-
Fedora 40 Beta Released Soon
With the official release of Fedora 40 coming in April, it's almost time to download the beta and see what's new.
-
New Pentesting Distribution to Compete with Kali Linux
SnoopGod is now available for your testing needs
-
Juno Computers Launches Another Linux Laptop
If you're looking for a powerhouse laptop that runs Ubuntu, the Juno Computers Neptune 17 v6 should be on your radar.
-
ZorinOS 17.1 Released, Includes Improved Windows App Support
If you need or desire to run Windows applications on Linux, there's one distribution intent on making that easier for you and its new release further improves that feature.
-
Linux Market Share Surpasses 4% for the First Time
Look out Windows and macOS, Linux is on the rise and has even topped ChromeOS to become the fourth most widely used OS around the globe.
-
KDE’s Plasma 6 Officially Available
KDE’s Plasma 6.0 "Megarelease" has happened, and it's brimming with new features, polish, and performance.
-
Latest Version of Tails Unleashed
Tails 6.0 is based on Debian 12 and includes GNOME 43.
-
KDE Announces New Slimbook V with Plenty of Power and KDE’s Plasma 6
If you're a fan of KDE Plasma, you'll be thrilled to hear they've announced a new Slimbook with an AMD CPU and the latest version of KDE Plasma desktop.
-
Monthly Sponsorship Includes Early Access to elementary OS 8
If you want to get a glimpse of what's in the pipeline for elementary OS 8, just set up a monthly sponsorship to help fund its continued existence.
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