“Many drops make a bucket, many buckets make a pond, many ponds make a lake, and many lakes make an ocean.”
One of the big OSS challenges for vendors and customers alike is version management.
Let’s say Customer X installs version 1.5.3 of Vendor Y’s exciting new resource management software. This software is a central component of Customer X’s best-of-breed OSS suite and there are numerous integrations of other software to it. Over time, Vendor Y enhances its solution, going through a number of releases that take it to 2.1.7. But Customer X still remains with 1.5.3 because of the worry that integrations with their various other tools will fail or require too much work. This is the integration tax at work – the chessboard analogy.
Customer X would love to be at 2.1.7 because of all the advanced new features that it could be using. Vendor Y would love them to be at the latest version of the software also, to decrease the number of versions of their software that they have to support. The less forks that require curation, the more progress on the main line of code.
Unfortunately, it’s quite common for an OSS vendor to end up supporting many different branches, possibly a different branch for every customer, especially if their customer base consists primarily of tier-1 CSPs.
This is a quandary for vendor and customer alike. I use this analogy – each new release is like a hole in a roof. When there is a storm, rain gets in. The customer has the option of patching the roof (patching the software – and related integrations) or placing a bucket under the leak (satisficing with the current version). As time goes by without patching, your floor becomes covered with more and more buckets.
It’s easy to say on paper that Customer X should just make every patch, incremental upgrades rather than monumental upgrades, but the reality is not that easy. You spend all of your time upgrading rather than making significant improvements to your OSS suite.
Release management needs a joint release simplification strategy from vendor and customer alike when signing any big OSS contract as well as joint initiative thereafter. The alternative is that the buckets becomes a pond, a lake, an ocean.
Removing the strings and pulleys of the chessboard analogy helps too.Read the Passionate About OSS Blog for more or Subscribe to the Passionate About OSS Blog by Email