James Dixon’s Blog

James Dixon’s thoughts on commercial open source and open source business intelligence

Forking Protocol: Why, When, and How to Fork an Open Source Project

with 6 comments

The right to fork open source projects is an important part of the freedoms that open source provides. This right is not theoretical it is real. It is seldom user for several reasons. As Eric Raymond says in ‘Homesteading the Noosphere’ in ‘The Cathedral & the Bazaar”:

There is a strong social pressure against forking projects. It does not happen except under plea of dire necessity, with  much public self-justification, and requires re-naming.

The recent fork of Nagois by Icinga is the most recent example of forking. I have been involved in several forking or potential forking incidents. The Why, When, and How presented below are based on that experience, on observations of other forking incidents, and on the writings and blogs of Eric Raymond and others. I have searched the internet for a step-by-step guide or protocol for forking and could not find one, if anyone knows of one please let me know, and I will reference it.

Why Fork?

Answer – Because you cannot get the software to meet your needs any other way.

There are different reasons that this might be the case. If the core developers, who have write-access to the source code, don’t accept your features or patches. If the core developers reject use cases or a direction that community members want. If the core developers don’t agree between themselves on what direction to go in.

Just because you don’t like, or don’t trust, the core developers or custodians of the project is not a good reason to fork the project. Being worried that the core developers or custodians, at some time in the future, will do something you don’t like, is not a good reason to fork a project.

Any preemptive fork of Java or MySQL, purely because of Oracle’s acquisition of Sun, is bad. Until Oracle does something bad and repeatedly fails to make it right (despite rationally-communicated requests from the community) there is no need for a fork of Java or MySQL.

There are things that you, as a project owner, can do to reduce the potential of a fork. First and foremost is to listen to, and interact with, your community. A lack of communication was one of the reasons for the Adempiere fork of Compiere.

There are also technical things that you can do.

Avoid Forks Via Plug-Ins

Support plug-ins. Plug-ins make it easy for developers to add features to the software. By using a plug-in architecture developers can create new features by writing only what is necessary for the functionality they need. The core software will automatically recognize the plug-in and make the feature available to the end user. Transformations and filters in graphics programs are a good example of this – no changes to the core program are needed to create a new filter. Plug-ins are a good way to allow ‘me-too’ or ‘same-category’ features to be added. For example a graphics program might allow plug-ins that provide certain types of functionality: filters, transformations, brushes, import/export.

The limitation of plug-ins is that they do not typically enable low-level or fundamental modifications.

Avoid Forks Via Inversion of Control

Inversion of control uses object factories or injection to provide software that is being executed with the objects that it needs. The objects used by the system can now be defined in configuration files instead of being fixed in code.

As it relates to forking inversion of control is very powerful. When inversion of control is implemented fully it enables community developers to extend or modify any part of the software, not just plug-in features.

For example in the Pentaho BI platform we use a combination of Spring xml files (injection) and object factories to enable all of the main platform objects to be defined in configuration. We use this ourselves as we have  multiple implementations of some of the major objects, for example the repository layer. The benefit to the community is that they can change the behavior of any part of the system very easily:

  • Sub-class the object that closest matches your needs.
  • Override the methods needed to introduce the functionality you need.
  • Change the configuration to use your object instead of the original one.

The advantage of this approach is that different segments of the community can create their own extensions by writing the smallest amount of code necessary, and their is no need or incentive to fork the core project.

When To Fork?

Answer – When you have exhausted all other options.

Take a look a:

The publicly stated reasons for the Icinga fork of Nagios – Why A Fork?

The debate about whether to fork Compiere – Debate – Has Compiere Become Closed? Do We Fork? How?

The letter from the Mambo developers before the Joomla fork – Mambo Developers Letter To The Community

You can see from these pages that the decision to fork was not made lightly. It is clear there was much discussion and involvement happened before the idea of forking was considered. The reasons for the fork are communicated clearly, often with regret that a fork was necessary.

How To Fork?

Answer: Carefully and responsibly

Here are my step-by-step suggestions.

Step 1: Exhaust All Other Options

Communicate your frustrations clearly. Doing this in a private email will help reduce the chance of the core developers/custodians getting defensive.

  • Find out how other community members feel. If no-one else agrees with you, there is a good chance your frustrations are misplaced.
  • Describe what you feel would be the bast-case outcome, and how it would be a good result for everyone (not just you).
  • Do not threaten to fork the project at this point.
  • Give the core developers/custodians 2 to 4 weeks to react.

If you get no reply or a negative one, proceed to step 2.

Step 2 – Communicate Intent Privately

If step 1 fails, in a private email:

  • Communicate your disappointment that a mutually beneficial resolution has not been reached
  • Communicate that you have no option but to announce an ‘intent to fork’.
  • Again give the core developers/custodians 2 to 4 weeks to react.

If again you get no reply or a negative one, proceed to step 3.

Step 3 – Publicly Announce Intent to Fork

Publicly announce your intent to fork the project. Communicate that you have exhausted all other options. Specify the date at which the fork will occur. This date should again be 2-4 weeks into the future.

Create forum threads so that other community members can voice their opinions of the proposed fork. Participate in any discussions that starts up.

In most cases the community members who have pledged to follow the fork will spend the time between the public announcement and the fork date working on materials for the new project, such as the home page.

Step 4 – Fork

If nothing changes before the fork date arrives – fork.

When creating your new project choose a name that is different from the original project.

On your project web site make it clear that this is a fork, and why the fork occurred.

Do not remove the names of developers or copyright notices from any of the source files or documentation. Choose the same license type as the original project.

Make it clear which version or revision or tagged branch was forked.

Many Forks Are Avoided

By following the steps above forks can be avoided. I have been involved in situations that made it to step 2 in this process. In these cases, when the threat of a fork was seen as credible, the custodians of the project started to engage and a mutually beneficial agreement was reached. I am not naming these projects, that was part of the agreement we reached.

Bad Example of a Fork

Here is a bad case: In July 2007 someone tried to fork Pentaho Data Integration. The project was called ‘No Pentaho Pentaho Data Integration’. The reasoning given for this fork was:

No Pentaho Pentaho Data Integration is intended to take an early version 3.x of Pentaho Data Integration, remove most of the features Pentaho added and as such starting a new more stable version of PDI.

The apparent motivation for this attempted fork was that the trunk code for the next major release was, at the time, unstable. This was due to a significant re-write of the core engine, and the fork happened at a time then the instability was expected. None of the core developers or active community members supported the fork. To date this project has produced no downloads and has one anonymous developer.

This was clearly an unsuccessful fork that did not follow the steps above. The Pentaho Data Integration developers received no communication that anyone was frustrated with the running of the project. The developers had no opportunity to resolve any of the issues the member had. There was no privately or publicly communicated intent to fork. The fork just happened. Since then has produced nothing.

Feedback Welcome

If you have any feedback to this or links to related content please comment below.

Written by James

May 7, 2009 at 5:25 am

6 Responses

Subscribe to comments with RSS.

  1. [...] a comment » As I mentioned in the forking protocol post there are different reasons why forks occur. One way to categorize forks is by looking at who [...]

  2. This is far the best article about this topic. I have this site under my bookmarks soon so long.

  3. As long as the license allows it. You do not need a permission to do a fork. You may, out of courtesy inform the developers. But the key point is that you are informing, not asking for permission. The permission was already given with the license.

    Another reason to do a fork is when you do not need 90% of the garbage a project has and just want to make a lean project.

    Lets face it, there are way too many open source projects that fall to the all but the kitchen sink approach. Which creates unnecessary complexity in code Which in turn creates a programming by faith paradigm. A simpler project, means more people able to understand it. Thus more eyes to spot any possible defect. In turn helping the original project (if your changes are placed in the same license).

    rxantos

    February 4, 2013 at 8:39 am

  4. Interesting articles, however the link in your section when to fork are pointing to bad pages returning no result found. Do you have a copy of those texts, it might be bery useful for me

    JPK

    August 22, 2014 at 6:46 am

    • Sorry I don’t. You can probably Google for the background story.

      James

      August 22, 2014 at 3:42 pm


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 718 other followers

%d bloggers like this: