I’ve just finished reading the book, “Elon Musk,” by Walter Isaacson. It’s a fascinating study of a fascinating, and highly polarising engineer. 
Polarising, but also inspiring (inspiring what to avoid as much as inspiring what one could/should/can do). Musk’s biography cites example after example of his ability to think big, but also think very small to solve problems across complex industries like space travel and automobiles. Yet it had me repeatedly thinking about how to apply similar thinking to improve the world of OSS.
One example is what Musk calls the Idiot Index.
“[Musk developed] the “idiot index,” which calculated how much more costly a finished product was than the cost of its basic materials. If a product had a high idiot index, its cost could be reduced significantly by devising more efficient manufacturing techniques.”
It is an easily applied rule-of-thumb that comments on how efficient something is to build. It also hints at how big a profit margin is built into its construction by suppliers.
As Jeff Bezos has said:
“Your margin is my opportunity.”
The costs and risks and decision delays and complexity and inefficiency run rampant through our industry. It manifests as systems that are overly complicated, requiring far more effort, time, and resources than initially anticipated, while still delivering suboptimal results and exacerbating risks.
Here’s how this aspect of the “idiot index” could apply to OSS:
Many OSS projects start with relatively simple objectives, such as improving network management, automating service delivery, or streamlining operational workflows. However, as the project progresses the creativity and intellect of the many very clever Engineers that work on OSS projects actually introduce more problems than they solve. Complexity creeps in due to additional customisations, integration with legacy systems, compliance with various standards, or dealing with multi-vendor environments. The final OSS product might become a tangled web of bespoke software, custom workflows, and manual workarounds that are far more complex than originally envisioned. This mismatch between the perceived simplicity of the initial solution and the bloated complexity of the final product would reflect a high idiot index.
OSS projects often suffer from feature creep, where more and more functionality is added to the system during development. While these features might seem necessary at the time, they can result in an overly complex product that is difficult to implement, use, or maintain. A high idiot index in this scenario would represent the gap between the belief that these features add value and the reality that they complicate the system without delivering proportional benefits. You’ve seen this story before in our long-tail graph below. It’s about how we have a tendency to build features that are at the far right edge of the blue arrow (where we barely move the needle) vs ruthlessly refining (red shaded box – think small) or reinventing (green arrow – think big) the stuff that really matters.
Another common issue is that the final OSS product might be extremely powerful but difficult for users to operate. The development process might focus too heavily on technical capabilities and fail to consider the practical usability for day-to-day operations. For example, a system might offer advanced automation features, but if the interface is too complex or unintuitive for operators to use effectively, the perceived value of the final product is diminished. The idiot index would highlight the gap between how advanced the product seems to be, yet how difficult it is to actually use (especially for the less experienced resources that are often tasked with using our OSS at scale, at the coal-face of customer interactions).
As OSS systems must integrate with a wide range of other tools, databases, and networks, the complexity of achieving seamless interoperability can be vastly underestimated. Companies may start with the assumption that they can easily connect different systems using APIs or middleware, but the reality often involves significant integration challenges, leading to delays, cost overruns, and a final product that is overly complicated and fragile. The idiot index here would represent the overconfidence in assuming integration is easy compared to the real difficulty and cost of achieving it.
In an attempt to meet specific organisational requirements, many OSS projects get bogged down by excessive customisation (again, with very clever Engineers inventing new ways of customising). While the core OSS platform might be relatively simple, each custom feature or modification adds layers of complexity. The result is often a highly customised system that is difficult to upgrade, maintain, or scale. The idiot index here would reflect the gap between “out of the box” and customised.
Automation is a major selling point in OSS, as the promise of automation is often used to form the foundation of a business case. However, if automation processes are overcomplicated, they can create more problems than they solve. For instance, organisations might attempt to automate too many processes too quickly, without properly understanding the full operational impact. If these automation efforts lead to convoluted workflows, errors, or frequent manual intervention, the result is an overly complex system that contradicts the original goal of simplicity and efficiency. The idiot index here would show how the expectation of smooth automation contrasts with the reality of operational complexity. The autobiography cites an example where Musk actually strips his giga-factories of robots because he mandated too much automation before they fully understood all the points on the assembly line.
Even after implementation, a highly complex OSS system may require constant maintenance, updates, and support to function correctly. If the final product is so complex that it requires a dedicated team of specialists to manage it, high ongoing costs are sure to follow (for buyer and seller alike). The idiot index would capture this mismatch between the desired low cost of maintaining the system and the reality of it becoming a resource drain for years to come.
Another fascinating insight from the book came from its Full Self-Driving (FSD) software. Initially FSD required over 300k lines of explicit C++ code, with all the logic (eg identifying red vs green lights, stop signs, etc, etc) built in. But then FSD 1.0 was entirely obsoleted by an artificial neural network (ANN) implementation (FSD 2.0). In FSD 2.0, the neural nets have been trained by millions of hours of real-life video clips of watching people drive their Teslas. It now makes decisions using the ANN based on millions of past observations but only using hundreds of lines of code (as opposed to hundreds of thousands). OSS are also machines designed to make repeatable decisions across high-volumes of data. Will we see the next generation of AI native OSS with much slimmer business logic layers (and associated code-bases)? Will incumbent OSS providers be too scared to discard the asset (code-base) that they’ve invested so heavily in?
Musk has mastered the skill of starting with an ambitious goal and working backwards to create a successful business plan to achieve it. For example, becoming interplanetary (establishing a colony on Mars) is the objective and a constellation of communications satellites (Starlink) is the go-to-market model that will fund missions to Mars.
Whilst we might delight in Musk’s disruption of the energy, battery and internal combustion engine industries, some might not realise that he is also an existential threat to the telco and OSS industries.
This by-product of his interplanetary objective has the potential to obsolete our traditional, terrestrial comms networks. Like many other industries, Musk has found a way to drastically reduce the cost-base of access networks (presumedly by applying the Idiot Index to designing, building and launching comms satellites). If LEO (Low Earth Orbit) satellite networks do disrupt the business models of traditional access network carriers, it has the potential to destroy the OSS industry in the process (the OSS Doomsday Scenario that we first discussed a few years ago).
Have you ever had an OSS or BSS project that’s impacted by poor data quality? The problem of data integrity gets raised on almost every
“One of my favorite things about designing software is designing the defaults. The defaults define the experience for everyone out of the box. And, therefore,
Have you ever been tasked with mapping out the processes for the telco you work for? Either as a way of documenting current state, or
In the last week alone, I’ve had two potent reminders that the world of OSS is simply (pun intended) too complex. This manifests in many
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.
