Describes the basics of open source development. Created for the Software Freedom day in Prague sponsored by Acision

1. 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

2. What is essential to get an open source project up and
running?
Slide Number: 2

3. • 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

4. 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

5. 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

6. Version control system
Vocabulary:
– Commit
– Log message
– Update
– Repository
– Checkout
– Working copy
– Revision, change
– Diff
– Branch
– Merge
– Conflict
– lock
Slide Number: 6

7. 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

8. 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

9. 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

10. 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

11. 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

12. 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

13. 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

14. 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

15. 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

16. 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

17. Release management
Slide Number: 17

18. 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

19. 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

20. 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/.../ReleaseMana
gement.pdf]
Slide Number: 20