Forks vs. distributions: the Drupal example

Dries Buytaert, lead developer on Drupal, has written an insightful post on the difference between forking a project and different distributions of that project. As he notes, the differences can be subtle, but ultimately come down to the intentions behind the divergence, revealed in how much the fork/distribution relies on the original project's foundation for future development.

The distinction is critical in light of Oracle's fork of Red Hat Enterprise Linux: customers that buy into Oracle's support are effectively buying into a fork, and one that Oracle is ill-equipped to support.

But the distinction plays out every day in a myriad of different projects, and occasionally turns into a full-fledged fork, which tends to benefit no one (which is why it rarely happens in the community-minded open source world. Dries writes of Drupal:

It is important that Drupal distributions collaborate, and not compete. To do so, we have to provide Drupal distributions an environment that encourages collaboration, and that allows for specialization (such as custom documentation and support) without introducing incompatibilities that drive competition.

The good news is that we know how to do this. We've been through this already with CivicSpace (previously called "DeanSpace"), a Drupal distribution for online campaign management and grassroots activism. They were quick to realize that the success of the CivicSpace distribution depends on the success Drupal core, and vice versa. The decided they shouldn't fork core development. Instead, CivicSpace decided to do all its development on the drupal.org infrastructure, to synchronize releases, to submit all patches upstream, to centralize bug reports, and to share documentation where possible. Collaboration, not competition.

The bad news is that can be hard work. People will find that creating a distribution is fun and easy, but that being a responsible maintainer might be a lot less fun. Who wants to track changes, write documentation, maintain modules, provide upgrade paths, manage releases and provide support for years to come?

In short, distributions are fine because they add value to the core. Forks are bad because they splinter communities and thereby fragment value, attenuating it until the point that either the fork dies or the originating project dies.

For this reason, I agree with Dries. What's true of Drupal is true of other open source communities. He writes:

As a community we should disapprove Drupal distributions that do not intend to collaborate, that have no signs of long term commitment, or that risk locking people in.

Amen, Dries.