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.
- 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.
- 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 catb.org