-
Our Offering
Our Offering
Learn more about our Kubernetes-enabled product offering.
-
Apprenda Cloud Platform
-
-
Resources
For Developers
For Everyone
- Support
- Contact Us
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:
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.
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.