Starting an open source project

This document can be freely distributed under the Creative Commons license http://creativecommons.org/licenses/by-sa/3.0/cz/

By Petr Havel 2010

What is essential to get an open source project up and running?

Slide Number: 2

• A problem that is bugging people

• Collaboration Software

• The right communication skills

• Capability to do what others don’t want to

• Lead by example

Slide Number: 3

Starting a project

Basic points for starting a new project:

• Choose a Good Name

• Have a Clear Mission Statement

• Put together the basic guidelines

• Version Control

• Bug Tracker

• Documentation (or at least the guidelines for it)

• Communication Channels

Slide Number: 4

Version control system

A combination of technologies and practices for tracking and controlling changes to a project's files, in particular

to source code, documentation and web pages.

Slide Number: 5

Version control system

Vocabulary:– Commit– Log message– Update– Repository– Checkout– Working copy– Revision, change– Diff– Branch– Merge– Conflict– lock

Slide Number: 6

Version control system

• Version everything

• Commit emails

• Should be browsable

Examples:

• Concurrent Versions System (CVS,

http://www.cvshome.org/)

• Subversion (SVN, http://subversion.tigris.org/).

Slide Number: 7

Bug tracker

• Accessible to everyone

• Create a policy for adding bugs

• Connect to a mailing list

• Buddy system

• Should ask for the mailing address but also allow

anonymity

• Do not allow it to be used instead of other

communication channels

Slide Number: 8

Bug tracker software

• Bugzilla [http://www.bugzilla.org/]

• GNATS [http://www.gnu.org/software/gnats/]

• RequestTracker [http://www.bestpractical.com/rt/]

• Trac [http://trac.edgewall.com/]

• Flyspray [http://www.flyspray.org/]

• Debian Bug Tracking System

[http://www.chiark.greenend]

Slide Number: 9

Documentation

• Use a simple easy to edit format like HTML,plain text,

Textinfo, XML

• Limit the scope

• Describe clearly and thoroughly how to set up the

software

• Give one tutorial-style example of how to do a common

task

• Label the areas where the documentation is known to be

incomplete.Slide Number: 10

Mailing lists

Are the main arteries of your project.

• Keep them to a minimum the basic are:Developer

Bug reports

Announcements (annoucment@yourproject.com)

• Remember to archive

• Management

• Interaction

Slide Number: 11

Mailing list software

Mailing list management software:– Mailman [http://www.list.org/]– SmartList [http://www.procmail.org/]– Ecartis [http://www.ecartis.org/]– ListProc [http://listproc.sourceforge.net/]– Ezmlm [http://cr.yp.to/ezmlm.html]– Dada [http://mojo.skazat.com/]

Mailing list archiving:– MHonArc [http://www.mhonarc.org/]– Hypermail [http://www.hypermail.org/]– Lurker [http://sourceforge.net/projects/lurker/]– Procmail [http://www.procmail.org/]

Slide Number: 12

Other Communication

IRC and chat room

• Helps to create a sense of community

• Secondary all agreements should go onto the mailing lists

• Archiving?

Wiki pages• Open to the public

RSS feeds

Slide Number: 13

Web site

Binds everything together

Should include:– Mission statement– Sate that the project is free and the name of the license– Features and requirements list– Development status– Downloads– Version control and bug tracker access– Communication channels– Guidelines– Documentation– Screen shots

Slide Number: 14

Canned sites

• Everything set up and ready

• Adds

• Cannot customize

Examples:– SourceForge [http://www.sourceforge.net/] – savannah.gnu.org [http://savannah.gnu.org/]– BerliOS.de [http://www.berlios.de/]– Apache Software Foundation [http://www.apache.org/] – Tigris.org [http://www.tigris.org/]

Slide Number: 15

Release Management

Release numbering– Stability (alpha,beta,stable,unstable,development)– Backwards, forward, compatibility – Major.minor.micro (R2.3.11)– Parity

Release branches– Snapshot– Stabilize

Release management– Dictatorship by owner– Change voting

Slide Number: 16

Release management

Slide Number: 17

Policy

• Benevolent Dictatorship– final decision-making authority rests with one person– Common founder of the project– Forking keeps dictator in check

• Consensus based democracy– Seems more evolutionarily stable– Version control lets this happen– Voting (last resort)– Has to have good guidelines – Who votes (very often commiters)

Slide Number: 18© 2008 Acision BV. All rights reserved© 2008 Acision BV. All rights reserved

Money

• Direct investment– People inside the company– Need to be accepted by the community– Each person for himself

• Contracting– Best to hire a person already involved– Let the other people know that you are working on a contract

• Contributions– Finical sponsoring– Quality insurance (testing)– Documentation – hosting

Slide Number: 19

Where to go from here?

• Producing oss [http://www.producingoss.com/]• Open source software development

[http://www.pascal.case.unibz.it/retrieve/2760/greenberg.pdf]

• The Cathedral and Bazaar [http://catb.org/esr/writings/cathedral-bazaar/]

• Ecology of open source software development [opensource.mit.edu/papers/healyschussman.pdf]

• Release management within open source projects [www.erenkrantz.com/Geeks/Research/.../ReleaseManagement.pdf]

Slide Number: 20