Forking: Development Coordination Technique or Project Correction Tactic?


By Atos Apprenda Support

A week ago I wrote a post that really riled up some of the folks at CloudFoundry and its partners. They took umbrage with my position; focusing energy on claims of FUD and that I don’t understand “modern” development and forking.

One thing was obvious: some people have “modernized” the word forking to use it to exclusively define forking in the context of Distributed Version Control Systems (DVCS). Unfortunately, this is not the only (nor is it the traditional) context in which we use the word “fork” in the software world. I think sorting some of this out well help more properly articulate what we meant,” in the context of my Cloud Foundry post.

DVCS has introduced forking as a construct for creating a copy of project source and then merging modifications of that copy back into the original. DVCS has trivialized what, prior to DVCS, was a nightmare. I worked on dozens of projects in the Subversion and CVS days, where multiple outstanding branches were a *nightmare,* so we avoided it at all costs. Stephen O’Grady wrote an excellent post on forking a while back where the following was the result of an exchange with a technical executive:

“I don’t believe in it,” is what an otherwise pragmatic CTO type of a major exchange told me a few weeks ago about distributed version control generally, Git specifically. “My developers work next to each other – they keep bugging me about it – but if we had branches everywhere we’d be stepping all over each other.” (Read more here)

Notice anything? The executive made reference to “branches”. Here’s the crux of the issue: traditionally, “branching” was the only technique for making isolated changes to projects, and merging was extremely difficult. Forking, in the context of version control, has created an abstraction layer above branching that allows anyone to clone a repository and make changes against that clone, and even branch, and finally rebase (copy local changes over a new version of master) and merge.

This is exactly why Apprenda has been a Mercurial shop for a long time. We dumped SVN because of the challenges articulated by the CTO in Grady’s post. We have developers spread across vast geographies and need to make changes in parallel without wanting to deal with the cost. Mercurial was a huge step in correcting this.

In this context, “forking” is a positive thing that is ultimately good for our customers. It means we can do more things in parallel more quickly and deal with contributions from our developers in a low-friction way, thereby resulting in value expeditiously reaching the market. I think we, at Apprenda, have a better handle than most  on what constitutes “modern” development. Because of “forking,” our development coordination is, to a greater extent, fluid.

Now, I need to address the “other” definition of forking. In my Cloud Foundry post, my reference to forking was in a project correction and market-action context. This is something any customer of OSS *should* and *does* care about. In this context, Wikipedia describes forking the best and even states:

The term often implies not merely a development branch, but a split in the developer community, a form of schism.

This is not good for the customer *unless* the fork is to remediate a significant political or project issue in the community AND that the community converges to a critical mass fork. This type of fork isn’t good for the customer because it fractures the community, creates splits in the code base that are purposely *not* being reconciled and causes product divergence. This results in the customer having to wade through the garbage that comes with the market level forking in order to make decisions. This is bad news, and ultimately adds significant cost to adopting OSS if a project is significantly fractured.

My Cloud Foundry post was digging into the market level forking, not the development coordination technique. Clearly, my expectation is that Cloud Foundry and all partners are using “modern” development approaches with DVCS. The reason I wrote the post is that I believe my customers deserve the best technology for the best value, and in the field, they frequently receive misinformation. In the context of Cloud Foundry, the questions that prompted the post were:

  1. Cloud Foundry community leads are described in analyst and press briefings as “standalone forks.” Are these not market level forks? It wouldn’t seem meaningful to describe their development contribution model to the market.
  2. Some Cloud Foundry community leads have described themselves as “standalone forks” with long standing open pull requests for support around non-trivial platform features like .NET. Has VMware, or whoever maintains the project, reconciled these? If so, why are partners like ActiveState still bundling IronFoundry for .NET support? Wouldn’t it be in the project core?
  3. Why are community leads referring to Cloud Foundry as a “library” incapable of being its own PaaS, but then Cloud Foundry is touted as a standalone PaaS
  4. Why is there no Java community lead? Is the VMware/Pivotal commercial offering focusing on owning Java and .NET (given #2) for their enterprise play?

All of these questions seem to point to the fact that multiple distributions and real “market level” forks exist. These are questions and issues I’m concerned with, and if this is FUD – then so be it. My customers care, and so do I.

Atos Apprenda Support

View Comments
  1. Phillip RuggeraDecember 3, 2016

    Thank you for bringing some clarity to this “open source” project. I have been looking for ways I could participate in the development effort and have not found any interest in my doing so. It’s all about providing OSS hype for the vendors to use to market their wares.

Comments are closed.