Fork me. Version rippling

The quickest way to enter the fourth dimension is through an operation called Fork. A fork copies a three-dimensional repository, creating two equal but distinct repositories. A commit performed against one repository has no impact on the other, which means the codebases contained within will become more and more different, and eventually evolve into different applications altogether.”
Alex Papadimoulis
, here on theDailyWTF.

The biggest CSPs tend to have a range of different OSS products in their suite of tools. They also have a tendency to heavily modify them to fit their highly exacting needs.

This can represent a huge challenge for their OSS vendors. The vendors are constantly enhancing and evolving their products, releasing version updates periodically. They would ideally like to maintain a single codebase for ease of support, release management, etc and general consistency of products across all their customers.

Unfortunately a version change to Product A can have ripple-down effects on the interfaces and configurations of integrated products, especially the highly customised ones of large CSPs. The CSPs tend to have the power to force the vendor to leave out-dated products in-situ, simply to avoid ripple-damage.

This leaves the vendor in a position of having to support multiple versions across their customer base. It forks up their plans for simplified support.

To be honest, I haven’t seen any OSS vendor to tier-one carriers completely overcome this problem, so I would love to hear about what you perceive to be the most successful approach.

Read the Passionate About OSS Blog for more or Subscribe to the Passionate About OSS Blog by Email

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.