Opensource Development

Embed Size (px)

DESCRIPTION

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

Text of Opensource Development

  • 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 dont 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