Forks can be an emotive subject for an open source community.

They can make or break communities – sometimes growing to become bigger and better than the original, but sometimes serving to fragment and drive both to the ground.

This article aims to propose why forks exist, and serve as a means for community members to better understand others’ motivations.

Every developer wants a different direction

To understanding motivations at the time of a fork, you need to understand the original motivation for initially getting involved in open source software development.

For most, this is summarised by the phrase “to scratch your own itch”.

In short, developers become involved because at that particular time, an open source project will get to 80-90% of their desired solution, with 10-20% of the work required to build from scratch.

I would propose that open source communities do not stay together for a sense of joint cause (they do not stay together "for the community").

They remain because the aims of the individuals present at that time are aligned enough with where the software itself is heading.

Speed together vs. direction apart

At some point, it is likely for everyone that they no longer share the direction that an existing project is heading.

There are various options for that individual (organisation):

1. Remain on board:

   Whilst the direction may not be perfect, the associated infrastructure, way of life or community may make it worthwhile to stick on the existing way.

   I label this option “speed together”, as it retains the sense of the efficiency of being involved with a community.

   Perhaps now the open source solution is only getting you to 50-60% of where you need to be with 20-30% of the effort though. 

2. Jump ship:

   It may be that a different project now suits your needs better.

   As an example: In CMS communities, there have been figures who have loudly moved between Joomla, Wordpress and Drupal (in all directions), and likely many more who have done this silently.

   Whilst you set yourself a learning curve on the change, by immediately joining a community that is set up and already has infrastructure and add-ons, you may benefit in the long-term. 

3. Fork:

   If no existing solution helps anymore, you’re back to going out on your own but may wish to take others with you.

   This option involves taking the product that you are already involved in, and pivoting to take the direction that suits you best.

   This is a risky tactic as it could leave you effectively maintaining a custom (but public) product - however the direction will be as close as possible to your requirements.

Tension leads to fractures

The scenarios that I described above do not occur unless there is enough tension in the community to trigger a fracture (either a single individual moving or a full fork).

I need to return to the idea that open source is governed by individuals (or organisations) that want to “scratch their own itch”, but now from the perspective of a leader in the community.

All of those leaders will have their own needs and requirements in order to “scratch their own itch” (or even, keep their job).

In large communities, tensions may arise simply due to the breadth of needs, or there may be an issue with leaders’ decisions not aligning with community consensus.

A fork may help a diverse community focus around multiple (but more specific) goals, but if consensus is disagreeing with community then a better solution would be a pivot of direction for the existing project.

Forks are a trigger for action

Whether a fork is needed or not (perhaps that is a subjective judgement), they force crucial issues to the top of mind with a sense of urgency – both in the fork and incumbent community.

Whatever the outcome, there will be a short-term boost in competition (whilst a fork is being proposed or trying to establish itself). Community members will be deciding which better suits their personal needs.

My hope, in this article is for any open source community discussing the option of a fork to recognise the reasons that the tension exists to begin with.

Disclaimer:

• This article was written in the wake of the announcement to create a fork of the Drupal CMS called Backdrop CMS.
• However, the aim of the article is to explore why forks take place, and is not intended to cast any judgement or implications about the pros and cons of the specific circumstances.

Category: Business & InnovationTags: Drupal PlanetOpen SourceforksBackdrop CMScommunity