Am I turning into the angry old guy who shakes his fist at the cloud(s)?

I know a guy. One of my great friends actually. We’ve known each other since kindergarten – back when we were five years old. He loves listening to the radio and watching old videos. He yearns for the old days – the simpler days, the easier days, the less tech-advanced days.

I’ve been finding myself looking at the constant stream of new content coming out of the tech, telco, and OSS industries with a healthy dose of scepticism. And I’ve started to wonder – am I becoming like that too? Am I the one shaking my fist at the cloud(s)?

But here’s the rub: I possibly am that angry old man, but I’m desperately trying to convince myself otherwise. (And no, that’s not a photo-realistic impression of me – yet).

I don’t yearn for the past. I don’t wish we could go back to the older, often simpler, ways of doing OSS. What I do want, however, is simpler OSS. Not old – just less complex. Not a focus on the tech and the latest buzzwords. Just solving the same old problems, but in more efficient / effective ways. Leveraging new technological opportunities to strip back branches from the variant tree, not add new branches on.

The Complexity Creep in OSS

OSS has come a long way from its early days. The scale, the sophistication, and the level of integration have grown exponentially. While this progress brings significant benefits, it has also introduced a creeping problem: unnecessary complexity. We have remarkably clever people working on OSS projects around the world. I just wished they were able to show off that cleverness with simplicity and reduction rather than complexity and endless additions.

We’ve layered new technology on top of old, added abstraction upon abstraction, and continually expanded the feature set in an attempt to meet every possible use case. The result? OSS stacks that are harder to manage, harder to integrate, and harder to use. Not to mention the continued Frankenstein-ing of UI/UX.

In many cases, the drive for innovation has led to over-engineering. We create solutions that are still solving yesterday’s problems but introduce new ones (often in the form of tech debt) today. We introduce frameworks that promise flexibility but add layers of rigidity instead (or just layers for the sake of layers – where each layer becomes just another thing to manage and another component that can potentially break). We design with best intentions, but we sometimes forget the fundamental rule: OSS are meant to simplify operations, not complicate them.

If anything, we need to reverse the creep.

Let me cite just one example. Back when I first started working on OSS projects, field techs used to do 2-3 year cadetships under the guidance of master craftsmen to learn how to build telco networks. The OSS tools were designed by engineers for engineers with hard-core engineering skills and knowledge. Today, I know of telcos that run 2 week courses to certify their field workforce, who are often contractors rather than staff these days. The hard-core OSP (outside plant) tools of the past offered amazing visibility of, and control over, the details. But they’re total overkill for many of today’s minimally-trained workers. They now need to be super-fast and efficient at handling the common cases (but hopefully still with the ability to drill down into the weeds for the rare cases or the die hards – or perhaps our OSS need to do more of the hard-core stuff in the background so the users can just get stuff done!). Doing a code-use review will help to tell you which granular functionality is still being used and which has quietly obsoleted itself over time.

Are We Solving Problems or Creating New Ones?

The OSS industry is filled with cutting-edge advancements: AI-driven operations, network slicing, intent-based automation, cloud-native architectures, network virtualisation and more. These innovations bring significant potential. But how often do we step back and ask: Are these actually making our jobs easier, or are they just adding complexity for complexity’s sake?

• Are our new OSS platforms intuitive and easy to deploy, or do they require months (or years) of professional services just to get up and running?
• Are we replacing old inefficiencies, or are we just shifting them around?
• Are we reducing operational workload, or are we introducing new failure points that require even more oversight?
• Are we responding to the networks we manage – where network equipment vendors keep adding new (but often unnecessary) features that just expand the variant tree (see the Pyramid of Pain)
• Are we making OSS transformation decisions harder because of the proliferation of things that need to be considered before landing on the agreed way forward

Do you notice a theme flowing through those questions? Do you notice that the complexity and associated delays are generally for the benefit of vendors or suppliers rather than the network operators, especially those who charge on a time and materials basis?

We often find ourselves managing more technical debt, navigating steeper learning curves, and maintaining a growing web of interdependent systems. I’m shaking my fist because somewhere along the way, we may have lost sight of what OSS is supposed to achieve: efficiency, automation, and simplicity.

The Path Forward: Smarter, Not More Complex

If we truly want to move OSS forward, we need to embrace a different mindset – one that prioritises simplification over expansion. How do we do that?

1. Eliminate the useless (or no longer used)
   1. Many OSS platforms still support legacy features and functionalities that add complexity without delivering impact (refer to what we can learn from rocket scientists)
   2. Build your platform so you can measure which parts of the code-base and functionality is actually being used
   3. Measure end-to-end flows through your solution (and to/from adjacent systems) to know whether end-users are able to use the solutions effectively
   4. Understand the true measures / metrics of success for clients, and then whether you’re actively seeking to optimise those (rather than just adding more features)
   5. Not just doing addition projects, but also subtraction projects to remove outdated / obsolete / unused components
   6. Consider measuring for the Net Simplicity Score (NSS)
   7. How do you measure up on the 13 OSS Friction Continuums?
2. Automate the repetitive
   1. Instead of adding more layers of manual intervention and bespoke-ness, identify what can be made more standardised and more repeatable (even there are only 50% repeatable and 50% bespoke elements out of a complex process or transaction)
   2. For where there’s repeatability, there can be continual improvement
   3. And where there’s repeatability, there’s a better chance of automation introducing cost-benefit
3. Understand, then double down on what truly moves the needle
   1. Refer to the rocket science article again
   2. Not every cutting-edge technology needs to be integrated into OSS. How do you quickly assess whether something is worth investing in (hint: we use the concept of a RIAT – Rapid Impact Assessment Tool)
   3. Do you truly know what moves the needle for your organisation? Qualitatively, or quantitatively?
   4. Focus on the core mission of OSS: reducing operational complexity, improving efficiency, and delivering real-world value

Summarising

I still haven’t convinced myself about whether I am the angry old man yet. (I think) The goal of my fist-shaking isn’t to resist change, but to resist unnecessary complexity.

As much as I’m in awe of the achievements of the OSS of the past, I’m even more excited by the improvements we can make in the future. I can’t wait to be involved in that ongoing evolution.

To reiterate:

• Eliminate the useless (or no longer used)
• Automate the repetitive, and
• Understand, then double down on what truly moves the needle

But here’s the question for you, especially if you’re a regular reader of the articles on PAOSS, should I be spending less time shaking my fists at the clouds??