Sometimes an OSS budget is too big

Wait, “What??” I hear you ask! No it can’t.

Have you ever worked on a BIG OSS project? One where the budget is in the hundreds of millions of dollars? Or even tens of millions of dollars? Have those big projects delivered your best transformation outcomes? Or have other projects, with more constrained budgets, been your more successful ones?

Big budgets come with big ambitions. Lots of scope that needs to be delivered. Lots of features. Lots of expectations. (and lots of risk, but let’s not get into that just yet).

I’m sure you’ve heard the old saying that any job will expand to fill the available time. The same tends to be true of budgets. With a massive budget, we tend to expand our thinking on what can be delivered…. albeit an expansion into lots and lots of incremental changes or functions in many cases.

With a big enough budget, we often begin to think we can customise everything. In fact modern IT frameworks like microservices and cloud-native architectures, plus continual development pipelines encourage us to take a “we can build anything we want” mindset.

Big budgets can lull us into a belief that we can take on the world. Aim big and build it all in-house. Build an all-new solution to cater for every whim of every person who will use the tools we build. Build something brand new that overcomes all the problems of the past. Sounds like an ideal project for most of us OSS implementers right? Not so fast!!

Clearly I’m all for big-picture thinking in the world of OSS. We certainly need to think differently and break out of many of the mental models we’ve been perpetuating for years. We need to break out of the legacy approaches and tools too.

However, I’ve also seen the profligacy that comes with massive in-house or heavily customised solutions. By contrast, some of the most fit-for-purpose and innovative OSS solutions I’ve seen have had tiny budgets comparatively.

The latter, where the budgets are constrained, have usually been clever in their use of constrained innovation. They’ve been very selective in what they re-use or buy off the shelf versus what they customise or build bespoke for their needs.

There’s so much “special snowflake” thinking in the world of telco. In theory, that’s justified because every telco IS different. Every OSS project is different and should be different. But that doesn’t mean it has to be entirely bespoke.

What we often overlook is that repeatable core building blocks plus a select few innovations / customisations can still give the appearance of a bespoke solution. It’s the 80/20 rule – 80% repeatable, 20% custom – and still gives a highly differentiated solution.Repeatability is under-valued in the world of OSS. Repeatability allows for continual improvement. Each time we do something, we refine and do it better. If we’re building something brand new from scratch, it means we can’t learn from the mistakes of the past. This pottery reference is a perfect example of the concept. (the quote, “the “quality” group had sat theorizing about perfection, and in the end had little more to show for their efforts than grandiose theories and a pile of dead clay”, sounds very reminiscent of some big-budget OSS projects I’ve worked on)

So, you might be wondering how we can increase repeatability on OSS projects? Off-the-shelf products are one example. They’ve usually been implemented many times by their vendors / integrators. They’ve already been battle-tested and refined to reduce foibles. But we also need to find a careful balance because off-the-shelf products often have too much rarely-used functionality baked in, making them bloated and unintuitive.

Many big contracts are known to start with off-the-shelf products. Where things often go wrong is that unconstrained thinking allows them to become a Frankenstein of customisations (often into the thousands of changes). This impacts the Total Cost of Ownership (TCO) as customised solutions become hard to version uplift after a new release from the OEM. Then heavily customised solutions are even harder to churn across to a more modern platform at some point in future.

I’ve recently seen a project fail to deliver after 2 years of effort by a big team…. even though the off-the-shelf solution delivered ~95% of required functionality straight out of the box. Instead of getting minimum viable workflows established and getting it in operation quickly, the focus was on what it couldn’t do rather than what it could. Sometimes it’s better to evolve our processes and practices to fit within the limitations of the products rather than forcing the products to unnaturally mould to every whim of the buyer.

I’ve seen another T1 telco spend millions of dollars developing an in-house solution and taking over two years to deliver anything to their sponsors when a more complete, existing open-source solution could’ve delivered business value within two weeks on a tiny budget. (I should caveat this by saying the open-source solution was more complete, but didn’t have a couple of important features the telco injected into their in-house solution. However, those same features could’ve been easily inserted into the open source solution, probably also within only a few weeks)

Just because we can, doesn’t mean we should. OSS/BSS are software (mostly) and software is infinitely malleable. Sometimes we need to force constraints even if the budget and team is large and myriad changes can be made.

Just because we can make thousands of customisations, doesn’t mean we should.

We should always force the team to focus on being tight, resourceful and encouraged to make small but bold experiments. This allows the team to confirm what really matters and only then commit to customisation as a last resort. This means we need an understanding of the functionality long tail, and only customising the stuff that really moves the needle.

Leave us a comment below about your experiences working with big vs smaller budgets. Which produced more resourcefulness? Which produced better results for the end-users? What did you learn from big or small-budget projects?

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

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.