After working with countless OSS product teams over the years, we’ve noticed one universal truth: they’re all overloaded by huge backlogs of feature requests. But when we saw this image of SpaceX’s Raptor engine evolution, it highlighted a vital lesson – one that has the potential to help guide how OSS development teams prioritise their work.
However, we’ll also provide you with a really interesting twist – one that describes how OSS buyers / sponsors can help keep OSS development teams focused.
In almost every OSS team, feature backlogs grow endlessly. Requests pour in from customers, internal stakeholders and even regulatory requirements, creating an overwhelming to-do list. With such a huge volume of work, teams often resort to chipping away at minor enhancements – fixing UI elements, tweaking performance metrics, or adding convenience features.
It’s far easier to keep adding simple features out to the far right of the features vs benefits graph below.
While these small changes may offer marginal benefits (as represented by the height of the y-axis), they rarely lead to transformative improvements.
The challenge is that, without a clear strategy, teams risk investing their time in iterations that don’t fundamentally improve the product. Just as a rocket engine needs thrust and weight reduction to break free from gravity, OSS teams need impactful improvements (and weight reduction?) to push their products forward in a meaningful way. The key is recognising which changes will generate significant, exponential benefits (the red box and green arrow) rather than just minor refinements (the blue arrow). The other key is recognising which changes could ultimately turn you solution into an ostracod.
SpaceX’s Raptor engine didn’t reach its current capability by making endless minor refinements to Raptor 1. Instead, SpaceX took a bold approach – identifying the fundamental limitations of their early designs and committing to major structural changes. Rather than simply widening fuel lines or tweaking individual components, they focused on redesigning the entire system to maximise thrust, efficiency, and reliability. Raptor 2 was a complete overhaul, and Raptor 3 continues this trend of massive leaps forward on metrics that do move the needle (or move the rocket in this case):
OSS teams have the opportunity to adopt the same mindset. Clearly the “blue arrow” features aren’t producing 10x benefits, nor are they requiring 10x rethinking or reframing.
The blue arrow features are relatively easy – just take what we’ve currently got and refine it.
The red box features are harder – take what we’ve currently got and refactor it to drive far better metrics.
The green arrow features are the hardest – this often requires going back to first principles and totally reinventing the way things have always been done to come up with an entirely new and much better way. The Raptor image above shows green arrow thinking at work.
A critical lesson from the Raptor evolution is that not all improvements contribute equally to success. Some changes provide incremental benefits, while others drive 10x improvements. The most successful engineering teams, whether in aerospace or software, know how to distinguish between the two.
One of the most important factors is prioritising performance (red box) over feature count (blue arrow). Adding more functionality can feel productive, but if the core system remains non-intuitive, slow, unreliable, or difficult to scale, then the overall product won’t truly improve. Just as Raptor 2 was an overhaul that streamlined its design to reduce unnecessary complexity, OSS teams can also focus on enhancing performance, reliability, and efficiency before adding new features.
Additionally, some performance gains compound over time. Just as each Raptor version builds upon the breakthroughs of the previous one, OSS teams can focus on evolutions that create a strong foundation for future development. Prioritising scalable design enhancements (eg transitioning from thick-client to cloud-native architectures or optimising data processing pipelines), can ensure that every future upgrade becomes easier.
Generally speaking, simplification leads to reliability. One of the most underappreciated engineering principles is that complexity often leads to fragility (the theory is that the larger the variant tree, the more moving parts, the more things that can go wrong and the harder it is to have sufficient test coverage). Raptor 2 removed unnecessary parts, making the system more robust. OSS teams can take the same approach. Eliminating outdated or unused code, reducing dependencies and streamlining workflows will often yield greater long-term benefits than adding more features.
Raptor 2 wasn’t just more powerful than Raptor 1. It was simpler, more efficient and easier to manufacture. . By applying the lessons of focused iteration from SpaceX, OSS teams can ensure that every improvement genuinely moves their project forward—rather than just adding more weight to an already overloaded system.
So here’s the challenge for all of us in the world of OSS. We should be asking: What’s the equivalent of increasing thrust by 20% or simplifying the entire system? What are the step-changes in performance, efficiency, or user experience? Prioritising transformative improvements – whether it’s re-architecting for scalability, automating key processes, or dramatically improving performance – ensures that every iteration truly drives progress.
Now, I promised you a twist. A bonus fifth lesson. So far, we’ve suggested lessons for the OSS product development teams (OSS Sellers). But perhaps the biggest driver of change can actually come from OSS Buyers.
OSS Vendor behaviour is predominantly based on the Darwin Theory – survival of the fittest. In the case of OSS, this means the Sellers who manage to win the most, and most profitable, OSS procurement events get to survive.
OSS Vendors have learnt that the behaviour of showing off the most features is most likely to win. It’s an arms race – If a competitor shows 1,000,000 features and you can show 1,000,001 then you’re a better chance of winning an RFP in many cases. The OSS peacocks win because their mates choose the ones with the brighter plumage.
But what if the OSS Buyers didn’t evaluate on list of features alone? What if they / we found a better way of evaluating by performance, efficiency and/or user experience instead?
Then we might get more OSS looking like Raptor 3, not the more complex Raptor 1 engines.
What do you think? What other effort prioritisation lessons have you learnt along the way?
If you’d like to chat about effort prioritisation on your next OSS project, we’d be delighted to hear from you.
We love doing The Passionate About OSS Podcast, but it’s been a loooong time between episodes. Too long. We love the conversations, but the
Yesterday marked a an exciting milestone for the PAOSS business. We made our very first commission payment to an affiliate whose introduction led to a
Your OSS is either a catalyst for innovation or a roadblock to progress for your business. The same strategies that built your OSS might now
For decades, OSS has followed the same pattern: design, then keep adding lots more “baked-in” capabilities into a complex OSS UI, process inputs, generate outputs.
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.
