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