OOSU – 23.aug 2011 Open Source Software Development

1. OOSU – 23.aug 2011Open Source Software Development Dagens • Hva sies om OSSD på wikipedia ? • Dere forteller om prosjekter dere har undersøkt. • Gjennomgang av Kap. 3 i Karl Fogels bok • Kommentarer til resten av Fogels bok og eksempel på forskningsartikkel innen temaet • I morgen – tar for oss en av innleveringene fra i fjor Dagens pensum : nr. 1 og 2 i artikkelsamlingen Forelesning 2 i IMT3102 høst 2011

2. OpenSource Software Development • Eksempel på hvordan det kan gå når man gjenbruker kode som ikke er Open Source : http://www.hegnar.no/okonomi/article445597.ece • Karl Fogel, velrenomert utvikler i OSSD-kretserhttp://www.ohloh.net/ med sentral rolle i SubversionSVN-utviklingsteamet (ansatt i CollabNet) http://www.collab.net/ • Interesseorganisasjon : http://www.opensource.org/ Forelesning 2 i IMT3102 høst 2011

3. Open Source Software Development Fogels oppstartstips : • Se etter tilsvarende / nært beslektede prosjekter Bli heller med i et eksisterende enn å starte opp nytt hvis mulig • Navnsetting av prosjektet • God beskrivelse av målet med prosjeket : OpenOffice : ”To create, as a sommunity, theleadinginternationaloffice suite thatwill run on all major platforms and provideaccess to all functionality and data throughopencomponentbasedAPIs and an XML-based file format” • Nedlastningsformat, verktøybruk (versjonskontroll, bug-tracker), angi lisens prosjektet legges under, hosting av prosjektet • Klargjør utviklingsstatus, avklar kommunikasjonskanaler og ha gode beskrivelser av rutiner for bidragsytere Forelesning 2 i IMT3102 høst 2011

4. Open Source roller : Forelesning 2 i IMT3102 høst 2011

5. Prosjektene dere har sett på til i dag : Hallvard og Arve : http://notepad-plus-plus.org/ … Jo, Solveigog Øyvind : http://gimp-win.sourceforge.net/ …. Andriusog Adiljan : http://audacity.sourceforge.net/ http://eclipse.net/

6. Teknisk infrastruktur (Fogelkap 3) Mailing Lists • den “aktive” kommunikasjonskanaleni OSSD • ofteskillemellombruker-listerogutvikler-lister • tegnpåprofesjonalitet at dettehåndteresskikkelig (Spamfiltrering, svarmekanismer, arkivering …) Versjonskontroll • idistribuerteutviklingsmiljøer med mange ogomskifteligedeltagereerversjonskontrollsystemerufravikelig. • programvarensombrukeskanvariere (Subversion, CVS, git …) ogdelsstyresavverten du leggerprosjektethos • Kildekodeer minimum. Dokumentasjon, web-info, FAQ, bug-historikk etc. kanogsåunderlegges “regimet” • Tilgjengelig repository via Web viktig • Commits børformidlestilegen mailing list • Opprett “Branch” vedbehov – flett inn igjensåsnartsommulig Forelesning 2 i IMT3102 høst 2011

7. Teknisk infrastruktur (forts.) Bug Tracker • Brukestilbådefeilrapporteringogforslagtilnyfunksjonalitet • Vedfeilkreves “reproduksjon” førbehandling • Egnestatusløppå bug-forløpet (jfr. Bugzillaprosessen) • Svartidogprofesjonalitetsværtavgjørende • Disiplinbådefratestereogfrautviklere • Unngå at detblir et “diskusjonsforum” IRC • Mange prosjekterhar en IRC hvordetdiskuteressanntidomprosjektet • Et supplement til Mailing List, ikke en erstatter • Twitter ogfacebook – sjekkeventuellaktivitet her påderesutvalgteprosjekter • RSS Feeds ogsåtilgjengeligpå en del prosjekters Web-sider Forelesning 2 i IMT3102 høst 2011

8. Teknisk infrastruktur (forts.) Wiki • PresentasjonavprosjektstadigviktigereI OSSDjungelen • Fordel med dedikerteressurspersoner her da presentasjons-ferdigheterofteer “fraværende” hos kjerneutviklere • Ikkeundervurder layout, navigasjonsmekanismer etc. Detblirstadigvanskeligere å skapeaktiveprosjekter. • Se påandreprosjekter sine Wiki og“kopier” FAQ • Ikkekonstrueropp en, la den vokse Web side • Canned hosting har sine fordelerogulemper Forelesning 2 i IMT3102 høst 2011

9. Open Source Bug-lifecycle . Forelesning 2 i IMT3102 høst 2011

10. “Resten” avFogel-boka : Kap 4 Social and Political Infrastructure - Forking - Benevolent Dictator - Avstemming - Avklaring : Braches, Forking og Distributions Kap 5 Money - Åpenhet eneste vei - Betalte utviklere gir større trøkk, men også usikkerhet i prosjekt Kap 6 Communiations - Unngå «Holy war», isoler bråkmakerne Kap 7 Releasing - Major, Minor, Micro (minor partall=stabil) Kap 9 Licenses - GPL – etterfølgere må være GPL og åpne (2/3) - MIT og BSD – kan bli proprietær, alle veier mulig Forelesning 2 i IMT3102 høst 2011

11. Struktur i sammenligningen Apache – Mozilla (Mockus m.fl. 2002) En artikkelerikkepensum, men ligger ute under “Ressurser” påhjemmesiden. Forfatternesøkteforståelse for selveutviklingsprosesseneog for resultatetavutviklingsprosessene. Lanserte 6 forskningsspørsmål : Q1 What were the processes used to develop Apache and Mozilla ? Q2 How many people wrote code .. reported problems .. repaired ? Q3 Were these functions carried out by distinct groups of people .. ? Q4 Where did the code contributors work in the code ? (ownership) Q5 What is the defect density of Apache and Mozilla code ? Q6 How long did it take to resolve problems ? (priority .. interval over time ..)

12. Q2 How many people wrote code .. reported problems .. repaired ? Apache (pr. 2002): • 400 bidragsytere innen kode • 182 personer bidro med 695 fixes • 249 personer bidro med 6092 submissions • 3060 personer la inn 3975 problemrapporter Forelesning 1 i IMT3102 høst 2010

13. Q3 Were these functions carried out by distinct groups of people? Apache (pr. 2002): • 15 utviklere stod for mer enn 80 % av ny-utviklingsaktiviteten • Men .. de 15 stod for bare 66 % av feilrettingene, her bidro et langt større antall • Feilrapportering fra ekstremt mange (2600 hadde 1 rapport, 306 hadde 2 rapporter, kun 85 hadde 3 !) Forelesning 1 i IMT3102 høst 2010