Open Source Software Development Et ferskt 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 SVNutviklingsteamet (ansatt i CollabNet) http://www.collab.net/ OSSD som tema vektlegges sterkere i emnet i år http://www.opensource.org/ 25.Aug 2010 Forelesning 1 i IMT3102 høst 2010 1 Open Source Community Open Source programvare : Programvare som lisensieres under en copyright-lisens som er i overensstemmelse med Open Source Definition og der kildekoden distribueres på et format som kan leses av mennesker. Selve utviklingsprosessen tilstrebest utført t i et åpent og samarbeidsfremmende miljø http://opensource.org/docs/osd IMT3102 - Objektorientert systemutvikling 1
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 XMLbased file format Nedlastningsformat, verktøybruk (versjonskontroll, bugtracker), angi lisens prosjektet legges under, hosting av prosjektet Klargjør utviklingsstatus, avklar kommunikasjonskanaler og ha gode beskrivelser av rutiner for bidragsytere 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, bughistorikk 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 IMT3102 - Objektorientert systemutvikling 2
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 Teknisk infrastruktur (forts.) Wiki Presentasjon av prosjekt stadig viktigere den jungel av OSSD og prosjekter som finnes. Fordel med egne dedikerte ressurspersoner her da presentasjonsferdigheter ofte er fraværende hos kjerneutviklere Ikke undervurder layout, navigasjonsmekanismer etc. Det blir stadig vanskeligere å skape aktive prosjekter etter på tross av når det gjelder brukervennlighet og dokumentasjon. Se på andre prosjekter sine Wiki og saks med det beste. FAQ Ikke konstruer opp en, la den vokse Web side IMT3102 - Objektorientert systemutvikling 3
MAPPE 1 : 3 4 OS-prosjekter som dere går inn og gransker nøye. NB! bruk tid til å orientere dere først og bytt gjerne ut enkeltprosjekter kt underveis. Finn ut : Målsetting for prosjektet, Hvem utvikler, organisering, lisensvalg, informasjonskanalene vurder web-side, wikibruk, mailinglister, IRC, twitter, facebook Antall deltagere i ulike kategorier, styringsstruktur, releaser, popularitet, Fork-historikk, prog.språk, plattformer Kommersielle aktører vs frivillige, betalte vs ubetalte, kobling til andre prosjekt, kom.versjon/fri versjon? Bug-innblikk, Historikken til prosjektet, startet det med working code Tilbakemeldinger på deltagelse hyppighet, form, åpenhet Analyser likheter, forskjeller. Faglig diskusjon. Open Source Mappe forts. : Hvis kontakt gjør klart at dere har et education-oppdrag som er kartlegging ikke deltagelse. Ikke spill potensielle utviklere for å få ut info mot reglene og god OSSD skikk. Hvis dere vil være Users så gjør det seriøst, ellers bare bruk tilgjenglig og åpen info. Kildehenvisninger viktig. Prosjektsiden klart viktigs kilde, men mys også litt rundt etter prosjektomdømme utenfor. IMT3102 - Objektorientert systemutvikling 4
Open Source roller : Open Source Bug-lifecycle. IMT3102 - Objektorientert systemutvikling 5
Øvrige temaer som berøres av Fogel Forking en uting, snarere et Ris bak speilet Benevolent Dictators ikke gitt at en lederstil er bedre, men vær nøye med å formidle hva som gjelder I ditt prosjekt Avstemming kun når consensus ikke nåes, veto aksepteres Kommersielle aktørers inntreden i Open Source Community fordeler og ulemper motiver, er det reell åpenhet? indirekte styring får vi en motreaksjon? kontraktsproblematikk og leveransefrister Lisensvalg IMT3102 - Objektorientert systemutvikling 6