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.
Forking - The mutationAs already pointed out in above comments, Forking is essential for Opensource.
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!FC Truter has it right. Forking is the Libre way of innovating off an ageing but widely embedded code base, to both serve new niches and weed out lax stewardship.
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 fittestI think FOSS is now beginning to reflect the mechanics of evolution, whereby you have two mechanisms - mutation (forking) to drive greater diversity, and selection (market popularity) to drive down diversity. It is this symbiosis that has driven our planet to where we are today. The interaction between two forces will eventually create a balance - a point where old software projects die out at the same rate that new forks are created.
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....Nothing to see here, just Bruce not getting it...again.
Trinity KDE not exactly a forkI'm not sure if Trinity KDE qualifies as a full on fork, it's more of a "different group took over maintenance". There aren't releases of KDE 3 that KDE itself is putting out, and Trinity has continued to work from where the last release KDE made of KDE 3 left off.
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 aroundThat is a very insightful analysis! I think that the kind of forking we are now seeing is a healthy thing, and it would be a mistake to try to limit it. Biological systems aren't the only things that are dependent on diversity for their continued existence, because the diversity gives the option of a new direction (fork) as an existing direction runs out of interest or innovation or growth.
MSBuild is now just another GitHub project as Redmond continues its path to the light.
Malware could pass data and commands between disconnected computers without leaving a trace on the network.
New rules emphasize collegiality in coding.
Upstart lands in the dust bin as a new era begins for Linux.
HP's annual Cyber Risk report offers a bleak look at the state of IT.
But what do the big numbers really mean?
.NET Core execution engine is the basis for cross-platform .NET implementations.
The Xnote trojan hides itself on the target system and will launch a variety of attacks on command.
Spammers go low-volume, and 90% of IE browsers are unpatched.
Adobe scrambles to release patches for vulnerable Flash Player.