picture

Tradisjonell produktutvikling har vært styrt av markedet. Markedet har satt premissene for de strategiske valgene til hva bedriftene utvikler, og suksessen har vært målt i omsetning og fortjeneste. Et godt produkt har vært et produkt som tjener mye penger. Produktutvikling har vært svært kostbart, og investeringene måtte derfor beskyttes med hemmelighold og kompliserte juridiske regler.

I åk miljøet er spillereglene annerledes. Det tradisjonelle markedet, dvs. det kommersielle markedet, har liten betydning. Produktutvikingen er motivert av et personlig engasjement, og det er utviklernes egne idéer og behov som bestemmer hva som blir utviklet. Suksessen måles i hvor mange og hvor fornøyde brukere produktene får, og ikke i penger. Det gjør at kvalitet får en helt ny betydning. Mens kvalitet er et nødvendig onde i kommersiell produktutvikling, egentlig bare er en merkostnad, er kvalitet et viktig mål i seg selv i åk miljøet. Et annet pussig kjennetegn er de mer eller mindre uskrevne reglene som gjelder i stedet for juss. Ta for eksempel lisensbetingelsene. De fleste åk prosjekter har en lisensavtale der hvem som helst kan videreutvikle prosjektet som de ønsker. Jeg kunne for eksempel lastet ned Linux, kalt det jarleos, og videreutviklet det som det passet meg. Dette ville vært helt lovlig, både ut ifra norsk juss, og lisensavtalen til Linux. Med så ukontrollerbare regler, så skulle man jo tro at prosjekter ville bli "kapret" hele tiden, og at utviklerne ville være så opptatt av å vinne flest mulig brukere til sin personlige versjon, at det ikke ville være tid og ressurser nok til å skape noe levedyktig. I praksis skjer ikke dette. For i fraværet av formalisert juss, har det utviklet seg klare spilleregler og en streng selvjustis blant hackere. Man tar ganske enkelt ikke over et prosjekt. Dersom noen "kapret" Linux, eller et annet prosjekt, ville personen som gjorde det bli frosset ut av miljøet. Han ville stå alene, uten tilgang på dyktige hackere til å programmere og teste programmet, og han ville være avskåret fra de attraktive distribusjonskanalene. Folk i hackermiljøet ville sky personen som pesten, og selv kommersielle interesser ville frykte konsekvensene av å bli assosiert med ham. Tilsvarende regler gjelder for hvordan man starter opp et prosjekt, hvordan man blir med på et prosjekt, hvilken innflytelse man skal ha på prosjektes utvikling, og hvordan man trekker seg ut av et prosjekt og gir stafettpinnen over til en annen.

Åk miljøet har lite til felles med tradisjonell kommersiell tenking. Det innebærer at vi i Norge har veldig vanskelig for å forstå både ideologien, og motivasjonen som driver utviklingen. Særlig om vi tenker på programutvikling som produktutvikling. Ser vi til forskningen, eller til kunsten, blir forståelsen en annen. En forsker er sjelden motivert av kvartalstall, salgsprognoser eller budskjetter. Å bli publisert i et anerkjent tidsskrift vil derimot være en voldsom motivasjon. For ikke å snakke om en Nobelspris. Det er ikke penger, men status som teller. Publiserer man noe banebrytende, blir man anerkjent og husket, og ikke minst beundret og respektert av sine likemenn. Og her ligger antakelig nøkkelen til å forstå åk miljøet. Programmererne er ikke asosiale altruister eller anarkister som pulser med sitt uten å bry seg om verden omkring dem. Tvert imot har de minst like velutviklede konkurranseinstinkter som sine kommersielle kollegaer. Men i stedet for penger, konkurrerer de om anerkjennelse blant likemenn. Dette gir en litt uventet effekt. Terskelen for å i det hele tatt komme inn i varmen i åk miljøet er uendelig mye høyere enn terskelen for å få jobb som programmerer. Kun de som over tid beviser at de både forstår de sosiale spillereglene, og kvalifiserer rent faglig, vil bli akseptert. Det betyr i praksis at kun kremen av programmererne (og de som klarer å late som de er det), globalt, får innflytelse på åk. Det tok for eksempel nesten 7 år fra jeg lanserte warftpd, og hadde "gudestatus" i hacker-miljøet på windowsplattformen, til jeg ble akseptert som bidragsyter i GNU miljøet. En slik streng "naturlig seleksjon" sørger for at kvaliteten på åk programmer i utgangspunktet er meget høy.

I tradisjonell programutvikling blir programmerere ofte satt til å arbeide på prosjekter de ikke har noe spesielt forhold til. Motivasjonen blir deretter. I tillegg skal alt gjøres fort og kosteffektivt. Det begrenser muligheten til å levere faglig god kvalitet, noe som igjen bidrar til å senke motivasjonen i en negativ spiral. I åk sammenheng begynner de fleste prosjektene med at en programmerer har et gitt behov som han ønsker å løse. Utviklerne finner med andre ord sine egne prosjekter, og de bidrar fordi problemet interesserer dem. I mange tilfeller var det ikke engang meningen å lage et åk prosjekt. Da jeg skrev warftpd var det fordi jeg ikke ville betale for noe så selvfølgelig som en FTP server. På det tidspunktet fantes det ikke noen gratis FTP server for Windows. Jeg la programmet ut på nettet for å dolke de to kommersielle serverne litt i siden – ikke fordi jeg trodde warftpd ville bli populær. Et år senere var det antakelig det mest kjente gratis serverprogrammet for Windows. Det var ikke fordi jeg satt meg ned og skrev noe genialt, men fordi jeg, uten å være klar over det selv, fulgte et par grunnleggende, den gang uskrevne, regler for åk. Jeg jobbet intenst med programmet fordi det interesserte meg. Jeg lyttet til all tilbakemeldingen jeg fikk, og implementerte alt jeg syntes var gode ideer. De som gav tilbakemeldinger, og fikk forslagene sine implementert, fikk vann på møllen og kom med enda flere og enda bedre forslag. Slik gikk warftpd på et halvår fra å være svært primitiv, til å bli et flaggskip på sitt område. Populariteten og utbredelsen kan illustreres ved at Microsoft la inn støtte både i Windows 2000 og i Internet Explorer 5 for å håndtere bugs i warftpd. Og denne suksessen ble nådd uten at det engang var åk!

Latskap er et typisk kjennetegn på suksessrike mennesker. Man gidder ikke å gjøre mer enn man behøver for å nå et mål. Dersom man trenger et program for en bestemt oppgave, er det idioti å skrive alt fra grunnen, om man kan ta utgangspunkt i et program som nesten gjør det man vil. Når programmer er åk, kan man gjøre nettopp dette, og så legge ned kreftene i de få forandringene som skal til for å løse den nye oppgaven. Dette var den opprinnelige innfallsvinkelen for mange av hackerne i åk miljøet, og det er denne mekanismen som driver mange prosjekter videre. Det var for eksempel enklere for meg å porte et DNS resolver bibliotek til Windows når jeg trengte det i warftpd, enn å skrive ett fra bunnen og opp selv. Jeg kunne til og med gjøre dette, selv om opphavsmannen til biblioteket opprinnelig var sterkt imot at det skulle portes til Windows. Siden har jeg fått en god del tilbakemelding fra andre som bruker det i sine egne programmer under Windows. Det opprinnelige arbeidet ble modifisert litt av meg, og lever så videre i nye programmer på en plattform som opphavsmannen ikke engang vurderte å støtte. Opphavsmannen vinner mer prestisje og respekt, jeg vinner respekt ved min minimale innsats, i tillegg til at jeg sparer måneders arbeid, og de som bruker min windowsport sparer tid. Alle tjener på opphavsmannens arbeid og mitt arbeid.

Kan dette prinsippet også gjøres gjeldende for annen kommersiell programvareutvikling? Vil ikke programmer miste sin kommersielle verdi dersom kildekoden er tilgjengelig for alle og enhver? For å svare på det må vi se litt på fordelingen av proprietær kontra generell programvare. Proprietær programvare er programvare som utvikles internt av bedrifter for deres spesielle behov. Det er programvaren som styrer allverdens forbrukselektronikk, dippedutter, kontrollsystemer, for ikke å snakke om hele den offentlige forvatningen, som folkeregister, trygd skatter og saksbehandling. Andelen av generelle programmer, som tekstbehandling, ruteark, FTP servere og operativsystemer oppi alt dette er under 5%. Det betyr at mer enn 95% av programvaren, og programutviklingen, gjelder proprietære systemer uten salgsverdi. Tenk hvilken enorme besparelser store bedrifter og offentlige etater kunne ha om de baserte seg på åk. De ville selvfølgelig ikke få gevinsten av å bruke de aller flinkeste og best motiverte programmererne, men de ville spare milliarder på lisenskostnader (for de programmer de måtte kjøpe) og egenutvikling, fordi de kunne dra nytte av gjenbruk av kode mellom etatene og over landegrensene. Dette har etter hvert begynt å gå opp for enkelte politikere og byråkrater.

Kan tradisjonell kommersiell programvare overhodet overleve? Det er flere studier som konkluderer med at det ikke ser lyst ut. For det første har åk en spesiell appell til veldig mange av de virkelig flinke programmererne. For det andre tiltrekker store, prestisjefylte prosjekter seg svært mange av dem. Det ville kort og godt vært for dyrt for et kommersielt firma å betale for alle de hundre tusener av timer tusenvis av verdens beste programmerer har lagt ned i Linux. For ikke å snakke om å organisere noe slikt! Dernest ville de neppe fått den samme kvaliteten på arbeidet, selv om de betalte svært godt for hver eneste time. Tradisjonell belønning i form av høy lønn er ganske enkelt ikke motiverende for kreativt arbeid. Tvert imot har psykolog Theresa Amabile fra Brandeis University i et studie fra 1984 slått fast at lønnet arbeid generelt er mindre kreativt enn arbeid utført av ren interesse. Lønn i seg selv påvirker ikke kreativiteten, men bonusordninger og akkord er direkte demotiverende! I tillegg har man "Brooks Law" som sier at desto flere folk man setter inn på et prosjekt, desto tregere går det. Dette har vist seg å stemme i mange kommersielle prosjekter. Nå kan du kanskje innvende at dette burde jo slå foten bort under store åk prosjekter! 1000 utviklere må jo arbeide fryktelig tregt, når man vet hvor lang tid en eneste programmerer bruker på en oppgave. Heldigvis er dette beviselig ikke tilfelle for åk. Dette har sammenheng med hvordan prosjektene organiseres. Mens kommersielle prosjekter har masse overhead i form av møter og kommunikasjon mellom alle deltakerne i prosjektet, er åk prosjekter mye mer fokusert direkte på kildekoden. Det er få personer som tar avgjørelsene i prosjektet. De som tar avgjørelsene har generelt full beslutningsdyktighet. De står ikke til ansvar for et styre eller en markedsavdeling. I tillegg går kommunikasjonen ikke mellom alle deltakerne, men mellom deltakerne på ett område, og den som bestemmer på det området. Det betyr at en ansvarlig for en modul kanskje kommuniserer med 200 utviklere i løpet av et år – men de 200 kommuniserer stort sett bare med ham. Dermed sparer man veldig mye tid. Typiske Åk prosjekter har altså ikke bare flere, mer kreative og bedre motiverte deltakere, - de er også mer effektivt organisert enn sine kommersielle konkurrenter. Dette har begynt å gå opp for de fleste tradisjonelle programvarehusene, og som et resultat av dette skjer det nå en manisk lobbyvirksomhet, særlig i USA, for å slå tilbake åk med nye lover og patenter. Dette forteller veldig klart hvordan disse aktørene vurderer sjansene sine på sikt, i åpen konkurranse.

Et av de største problemene med moderne programmer er feil, eller bugs. Alle som skriver programmer sliter med dette. De seriøse, kommersielle programvarehusene legger ned veldig mye tid og ressurser i å finne og fjerne bugs før et produkt kommer på markedet. Stort sett uten særlig hell. Hvordan kan åk kvalitetssikre programmer? Å lete etter bugs er jo ikke akkurat det mest spennende å fordrive tiden med, og uten penger kan man tross alt ikke betale noen for å gjøre det. Svaret er at debuggingen skjer uhyre effektivt med åk. For det første vil flere utviklere, med radikalt forskjellig bakgrunn, lese kildekoden. Noen for å gi en håndsrekning med debuggingen, andre fordi de skal legge inn ny funksjonalitet. Veldig mange bugs ser man øyeblikkelig når man leser en annens kode. Dernest vil mange utviklere oppdage andres bugs når de arbeider med sine egne moduler. Mens vanlige sluttbrukere gjerne beklager seg over at program X "ikke virker", vil en programmerer typisk gi en mye mer presis feilmelding. Enkle problemer vil han typisk rette selv. Vanskeligere bugs vil han rapportere på en så presis måte som mulig. Når mange nok ser på den samme kildekoden er det alltid noen som oppdager det underliggende problemet. Dette har vist seg i utviklingen av Linux mange ganger.
Vil ikke dette medføre en masse dobbeltarbeid? I praksis går debugging av åk programmer raskt. For å unngå at folk skal kaste bort tid på å debugge feil som allerede er løst, er det vanlig å slippe nye versjoner hyppig, ofte daglig, på prosjekter i full utvikling. Men også her kommer prestisjen inn. Det gir prestisje å være raskt ute med nye versjoner når det er oppdaget feil. Særlig når det gjelder alvorlige feil. Jeg tar det alltid som et personlig nederlag når noen rapporterer en alvorlig feil i warftpd, og legger alt annet til side til feilen er rettet. Dette fikk en av lederne på SecurityFocus (et av de ledende nettstedene for datasikkerhet på nettet) til å sende meg en mail for et par år siden, der han hevdet at jeg var kjent som en av de beste i bransjen på dette feltet. Mens kommersielle aktører må ta hensyn til salgsbudsjettet og aksjekursen, prioriterte jeg til enhver tid prestisjen i å ha et produkt helt fritt for kjente, alvorlige feil. Jeg tror denne fagstoltheten er betegnende for åk hackerne.

De sterkeste innvendingene mot åk er gjerne "Hva om prosjektet blir forlatt?", eller "Hva om noen kjøper det og krever lisens?". Sjansen for at et åk prosjekt av noen størrelse blir forlatt er mindre enn sjansen for at en kommersiell aktør enten legger ned, eller kutter et tilsvarende prosjekt. For det første er prosjektet uttrykk for et genuint engasjement fra forfatteren. For det andre er det en del av åk kulturen å gi prosjektet videre til en ny og kompetent "eier" dersom man går lei. Skulle eieren av en eller annen grunn dø eller forsvinne, finnes det klare regler for hvordan prosjektet kan overtas av en annen. Dette gjør at åk prosjekter kan leve i mange tiår, mens kommersielle produkter gjerne bare har en levetid på noen få år. Den andre innvendingen, at noen kan "kjøpe" prosjektet, er blokkert av lisensavtalen. Det finnes mange lisensavtaler for åk. Samtlige gir brukere av programmet rett til å bruke det for all fremtid. De større prosjektene, som Linux, GNU osv, har svært eksplisitte lisensbestemmelser om at kildekoden skal være åpen for all fremtid. Det er med andre ord ikke mulig å kjøpe et åk prosjekt, og så kommersialisere det.

Det mest interessante spørsmålet for ikke-nerdene blant oss er da: Hvordan tjener vi penger på åk? Det finnes flere måter. De mest umiddelbare er:

  1. Ved salg av support, tilpasninger og kompetanse rundt et prosjekt
  2. Ved å selge programmerertimer til bedrifter som utvikler egne åk løsninger
  3. Ved å slå seg sammen med andre og utvikle programmer for en bestemt oppgave, og så selge implementasjon og konsulenttid.

Listen kan gjøres svært lang. Det eneste man ikke kan gjøre, er å krympeplastpakke åk produkter, og hevde noen form for eksklusivitet på salg og distribusjon. De som er flike og tilpasser seg den nye virkeligheten, kan tjene meget gode penger på åk. Både ved å engasjere seg i utvikling, med den prestisje, spesialkompetanse og faglige tyngde det gir, og ved å plassere seg på sidelinjen og selge tjenester rundt produktene. Åk er begynnelsen på en ny tid og en ny postindustriell tenkemåte, der personlig frihet og personlig vekst blir dominerende i programvareindustrien. Det betyr at mennesket, i stedet for kapitalen, vil stå i fokus hos dem som gjør suksess. Det innebærer også at tradisjonelle ansettelsesforhold, der ansatte settes på prosjekter, kan forsvinne til fordel for prosjektansatte som velger sine egne prosjekter, og gjennom prosjektene, sin midlertidige arbeidsgiver.