The E-Learning Curve Blog has moved!

You will be automatically redirected to the new address in 10 seconds. If that does not occur for some reason, visit
http://michaelhanley.ie/elearningcurve/
and update your bookmarks.

Monday, October 5, 2009

E-Learning, the Cathedral and the Bazaar: Courseware Development Approaches

...or Top-down versus Bottom-up approaches to content design.

In his 1997 essay The Cathedral and the Bazaar, open source evangelist Eric S. Raymond suggests that

the closed-source world cannot win an evolutionary arms race with open-source communities that can put orders of magnitude more skilled time into a problem.
Raymond considers the development of software by traditional methodologies as analogous to building a mediaeval cathedral,
carefully crafted by individual wizards or small bands of mages working in splendid isolation, with no beta to be released before its time.
He asserts that all software could be developed using the bazaar approach, which he described as
a great babbling bazaar of differing agendas and approaches... open to the point of promiscuity.

In this so-called Bazaar Model, roles are not clearly defined. Gregorio Robles suggests that software developed using the Bazaar model should exhibit the following patterns:

  • Users should be treated as co-developers
The users are treated like co-developers and so they should have access to the source code of the software. Furthermore users are encouraged to submit additions to the software, code fixes for the software, bug reports, documentation etc. Having more co-developers increases the rate at which the software evolves. Linus' Law states that, "Given enough eyeballs all bugs are shallow." This means that if many users view the source code they will eventually find all bugs and suggest how to fix them. Note that some users have advanced programming skills, and furthermore, each user's machine provides an additional testing environment. This new testing environment offers that ability to find and fix a new bug.
  • Early Releases
The first version of the software should be released as early as possible so as to increase one's chances of finding co-developers early.
Frequent Integration
New code should be integrated as often as possible so as to avoid the overhead of fixing a large number of bugs at the end of the project life cycle. Some open source projects have nightly builds where integration is done automatically on a daily basis.
  • Several Versions
There should be at least two versions of the software. There should be a buggier version with more features and a more stable version with fewer features. The buggy version (also called the development version) is for users who want the immediate use of the latest features, and are willing to accept the risk of using code that is not yet thoroughly tested. The users can then act as co-developers, reporting bugs and providing bug fixes. The stable version offers the users fewer bugs and fewer features.
  • High Modularization
The general structure of the software should be modular allowing for parallel development.
  • Dynamic decision making structure

There is a need for a decision making structure, whether formal or informal, that makes strategic decisions depending on changing user requirements and other factors (i.e. in extreme programming).

In Raymond's view, most well-known OSS products including Linux, Apache, and the GNU Compiler Collection align with the Bazaar model.
In the 'traditional' Cathedral model (advocated in Fredrick P. Brooks, Jr. in The Mythical Man-Month), development takes place in a centralized fashion. Clearly defined roles including experts dedicated to designing (the architects), established management styles, and 'craftsmen' (developers) responsible for implementation all contribute build a pre-established design according to a pre-agreed blueprint.


He goes further to say that in order to preserve the architectural integrity of a system, its design should be done by as few architects as possible.

Interestingly, the Bazaar model comes close (in manifestation, if not in philosophy) to what Brooks in the 1995 Anniversary edition of his text describes as "shrink-wrapped software." Brooks suggests:

For the developer in the shrink-wrapped industry, the economics are entirely different from those of the classical industry... the starkly different economies have given rise to starkly different programming cultures.

(p.284)


Rather than the traditional Cathedral model,
The shrink-wrapped industry... [is] freewheeling and fiercely focused on getting the job done rather than on process. in this climate, there has always been a much greater recognition of the talent of the individual programmer, an implicit awareness that great designs come from great designers [my italics]. The start-up culture has the capability of rewarding star performers in proportion to their contributions... [i]t is not surprising that many of the stars of the new generation have gravitated to the shrink-wrapped industry.

(p.284)


More tomorrow as I discuss towards the implications of these two models for the e-learning industry.

___________
References:

Brooks, R.P. (1995). The Mythical Man-Month Anniversary Edition London, Addison Wesley Longman, Inc.


Raymond, E. S. (2000). The Cathedral and the Bazaar Version 3, Revision 1.57 [Internet] Available from: http://www.catb.org/~esr/writings/
cathedral-bazaar/cathedral-bazaar/
[Accessed 22nd August 2009]

Robles, G. (2004) A Software Engineering approach to Libre Software, IN: Robert A. Gehring, Bernd Lutterbeck: Open Source Jahrbuch 2004, Berlin: Lehmanns Media. [Internet] Available from: http://www.opensourcejahrbuch.de/download/
jb2004/chapter_03/III-3-Robles.pdf
[Accessed 21st April 2008]
--

No comments: