Personliga verktyg
Du är här: Hem Dokumentation Tutorials Katedralen och basaren Nödvändiga förutsättningar för basarstilen
Donera
Inloggning


Glömt ditt lösenord?
Ny användare?
« November 2019 »
November
TiOnToFr
123
45678910
11121314151617
18192021222324
252627282930
 
Dokumentåtgärder

Nödvändiga förutsättningar för basarstilen

Nödvändiga förutsättningar för basarstilen
Jag analyserar ett framgångsrikt open-source projekt, fetchmail, som medvetet kördes som en test av några överraskande teorier om utveckling av programvara, som kommer från Linux historia. Jag diskuterar dessa teorier utifrån två fundamentalt olika utveklingsmodeller, 'katedral-modellen', som flertalet i den kommersiella världen använder, kontra 'basar-modellen' från Linuxvärlden. Jag visar, att dessa modeller emanerar från motstridiga ansatser om felsökningens natur gällande programvara. Jag ger sedan en underbyggd argumentation för att Linuxerfarenheten "med ett tillräckligt antal ögon blir alla fel ytliga" visar analogi med andra självkorrigerande system av själviska agenter, och avslutar med en utredning om vad denna insikt betyder för programmeringskonstens framtid.
Page 10 of 16.

Tidiga läsare av denna artikel ställde frågor om förutsättningarna för ett framgångsrikt utvecklingsarbete enligt basarmodellen, inklusive projektledarens kvalifikationer och om tillståndet på den programkod då man publicerar och börjar bygga upp en kommunitet av medutvecklare.

Det står rätt klart att man inte kan bygga kod från första början i basarstilen [IN]. Man kan testa, debugga och förbättra i basarstilen, men det skulle vara svårt att starta helt från noll. Linus försökte inte detta. Inte heller jag. Ens nytillkomna samhälle av medutvecklare måste ha något körbart att testa och leka med.

När man börjar bygga sitt samhälle, så behöver man också kunna presentera ett trovärdigt framtidslöfte. Programmet behöver inte fungera särskilt väl. Det kan vara grovt, buggigt, ofullgånget och dåligt dokumenterat. Men det måste kunna (a) köras, och (b) övertyga potentiella medhjälpare att det kan utvecklas till något verkligt bra inom överskådlig tid.

Både Linux och fetchmail lades ut med starka och attraktiva grundkoncept. Många personer som funderar på basarmodellen såsom jag har presenterat den, har med rätta ansett detta vara fundamentalt, och därifrån dragit slutsatsen att intuition och klurighet hos projektledaren är en nödvändig förutsättning.

Men Linus fick sin design från Unix. Jag fick min från föregångaren Popclient (även om den senare skulle komma att ändras en hel del, mycket mer än Linux proportionellt sett). Så vad betyder detta för ledaren/koordinatorn för ett projekt i basarstilen? Måste han själv ha en exceptionell begåvning eller kan han lyfta sig med andras talanger?

Jag tror inte att det är kritiskt att koordinatorn är begåvad med en exceptionell briljans, men att det är absolut nödvändigt att han känner igen och förstår goda designidéer hos andra.

Både Linux och fetchmail-projekten visar detta. Linus är, som tidigare diskuterats, inte någon spektakulärt originell designer, men han har visat ett gott handlag i konsten att känna igen bra saker och integrera dessa i Linuxkärnan. Och jag har redan beskrivit hur den bästa enskilda design idéen i fetchmail (SMTP forwarding) kom utifrån.

Tidiga läsare av denna essä smickrade mig med att antyda att jag tenderar underskatta originalitet i basarprojekt eftersom jag själv äger mycket av denna gåva och sålunda tar mycket för givet. Det kan vara någon sanning i detta, eftersom design, till skillnad från kodning och felsökning, är min starkare sida.

Men problemet med att vara klurig och originell i mjukvarudesign är att det blir till en dålig vana. Man börjar reflexmässigt med att göra saker tjusiga och komplicerade, när man istället borde göra dem robusta och enkla. Jag har kraschat projekt med dylika misstag, men lyckades undvika detta med fetchmail.

Jag tror att fetchmail-projektet lyckades delvis därför att jag lade band på min tendens att vara klurig. Detta talar emot att designoriginalitet skulle vara väsentligt för ett lyckat basarprojekt. Och tänk på Linux. Antag att Linus Torvalds hade försökt att att driva fram fundamentala innovationer inom operativsystemdesign; är det då särskilt sannolikt att den resulterade kärnan hade blivit så stabil och lyckad som den är?

En viss basnivå på skicklighet i design och kodning är naturligtvis nödvändig, men jag tror att nästan alla som på allvar funderar på att sjösätta ett projekt i basarstilen redan ligger över denna miniminivå. Open-source rörelsens interna marknad för anseende utövar ett subtilt tryck på folk att inte sätta igång utveckligsarbeten som de inte är kapabla att fullfölja. Detta tycks ha fungerat bra hittills.

Det finns en annan sorts förmåga som vanligtvis inte associeras med med programutveckling som jag tror är väl så viktig för basarprojekt som designkunnande - ja, kanske viktigare. En ledare för ett basarprojekt måste ha god hand med folk och kunna kommunicera.

Detta torde vara uppenbart. För att bygga upp ett utvecklingssamhälle måste man attrahera människor, intressera dem för det man gör och få dem att känna sig tillfreds med den del av arbetet som de utför. Tekniskt briljans går långt i detta, men det är inte hela sanningen. Den personlighet man uppvisar betyder också mycket.

Det är ingen tillfällighet att Linus är en trevlig kille som väcker sympati och får folk att vilja hjälpa honom. Det är ingen tillfällighet att jag är en utåtriktad person som tycker om att bearbeta en publik och har stå-upp-komikerns instinkter. För att få ett basarprojekt att fungera, så hjälper det enormt om man har lite av förmågan att charma människor.