Hur utvecklar man öppen källkod?

Hur utvecklar man öppen källkod? Göran Landgren, Informatik Dataföreningen tisdag 21 april 2009

Innehåll En förståelse av hur öppen källkod är viktigt även om man inte är intresserad av att syssla med utveckling Bredda utvecklingsperspektivet Frågeställningar Vad är öppen källkod? Varför intressera sig för öppen källkods-utveckling? Vad kännetecknar utveckling av öppen källkod? Hur arbetar man inom ett öppen källkods-community? Hur man hittar och bedömer öppen källkods-produkter att vidareutveckla? Vilka verktyg behöver man? Licensmodeller? 2

Vad är öppen källkod? Ett system/program vars programkod är fritt tillgänglig att nyttja och förändra Öppen behöver inte vara gratis (och gratis behöver inte vara öppet) beror på licensmodellerna Utvecklas (vanligtvis) inom en sammanslutning (community) av utvecklare En sammanslutning av människor med ett delat intresse, men med olika bakgrunder, motiv och ekonomiska förutsättningar har inget direkt kommersiellt intresse Transparent utvecklingprocess utomstående kan bedöma produktens och processens kvalitet 3

Varför intressera sig för öppen källkods-utveckling? Behov av att bedöma en Ö.K.-produkts kvalitet Förstå ett programs upphov, nuvarande och kommande utveckling Arbetsformernas betydelse för utvecklingen Programmets kvalitet (buggar, nya features) Hur lätt är det att komma igång med användning av produkten Personliga motiv för att bli Ö.K.-utvecklare Ett programbehov ny Ö.K.-produkt Förbättra en befintlig Ö.K.-produkt Politiska/ideologiska motiv (anti-kommersiellt, free information, open formats, etc.) Karriär- och kompetensutvecklande motiv Sociala motiv 4

Varför intressera sig för öppen källkods-utveckling? Utvecklar-organisationers motiv Bemästra en specifik Ö.K.-produkt sälja support-tjänster på denna produkt Förbättra egna program genom att införliva öppen källkod Ex: Apache Commons http://commons.apache.org/ Väcka liv i en egen, avsomnad, misslyckad produkt Ex: Netscape/Mozilla Övriga organisationers motiv Minska licenskostnader - byta ut en kommersiell produkt Behov av att utveckla en befintlig Ö.K.-program som redan används eller borde användas inom organisationen 5

Utvecklingens karaktär Drivs av ett programbehov (Stallman klåda ) Inte nödvändigtvis nyskapande (ex. Linux) Föregås av liten eller ingen analys (i huvudet på skaparen) Ingen genomtänkt designplan behövs Det blir lättare att attrahera utvecklare Användare kan också vara utvecklare Programmet måste fungera, men behöver ej vara färdigt exekverbart på många plattformar Att ladda ned och testa ett program är ofta det första steget mot att bli os-utvecklare Ärlighet i fråga om brister är en god sak tala om vad som är fel, sakas, etc. ofiltrerad kommunikation 6

Evolutionär programutveckling Fungerade kod kommer att kopieras Låt produkten växa fram produkten måste tillåta detta (arkitektur) Wicked problems Man försöker lösa fel problem vid första försöket Bygga vidare/förändra ett befintligt projekt Scaffolding (Raymond: Fetchmail) Forkning konflikt om produktens riktning eller grundläggande designprinciper kan vara positivt OpenOffice och NeoOffice Hur väljer man sida (vilken är återvändsgränden?) 7

Olika aspekter av utvecklingsarbetet och användning Programmering: nyutveckling och buggfix code-review Testning Lågnivåtest Högnivåtest: funktions- och acceptanstester (kvalificerad) buggrapportering Författa manualer och annan dokumentation Utveckla användarfall Utveckla produktens användningsområde Grafik och gränssnitt användbarhet, webbdesign (CSS, JavaScript, Flash, etc) Installation och konfigurering Utveckling av mallar och exempel 8

Öppen källkods-community Utveckling sker oftast inom ett community Är en sammanslutning av utvecklare och användare med ett delat intresse, kan ha olika bakgrund, motiv, ekonomiska förutsättningar och geografisk tillhörighet Har en egen kultur, normer, regler och konventioner Har experter (kärnan) och nybörjare Platt kommunikationsstruktur Communitets tillstånd återspeglar produktens kvalitet Deltagare: individer och organisationer Kompetens Utvecklas produkten?, i vilken riktning utvecklas den? 9

Hur leder man och arbetar inom ett community? Ledning: Utmaning att leda (ett stort antal) personer som är tids- och platsmässigt utspridda kan ha skilda motiv och kompetens tillhör kommersiella eller icke-kommersiella organisationer eller ingen org. alls Communitets kultur skapar förutsättningar och sätter begränsningar för hur det kan ledas Ledningsmodeller (K. Fogel) Den gode envåldshärskare Demokrati 10

Den gode envåldshärskaren Känner till programmets syfte och känner för programmet Kunna avgränsa systemet förstår problemdomän och programmets riktning Låter communitet sköta sig själv så mycket som möjligt Sätta ned foten när det behövs Säga JA och NEJ, med goda argument Har en förmåga att känna igen bra lösningar (genomförbara och underhållbara) lösningar Svårt att vara ond - missnöjda undersåtar kan alltid brytas sig ut (kopiera kungariket och flytta) kompromissvilja 11

Demokrati Ledningsgrupp av framstående utvecklare som väljs på något sätt Medlemmarna måste förtjäna sin plats (förmåga att tillföra) Väljs av andra medl. Omröstning vid viktiga förändringar och nyutveckling där communitet inte kan komma överens Har rätt att checka in kod (committa) Andra community-deltagare skickar patchar till gruppen Folkomröstning bland de övriga medlemmarna Styrelse i riktigt stora open source-projekt Sakai 12

Organisation och arbetsformer Modularisering som förutsättning för arbetsdelning Traditionella programutvecklingsmetoder och organisationsindelning funkar dåligt; istället: Agila metoder: Scrum, XP Leverera lite men ofta, omarbetning av koden, modultester Man kan olika projektroller Det är svårt kommendera någon, men man kan be eller ställa upp frivilliga utvecklare arbetar med det man är intresserad av undantag -> betalada utvecklare Lätt att öka på antalet medlemmar (falsifierar Brooks lag) p.g.a. kommunikationens karakatär 13

Programkvalitet Ger öppen källkod bättre program? E. Raymonds tre faktorer för os högre kvalitet Transparant utvecklingsprocess Leveranspolicy: anti-deadline policy Utvecklarna har själv valt att arbeta med produkten Utplattad och ofiltrerad kommunikation Code review: tillräckligt många utvecklare som tittar på koden ( Linus law, Raymond) Användare som själva är utvecklare kan rapportera buggar på ett kodnära sätt Automatiserad lågnivåtestning(ex. junit) Communities kan vara mycket uthålliga Standardisering och kvalitets-certifiering är oviktigt Följa öppna standards är däremot viktigt 15

Hur hittar man Ö.K-produkter? Börjar med ofta med användandet av programmet Hur hittar man produkten (och communitet)? http://freshmeat.net/ http://sourceforge.net/ http://slashdot.org/ http://directory.fsf.org/ (Free Software Directory) Hitta: källkod och ev. binära distributioner dokumentation och kommunikationsverktyg Förstå programmets källkod och arkitektur programspråk används ramverk? (ex: Spring, Hibenate) andra tekniker och språk (ex: Ajax, XML, CSS, etc) 16

Freshmeat

Sourceforge.net

Free Software Directory

Verktyg för utveckling av Ö.K Verktygen inte unika för open-sourcecommunities Kommunikations- och dokumenthanteringssystem Epost-listor Diskussionsforum Chat (IRC) Bloggverktyg Wiki Content management system (CMS) 20

Verktyg: Bugghantering Inrapportering av fel Beskrivning av felet Vad utlöste felet I vilken version uppstod felet Feature request / ändringsbegäran Att göra-lista Status och prioritering Öppen, löst, återöppnad,... Önskvärd, kritisk,... 21

Verkyg: Bugghantering och programkvalitet Även för yttervärlden Hur ser buggdatabasen ut Ingen inget görs Få buggar ingen jobbar, få använder produkten Många allvarliga buggar instabil Gamla allvarliga buggar hur bra fungerar communitet? Hälsosamt med en lagom lista med buggar Exempel på bugghanteringssystem Bugzilla, Jira, Trac... 25

Verktyg: Versionshantering Många som jobbar mot samma filer Hämta ut senaste versionen av en fil Jämföra olika versioner Sammanföra ändringar Leverera versionen vid en viss tidpunkt Täta releasecykler CVS, Subversion, Git,... 3.0rc 3.0 Branch 2.4 2.4.1 26

Licensmodeller Oerhört viktigt att förstå de olika licensmodellerna En juridisk utmaning! GPL (GNU General Public Licence) V1, V2 och V3 Copyleft: sprider sig till egen kod -> GPL Copyleft ger rätt att: använda och undersöka programmet kopiera och dela programmet med andra modifiera programmet distribuera modiferad och härledda program Kan vara nödvändigt att dela upp i delsystem med tydliga gränssnitt 27

Licensmodeller GNU Lesser General Public License kod kan länkas (ej derivat) in av proprietära program (utan att förändra licensformen) Apache License kräver INTE att modifierade varianter måste ha samma licens (men ursprunget skall anges) Common Development and Distribution License (SUN) Common Public License (IBM) Mozilla Public License Jämförelser mellan licenser http://en.wikipedia.org/wiki/comparison_of_free_s oftware_licences 28

Bedömning av programkvalitet Communitiets status antal och typ av deltagare aktiviteter möjligheter att få hjälp och påvera utvecklingen Arkitektur nyttjande av kända standards flexibilitet (hur lätt är det att integrera mot andra system?) Produktens mognad Antal och typer av buggar Produktens potential Enkelhet att initera användande hur mycket måste konfigureras, etc 29

Hur kan en traditionell organisation bidra till Ö.K.-utv.? Använda öppen källkods-produkter (t.ex. utvecklingsverktyg och serverprogramvara) större användarbas, fostra användare Bidra ekonomiskt donera pengar, utrustning, lokaler, prylar, etc. det är svårt att köpa inflytande bidra med utvecklare (bästa sättet att få inflytande) bidra med användarfall och högnivåtestning (ovärderligt) Utveckla produkten och låta ändringarna gå tillbaka till communitet De egna ändringar kommer att ingå i de officiella produkten (man slipper modifiera sin version vid varje ny uppdatering) 30