Open Source: Cathedrals, bazaars or dinner tables? The challenges involved in managing the development processes involved in Open Source projects are well known.
Eric S Raymond, in his book called The Cathedral and the Bazaar, examines the struggle between two different software development models: the Cathedral model, where source code is available with each software release, but code developed between releases is restricted to an exclusive group of software developers; and the Bazaar model, where code is developed over the Internet in view of the public.
This ‘struggle’ has been brought to mind recently as the community-led initiative Ripple, which is leading a collaborative approach to developing an integrated digital care record, has assigned the ‘technical custodian role’ of the open source platform code to our team at Answer Digital. Which of Raymond’s models will we follow? The answer is neither.
The integrated digital care record that Ripple’s international community aims to create will allow frontline staff access to the most up-to-date, joined-up care information about an individual to drive better and safer care. As code is produced for new features and functions by the widening Ripple community, Answer Digital will review the quality and approach against industry best practice. We’ll ensure the core code is of the ‘Gold Standard’.
Top-down VS bottom-up design...
Raymond’s Cathedral and Bazaar models examine the struggle between top-down and bottom-up design. But I’d like to propose a middle ground: the dinner table. This is less formal and restrictive than a cathedral, with its conformist environment, heavy doors and magnificent architecture; but it’s more formal than a Bazaar. There will be no queue-jumping, aggressive haggling or secretive dealings. There’s a definite code of etiquette to be observed at a decent dinner table, but everyone has a chance to debate in a safe and supportive setting.
A question I’ve been asked often (and recently) is about the inherent risk of bugs and viruses within Open Source code. Raymond's proposition is that "given enough eyeballs, all bugs are shallow" – something he calls Linus's Law. That is, the more widely available the source code is for public testing, scrutiny and experimentation, the more rapidly all forms of bugs will be discovered. In contrast, he claims that an inordinate amount of time and energy must be spent hunting for bugs in the Cathedral model, since the working version of the code is available to only a few developers.
I’m proud that our team has been asked to take care of Ripple’s core code. It’s a critical role and we’ll be providing guidance on technology choices and assurance against standards. We intend to approach our new role by setting the dinner table (metaphorically speaking, of course) so that anyone can join and being flexible within certain parameters. All the time, we’ll aim to bring balance and merge valuable contributions to improve the product for the benefit of the global community.
https://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar for more info on Eric S Raymond’s book The Cathedral and the Bazaar
http://rippleosi.org for more info on Ripple
http://rippleosi.org/ripple-assigns-answer-digital-technical-custodian-open-source-code/ for more info on Answer Digital’s role as technical custodian