Just one more bucket

Many drops make a bucket, many buckets make a pond, many ponds make a lake, and many lakes make an ocean.”
Percy Ross

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.

If this article was helpful, subscribe to the Passionate About OSS Blog to get each new post sent directly to your inbox. 100% free of charge and free of spam.

Our Solutions


Most Recent Articles

4 Responses

  1. Very true. This also depends on the NEP ems versions. Some NEPs have different versions of the ems running for a customer. This necessitates the OSS vendor to maintain different versions of the ‘adaptors’. Standardization of the NBI is crucial but NEPs who claim adherence to standards like TMF814 don’t really comply fully to it, keeping some of it proprietary to differentiation with competing NEPs. This has a domino effect starting from the network layer all the way up the OSS stack.

  2. Hi Steelysan,
    Thanks for your comments and contribution to the PAOSS community.
    Yes, “compliance” can be a very loose term in our industry. I have seen organisation claim TMF compliance just because they’re able to put some circles around boxes in the eTOM or TAM diagrams. πŸ™‚

  3. I love your incisive blog and topics which are very relevant.

    The comments above bring me to the topic of Best of breed Vs best of suite discussion. I’m not sure if you have discussed the pros and cons of both in your earlier posts. Tier 2/3 operators tend to go best of suite due to perceived lower ‘integration tax’, thereby foregoing some of the superior functionality aspects of a best of breed solution and the lure of lower integration tax.

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.