Opensource Development

Opensource Development

• 1.
  Starting an opensource 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 essentialto get an open source project up and running? Slide Number: 2
• 3.
  • A problemthat 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 Basicpoints 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 Acombination 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 • Accessibleto 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 asimple 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 themain 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 Mailinglist 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 andchat 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 everythingtogether 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 • Everythingset 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 gofrom 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