Cathedral and the Bazaar

Cathedral and the Bazaar: Musings on Linux and Open Source by an Accidental Revolutionary, by Eric S. Raymond

 

This book gives a very interesting insight into the state of Linux and Open Source in the late 1990s.  From a historical perspective it shows the success of Linux and attributes this to using a far more flexible model than previous open source development.  That is, Linus Torvalds style of development “release early and often, delegate everything you can, be open to the point of promiscuity” came as a surprise. This was a break from the “Cathedral Building” building process and more like a “a great babbling bazaar of differing agendas and approaches.”   The author tried to understand how Linux with several thousand developers scattered over the globe did not fly apart in confusion. One of the premises is around the nature of software debugging – especially that “given enough eyeballs, all bugs are shallow”.

 

“Quality was maintained not by rigid standards or autocracy but by the naively simple strategy of releasing every week and getting feedback from hundreds of users within days”

 

I recommend this book to those interested in software development and open source.  It is an important book with significant insight that the industry at large still hasn’t digested in many aspects.

 

There are many other factors related to software development in this book that are still relevant today.

 

  1. Gift cultures are adaptations not to scarcity but to abundance.

 

Open source is a gift culture and the author presents that the “reputation-game gift culture is the globally optimal way to cooperate for generating (and checking!) high quality creative work.”

 

Most economics is based on the principle of scarcity. (see also https://www.linkedin.com/pulse/all-software-licensing-theft-gary-elmes )

 

Theresa Amabile’s 1984 study or motivation and reward is mentioned which observed “It may be that commissioned work will, in general, be less creative than work that is done out of pure interest.”  She also observed that “the more complex the activity, the more it is hurt by extrinsic reward.” (Theresa Amabile almost 30 years later wrote The Progress Principle in 2011 which studied a number of teams over a long period and found that one of the best motivators was knowing that you are making progress.  This book was also referenced by Dan Pink’s book drive.)

 

The last paragraph in the section “Gift outcompetes Exchange reads as follows:

“Indeed, it seems the prescription for highest software productivity is almost a Zen paradox; if you want the most efficient production, you must give up trying to make programmers produce. Handle their subsistence, give them their heads, and forget about deadlines.  To a conventional manager this sounds crazily indulgent and doomed – but it is exactly the recipe with which the open source culture is now clobbering its competition”

 

I think that many hierarchical organisations are still struggling with the motivation and measurement of developer productivity and many progressive organisations are working to increase the autonomy of development teams with a view to greater productivity.

 

  1. Software is largely a service industry operating under the persistent but unfounded delusion that it is a manufacturing industry.

 

The author uses the question “What is software worth when the producer is going out of business?”  The answer is usually close to zero proving that the purchase of software is actually about trust that the producer will continue to enhance and support the software, thus a service relationship rather than a widget purchase relationship.

 

Red Hat from this time and based on the Open Source principles under which it abides sells only support and not software.  Selling software for a fixed price and infinitely continuing support does not work. Use value rather than sale value is one alternative way to make money from software and is arguably the major driver of software development.  That is, we don’t further develop software because we sold many copies, we develop because people are using it and asking for additional capability.

 

  1. Usability

Usability was terrible in most software in the late 90s with attitudes like “The users are stupid” or “The users need more training”.  The author knew that Open Source had a major hurdle which was that hackers were good at designing interfaces for other hackers but poor at modelling the thought processes of the other 95% of the population.

 

The author proposed that we need to “learn how to think about what we do in a fundamentally new way, and ruthlessly reducing the user visible complexity of the default environment to an absolute minimum.  Computers are tools for human beings. Ultimately therefore, the challenges of designing hardware and software must come back to designing for human beings – all human beings.

 

We are still on this journey.  Many modern software companies such as Spotify, Netflix, Uber, Facebook, Amazon, Xero, Trade Me are doing this well.  Banks are catching up and government has seen some progress but still a lot of awful software processes.