What if the Real Legacy in OSS isn’t Code – But Culture?

Everyone’s chasing a better OSS, which for most means planning the next OSS platform migration.
Yet we rarely ask the key questions that guarantees long-term success:

• “When was the last time someone in your team really challenged the way things are done?”
• “Does everyone on your team feel empowered / safe to pose radical new ideas (not just incremental suggestions)?”
• “Are we designing for day 1 after handover or 5+ years into the future?“

We see teams invest millions in systems transformations that fail to stick. Why? A variety of reasons that include technology, process and definitely people. It’s the people and culture that we’ll explore more deeply in this article via a series of questions for you to ponder.

.

Culture Debt: The Hidden Legacy OSS Projects Rarely Account For

Most OSS teams can spot technical debt a mile away. It’s a patchwork of integrations, unreliable workflows, code that was written during the time of the dinosaurs and is still somehow clinging to life. But ask about culture debt, and the room goes quiet. It’s just not something we ask ourselves. Or maybe we just ask about it in different ways rather than the term, “culture debt.”

Culture debt is more dangerous than technical debt because it’s invisible. Well, at least it’s invisible until it completely obviously isn’t.

It’s the accumulation of behaviours, fears and unspoken rules that shape and constrain how your team thinks. And  perhaps more importantly, what they don’t dare to think about.

You can refactor a monolith. But unlike outdated systems, you can’t simply replace culture with a new stack. You can’t Git revert a mindset (although with the hype of AI running crazy at the moment, perhaps some might suggest we’re not too far away from achieving this!).

The real trap that I see happening over and over is believing that new tooling will solve for old thinking and data. Yet, the specifications of new systems tend to be built on old thinking, thus perpetuating old thinking. We see “old thinking” popping up in RFP documents consistently.

In another example, I recently spoke with a GM of Product whose R&D budget was slashed by more than half after being acquired. The new buyers wanted the old systems and revenues, not the new product roadmaps that their clients were desperately waiting for.

From another perspective, as an industry, we tend to design for day 1 after OSS handover rather than for what the world will look like in 5-10 years when the solution will still hopefully be operating. This is the core concept of the reframing exercises that PAOSS runs with many of our clients. (Note: If you’d like a copy of the Reframing Pack we use to guide discussions with our clients, leave us a comment below that says “Reframe” and we’ll send you a copy).

Why do we still assume the next platform upgrade will overcome years of cultural inertia? Until we talk about culture debt with the same level of priority / urgency as system features and performance, the transformation story will also tend to repeat itself.

.

The Questions that Either Get You Fired…. or Move the Industry Forward

In every successful OSS transformation, there’s a moment that’s never written down in any documentation (well, maybe now with AI meeting summaries there is). It’s the moment when a question is asked that completely changes the collective train of thoughts or perceptions about the status quo.

I’ve experienced many of those, but one in particular sticks with me. It was my first project working under an Agile delivery model. We were dependent on some long-lead-time hardware, which had to be specified, then quantified, then ordered, then built, then delivered, then commissioned, then made available to the team to start their software build and configuration phase. As you can tell, this put a major pause in the delivery timeline.

One of the other members of the team asked the questions, “How can we deliver value earlier and what would be some more lateral ways of defining business value?” Those two questions were a masterstroke and led to us coming up with a variety of different ways to slice and dice the scope on that project, reducing hardware dependencies along the way. It looked at the constraints and reframed them.

Depending on the project environment, there are so many other questions that are so left-field that we might be barely brave enough to ask, such as:

• “Why are we still doing this process when no one knows why it exists?”
• “What if we treated our OSS like a product to be used by telco subscribers, not NOC operators, thus flipping the script of them being profit centres, not a cost centre?”
• “Who benefits from this complexity and who is disadvantaged?”
• “Why does it take so long for us to find the best-fit solution for our upcoming transformation?”

These questions are often met with eye-rolls, organisational “antibodies,” or outright resistance. But they might just be the questions that change everything. The irony? The people who ask these questions aren’t naive or ill-informed. They’re often the people who care so much that they want to challenge the stagnation.

Unfortunately, in many OSS environments, that kind of curiosity can feel dangerous. Who in your team has permission to say, “This doesn’t make sense anymore”? Everyone, from the newest of newbies (with fresh eyes) or only the twenty-year veteran (with the hardened stare)?

Every team needs its internal contrarians, the people who aren’t satisfied with “how it’s always been done.” Without them, your OSS project might be technically perfect, but strategically irrelevant (like the OSStracod). Funnily enough, it’s often the ones with least experience that might ask the naive, yet obvious, or importantly contrarian questions… if they’re encouraged and empowered to do so.

.

Spotting the Signs: Are You in a Room That Punishes Curiosity and Experimentation?

You know you’re in the wrong OSS room when:

• Every discussion ends with “let’s be pragmatic” or “let’s not bite off more than we can chew”
• Wild ideas die before they’re even debated
• Meetings sound like status reports, not exploration sessions
• Everyone agrees too quickly with the small numbers of “loud voices” in the room (and feels ostracised or punished for not)
• There’s more fear of failure than openness to experimentation

These aren’t just annoying team dynamics. They’re signals of a low-trust culture. The kind that only considers safe, incremental change that satisfies KPIs while ignoring the exponential possibilities that lay before us.

The same GM mentioned above felt totally isolated by his executives when he or other members of his team raised new ideas and innovations. They eventually just stopped raising ideas because they felt it put their careers at risk. Their clients could clearly see this lack of innovation and became frustrated.

By contrast, high-agency OSS teams don’t wait for permission to ask better questions. They experiment, debate, challenge, and adapt because they know that curiosity is the foundations of growth.

Consider the question, “When did we last invite someone from outside the telco bubble to challenge our thinking?” Often, the most valuable OSS insights come from people who aren’t yet conditioned by legacy assumptions. But first, the room needs to welcome them.

.

OSS Innovation Isn’t About Tools. It’s About the Permission to Rethink and Reframe Everything.

You can buy the best stack money can build, but if no one in your team feels safe asking “how do we know whether there’s something better?”, it won’t matter. Innovation isn’t a feature. It’s a function of the environment.

The most transformative OSS projects don’t succeed because they have better tech stacks (although that certainly helps). They succeed because they are led by people who are willing to rethink their architectures, their processes, their assumptions and more.

For as proud as I am of the amazing solutions we’ve collectively built to help network operators, I still feel we’re miles away from everything that is still yet to be achieved.

Real transformation doesn’t begin with implementation plans. It begins when someone dares to say, “We’re solving the wrong problem” or “What layers of friction should we be removing?” or “If we had a choice of using our current way of working, would anyone adopt it voluntarily?”

The next time your team plans a system migration, pause. Look around the room. Ask not what you’re building, but who you’re becoming and what your solutions are becoming while you build it.

[Reminder: If you’d like a copy of the Reframing Pack we use to guide discussions with our clients, leave us a comment below that says “Reframe” and we’ll send you a copy]