Open Source Development from the trenches (Jajuk) Bertrand Florat

Transcription

1 Open Source Development from the trenches (Jajuk) Bertrand Florat

2 Talk agenda Objectives Background Getting started Methodology and team management Communication

3 Objectives Get a first realistic vision of creating / managing a FLOSS(*) project Learn about required infrastructure Learn about FLOSS project team management Provides and exchange tips and traps (*) FLOSS = Free Libre Open Source Software

4 Talk agenda Objectives Background Getting started Methodology and team management Communication

5 Jajuk in less than 100 words... Jajuk = "Java Jukebox" (official name) or "Just Another Jukebox" (geek name) Java Jukebox for advanced users with large collections First release in early KLOC (Sonar metric) 20 commiters, ~40 contributors over 6 years, ~8-10 contributors at a time, ~3-4 really active contributors. 307,048 downloads on SF (2009/07/06) GPL V2, 100% FLOSS according to DFSG, just entered Debian main repo and run under OpenJDK

6 Jajuk Advanced jukebox For more information, check

7 Related projects QDWizard Initialy a Jajuk sub-project, now independent project on SF Wizard Swing lib atunes and Jukes com/products/jukes/index.html Good replacements for Jajuk Cross collaboration between projects Common-jukebox "Think-tank" Common ML Few code repository

8 The POSS book Producing Open Source Software (POSS) is a book from Karl Fogel (SVN team) edited for the first time in 2004 Gold mine for new or experienced project leaders Free online (CC) Translated in to ~10 languages, translated in french (Framalang) We applied many principles at Jajuk

9 Jajuk : half success, half failure - Real product, not a toy - Many (happy) users - Collaborative dev - We learnt a lot - Wrong "bus factor" - Not enough developers - Not agile enough - We lose money Jajuk is a good example for today's talk

10 Talk agenda Objectives Background Getting started Methodology and team management Communication

11 Why you should *not* start a FLOSS project (applies to communautary FLOSS project, not paid ones) Because you have not the time (1 to 2 hours a day minimum) Because the wheel has already been invented Because you need to be headstrong over *years* Because you'll (probably) not gain money Because (almost) nobody will help you before you established a user bases Because writing software is *really* hard Because coding/technology is only a part of a project

12 Why you *should* start a FLOSS project Because it's fun (meet people from around the world, try new technologies) Because here at least, you can do things right! Because it's good for your resumé and network (peer visiblity) Because you'll learn *really* a lot Because it's a hobby more compatible with today's life constraints than water skiing

13 The first steps... Look around first Write a POC (Proof Of Concept) first Read POSS book Select a (good) name, buy the domain name(s) Select a forge Select a license and a copyright policy Write down the project main ideas : Mission statements Main principles Governance aspects (votes, who's the boss...)

14 Do you need a forge? dedicated infrastructure? Yes, you need a forge. SaaS is the best option for a FLOSS project. Use dedicated infrastructure : costs money, time requires sysadmin skills can be dangerous (backup, unavailability, attacks...) Use dedicated server only : if you need fine tuning or unavailable tools if you want to make money with online advertisement Jajuk : SF + a dedicated virtual server.

15 Budget Most project can have no budget at all (100% forge hosted) except : (revenues) donations if any (expences) domain name(s) At Jajuk, we publish the budget ( php/project_budget) How to gain money? Donations (jajuk : average of 40 /year) Advertising (jajuk : average of 150 /year) Expences Dedicated server(jajuk : ~300 /year) Domain names (jajuk : 10 /year) We lose money at Jajuk (around 100 /year)

16 Jajuk infrastructure at a glance SCM CMS Ticket manager Continuous Integration Java Web Start Quality insurance Download service Forum Mailing lists Instant messaging Subversion on SF MediaWiki on dedicated server* Trac on dedicated server* Hudson on dedicated server Tomcat on dedicated server Sonar on Sonar demo server FRS on SF SF Forum on SF Mailman on SF Jabber protocol (room at jabber.org) (*) These services are now available on several forges, including SourceForge

17 Mandatory infrastructure SCM (version control) SVN is good CVS is outdated Git is promising CSM (Content Management System) Either a publishing tool like Drupal / WordPress... Either a wiki oriented (MediaWiki is excellent) In any cases, you'll need a wiki Mailing lists The dev list often the main communication stream Most forge tools are OK, mailman is good Ticket tracker Trac is the killer-app but the wiki is not perfect Others : Buzilla, Mantis...

18 CMS : Jajuk uses MediaWiki Most pages are anonymous-editable

19 Ticket tracker : Jajuk uses Trac We almost don't use the Trac embedded wiki

20 Optional infrastructure Quality Insurance In the java world, check Sonar Others : XRadar, Maven Dashboard Continuous Integration Server Try Hudson! light and powerful... Others : Cruise Control, Continuum Test cases, requirements : TestLink

21 Quality Insurance : Jajuk uses Sonar

22 CI : Jajuk uses Hudson

23 Tips Less is better, smart small and use tools only when really required Always use a SCM Use a (single) wiki

24 Traps Underestimate sysadmin (backup, security) tasks on a dedicated server Use duplicate tools (MediaWiki + Trac wiki for instance)

25 Talk agenda Objectives Background Getting started Methodology and team management Communication

26 Best practices «Release soon and often» + bazaar philosophy Provide daily builds Plan one release every 2 to 3 months Leverage users feedback, make everything public KISS (Keep It Simple, Stupid) principle RE-USE everything you can.

27 Invest on internal documentation Good guides enable new contributors to be productive soon and save your time A wiki member guide A guide for each role (emphase the dev guide) We created a workspace by role: Developer Doc writer Translator Project admin Sysadmin Tester Media Designer

28 Few words on team management Contributor (developers) main profiles : Experienced devs Student or newbie «Vapor volonteers» Every new subscription requires time and training Use tools that allow self-subscription Make extensive guides and procedures Require a ticket for new contributors : asking a patch is often enough to filter vapor volonteers

29 Invest on packaging Don't expect users to build and try raw code Provide a specific packaging for each OS.rpm,.exe,.deb,.app... If under GNU/Linux, contact distribution packagers to help them packaging your app. However, it's good to provide our own packaging

30 Tips Delegate everything you can. For medium-sized project, nominate a responsible for each role. Write FAQ and howto guides in addition to dev guide Keep your code clean and homogenous (use quality analysis and IDE formaters). Permanent code refactoring is good practice With good dev guide and clean code, a developer should be able to start coding in few days only. Organize "coding parties" through Instant Messaging

31 Traps Starting a project with friends or collegues is not always a good idea Avoid vapor volonteers, ask for real code! Listen to your users but you remain the boss when choosing the features to code or not (KISS)! Avoid wasting too much time on user manuals Keep them as short as possible Avoid multi-language manuals Avoid screenshots, insert only icons

32 Talk agenda Objectives Background Getting started Methodology and team management Communication

33 Be transparent! Avoid private discussions Always reply with CC: the dev ML Almost nothing has be be actually private Use a common room for instant messaging

34 Use the right stream Dev mailing list for main exhanges on the project Ticket tracker to create and follow a work unit (bug, task, feature) Store everything stated directly into the ticket, do not let information in the instant messaging or ML stream! Instant messaging for brainstorming / difficult issues Store the discussions Don't forget summary into tracker

35 Good communication toward users... Make a net and fast web site (use a CMS) Provide clear abstract Provide demo tours (flash screencasts) Provide screenshots State that the project is FLOSS Clear download links

36 Tips Keep the wiki and tracker (mainly) anonymous Daily builds Create news on right websites (freshmeat...)

37 Traps Think that users can write the wiki manual Spam (wiki / ML / ticket manager...) Auto-promotion

38 Questions? Contact : Bertrand Florat This presentation is published under the Creative Commons Attribution-Noncommercial- Share Alike 2.0 France License