Tartalomjegyzék
KivonatA katedrális és a bazárA levélnek át kell jutnia 1. Minden jó szoftver egy fejlesztő személyes vágyainak kielégítésével kezdődik. 2. A jó programozók tudják mit írjanak. A nagyok azt is tudják, mit írjanak (és használjanak) újra. 3. „Tervezd be, hogy egyet el fogsz dobni, úgyis el fogod” (Fred Brooks, The Mythical Man-Month, 11. fejezet) 4. Megfelelő attitűd mellett az érdekes problémák megtalálnak. 5. Ha már nem érdekel egy program, az utolsó kötelességed átadni azt egy kompetens utód számára.Kivonat
A fetchmail nevű, sikeres nyílt forráskódú projektet boncolgatom, amely tudatos kísérlet volt a Linux történetéből leszűrhető meglepő szoftvertervezési elméletek tesztelésére. Ezeket az elméleteket két különböző fejlesztési stílus mentén fejtem ki, a kereskedelmi világ katedrális modellje, illetve a vele szemben álló linuxos világ bazár modellje mentén. Bemutatom, hogy ezek a modellek a szoftverhiba-keresési folyamat természetére vonatkozó ellentétes feltételezésekből származnak. A linuxos tapasztalatok alapján amellett érvelek, hogy „elég sok szem mellett minden hiba jelentéktelenné válik”; termékeny analógiákat javaslok más, önző ágensekből álló önjavító rendszerekkel, majd ezen meglátások következményeinek a szoftverek jövőjére gyakorolt hatásával fejezem be.
A katedrális és a bazár
A Linux felforgató. Ki gondolta volna még csak öt évvel ezelőtt is (1991), hogy a bolygón szétszórt, csupán az internet finom fonalával összekötött sok ezer fejlesztő részidős bütykölése, mintegy varázsütésre, világszínvonalú operációs rendszerré egyesül?
Én biztosan nem. Mire feltűnt az érzékelőimen a Linux 1993-ban, már benne voltam a Unix-fejlesztésekben és a nyílt forráskódú fejlesztésekben tíz éve. Az első GNU-közreműködők egyike voltam a nyolcvanas évek közepén. Jelentős mennyiségű nyílt forráskódú szoftvert tettem közzé a hálón, fejlesztettem és társfejlesztettem számos programot (nethack, az Emacs VC és GUD üzemmódjai, xlife és egyebek), amelyek még ma is széles körben használtak. Azt hittem, hogy tudtam, hogyan készültek.
A Linux felborított sok dolgot, amelyről úgy gondoltam, ismerem. Hirdettem a kis eszközök, a gyors modellalkotás és a lépésenkénti fejlődést elősegítő programozás unixos igéjét évekig. Ugyanakkor abban is hittem, hogy létezik egy bizonyos összetettség, amely fölött egy centralizáltabb, a priori megközelítés szükséges. Hittem benne, hogy a legfontosabb szoftverek (az operációs rendszerek és az olyan igazán nagy eszközök, mint az Emacs programozói szerkesztő) szükségszerűen a katedrálisokhoz hasonlóan épülnek, egyéni varázslók által, óvatosan ügyeskedve, vagy mágusokból álló, elszigetelt kis csoportok által, idő előtti bétaverziók nélkül.
Linus Torvalds fejlesztői stílusa – adj ki korán és gyakran, adj ki mindent, amit csak tudsz, a kuszaságig légy nyílt – meglepetésként ért. Nem volt itt semmiféle csöndes, tiszteletteljes katedrálisépítés, a Linux-közösség a különféle tennivalók és megközelítések nagy, fecsegő bazárjára hasonlított (ezt leginkább azok a Linux-archívumok jelképezik, amelyek bárkitől elfogadják a beküldött dolgokat), amelyből egy koherens és stabil rendszer látszólag csak valami csoda folytán születhetne.
Az a tény, hogy a bazár stílus működni látszott, és nem is rosszul, határozottan sokkoló volt. Ahogy jártam az utamat, nemcsak egyéni projekteken dolgoztam keményen, hanem annak a megértésén is, hogy a linuxos világ miért veszi olyan jól az akadályokat a katedrálisépítők számára aligha elképzelhet51; sebességgel, ahelyett, hogy egyszerűen darabjaira esne.
1996 közepére úgy gondoltam, hogy kezdem érteni. Tökéletes lehetőségem nyílt az elméletem tesztelésére egy nyílt forráskódú projekt keretében, amit megpróbálhattam a bazár módszerével fenntartani. Meg is tettem, és hatalmas siker lett belőle.
Mindez annak a bizonyos projektnek a története. Felhasználom, hogy néhány fontos dolgot állíthassak a hatékony nyílt forráskódú fejlesztésről. Ezek közül némelyikkel nem a linuxos világban találkoztam először, de majd meglátjuk, hogyan ad nekik a linuxos világ különös jelentőséget. Ha nem tévedek, segíteni fognak annak a pontos megértésében, hogy mi teszi a Linux-közösséget olyan termékennyé a jó szoftverek terén, és talán abban is segít, hogy te magad termékenyebb legyél.
A levélnek át kell jutnia
1993 óta felelős vagyok egy kicsi, ingyenes hozzáférést biztosító, Chester County InterLink (CCIL) nevű internetszolgáltató műszaki üzemeltetésért a pennsylvaniai West Chesterben. A CCIL társalapítójaként megírtam az egyedi, többfelhasználós hirdetőtábla-szoftverünket, ami a locke.ccil.org-ra betelnetelve megnézhető. Mára már csaknem háromezer felhasználóval működik, harminc vonalon. A munka lehetővé tette számomra a napi 24 órás hálózati hozzáférést a CCIL 56K-s vonalán, sőt egyenesen megkövetelte.
Igencsak hozzászoktam az azonnali internetes e-mailezéshez. Bosszantónak találtam telnettel periodikusan bejelentkezni a locke-ra, hogy megnézzem a leveleim. Azt szerettem volna, hogy a levelek a snarkra (az otthoni rendszeremre) érkezzenek, így értesülhetnék kézbesítésükről, és a saját eszközeimmel kezelhetném őket.
Az interneten használt levéltovábbító protokoll, az SMTP (Simple Mail Transfer Protocol) azért nem felelt meg, mert az akkor működik optimálisan, ha a gépek folyamatosan a hálózatra vannak kapcsolva, miközben az én számítógépem nem volt állandóan az interneten, és nem volt statikus IP-címe sem. Szükségem volt egy programra, amely az időszakosan felépített betárcsázós kapcsolaton keresztül behúzza a leveleket helyi kézbesítés céljából. Tudtam, hogy ilyen dolgok léteznek, és hogy legtöbbjük a POP (Post Office Protocol) nevű egyszerű alkalmazásprotokollt használja. A POP-ot ma a legtöbb e-mail kliens támogatja, de abban az időben nem volt beépítve a levélolvasó programba, amit használtam.
Szükségem volt egy POP3 kliensre. Szétnéztem az interneten, és találtam egyet. Valójában hármat vagy négyet találtam, használtam őket egy ideig, de hiányoltam a bejövő levelekben szereplő címek megpiszkálásának egyébként nyilvánvaló lehetőségét, amellyel az elhozott levélre adott válasz funkciója is jól működött volna.
A probléma a következő volt: ha valaki a locke-ról „joe” néven küldött nekem levelet, akkor a snarkra átmásolt levélre adandó választ a levelezőprogramom boldogan elküldte volna a snarkon nem is létező „joe” számára. A válaszcím kézzel való szerkesztése, és átirányítása a @ccil.org-ra hamarosan gyötrelmessé vált.
Ez egyértelműen olyan dolog volt, amit a számítógépnek kellett volna megtennie, de egyetlen létező POP kliens sem tudta hogyan. Ez vezet minket az első tanulsághoz:
1. Minden jó szoftver egy fejlesztő személyes vágyainak kielégítésével kezdődik.
Ennek bizonyára nyilvánvalónak kellett volna lennie (ahogy a mondás tartja: a szükség találékonnyá tesz), ám a szoftverfejlesztők túl gyakran töltik az idejüket olyan lélekölő, de pénzt hozó programokkal, amelyekre nincs szükségük és amelyek nem is érdeklik őket. Másképp van ez a Linux világában, ami megmagyarázhatja, hogy miért olyan jó minőségűek a Linux-közösséghez visszavezethető szoftverek.
Vajon őrült pörgésbe kezdtem-e azonnal, hogy lekódoljak egy teljesen új POP3 klienst, hogy versengjek a már létezőkkel? Semmi esetre sem. Alaposan megvizsgáltam a kezem ügyébe kerülő POP segédprogramokat és megkérdeztem magamtól, hogy melyik áll legközelebb ahhoz, amit szeretnék. Mert:
2. A jó programozók tudják mit írjanak. A nagyok azt is tudják, mit írjanak (és használjanak) újra.
Bár nem tartom magam nagy programozónak, azért megpróbálok úgy tenni. A nagyok fontos jellemzője a konstruktív lustaság. Tudják, hogy a legjobb jegyet nem a szándékra, hanem az eredményre adják, és majdnem mindig egyszerűbb továbblépni egy jó részmegoldásról, mint a semmiről kezdeni.
Linus Torvalds például nem az alapoktól kezdte el a Linux írását, hanem a Minix, egy kicsi, PC-re írt Unix-szerű operációs rendszer kódját és ötleteit használta fel újra. Végül minden Minix-kód eltűnt vagy teljesen át lett írva, de amíg a helyükön voltak, segítették azt a kezdeményt, ami később Linuxszá vált.
Ennek szellemében egy létező POP segédprogramot kerestem, amit elég jól kódoltak ahhoz, hogy a fejlesztés alapjául használhassam fel.
A unixos világ forráskód-megosztással kapcsolatos hagyományai mindig kedveztek a kódújrahasznosításnak (ezért választotta a GNU Projekt is a Unixot alap OS-nek, az OS súlyos megszorításai ellenére is). A linuxos világ ezt a hagyományt majdnem a technológiailag lehetséges határokig elvitte, terabájtnyi nyílt forráskódot téve elérhetővé. Ezért mások majdnem jó megoldásainak keresése valószínűleg eredményesebb lehet a linuxos világban, mint bárhol máshol.
Eredményes is volt. A korábbiakkal együtt a második keresés után kilenc jelöltem volt: a fetchpop, a PopTart, a get-mail, a gwpop, a pimp, a pop-perl, a popc, a popmail és az upop. Elsőként a Seung-Hong Oh által írt fetchpop mellett tettem le a voksomat. Kibővítettem a fejlécátíró funkcióval és egyéb javításokkal, amelyeket a szerző az 1.9-es kiadásban át is vett.
Néhány hét múlva azonban belebotlottam Carl Harris popclientjének kódjába, és rájöttem, hogy ez így nem lesz jó. Bár a fetchpopban volt néhány igazán eredeti ötlet (például a háttérben, démonként való futás), csak a POP3-at tudta kezelni, és eléggé amatőr módon volt kódolva (Seung-Hong akkoriban egy okos, de tapasztalatlan programozó volt, mindkettő érezhető volt). Carl kódja jobb, eléggé professzionális és megbízható volt, de a programból számos fontos és nehezen implementálható fetchpop-tulajdonság hiányzott, beleértve azokat is, amelyeket már én kódoltam.
Maradjak vagy váltsak? Ha váltanék, eldobnám az addigi munkámat egy jobb fejlesztési alapért.
A több protokoll támogatásának megléte a váltást motiválta. A POP3 a leggyakrabban használt postafiók-protokoll, de nem az egyetlen. A fetchpop és a többi vetélytárs nem tudta a POP2-t az RPOP-ot vagy az APOP-ot, és időnként voltak olyan gondolataim, hogy talán szórakozásból hozzáadhatnám az IMAP-ot is (Internet Message Access Protocol, a legfrissebb tervezésű és legerőteljesebb postafiók-protokoll).
De voltak elméleti okai is annak, hogy a váltás jó ötlet lehet, ezt még jóval a Linux előtt tanultam.
3. „Tervezd be, hogy egyet el fogsz dobni, úgyis el fogod” (Fred Brooks, The Mythical Man-Month, 11. fejezet)
Avagy másképp fogalmazva: gyakran nem is érted a problémát egészen addig, amíg először nem készítesz rá megoldást. A második alkalommal talán már eleget tudsz ahhoz, hogy jól csináld. Ha tehát jól akarod csinálni, készülj fel arra, hogy legalább egyszer újra kell kezdened [JB].
Nos, azt mondtam magamnak, hogy a fetchpop megváltoztatása volt az első próbálkozásom, ezért váltottam.
Miután elküldtem a popclienthez készült első patchgyűjteményemet Carl Harrisnek 1996 június 25-én, rájöttem, hogy ő valamivel előtte már elvesztette a popclient iránti érdeklődését. A kód már porosodott, kisebb hibái is voltak. Sok változtatást szerettem volna végrehajtani benne, így gyorsan megállapodtunk, hogy a logikus lépés az lesz, ha átveszem a programot.
Mielőtt észrevettem volna, a projekt már be is indult. Már nem a létező POP kliensek kisebb javításaival foglalkoztam, hanem átvettem egynek a karbantartását, gondolatokat forgattam a fejemben, amelyekről tudtam, hogy fontos változásokat fognak eredményezni.
Egy szoftverkultúrában, amely bátorítja a forráskód-megosztást, ez a projektfejlődés természetes útja. A következő alapelvet vittem át a gyakorlatba:
4. Megfelelő attitűd mellett az érdekes problémák megtalálnak.
De Carl Harris hozzáállása ennél is fontosabb volt. Ő megértette azt, hogy:
5. Ha már nem érdekel egy program, az utolsó kötelességed átadni azt egy kompetens utód számára.
Anélkül, hogy valaha is meg kellett volna beszélnünk, Carl és én tudtuk, hogy közös célunk a létező legjobb megoldás létrehozása. Az egyetlen kérdés az volt, hogy vajon be tudom-e bizonyítani, én vagyok az alkalmas személy. Amint ez megtörtént, ő jóindulatúan és gyorsan cselekedett. Remélem, hogy én is ezt fogom tenni, ha egyszer majd rajtam lesz a sor.
