Open Source Software Development

1
Open Source Software Development

• Six years after The Cathedral and the Bazaar
• Realities of Open Source Projects

Ian Stokes-Rees, 10 November, 2009
2
Background to CatB

• Eric Raymond (ESR) wanted to try out Linux
  style development to see if it would work
• In 1996, three years after Linux was unleashed on
  comp.os.minix, ESR decided to develop fetchmail
• Experience of this and observations of open
  source development around Linux led to paper CatB
• Often called the Manifesto of the Open Source
  Movement (probably by people who havent read
  it)
• Influential in the authoring of the Halloween
  Papers

3
How to form a successful OS community in 8 easy
steps

• (or What is the Bazaar)
• Start with a good idea or improvement
• First release must run, be testable and provide
  plausible promise
• Strong central leadership and co-ordination
• Release early and often

4
How to form a successful OS community in 8 easy
steps

• Nurture a strong community
• Encourage bug reports and user feedback
• Be prepared to allow branching and competing
  projects
• Retire gracefully

5
What is the Cathedral?

• ESR doesnt really say, but
• Very hierarchical
• Rigidly defined and enforced chains of command
• Design dictated from above
• Code protected as crown jewels
• Monotheistic fervently Our way is the only way

6
Tenets of the Bazaar

• Release early and often
• Nurture a strong community
• Given enough eyeballs, all bugs are shallow
• Use best practice
• Accept and learn from diversity
• Pluralistic shrines

7
Release Early and Often

• but not too early
• must have something which runs before open
  sourcing
• Rapid feedback to users
• Developer satisfaction
• Very XP keep code running

8
Nurture Strong Community

• Project co-ordinator is single most important
  aspect for success
• Must provide plausible promise of a good piece
  of software at the end of the day
• No option for commercial style dictatorship

9
Given enough eyeballs, all bugs are shallow

• Result of release early and often and
  nurturing strong community
• Entire community discovers bugs, rather than just
  developers
• Limited form of code review helps keep people
  honest

10
Use Best Practice

• Encourage reuse
• Consider extensive shared libraries
• Many packages are interdependent (good and bad)
• Require testing
• Data centric designs
• KISS Keep It Simple, Stupid
• Most science, engineering, and software
  development isnt done by original genius, hacker
  mythology to the contrary

11
Diversity

• Exposure to many design styles
• Acceptance of different approaches
• Open to code base branching, competing projects,
  and project hand off
• Flexibility to adhere to project specific
  standards mandatory with shared code base and
  diverse group of part-time developers

12
Realities of the Bazaar

• Hard to find stable code
• Usually very difficult to debug or fix due to
  code complexity
• Even harder to get patches accepted by project
  team
• Not much motivation to stick with project to
  provide polish and completeness
• Nurturing, managing and maintaining a community
  is half to full time job
• Critical mass for good quality bug reporting is
  high

13
Realities of the Bazaar (2)

• Dont expect anyone to bug fix
• User documentation slim to non-existant
• Code documentation only marginally better
• Design documents? What are design documents?
• No help with difficult bugs or fundamental design
  problems
• People want working code NOW open source is
  often too much hassle

14
And the Cathedral?

• Actually, they too release early and often
• Windows 3.0, 3.1, Office, Windows 95, Acrobat
• Could IBM have done better with OS/2 Warp if it
  had been released sooner?
• Still have upper hand on professional products
• well packaged
• documented
• easy to install
• easy to maintain
• Very modular and well integrated
• Automatic updates have become the norm

15
SourceForge
16
And the Cathedral? (2)

• BUT
• Still buggy
• Much slower pace of innovation
• Code quality at least as bad as open source due
  to code ownership issues
• Problem of product end of line or end of support
• No option for users to fix bugs in failing
  critical applications

17
My Thoughts

• The Bazaar is actually a congregation of
  shrines
• Every open source project needs a cathedral-like
  core team which is not at all democratic
• Cathedrals adopt, internally, many Bazaar
  qualities, and still produce better products
• Open source has a very different character today,
  compared with 1996, and still has a way to go
  lots of potential

18
My Thoughts (2)

• OSSD breaks through (not breaks) Brooks Law
• virtually zero cost of adding developers and
  debuggers
• must address cost of integrating feedback
• consider testing regime to be definition of
  acceptable commit
• ASPs and web based apps now blurring the line of
  traditional software application and allow for
  continuous, transparent upgrades
• What version of Google are you running?

19
Models for OSSD

• Hackers in spare time out of passion
• Corporate sponsored developers with self interest
  in project success
• Zope, IBM, RedHat, SUSE, TrollTech
• New Model software shops
• free code, but sell integration, support,
  services
• Developers distributed among user community
• transfer cost from purchasing software and
  support to hiring developer

20
For Discussion

• What is the most significant contribution of
  OSSD?
• What is the greatest weakness of OSSD?
• Does current software engineering education
  encourage OSSD?
• Is this a good or bad thing?
• Is academic software development/research more
  like the Cathedral or the Bazaar?