During my first forays into OSS, over a period of 6+ years, I averaged 85 hours a week whilst being paid for a 40 hour week – and loved every minute of it! It wasn’t because I had to, but because I wanted to – all because OSS felt like play. Time was meaningless as I was constantly lost in flow state. Learning from that experience, our challenge today is to build OSS that are worth getting lost in again.
I started working in OSS during a time when systems were nascent and raw; expectations were fluid but evolving; and the scope of what was possible felt limitless. The hours were long – but I didn’t notice. I should point out that long hours are no badge of honour, nor is this a form of productivity boast. It’s just a testament to how engaging the work was back in the days when I was single and working with a tight-knit team where everyone was stationed far from home. Whilst not the same for most of my colleagues, for me it felt like an exploration, the most important quest of my career to date.
I was taking large swathes of information sets (eg user manuals, network log data, NMS extracts, etc, etc) about nation-wide networks, decoding them and stitching all the pieces into a complex tapestry. Modelling the unstructured and disparate into data sets that could be bulk loaded into databases that would then drive network visualisation engines. The challenge of creating whole-of-country, multi-domain, multi-tiered networks, for me, was a playground like I’d never had before. It was a game of logic, abstraction and design. The work pulled me in, not because it was easy, but because it was worth getting lost in.
When I look back on it, looking back on the flow states that I slipped into so easily, network visualisation was at the heart of the joy and sense of achievement. I was decoding and modelling sprawling national networks, translating them into interactive, dynamic visuals. These weren’t just pretty pictures – they were tools for understanding, communicating and operating networks at scale. They also helped others make sense of these networks from top-to-bottom, from end-to-end, where they’d only known segmentation and siloes previously.
As the pieces of data came together bit by bit, the visualisations provided a tangible sense of progress. Each new layer of clarity, each new network domain or service type added was a small win. Watching a complex system snap into visual coherence triggered the same satisfaction you get from solving a puzzle. It was motivating in ways I can’t even attempt to describe – not because someone told me it mattered but because I could see that it did.
This visual feedback loop was crucial. It gave weight to the work and direction to the hours. In a world where much of OSS is buried in endless streams of 1s and 0s, API flows, configuration files and data logs, the ability to actually see how it all hung together made the labour meaningful.
Those years weren’t just enjoyable – they were productive in the truest sense. We solved problems, built functionality and systems that, in many cases, are still quite rare nearly 25 years later. During a recent vendor selection event, we had the chance to view multiple product demos from some of the world’s most impressive and innovative OSS vendors. Two of the biggest made claims during the demos around functionality that they’d only just recently mastered – functionality that they thought was ground-breaking and that none of their competitors had delivered yet. That might have been true, but I had to smile knowing that our very special teams had cracked the code over two decades earlier.
They felt like career-defining achievements back then and I’m even prouder of them today.
That wasn’t a result of rigid planning or polished specifications. It came from immersion, experimentation and a sense of play, trying to achieve what the company had never achieved before (and probably few in the industry, not even the heavyweights, had achieved at that stage either).
When engineers are deeply engaged – not just assigned – they have the potential to build innovative solutions that are grounded in genuine understanding. I fear that as we dumb down our solutions and use algorithms to solve most problems automatically, we’re leaving less opportunities for the next generation to dive deep, understand fundamentals or feel that same sense of achievement we had.
Contrast that with today. Meetings, status updates, checklists, mindless / transactional work activities and micromanagement dominate too many OSS environments. The freedom to think deeply, to build without interruption, to solve hard problems, has been traded for a culture of constant visibility. But visibility doesn’t create value – clarity does.
In the modern OSS workspace we risk treating clever Engineers as task processors rather than thinkers, plugged into workflows that prioritise predictability over creativity.
Flow can’t be scheduled, much less achieved, in 30-minute windows. It requires uninterrupted time, psychological safety and tools that enable, rather than constrain, exploration. Without those, even the best engineers struggle to find that spark. This point alone is one of the greatest outcomes of leaving the workforce to run PAOSS – autonomy over the time I can spend to dive deep and get into flow state on whatever problems are at hand. That’s not to say the calendar is devoid of meetings, but it is now possible to allocate hours without interruption.
And I really want to highlight that this concept is just about work culture and behaviours. This is also about how we design our OSS UX/UI/CX – to minimise distractions and facilitate deep work, deep focus.
So now let’s try to summarise the key learnings from my distant past for today’s article:
Ironically, the tools I used way back when were bleeding edge in some ways, yet far from perfect. But they represented an enablement platform. They gave me room to model complex problems and think laterally. They didn’t need to be polished or heavily automated – they needed to facilitate curiosity. That was enough.
If we want OSS to evolve, we must return to that mindset. To build solutions that allow users to explore. To experiment. To play. Build systems that provide feedback, that clearly visualise progress, and reward curiosity. You could even argue that the best OSS aren’t built in 40-hour weeks or 2-week sprints. They’re built in the kind of time-warping flow that only play can produce, where 85 hour weeks routinely feel like 40.
Making your OSS easy to use isn’t about adding more “easyness” – it’s about subtracting what sucks. “To make your stuff “easier to use” you
The call came in at 5:43am. “The routers are acting up again down at 1313 Packetloss Lane” the night supervisor whispered, as if afraid the
Telco appears to be an increasingly tough industry. Demand for connectivity continues to soar, yet profitability and differentiation are becoming ever more difficult to achieve.
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
Here at Passionate About OSS, we are exactly that – Passionate About OSS (Operational Support Systems). We’re also passionate about BSS, NMS, or any other names you call the tools that help to operationalise your network.
