Agile Methods and Open Source Software Development

Agile Methods and Open Source

Software Development

Prof. Dr. Dirk Riehle

2

Table of Contents

#

Content

1

Classic open source software development

2

Three examples: Linux Kernel, PostgreSQL, TikiWiki

3

Conceptual and practical differences

4

Open source best practices

5

6

Community 

Open Source

(e.g. Linux, TikiWiki)

Commercial

Distribution

(e.g. RHEL, SLES)

Community

Distribution

(e.g. Debian)

Commercial

Open Source

(e.g. MySQL, Jasper)

Multi­product

assembly (“stack”)

Single product

or product line

Community­owned

Single proprietor

Community vs. Commercial Open Source

9.1

4

Open Source Time­Line

1991: Linux project started

1999: Apache Software Foundation founded

2004: Eclipse Foundation founded

1995: MySQL AB founded

1998: Open Source Initiative founded

2001: MySQL AB funded

Single Vendor (“Commercial”) Open Source

Managed Community Open Source

Classic Community Open Source

Three Very Different Examples

• Linux Kernel

− An operating system kernel

− Hierarchical: “Linus and his trusted lieutenants”

• PostgreSQL

− A relational database system

− Core peer group of committers and evangelists

• TikiWiki

− A web content management system

− Anarchic: (Almost) everything goes

9.2

Three Examples

6

Roles in Traditional Processes (Recap)

...

Product

Management

Research and

Development

Assurance

Quality

Tester

Development

Manager

Developer

Developer

Product

Manager

Artifacts in Traditional Processes (Recap)

PM

R&D

QA

Tester

Development

Manager

Developer

Developer

Product

Manager

Requirements

Document

Reports and

Test Code

Program

Code

Time Table

8

Committers, Contributors, Community

• Committers

− Main developers

− With access rights

• Contributors

− Casual developers

− Submit patches

• (User) community

− Provide bug reports

− Provide feedback

(User) community

(100­100.000)

Contributors

(10­100)

Committers

(1­10)

Linux Kernel Product Management

• Who defines features?

− Patches

− Scratching one's itch

− Individual maintainer initiatives

− Company­driven contributions

• Product management practices

− No overall product manager

− Practices vary by sub­project

− E.g. brain, wiki, todo list

10

Linux Kernel Development

David S.

Miller

Networking

Greg Kroah­

Hartman

Device Driver

Balbir

Singh

Memory

Management

Linux 

Thorvalds

Linux Kernel

Li

Yang

USB Driver

Dario

Ballabio

SCSI Driver

...

...

...

...

Anon B.

Coder

Some Fix

Linux Kernel Quality Assurance

Linux Kernel

Friendly C.

Tester

Winky “too much 

time” Warner

Always “latest 

greatest” ADDer

Random B.

Hacker

Big T.

Distributor

Distribution

Big T.

Cedric D.

User

Erich F.

Admin

Alma B.

User

...

12

PostgreSQL Product Management

• Who defines features? [1]

− Patches

− Scratching one's itch

− Individual developer initiatives

− Company­driven contributions

− User polls on project home page

• Product management practices

− Leadership by core team

− Maintenance of a todo list [2]

− No prioritization: “Pick your feature”

[1] http://www.postgresql.org/developer/roadmap

[2] http://wiki.postgresql.org/wiki/Todo

PostgreSQL Development

Command Prompt

Product

0+3

EnterpriseDB

Product

2+1

ACME

Product

0/1+0/1

...

Core Team [1]

Major Contributors

PostgreSQL

Official releases

Versions 8.x, 7.4

Some Fix

Anon B.

Coder

14

PostgreSQL Quality Assurance

Anon B. Company

Product

Developer

Core Team

Major Contributors

PostgreSQL

Official releases

Versions 8.x, 7.4

Anon B. Customer

Project

Developer

CommitFest

Patch Review

Round Robin

Anon B. Coder

Project

Developer

TikiWiki Product Management

• Who defines features?

− Patches

− Scratching one's itch

− Individual developer initiatives

• Product management practices

− Maintenance of a todo list

− No prioritization: “Pick your feature”

•

The wiki process applied to software

16

TikiWiki Development

TikiWiki

D

D

D

D

D

D

D

D

• Development process

− Equal rights for 200 contributors

− “Recruit early, recruit often”

− Smart people, highly collaborative

− Strong feature ownership

• Software architecture

− Monolithic application

− “Everything is optional”

− “Don't break anything”

− Avoids “dependency hell”

TikiWiki Quality Assurance

Large user base, more than 700.000 downloads

“Given enough eyeballs, all bugs are shallow.”

frequency of feature use

bu

g 

co

un

t

18

Conceptual and Practical Differences

• Underlying philosophies

− Cathedral vs. bazaar style

− Open collaboration

− Do­ocracy

• Actual practical differences

− Non­monetary motivation

− Volunteer and community process

− Two­tier committer/contributor structure

− Highly distributed process

− Written communication culture

9.3

Conceptual and

Practical Differences

The Cathedral and the Bazaar [1]

• History of an influential paper

− Conceived 1997, revised over the next years

− Influenced Netscape to release the Communicator source code

− In the Netscape aftermath, motivated the Open Source Initiative

− Strong on metaphor and specific observations as well as aphorisms

20

Raymond's Aphorisms

•

Every good work of software starts by scratching a 

developer's personal itch.

•

Good programmers know what to write. Great ones know what 

to rewrite (and reuse).

•

“Plan to throw one away; you will, anyhow.” [1]

•

If you have the right attitude, interesting problems will find you.

•

When you lose interest in a program, your last duty to it is to 

hand it off to a competent successor.

•

Treating your users as co­developers is your least­hassle 

route to rapid code improvement and effective debugging.

•

Release early. Release often. And listen to your 

customers.

•

Given a large enough beta­tester and co­developer base, 

almost every problem will be characterized quickly and 

the fix obvious to someone.

•

Smart data structures and dumb code works a lot better than 

the other way around.

•

If you treat your beta­testers as if they're your most 

valuable resource, they will respond by becoming your 

most valuable resource.

[1] Fred Brooks. The Mythical Man­Month. Chapter 11.

[2] Attributed to Antoine de Saint­Exupery.

•

The next best thing to having good ideas is

recognizing good ideas from your users. Sometimes the 

latter is better.

•

Often, the most striking and innovative solutions come from 

realizing that your concept of the problem was wrong.

•

“Perfection (in design) is achieved not when there is nothing 

more to add, but rather when there is nothing more to take 

away.” [2]

•

Any tool should be useful in the expected way, but a truly great 

tool lends itself to uses you never expected.

•

When writing gateway software of any kind, take pains to disturb 

the data stream as little as possible—and never throw away 

information unless the recipient forces you to!

•

When your language is nowhere near Turing­complete, syntactic 

sugar can be your friend.

•

A security system is only as secure as its secret. Beware of 

pseudo­secrets.

•

To solve an interesting problem, start by finding a problem that is 

interesting to you.

•

Provided the development coordinator has a communications 

medium at least as good as the Internet, and knows how to lead 

without coercion, many heads are inevitably better than one.

Cathedral vs. Bazaar

• Carefully crafted work by small 

group of experts

• Bugs and problems are tricky, 

requiring deep analysis

• Project is led by command and 

control approach

• No early releases nor beta

• Incremental rapidly evolving work 

by large group of people

• “Given enough eyeballs, all bugs 

are shallow”

• Project leader needs people 

skills, know how to work a crowd

• “Release early, release often”

The Bazaar

The Cathedral

22

Open Collaboration [1]

Egalitarian

Meritocratic

Self-organizing

[1] Dirk Riehle et al. “Open Collaboration.” IEEE Software 26 (2)

Traditional vs. Open Collaboration

• Hierarchical

− Closed and hidden silos

− Assigned to project

• Status­driven

− Public and private discussions

− Hierarchical status decides

• Assigned tasks

− Prescribed process

• Egalitarian

− Open for contribution

− Everyone can contribute

• Meritocratic

− Public discussion process

− Decisions based on merit

• Self­organizing

− People find their own process

Open Collaboration

Traditional Work

24

Do­ocracy

• Definition of do­ocracy

− An organizational setup in which people choose their own tasks and roles

− A term used in the context of open source but not much beyond

• Neither democracy nor meritocracy

− Slightly derogatory as in “those who do, rule”

(Some) Open Source Best Practices

• Project marketing

• Volunteer acquisition

• Code submission

• Decision making

• Project documentation

9.4

Open Source

Best Practices

26

Lecture Outlook

• Next lecture: Managed community open source

• Exercises: Classic open source best practices

28

Exercise Questions Lecture 9

• Review Google Code license policy

• Practice diff/patch code submission

Questions? Feedback!