Forelesning 2 i IMT3102 høst 2011 123.Aug 2011

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 223.Aug 2011

Open Source 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-kretser

http://www.ohloh.net/ med sentral rolle i Subversion SVN-

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, the leading international office suite that will run on all major platforms and provide access to all functionality and data through open component based APIs 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

23.Aug 2011

Forelesning 2 i IMT3102 høst 2011 4

Open Source roller :

23.Aug 2011

Prosjektene dere har sett på til i dag :

Hallvard og Arve : http://notepad-plus-plus.org/

…

Jo, Solveig og Øyvind : http://gimp-win.sourceforge.net/

….

Andrius og Adiljan : http://audacity.sourceforge.net/

  http://eclipse.net/

Forelesning 2 i IMT3102 høst 2011 6

Teknisk infrastruktur (Fogel kap 3)

Mailing Lists den “aktive” kommunikasjonskanalen i OSSD ofte skille mellom bruker-lister og utvikler-lister tegn på profesjonalitet at dette håndteres skikkelig

(Spamfiltrering, svarmekanismer, arkivering …)

Versjonskontroll i distribuerte utviklingsmiljøer med mange og omskiftelige

deltagere er versjonskontrollsystemer ufravikelig. programvaren som brukes kan variere (Subversion, CVS, git

…) og dels styres av verten du legger prosjektet hos Kildekode er minimum. Dokumentasjon, web-info, FAQ, bug-

historikk etc. kan også underlegges “regimet” Tilgjengelig repository via Web viktig Commits bør formidles til egen mailing list Opprett “Branch” ved behov – flett inn igjen så snart som

mulig

23.Aug 2011

Forelesning 2 i IMT3102 høst 2011 7

Teknisk infrastruktur (forts.)

Bug Tracker Brukes til både feilrapportering og forslag til ny funksjonalitet Ved feil kreves “reproduksjon” før behandling Egne statusløp på bug-forløpet (jfr. Bugzilla prosessen) Svartid og profesjonalitet svært avgjørende Disiplin både fra testere og fra utviklere Unngå at det blir et “diskusjonsforum”

IRC Mange prosjekter har en IRC hvor det diskuteres sanntid om

prosjektet Et supplement til Mailing List, ikke en erstatter Twitter og facebook – sjekk eventuell aktivitet her på deres

utvalgte prosjekter RSS Feeds også tilgjengelig på en del prosjekters Web-sider

23.Aug 2011

Forelesning 2 i IMT3102 høst 2011 8

Teknisk infrastruktur (forts.)

Wiki Presentasjon av prosjekt stadig viktigere I OSSD jungelen Fordel med dedikerte ressurspersoner her da presentasjons-

ferdigheter ofte er “fraværende” hos kjerneutviklere Ikke undervurder layout, navigasjonsmekanismer etc. Det blir

stadig vanskeligere å skape aktive prosjekter. Se på andre prosjekter sine Wiki og “kopier”

FAQ Ikke konstruer opp en, la den vokse

Web side Canned hosting har sine fordeler og ulemper

23.Aug 2011

Forelesning 2 i IMT3102 høst 2011 9

Open Source Bug-lifecycle

.

23.Aug 2011

Forelesning 2 i IMT3102 høst 2011 10

“Resten” av Fogel-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

23.Aug 2011

Struktur i sammenligningen Apache – Mozilla (Mockus m.fl. 2002)

En artikkel er ikke pensum, men ligger ute under “Ressurser” på hjemmesiden. Forfatterne søkte forståelse for selve utviklingsprosessene og for resultatet av utviklingsprosessene.

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

Forelesning 1 i IMT3102 høst 2010 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

19.Aug 2010

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 !)

19.Aug 2010