Release early, release often

by | 21.10.2020 | Product Management

I guess we’ve all heard this. Here’s a little background to why this might be a real good approach for you – or why not.


The Linux Kernel is developed in a bazaar-style approach. Historically, software has been built in a more cathedral-style approach as in “huge increments, huge cycles”.

The bazaar-style approach is arguably what made Linux so successful as a software development project. It introduced kind of a swarm-intelligence to stakeholdership, fueled by the real-time connectivity the internet provides.

Cathedral-style Development

  • long release cycles
  • bugs are fixed in between huge releases
  • slow traction

In the cathedral-builder view of programming, bugs and development problems are tricky, insidious, deep phenomena. It takes months of scrutiny by a dedicated few to develop confidence that you’ve winkled them all out. Thus the long release intervals, and the inevitable disappointment when long-awaited releases are not perfect.

Bazaar-style Development

  • Release early, release often
  • short release cycles
  • short feedback loops between developers and users

In the bazaar view, on the other hand, you assume that bugs are generally shallow phenomena—or, at least, that they turn shallow pretty quickly when exposed to a thousand eager co-developers pounding on every single new release. Accordingly you release often in order to get more corrections, and as a beneficial side effect you have less to lose if an occasional botch gets out the door.


  • the Linux Kernel is developed with a bazaar-style approach, leveraging a huge amount of developers connected through the internet
  • Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone (“Linus Law”)
  • Keep Developers happy through high velocity and quick turnarounds
  • make effects of work visible to a broader audience immediately to satisfy people’s egos
  • the one who finds a problem is not necessarily the one who understands or even fixes it; thus, the more skill you can throw at problems, the quicker they get identified and solved

Read a more in-depth view on this in this great article on


The DevOps Awareness Program

Subscribe to the newsletter

Join 100+ cloud native ethusiasts


Join the community Slack

Discuss all things Kubernetes, DevOps and Cloud Native

Related articles6

On Charming Engineering Culture: My Notes

On Charming Engineering Culture: My Notes

Engineering teams are at the core of any modern organisation. They break/make an organisation, and empowering them is critical to any modern companies’ success. A motivated engineer brings more value than a ‘whatever’ engineer. Its high time managers and leaders focus...

The Impostor’s Advantage

The Impostor’s Advantage

You certainly heard of Impostor Syndrome - the feeling of accomplished people belittling their own talents and constantly being terrified of being discovered as a fraud. While it might feel like a handicap, it's actually an advantage. You already took the hardest step...

It’s not your job to write requirements

It’s not your job to write requirements

Modern product development is about best-practice discovery to built sustainable long-term options right into your product design. As a PM, you need to re-think how you approach solution design.