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�pzelhető 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.

Felhaszn�l�ink jelentős�ge

�gy t�rt�nt, hogy meg�r�k�ltem a popclientet, �s legal�bb ennyire fontos, hogy �r�k�ltem a felhaszn�l�i b�zis�t is. Nagyszerű dolog, ha felhaszn�l�id vannak, nemcsak az�rt, mert mutatj�k, hogy sz�ks�gletet el�g�tesz ki, vagy mert valami j�t teszel. Helyesen nevelve őket, t�rsfejlesztőkk� is v�lhatnak.

A Unix trad�ci� m�sik erőss�ge, ami a Linuxn�l ism�t sz�lsős�g, hogy sok felhaszn�l� egyben hacker is, �s mivel a forr�sk�d hozz�f�rhető, ezek a hackerek hat�konyak lehetnek, ami le�rhatatlanul hasznos lehet a hibakeres�sre ford�tott idő cs�kkent�s�ben. Egy kis b�tor�t�ssal a felhaszn�l�k diagnosztiz�lj�k a probl�m�kat, javaslatokat tesznek a jav�t�sra, �s seg�tenek a k�d ann�l jelentősen gyorsabb tov�bbvitel�ben, mint amire a seg�ts�g�k n�lk�l lenn�l k�pes.

6. A gyors k�dfejleszt�s �s a hat�kony hibakeres�s fel� vezető legk�nnyebb �t a felhaszn�l�k t�rsfejlesztők�nt val� kezel�s�n �t vezet.

Ennek a hat�sait k�nnyű al�becs�lni. Val�j�ban a ny�lt forr�sk�d� vil�gban j�form�n mindannyian drasztikusan al�becs�lt�k, hogy milyen viszonyban �ll ez a felhaszn�l�k sz�m�val �s a rendszerek bonyolults�g�val, am�g Linus Torvalds be nem mutatta az ellenkezőj�t.

�gy gondolom, Linus legokosabb �s legk�vetkezetesebb tette nem a Linux kernel fel�p�t�se volt, hanem a linuxos fejleszt�si modellre val� r�tal�l�s. Amikor kifejtettem ezen v�lem�nyem a jelenl�t�ben, elmosolyodott, �s cs�ndben megism�telte azt, amit gyakran elmond: „alapvetően nagyon lusta vagyok, aki szereti m�sok helyett learatni a bab�rokat”. Okos. Vagy ahogy Robert Heinlein �rja az egyik karakter�ről: t�l lusta ahhoz, hogy kudarcot valljon.

Visszatekintve a Linux m�dszereinek �s sikeress�g�nek egy p�ld�j�t tal�ljuk a GNU Emacs Lisp programk�nyvt�r �s a Lisp k�darch�vum fejleszt�s�ben. Az Emacs C nyelven �rt magj�nak, illetve az egy�b GNU eszk�z�knek a katedr�lis�p�tő st�lus�val ellent�tben a Lisp k�dk�szlet rugalmas fejlőd�s�t a felhaszn�l�k ir�ny�tott�k. Az �tleteket �s az �zemm�dok protot�pusait gyakran h�romszor-n�gyszer is �jra�rt�k, mielőtt elnyert�k v�gső, megb�zhat� form�jukat. Az internet seg�ts�g�vel l�trej�vő laza egy�ttműk�d�s, ahogy a Linuxn�l, gyakori volt.

A fetchmail előtti legsikeresebb alkot�som tal�n az Emacs VC (verzi�k�vet�s, version control) m�dja volt, egy Linux-szerű, e-mailen kereszt�li egy�ttműk�d�s h�rom m�sik emberrel, mind a mai napig csak az egyik�kkel (Richard Stallmannel, az Emacs szerzőj�vel �s a Free Software Foundation alap�t�j�val) tal�lkoztam. A VC m�d egy előt�t (frontend) volt az SCCS-hez, az RCS-hez, majd k�sőbb a CVS-hez, amelyben az Emacs egyszerűen tudott v�gezni verzi�k�vet�si műveleteket. Egy apr�, durva, m�s �ltal �rt sccs.el nevű �zemm�db�l fejlőd�tt ki. A VC fejleszt�se az�rt volt sikeres, mert az Emacs-től elt�rően az Emacs Lisp k�dja nagyon gyorsan volt k�pes �tmenni a kiad�s-tesztel�s-fejleszt�s ciklusokon.

Az Emacs t�rt�nete nem egyedi, m�s szoftverterm�kek is l�teznek k�tszintű architekt�r�val �s k�tfel� k�tődő felhaszn�l�i k�z�ss�ggel, amely egyes�ti a katedr�lisk�nt �p�lő magot �s a baz�rk�nt fejlődő kieg�sz�tőket. Az egyik ilyen a MATLAB, egy kereskedelmi adatelemző �s -megjelen�tő programrendszer. A MATLAB �s egy�b, hasonl� szerkezetű term�kek felhaszn�l�i egy�ntetűen arr�l sz�molnak be, hogy a mozg�s, forgol�d�s, innov�ci� legink�bb az eszk�z�k ny�lt r�sz�ben t�rt�nik, ahol a nagy �s v�ltozatos k�z�ss�g kedv�re bark�csolhat.

Korai, gyakori kiad�sok

A Linux fejleszt�si modellj�nek kritikus r�szei a korai �s gyakori kiad�sok. A legt�bb fejlesztő (k�zt�k �n is) �gy gondolta, hogy ez hib�s vez�relv a trivi�lis feladatokn�l nagyobb projektek eset�n, mert a korai verzi�k majdnem defin�ci� szerint hib�sak, �s senki nem akarja ilyesmivel pr�b�ra tenni a felhaszn�l�k t�relm�t.

Ez a hit erős�tette meg a katedr�lis�p�t�s-szerű modell melletti elk�telezetts�get. Ha a kiemelt c�l az, hogy a felhaszn�l�k min�l kevesebb hib�t l�ssanak, mi�rt adn�l ki f�l�venk�nt �j verzi�t, �s dolgozn�d magad hal�lra a kiad�sok k�zti hibakeres�s sor�n? Ink�bb legyen hosszabb a kiad�si ciklus. Az Emacs C magj�t �gy fejlesztett�k. A Lisp k�nyvt�rat gyakorlatilag nem, ugyanis az FSF (Free Software Foundation) hat�k�r�n k�v�l is l�teztek Lisp arch�vumok, ahol az Emacs kiad�sait�l f�ggetlen �j, illetve fejlesztői k�dv�ltozatokat lehetett tal�lni [QR].

A legjelentősebb az Ohio State Emacs Lisp arch�vum volt, amely a mai nagy Linux-arch�vumok hangulat�t �s tulajdons�gait vet�tette előre. N�h�nyunk azonban elgondolkodott azon, mit is csin�lunk, illetve azon, hogy ennek az arch�vumnak a l�te az FSF katedr�lis�p�tő modellj�ben l�vő probl�m�kra mutat r�. 1992 k�r�l volt egy komoly k�s�rletem, hogy az ohioi k�dot form�lisan is beolvasszam a hivatalos Emacs Lisp k�nyvt�rba, de probl�m�kba �tk�ztem, rendk�v�l sikertelen k�s�rlet volt.

Egy �vvel k�sőbb, amikor a Linux sz�lesebb k�rben is l�that�v� v�lt, nyilv�nval� volt, hogy valami m�s, valami sokkal eg�szs�gesebb t�rt�nik arrafel�. Linus ny�lt fejleszt�si ir�nyelve a katedr�lis�p�t�s sz�ges ellent�te volt. Gombam�d szaporodtak a linuxos internetes arch�vumok, t�bbf�le disztrib�ci� keringett, amelyek m�g�tt egy soha nem tapasztalt gyakoris�g� alaprendszer-kiad�s �llt.

Linus a lehető leghat�konyabb m�don kezelte t�rsfejlesztők�nt a felhaszn�l�it:

7. Adj ki kor�n. Adj ki gyakran. �s figyelj a fogyaszt�idra.

Linus innov�ci�ja nem igaz�n a gyors ciklusokr�l sz�lt, amelyekbe a felhaszn�l�i visszajelz�sek is be�p�ltek (valami ilyesminek a Unix vil�g�ban m�r hossz� hagyom�nya volt), hanem arr�l, hogy a fejleszt�s bonyolults�g�val ar�nyban �ll� intenzit�ssal csin�lta. Azokban a korai időkben (1991 k�r�l) nem volt szokatlan, hogy egyetlen nap alatt t�bb �j kernelt is kiadott. Mivel kitermelte a t�rsfejlesztőit, �s mindenki m�sn�l erőteljesebben haszn�lta az internetet az egy�ttműk�d�sre, a dolog műk�d�tt.

De hogyan műk�d�tt? Valami olyasmi volt, amit �n is lem�solhatn�k? Vagy mindez Linus Torvalds kiv�teles zsenij�re t�maszkodott?

Nem hinn�m. Elismerem, Linus �tkozottul tehets�ges hacker. K�z�l�nk vajon h�nyan lenn�nek k�pesek egy teljes, minős�gi oper�ci�s rendszer magj�nak megtervez�s�re az alapokt�l? A Linux azonban nem jelentett semmilyen nagyobb horderejű elm�leti előrel�p�st. Linus nem (vagy legal�bbis m�g nem) olyan innovat�v tervezőzseni, mint mondjuk Richard Stallman vagy James Gosling (NeWS �s Java). Linus sz�momra ink�bb a tervez�s �s a megval�s�t�s g�niusz�nak tűnik, egyfajta hatodik �rz�kkel a hib�k �s fejleszt�si zs�kutc�k elker�l�s�re, �s rendk�v�li �gyess�ggel az A-b�l B pontba vezető k�nnyű utak megtal�l�s�ra. A teljes Linux konstrukci� ezt sugallja, h�ven t�kr�zi Linus m�rt�ktart� �s egyszerűs�tő tervez�si megk�zel�t�seit.

Ha teh�t a gyors kiad�sok �s az internetes k�zeg megragad�sa nem v�letlen volt, hanem Linus tervezőtehets�g�ből fakad� megl�t�s, amellyel felismerte a legkisebb erőkifejt�st ig�nylő utat, akkor mit maximaliz�lt? Mit hozott ki a szerkezetből?

Linus folyamatosan �szt�n�zte �s jutalmazta a hackereit/felhaszn�l�it. �szt�n�zte őket az �nbecs�l�s�ket kiel�g�tő cselekv�sek t�vlataival, �s jutalmazta őket azzal, hogy l�tt�k, �lland�an (ak�r naponta) fejlődik munk�juk.

Linus k�zvetlen�l megc�lozta, hogy min�l t�bb munka�ra jusson a hibakeres�sre �s a fejleszt�sre, m�g a k�dban l�vő instabilit�s �s a felhaszn�l�i b�zis esetleges konok hib�kon val� ki�g�se �r�n is. �gy viselkedett, mintha valami ilyesmiben hinne:

8. Elegendően sok b�tateszter �s t�rsfejlesztő mellett majdnem minden probl�ma gyorsan felismerhető, �s a jav�t�s is nyilv�nval� valaki sz�m�ra.

Ugyanez laz�bban: elegendő mennyis�gű szem mellett minden hiba jelent�ktelenn� v�lik. Ezt nevezem Linus t�rv�ny�nek.

Eredetileg �gy fogalmaztam, hogy minden probl�ma „vil�gos lesz valaki sz�m�ra”. Linus k�zbevetette, hogy �ltal�ban nem, vagy nem felt�tlen�l az az ember �rti a probl�m�t, �s ad r� megold�st, aki elősz�r felismeri: „Valaki megtal�lja a probl�m�t �s valaki m�s pedig meg�rti. Fel fogj�k jegyezni r�lam, hogy azt mondtam: r�akadni a nagyobb kih�v�s”. Ez a kiigaz�t�s fontos, a k�vetkező fejezetben, ahol a hibakeres�s gyakorlat�t vizsg�ljuk r�szletesebben, majd kider�l, hogy mi�rt. A l�nyeg, hogy a folyamat mindk�t r�sze (a felfedez�s �s a jav�t�s) gyorsan megt�rt�nhet.

Szerintem Linus t�rv�ny�ben testes�l meg a katedr�lis�p�tő �s a baz�ri st�lus m�g�tt l�vő legfontosabb k�l�nbs�g. A programoz�s katedr�lis�p�tő megk�zel�t�s�ben a hib�k �s fejleszt�si probl�m�k ravasz, alattomos, m�ly jelens�gek. A kiv�lasztott kevesek h�napokig tart� alapos vizsg�lat�ba ker�l eljutni a megb�zhat�s�gnak arra fok�ra, amikor �gy �rzik, kigyoml�lt�k őket. Ez�rt hossz�ak a kiad�si ciklusok, �s ez�rt az elker�lhetetlen csal�dotts�g, ha a r�g�ta v�rt kiad�s nem t�k�letes.

A baz�rban viszont felt�telezed, hogy a hib�k �ltal�ban felsz�ni jelens�gek, vagy legal�bbis el�g gyorsan felsz�ni jelens�gg� v�lnak az egyes kiad�sokhoz kapcsol�d� ezernyi lelkes t�rsfejlesztő zsivaja mellett. �ppen ez�rt gyakran k�sz�tesz kiad�sokat, hogy m�g t�bb jav�t�st kapj, �s mindez azzal a remek mell�khat�ssal j�r, hogy sokkal kevesebbet vesz�tesz, ha alkalmasint valami t�kolm�ny is kiker�l az utc�ra.

Ennyi. Ez m�r el�g. Ha Linus t�rv�nye hamis, akkor b�rmilyen rendszer, amely a kernelhez hasonl�an bonyolult, �s amelyen annyi k�z dolgozott, mint a kernelen, egy ponton �ssze kellene, hogy omoljon az előre nem l�tott hib�s interakci�k �s a felfedezetlen m�ly hib�k s�lya alatt. Ha viszont a t�rv�ny igaz, akkor megfelelő magyar�zat lehet a Linux relat�v hib�tlans�g�ra �s a h�napokt�l eg�szen az �vekig �velő folyamatos �zemel�si idej�re.

Tal�n ez nem is kell, hogy meglepet�st okozzon. �vekkel ezelőtt szociol�gusok arra j�ttek r�, hogy egyform�n k�pzett (vagy egyform�n tudatlan) megfigyelőkből �ll� csoportok v�lem�ny�nek k�z�p�rt�ke sokkal megb�zhat�bb előrejelz�st ad, mint a v�letlenszerűen kiv�lasztott megfigyelők v�lem�nyei. A jelens�get Delphoi-effektusnak nevezt�k el. �gy tűnik, hogy Linus Torvalds megmutatta, hogy ez m�g az oper�ci�s rendszerek hibakeres�s�re is �rv�nyes, hogy a Delphoi-effektus elnyomhatja a fejleszt�s bonyolults�g�t, �s m�g egy oper�ci�s rendszer magj�nak komplexit�s�t is megszel�d�theti [CV].

A Linux helyzet�nek egy speci�lis saj�toss�ga, amely egy�rtelműen seg�ti a Delphoi-effektust, az, hogy a projektek munkat�rsai �nk�ntesek. Egy korai olvas�m mutatott r� arra, hogy a munkat�rsak nem v�letlen mint�b�l sz�rmaznak, hanem olyan emberek, akiket �rdekel annyira a szoftver haszn�lata, hogy megtanulj�k hogyan műk�dik, �s megpr�b�ljanak megold�st keresni a felmer�lő probl�m�kra, sőt nyilv�nval�an elfogadhat� jav�t�sokat is l�trehoznak. Aki �tjut ezeken a szűrők�n, annak feltehetően vannak hasznos �tletei, amelyekkel hozz�j�rulhat a munk�hoz.

Linus t�rv�nye �gy is �jrafogalmazhat�, hogy „a hibakeres�s p�rhuzamos�that�”. Noha a hibakeres�s megk�veteli a hibakeresőktől, hogy valamilyen koordin�l� fejlesztővel kommunik�ljanak, nem k�veteli meg a jelentős koordin�ci�t a hibakeresők k�z�tt. Ez�rt nem is esik �ldozat�ul annak a bonyolults�gnak �s ir�ny�t�si k�lts�gnek, amely az �jabb fejlesztők felv�telekor jelentkezik [a z�rt k�d� projektek eset�ben].

A hibakeresők �ltal dupl�n elv�gzett munk�b�l sz�rmaz� elm�leti vesztes�g a gyakorlatban szinte soha nem gond a Linux vil�g�ban. A korai �s gyakori kiad�s ir�nyelv�nek egyik hat�sa, hogy a visszajelz�sekből sz�rmaz� jav�t�sokkal minimaliz�lja az ilyen jellegű duplik�ci�t [JH].

Brooksnak (a The Mythical Man-Month szerzőj�nek) ezzel kapcsolatban m�g egy spont�n megfigyel�se is van: „Egy sz�les k�rben haszn�lt program karbantart�s�nak teljes k�lts�ge �ltal�ban a kifejleszt�s k�lts�geinek 40 sz�zal�ka vagy m�g t�bb. Meglepő m�don ez a k�lts�g erősen f�gg a felhaszn�l�k sz�m�t�l. T�bb felhaszn�l� t�bb hib�t tal�l.”

T�bb felhaszn�l� t�bb hib�t tal�l, mert t�bb felhaszn�l� t�bbf�le m�don veszi ig�nybe a programot. Ezt a hat�st erős�ti, ha a felhaszn�l�k t�rsfejlesztők is. A hibafelismer�st mindegyik�k m�sk�nt k�zel�ti meg, n�mileg k�l�nb�ző m�don �rz�kelve, m�s eszk�z�kkel elemezve, m�s sz�gből. A Delphoi-effektus �gy tűnik, hogy pontosan ezen v�ltozatoss�g miatt műk�dik. A hibakeres�s kontextus�ban a vari�ci� seg�t az azonos t�rekv�sek t�bbsz�ri előfordul�s�nak cs�kkent�s�ben is.

Teh�t t�bb b�tateszterrel nem cs�kken az �ppen legkomolyabbnak tartott hiba m�lys�ge a fejlesztő szem�ben, de megnő annak a val�sz�nűs�ge, hogy lesz olyan szem�ly, akinek a tarsoly�ban benne van a sz�m�ra viszont k�nnyű probl�ma megold�sa.

Linus pedig a legjobbat hozhatja ki a helyzetből: ha val�ban komoly hib�k vannak benne, akkor a kernelt olyan m�don sz�mozz�k, hogy a potenci�lis felhaszn�l�k eld�nthess�k, az utols� stabil v�ltozatn�l maradnak, vagy v�llalj�k a hib�k kock�zat�t is az �j lehetős�gek miatt. Ezt a taktik�t m�g nem minden fejlesztő vette �t, de tal�n �gy a j�, a t�ny, hogy mindk�t v�laszt�s el�rhető, mindkettőt vonz�bb� teszi [HBS].

A sok szem cs�kkenti a komplexit�st

M�s dolog nagy vonalakban megfigyelni, hogy a baz�r m�dszere felgyors�tja a hibakeres�st �s k�d fejlőd�s�t, �s ugyancsak m�s pontosan meg�rteni, hogyan �s mi�rt műk�dik �gy a mindennapi fejlesztői �s tesztelői magatart�s mikroszintj�n. Ebben a fejezetben (amely h�rom �vvel az eredeti sz�veg ut�n �r�dik, �s felhaszn�lja olyan fejlesztők n�zeteit, akik olvast�k az eredetit, �s megfigyelt�k saj�t viselked�s�ket) alaposan megvizsg�ljuk a t�nyleges mechanizmusokat. A nem műszaki �rdeklőd�sű olvas�k nyugodtan �tugorhatnak a k�vetkező fejezetre.

A meg�rt�s egyik kulcsa annak a pontos felismer�se, hogy a forr�sk�dhoz nem jut� felhaszn�l�k hibabejelent�sei �ltal�ban mi�rt bizonyulnak kev�sb� hasznosnak. A forr�sk�dot nem ismerők csak a k�lső t�neteket szokt�k jelenteni, term�szetesnek veszik a saj�t k�rnyezet�ket, �gy (a) l�nyeges h�tt�rinform�ci�kat hagynak ki, �s (b) ritk�n adnak megb�zhat� receptet a hiba reprodukci�j�hoz.

Az alapprobl�ma itt a fejlesztő �s a tesztelő programr�l alkotott ment�lis modellj�nek k�l�nbs�g�ből ad�dik, a tesztelő k�v�lről n�z be, m�g a fejlesztő bel�lről n�z ki. A z�rt k�d� fejleszt�sek sor�n mindketten megragadnak ebben a szerepk�rben, elbesz�lnek egym�s mellett, �s m�lys�gesen frusztr�l�nak tal�lj�k egym�st.

A ny�lt forr�sk�d feloldja ezt a k�t�tts�get, �s sokkal k�nnyebb� teszi a tesztelő �s a fejlesztő sz�m�ra egy k�z�s, a forr�sk�dra �p�tő �br�zol�sm�d kialak�t�s�t, illetve az arr�l val� hat�kony kommunik�ci�t. A gyakorlatban �ri�si a k�l�nbs�g a fejlesztőre gyakorolt hat�s tekintet�ben a csak k�lsőleg l�that� t�netek felsorol�sa, valamint az olyan hibabejelent�s k�z�tt, amely k�zvetlen�l a fejlesztőben, a forr�sk�d alapj�n kialakult ment�lis �br�zol�sm�dhoz kapcsolhat�.

A legt�bb hiba az esetek t�bbs�g�ben k�nnyen megcs�phető egy r�szleges, de a hiba k�r�lm�nyeiről a forr�sk�d szintj�n sokatmond� jellemz�ssel. Ha valaki a b�tatesztelők k�z�l r�mutat arra, hogy egy elhat�rol�si (boundary) probl�ma van az nnn sorban, vagy csak annyit mond, hogy „X, Y �s Z felt�telek eset�n ez a v�ltoz� �tfordul”, egy gyors pillant�s a gyan�s k�dra gyakran elegendő a hiba pontos meg�llap�t�s�hoz, illetve a jav�t�s elk�sz�t�s�hez.

A forr�sk�d hozz�f�rhetős�ge mindk�t oldalr�l nagym�rt�kben seg�ti a kommunik�ci�t, �s kapcsolatot teremt b�tatesztelő jelent�sei, valamint a vezető fejlesztők tud�sa k�z�tt. R�ad�sul ez azt is jelenti, hogy a vezető fejlesztők ideje gyakran m�g sok egy�ttműk�dő eset�n is megmarad.

A fejlesztői időt megőrző ny�lt forr�sk�d� m�dszer m�sik jellemzője az ilyen projektek kommunik�ci�s strukt�r�ja. Az im�nt a vezető fejlesztő kifejez�st haszn�ltam, ez a projekt k�zpontj�t alkot�k (rendszerint el�g kev�s, gyakran csak egy vagy egy-h�rom fejlesztő), illetve a projekt holdudvar�t alkot� munkat�rsak, b�tatesztelők (t�bb sz�zan is lehetnek) megk�l�nb�ztet�s�re utal.

Az alapvető probl�ma, amivel a tradicion�lis szoftverfejlesztő szervezet k�zd, Brooks t�rv�nye: „Egy k�s�sben l�vő projekt bőv�t�se �jabb programoz�kkal tov�bbi k�s�st eredm�nyez”. �ltal�nosabban megfogalmazva Brooks t�rv�nye szerint egy projekt bonyolults�ga �s kommunik�ci�s k�lts�ge a fejlesztők sz�m�val n�gyzetesen emelkedik, m�g az elv�gzett munka mennyis�ge csup�n line�risan nő.

Brooks t�rv�ny�nek alapjait az a tapasztalat adja, amely szerint a hib�k a k�l�nb�ző emberek �ltal �rt az interf�szekn�l hajlamosak �sszegyűlni, valamint az, hogy egy projekt kommunik�ci�s/koordin�ci�s k�lts�ge az embereket elv�laszt� hat�rfel�letek sz�m�val szokott emelkedni. Ilyenform�n a probl�m�k a fejlesztők k�z�tti kommunik�ci�s �tvonalak sz�m�val �llnak ar�nyban, amelyek viszont a fejlesztők sz�m�nak n�gyzet�vel �llnak ar�nyban (pontosabban az N*(N-1)/2 k�plet szerint alakulnak, ahol az N a fejlesztők sz�ma).

Brooks t�rv�ny�nek elemz�se (�s az ebből k�vetkező f�lelem a nagy l�tsz�m� fejlesztőcsoportokt�l) azon a burkolt felt�telez�sen nyugszik, hogy a projekt kommunik�ci�s strukt�r�ja sz�ks�gszerűen teljes gr�f, �s mindenki mindenki m�ssal besz�l. A ny�lt forr�sk�d� projektekben azonban a holdudvarhoz tartoz� fejlesztők gyakorlatilag elk�l�n�thető, p�rhuzamos r�szfeladatokon dolgoznak, alig van k�zt�k interakci�, a k�d v�ltoz�sai �s a hibabejelent�sek a vezető fejlesztők�n kereszt�l folynak, �s csak ebben a kis csoportban kell megfizetni a teljes Brooks-f�le k�lts�get [SU].

Vannak egy�b okai is a forr�sk�d szintű hibabejelent�s hat�konys�g�nak, amelyek ak�r� szerveződnek, hogy egy hib�nak gyakran t�bb lehets�ges t�nete van, �s ezek a felhaszn�l� �ltal gyakorolt kezel�si mint�zat �s a k�rnyezet f�ggv�ny�ben v�ltoznak. Az ilyen hib�k pontosan azok a komplex, k�rm�nfont dolgok (p�ld�ul a dinamikusmem�ria-kezel�si hib�k vagy a nem determinisztikus megszak�t�sablakokkal kapcsolatos leletek), amelyeket neh�z sz�nd�kosan reproduk�lni vagy elemz�ssel kisz�rni, �s amelyek a szoftverek hossz� t�v� probl�m�i�rt legink�bb felelősek.

Az a tesztelő, aki pr�bak�ppen bek�ldi egy hiba forr�sk�d szintű jellemz�s�t (p�ld�ul: „�gy tűnik, mintha lefedetlens�g lenne a szign�lkezel�sben az 1250. sor k�r�l” vagy „Hol null�zz�tok ezt a puffert?”), a fejlesztőt – aki k�zvetlen�l a k�ddal dolgozik, �s e k�zels�g miatt a probl�m�t egy�bk�nt �szre sem venn� – egy f�ltucat k�l�nb�ző t�net ok�ra �bresztheti r�. Ilyen esetekben neh�z vagy egyenesen lehetetlen megtudni, hogy az egyes, k�lsőleg is l�that� rendelleness�geket pontosan melyik hiba okozza, de a gyakori kiad�sok mellett ez nem is sz�ks�ges. Az egy�ttműk�dők feltehetően gyorsan felt�rk�pezik, hogy a hib�jukat kijav�tott�k-e vagy sem. A forr�sk�d szintű hibabejelent�sekkel sokszor a tudatos jav�t�sok n�lk�l is kisz�r�dnak a rendelleness�gek.

A bonyolult, t�bb t�netet okoz� hib�kn�l gyakori, hogy t�bb visszak�vet�si �tvonal vezet a t�nyleges hib�ig. Egy adott fejlesztő vagy tesztelő csak n�h�ny ilyen �ton k�pes elindulni a k�rnyezet�nek finoms�gait�l f�ggően, amely egy�bk�nt idővel j�csk�n v�ltozhat, �s nem is felt�tlen�l sz�ks�gszerű m�don. Gyakorlatilag minden fejlesztő �s tesztelő egy f�lig v�letlen mint�t vesz a program �llapotaib�l a t�netek okainak kutat�sa k�zben. Min�l ravaszabb, bonyolultabb egy hiba, ann�l kisebb az es�lye annak, hogy az adott mint�ba fontos nyom ker�l.

Az egyszerű, k�nnyen reproduk�lhat� hib�kn�l a hangs�ly nem a v�letlenen van, sokat sz�m�t a hibakeres�sben val� j�rtass�g �s k�d fel�p�t�s�nek ismerete. A komplex hib�k est�ben viszont a v�letlen a hangs�lyos. Ilyen felt�telek mellett a sok ember �ltal bej�rt hibakeres�si utak j�val hat�konyabbak, mint a kev�s ember �ltal egym�s ut�n v�gigk�vetett nyomok – m�g akkor is, ha ezen keveseknek sokkal nagyobb a j�rtass�guk.

Ezt a hat�st nagym�rt�kben erős�ti, ha a k�l�nb�ző felsz�ni jelens�gektől a hib�ig vezető nyomk�vet�si �tvonalak, a felsz�ni t�netekből nem k�vetkező m�don, jelentősen v�ltoznak. Egyetlen fejlesztő az ilyen utakb�l vett mint�kat egym�s ut�n bej�rva legal�bb olyan val�sz�nűs�ggel akad r� egy neh�z �tvonalra elsők�nt, mint egy k�nnyűre. Ha viszont felt�telezz�k a gyors kiad�si ciklusokat, �s azt, hogy sok ember v�gzi a nyomk�vet�st, akkor feltehetően az egyik�k azonnal megtal�lja a hib�hoz vezető legr�videbb utat, �s sokkal gyorsabban azonos�tja a hib�t. Amikor a projekt vezetője �rtes�l a dologr�l, �j kiad�st k�sz�t, �s az ugyanezen a hib�n dolgoz� egy�b emberek le�llhatnak a keres�ssel, m�g mielőtt t�l sok időt t�lten�nek el a bonyolultabb �tvonalakon [RJ].

Nem fen�kig tejf�l

Linus magatart�s�t tanulm�nyozva, �s fogalmat alkotva arr�l, mi�rt volt sikeres, �gy d�nt�ttem, hogy tesztelem az elm�letet �j, k�ts�gk�v�l egyszerűbb �s kev�sb� ambici�zus projektemen.

De előtte �jraszerveztem �s egyszerűs�tettem a popclientet. Carl Harris megval�s�t�sa becs�lettel volt meg�rva, de volt benne egyfajta, a C programoz�kra jellemző, sz�ks�gtelen �sszetetts�g. A k�zpontban maga a k�d �llt, m�g az adatszerkezeteket a k�d kieg�sz�tőik�nt kezelte. Ennek az eredm�nye volt, hogy a k�d gy�ny�rű volt ugyan, de az adatszerkezeti elgondol�s bizony csak alkalmi �s cs�ny�cska (legal�bbis egy veter�n Lisp-hacker magas m�rc�je szerint).

Egy m�sik sz�nd�kom is volt az �jra�r�ssal, a k�d �s az adatszerkezet t�k�letes�t�s�n t�l szerettem volna olyasmiv� fejleszteni, amit teljesen meg�rtek. Nem �lvezetes felelőss�get v�llalni egy olyan program hib�inak jav�t�s��rt, aminek nem �rted a műk�d�s�t.

Az első h�napban egyszerűen csak Carl alapvető sz�nd�kait k�vettem. Az első komoly v�ltoztat�s amit v�grehajtottam, az IMAP t�mogat�s hozz�ad�sa volt. �gy oldottam meg, hogy a protokollok�rt felelős r�szt �jraszerveztem, l�trehozva egy �ltal�nos motort �s h�rom elj�r�st�bl�zatot (a POP2, a POP3 �s az IMAP r�sz�re). Ez, �s az előző v�ltoztat�sok azt az �ltal�nos elvet k�vetik, amit a programoz�knak �rdemes szem előtt tartaniuk, k�l�n�sen az olyan erősen t�pusos nyelvekn�l, mint a C:

9. A buta k�d �gyes adatszerkezetekkel jobban műk�dik, mint a ford�tottja.

Brooks, kilencedik fejezet: „Mutasd a folyamat�br�d �s rejtsd el t�bl�zataid, tov�bbra is zavarban leszek. Mutasd meg a t�bl�zatokat, �s nem lesz sz�ks�gem a folyamat�br�ra, minden nyilv�nval�v� v�lik.” Eltekintve a harminc�ves technol�giai �s kultur�lis k�l�nbs�gtől, a l�nyeg ugyanaz.

Akkoriban (1996 szeptember�nek elej�n, a kezd�s ut�n hat h�ttel) azt kezdtem el fontolgatni, hogy hely�nval� lenne a n�vv�ltoztat�s. V�g�l is m�r nem csak egy POP kliensről volt sz�. Az�rt bizonytalankodtam, mert semmi eredeti nem volt a szerkezetben, popclientemnek m�g ki kellett fejlesztenie a saj�t egy�nis�g�t.

Mindez radik�lisan megv�ltozott, amikor a popclient megtanulta, hogy tov�bb�thatja az �th�zott leveleket az SMTP portra. Egy pillanat, �s erre is r�t�rek, de előtte: azt mondtam kor�bban, hogy eld�nt�ttem, felhaszn�lom a projektet Linus Torvalds igaz�r�l alkotott elm�letem tesztel�s�re. Megk�rdezhetn�d, hogyan? �gy:

Kor�n �s gyakran adtam ki (�ltal�ban t�znaponk�nt, intenz�v fejleszt�sek idej�n minden nap).
A b�ta list�hoz hozz�adtam mindenkit, aki a fetchmail �gy�ben kapcsolatba l�pett velem.
Bő l�re eresztett bejelent�seket k�ldtem a b�ta list�ra minden kiad�s alkalm�val, �gy b�tor�tottam a r�szv�telt.
Figyeltem b�tatesztelőimre, tervez�si k�rd�seket tettem fel nekik, h�zelegtem, amikor jav�t�sokat �s visszajelz�seket k�ldtek.

Egyszerű l�p�seimnek azonnali hat�sa volt. A projekt kezdeteitől olyan minős�gű hibajelent�seket kaptam, gyakran haszn�lhat� jav�t�sokkal egy�tt, amilyenek�rt a legt�bb fejlesztő �lni tudna. Kaptam elgondolkodtat� kritik�t, rajong�i levelet, intelligens javaslatokat. Ebből k�vetkezően:

10. Ha b�tatesztelőidet a leg�rt�kesebb erőforr�sodk�nt kezeled, a leg�rt�kesebb erőforr�sodd� v�lva reag�lnak.

A fetchmail siker�nek egy �rdekes m�rc�je a projekt b�tatesztelői list�j�ra, a fetchmail-friendsre feliratkozott tagok sz�ma. Amikor utolj�ra �tn�ztem ezt a sz�veget (2000 november�ben), 287 tag volt, �s heti k�t-h�rom �j taggal bőv�lt.

Egy�bk�nt amikor 1997 m�jus�nak v�g�n n�ztem �t, a lista �rdekes okb�l kezdett el tagokat veszteni a 300 k�r�li maximum�b�l. T�bben is jelezt�k, hogy szeretn�nek leiratkozni, mert a fetchmaillel olyan m�rt�kben el�gedettek, hogy nincs sz�ks�g�k m�r a list�ra. Tal�n ez is r�sze a egy �rett, baz�r st�lus� projekt �letciklus�nak.

A popclientből fetchmail lesz

A projekt val�di fordul�pontja az volt, amikor Harry Hochheiser elk�ldte nekem azt a r�gt�nz�tt k�dot, amely a leveleket a kliens sz�m�t�g�p SMTP portj�ra tov�bb�totta. Majdnem azonnal r��bredtem, hogy ennek a lehetős�gnek a megb�zhat� megval�s�t�sa az �sszes egy�b lev�lk�zbes�t�si �zemm�dot elavultt� teszi.

Heteken �t tr�kk�ztem a fetchmaillel, mik�zben �gy �reztem, hogy az interf�sz fel�p�t�se haszn�lhat�, de f�s�letlen, nem eleg�ns, t�l sok benne a jelent�ktelen opci�. A leszedett levelek postafi�kf�jlba vagy a szabv�nyos kimenetre val� ki�r�sa k�l�n�sen sok bossz�s�got okozott, de nem tudtam, hogy mi�rt.

(Ha nem �rdekel az internetes levelez�s technik�ja, a k�vetkező k�t bekezd�st nyugodtan �tugorhatod.)

Az SMTP-tov�bb�t�sr�l gondolkodva azt l�ttam, hogy a popclient t�l sok dolgot pr�b�l elv�gezni. Egyszerre alkalmas lev�ltov�bb�t�sra (MTA, Mail Transport Agent) �s helyi k�zbes�t�sre (MDA, Mail Delivery Agent). Az SMTP-tov�bb�t�ssal kisz�llhattam volna az MDA-s �gyekből, �s megmaradtam volna tiszt�n MTA-nak, �tadva a leveleket m�s programoknak helyi tov�bb�t�sra, pont �gy, ahogy azt a sendmail is teszi.

Mi�rt maszatoljak a bonyolult k�zbes�t�si be�ll�t�ssal, vagy a postal�da z�rol�s�val �s a hozz�fűz�ssel, ha ak�rmilyen TCP/IP t�mogat�ssal rendelkező platformon csaknem garant�ltan ott v�r m�r a 25-�s port? K�l�n�sen, ha ez azt jelenti, hogy az elhozott levelek biztosan �gy fognak kin�zni, mint egy rendes �zenetk�ldő �ltal elind�tott SMTP �zenet, hiszen ez volt egy�bk�nt is a c�l.

(Vissza magasabb szintre…)

M�g ha nem is k�vetted a műszaki zsargont, fontos tanuls�gok v�rnak itt r�nk. Elsők�nt az, hogy az SMTP-tov�bb�t� koncepci� volt a legnagyobb eredm�nye a Linus �ltal haszn�lt m�dszer k�vet�s�nek. Egy felhaszn�l� iszonyatos �tlettel �llt elő, �s csak annyit kellett tennem, hogy meg�rtem ennek a k�vetkezm�nyeit.

11. A saj�t j� �tletek ut�ni legjobb dolog a felhaszn�l�idt�l sz�rmaz� j� �tletek felismer�se. Időnk�nt ez ut�bbi jobb.

�rdekes m�don hamar r��bredsz: ha teljesen, �nelnyom� m�don őszinte vagy abban, hogy mennyivel tartozol m�soknak, a vil�g �ltal�ban �gy fog kezelni, mintha az �tlet utols� bitje is a ti�d lenne, csup�n szer�nyen nyilatkozt�l a tehets�geddel kapcsolatban. L�thatjuk, hogy ez milyen j�l műk�d�tt Linus eset�ben is.

(Amikor előadtam 1997 augusztus�ban az első Perl Konferenci�n, Larry Wall, a nagyszerű hacker az első sorban �lt. Amint el�rtem a fenti mondathoz, mintha �jj�sz�letett volna, felki�ltott: „M�g ilyet, testv�rem!”. Az eg�sz k�z�ns�g hahot�zott, tudt�k j�l, hogy ugyanez műk�d�tt a Perl atyj�nak eset�ben is.)

A projektet hasonl� szellemben futtatva n�h�ny h�ten bel�l dics�reteket kezdtem kapni nemcsak a felhaszn�l�imt�l, de m�s emberektől is, akikhez eljutott az ige. N�h�ny ilyen e-mailt biztons�gba is helyeztem, �s elő fogom szedni őket, ha valaha is azon kezdek el tűnődni, hogy �rt-e valamit az �letem :-).

De van m�g k�t alapvető tanuls�gunk, amelyek mindenf�le tervre vonatkoztatva �ltal�nosan �rv�nyesek.

12. A legink�bb megd�bbentő �s innovat�v megold�sok gyakran annak a felismer�s�ből sz�rmaznak, hogy hib�s volt a probl�ma felfog�sa.

Rossz probl�m�t pr�b�ltam megoldani a popclient kombin�lt MTA/MDA-k�nt val� fejleszt�s�nek folytat�s�val �s az �sszes tr�kk�s helyi tov�bb�t�si m�ddal. A Fetchmail szerkezet�t az alapokt�l tiszt�n MTA-k�nt kellett �jragondolni, az internetes levelez�s SMTP-t besz�lő vil�g�nak norm�lis r�szek�nt.

Ha falba �tk�z�l a fejleszt�s sor�n, ha �gy �rzed, hogy nem vagy k�pes t�ljutni a k�vetkező jav�t�son, akkor gyakran nem azt a k�rd�st kell feltenned, hogy vajon van-e j� v�laszod, hanem azt, hogy egy�ltal�n j�-e a k�rd�s. Tal�n �j keretbe kell helyezni a probl�m�t.

Nos, �n megtettem. Vil�gos, hogy az első dolog (1) az SMTP-tov�bb�t�s t�mogat�s�nak az �ltal�nos motorba val� val� beilleszt�se volt, majd (2) ennek az alap�rtelmezett m�dd� val� t�tele, �s (3) minden m�s k�zbes�t�si �zemm�d kidob�sa, k�l�n�sen a f�jlba �s szabv�nyos kimenetre val� k�zbes�t�s kidob�sa.

A harmadik l�p�s előtt hezit�ltam egy ideig, att�l f�ltem, hogy a r�gi popclient-felhaszn�l�kat, akik sz�m�tottak az ilyen alternat�v k�zbes�t�si mechanizmusokra, ki fogom bor�tani. Elm�letileg azonnal v�lthattak volna, �s .forward f�jlokat, vagy annak a nem sendmailes megfelelőit l�trehozva, ugyanazt a hat�st �rhett�k volna el. A gyakorlatban azonban az �tmenet r�z�sabb is lehet.

V�g�l amikor l�ptem, hatalmas előny�k sz�rmaztak belőle. A motor k�dj�nak t�lbonyol�tott r�szei eltűntek. A be�ll�t�sok radik�lisan leegyszerűs�dtek, nem volt t�bb nyűglőd�s az MDA-val �s a felhaszn�l�i postafi�kkal, nem kellett amiatt sem agg�dnom, hogy program kez�re dolgoz� oper�ci�s rendszer t�mogatja-e f�jlok z�rol�s�t.

A levelek elveszt�s�nek egyetlen lehetős�ge is eltűnt. Ha ugyanis a k�zbes�t�s f�jlba t�rt�nt, a lemez pedig megtelt, a levelek elvesztek. Ez nem t�rt�nhet meg az SMTP-tov�bb�t�s eset�ben, mert az SMTP-listener nem t�r vissza az OK-val, csak abban az esetben, ha az �zenet k�zbes�thető, vagy legal�bbis beker�lt a k�sőbbi k�zbes�t�sre v�rakoz� sorba.

N�vekedett tov�bb� a teljes�tm�ny (ha nem is t�l jelentősen). A v�ltoztat�s tov�bbi jelentős előnye a k�zik�nyvoldal sokkal egyszerűbb� v�l�sa volt.

K�sőbb azt�n a felhaszn�l� �ltal defini�lt helyi MDA-n kereszt�li k�zbes�t�st vissza kellett hoznom, hogy lehetőv� tegyem bizonyos k�l�n�s, dinamikus SLIP-pel kapcsolatos szitu�ci�k kezel�s�t. De sokkal egyszerűbb megold�st tal�ltam r�.

K�telyek? Ne t�tov�zz, dobd ki a t�lhaladott lehetős�geket, ha meg tudod tenni a hat�konys�g cs�kken�se n�lk�l. Antoine de Saint-Exup�ry (aki pil�ta �s rep�lőg�p-tervező volt, nem pedig klasszikus gyermekk�nyvek szerzője) mondta:

13. A t�k�letess�get (a tervez�sben) nem akkor �rj�k el, amikor m�r nincs mit hozz�adni, hanem amikor m�r nincs mit elvenni.

Ha a k�dod jobb� �s egyszerűbb� is v�lik, tudod, hogy az helyes. A folyamat k�zben a fetchmail fel�p�t�se eredetiv�, a r�gi popclienttől k�l�nb�zőv� v�lt.

El�rkezett a n�vv�ltoztat�s ideje. Az �j fel�p�t�s miatt a fetchmail a r�gi popclientn�l sokkal ink�bb volt a sendmail p�rja. Mindkettő MTA, de m�g a sendmail kik�ld �s k�zbes�t, addig a meg�jult popclient elhoz �s k�zbes�t. K�t h�nappal az indul�s ut�n megt�rt�nt a fechmaill� val� �tnevez�s.

Az SMTP-tov�bb�t�s fetchmailbe ker�l�s�n t�l �ltal�nosabb tanuls�ggal is szolg�l a t�rt�net. Nemcsak a hibakeres�s p�rhuzamos�that�, hanem a fejleszt�s (tal�n eg�szen meglepő m�rt�kig) �s a tervez�si t�r felfedez�se is. Ha a fejleszt�si m�dszered gyorsan ism�tlődő kiad�sokat alkalmaz, a fejleszt�s �s a bőv�t�s a hibakeres�s speci�lis eseteiv�, a szoftver eredeti k�pess�geiben �s koncepci�j�ban maradt „mulaszt�si hib�k” jav�t�saiv� v�lhatnak.

M�g a tervez�s magasabb szintjein is nagyon �rt�kes lehet, ha t�bb t�rsfejlesztő pr�b�lgatja a lehetős�geket. Ahogy a v�z megtal�lja a lefoly�t, vagy m�g enn�l is szeml�letesebben, ahogy a hangy�k r�tal�lnak az �lelemre: sz�tsz�r�d�sb�l ad�d� felfedez�s, amit majd egy rugalmas kommunik�ci�s mechanizmus seg�ts�g�vel haszn�lnak ki. Ez nagyon j�l műk�dik. Ahogy Harry Hochheiserrel �s velem is megt�rt�nt, a k�s�rőid egyike olyan előny�kre bukkanhat, amelyeket a szemellenződ miatt �szre sem veszel.

A fetchmail felnő

Ott voltam egy csinos, meg�jult fel�p�tm�nnyel, olyan k�ddal, amelyről tudtam, hogy j�l műk�dik, mert minden nap haszn�ltam, �s egy beindul� b�ta list�val. Apr�nk�nt kezdtem meg�rezni, hogy t�bb� m�r nem az egyszerű, szem�lyes b�tyk�l�ssel kell t�rődn�m, amely t�rt�netesen hasznosnak bizonyulhat m�sok sz�m�ra is. Olyan program volt a kezemben, amelyre minden SLIP/PPP levelez�si kapcsolattal �s Unixszal rendelkező hackernek sz�ks�ge van.

Az SMTP-tov�bb�t� funkci�val a program elh�zott a vet�lyt�rsak mellett, �s megvolt az es�lye, hogy a kateg�ria legjobbj�v� v�ljon, egy olyan klasszikus programm�, amely kit�lti a sz�m�ra fenntartott helyet, �gy az alternat�v�k nemcsak feleslegess� v�lnak, de szinte el is felejtődnek.

Szerintem az ilyen eredm�nyeket nem lehet igaz�n előre megtervezni. Azok az erőteljes tervez�si �tletek visznek bele, amelyek k�sőbbi eredm�nyei egyszerűen kiker�lhetetlennek, term�szetesnek, sőt eleve elrendeltnek tűnnek. Az ilyen �tleteket csak �gy lehet kipr�b�lni, ha sok �tlet van – vagy tervez�si d�nt�sekkel kell elvinni m�sok j� �tleteit oda, ahov� az �tletgazd�k sem gondolt�k volna, hogy eljuthatnak.

Eredetileg Andy Tanenbaum �tlete volt egy egyszerű, nat�v Unix �p�t�se az IBM PC-kre, amit oktat�si seg�deszk�zk�nt haszn�lhat (Minixnek h�vta). Linus Torvalds tov�bb vitte a Minix-koncepci�t, mint amire Andrew sz�m�thatott, �s valami remek dolog lett belőle. Ugyan�gy (kisebb ar�nyokban persze) �n �tvettem Carl Harris �s Harry Hochheiser �tleteit, �s adtam nekik egy l�k�st. Egyik�nk sem volt eredeti a romantikus �rtelemben. A hackerm�toszokkal szemben a term�szettudom�ny, a m�rn�ki munka �s a szoftverfejleszt�s nagyobb r�sze sem eredeti tehets�gek műve.

Az eredm�ny ugyanakkor m�mor�t�, pontosan az a t�pus� siker, ami minden hacker c�lja. Ez azt jelentette, hogy m�g magasabbra kell helyeznem a l�cet, olyan m�rt�kben kell hasznoss� tennem a fetchmailt, amennyire csak most l�tom, hogy lehets�ges volt. Nem csup�n a saj�t ig�nyeim szerint kell meg�rnom, hanem t�mogatnom kell m�sokat is. Mindezt �gy, hogy a program tov�bbra is egyszerű �s erőteljes marad.

Az első, nyomaszt�an fontos lehetős�g amit ezek ut�n meg�rtam, a multidrop t�mogat�sa volt, annak a megval�s�t�sa, hogy az olyan postal�d�kb�l, amelyekben egy csoport �sszes k�z�s levele gyűlt, a program kiszedje a leveleket �s minden egyes darabot a megfelelő c�mzetthez ir�ny�tson.

A multidrop hozz�ad�s�t r�szben az�rt hat�roztam el, mert n�h�ny felhaszn�l� m�r k�vetelte, de fők�nt az�rt, mert �gy gondoltam, hogy ez ki fogja hozni a hib�kat az egyszerű k�zbes�t�s�rt felelős (single-drop) k�db�l azzal, hogy r�k�nyszer�t a c�mz�s �ltal�nos kezel�s�re. Ez be is bizonyosodott. Az RFC 822 �ltal le�rt c�melemz�s l�trehoz�sa k�l�n�sen sok időmbe ker�lt, nem az�rt, mert b�rmelyik r�sze neh�z volt, hanem mert egy halomnyi f�ggetlen �s vesződs�ges r�szletet is beker�lt a k�pbe.

De a mutidrop c�mz�s ism�t csak nagyszerű tervez�si d�nt�snek bizonyult. Ezt abb�l tudtam, hogy:

14. Ak�rmilyen eszk�znek az elv�rt m�don kell hasznosnak lennie, de az igaz�n j� eszk�z ott is felhaszn�lhat�, ahol soha nem sz�m�tott�l volna r�.

A multidropos fetchmail v�ratlan felhaszn�l�sa olyan levelez�si list�k �zemeltet�s�ben jelentkezett, ahol a lista �s az �ln�v-felold�s (alias expansion) az internetkapcsolat kliensoldal�n t�rt�nik. Ez azt jelenti, hogy egy internetszolg�ltat�n�l fi�kkal rendelkező g�p k�pes egy levelez�si lista kezel�s�re a szolg�ltat�n�l l�vő alias f�jlokhoz val� folyamatos hozz�f�r�s n�lk�l.

A b�tatesztelőim �ltal ig�nyelt m�sik v�ltoztat�s a 8 bites MIME (Multipurpose Internet Mail Extensions) műk�d�s volt. Ezt rendk�v�l k�nnyű volt teljes�teni, mert elővigy�zatosan �gy k�doltam, hogy az nem volt �rz�keny a nyolcadik bitre (ez azt jelenti, hogy nem haszn�ltam a nyolcadik bitet, amely az ASCII karakterk�szletben egy�bk�nt is �res, a programon bel�li inform�ci��tvitelre). Nem az�rt, mert előre l�ttam ezt az ig�nyt, hanem mert a k�vetkező szab�lynak engedelmeskedtem:

15. B�rmilyen inform�ci�k�zvet�tő szoftver �r�sa eset�n t�rekedj arra, hogy a lehető legkisebb m�rt�kben avatkozz csak be az adat�raml�sba, �s soha ne dobj el semmilyen inform�ci�t, hacsak a fogad� f�l nem k�nyszer�t erre.

Ha nem tartottam volna be ezt a szab�lyt, a 8 bites MIME-t�mogat�s bonyolult lett volna �s hib�s. Nekem azonban csak a MIME szabv�nyt (RFC 1652) kellett elolvasnom, �s egy kis fejl�cgener�l� tud�ssal ell�tnom a programot.

N�h�ny eur�pai felhaszn�l� addig nyaggatott, hogy bőv�tsem a programot egy olyan opci�val, amellyel szab�lyozhat� az egy menetben let�lthető �zenetek sz�ma (�gy k�zben tarthatj�k a dr�ga telefonos h�l�zati k�lts�geiket), am�g meg nem tettem. Sok�ig ellen�lltam, �s m�g most sem igaz�n tetszik. De ha egy vil�g sz�m�ra programozol, hallgatnod kell a fogyaszt�idra, ez nem v�ltozik meg att�l, hogy nem p�nzben fizetnek neked.

Tov�bbi fetchmail-tapasztalatok

Mielőtt visszat�rn�nk az �ltal�nos szoftvertervez�si k�rd�sekhez, van n�h�ny m�rlegelendő fetchmail-es tapasztalat. A nem műszaki �rdeklőd�sű olvas�k b�tran tov�bbl�phetnek.

A program műk�d�s�t szab�lyoz� rc f�jl szintaxisa olyan opcion�lis, „zajk�nt” jelenl�vő szavakat is mag�ban foglal, amelyekkel az elemző egy�ltal�n nem t�rődik. Ezek az angol nyelvhez hasonl� szintaxist tesznek lehetőv�, �gy a hagyom�nyos, t�m�r kulcssz�-�rt�k p�rokn�l, amelyeket akkor kapunk, ha kiszűrj�k ezt a zajt, jelentősen k�nnyebben olvashat�.

Az eg�sz egy k�ső �jszakai k�s�rletk�nt kezdőd�tt, �szrevettem, hogy mennyire kezdenek hasonl�tani az rc f�jl deklar�ci�i egy imperat�v mininyelvre. (Ez�rt v�ltoztattam meg a popclient „server” kulcsszav�t „poll”-ra.)

�gy tűnt sz�momra, hogy ezt az imperat�v mininyelvet tal�n k�nnyebb lesz haszn�lni, ha az angolhoz hasonl�v� teszem. B�r �n az olyan p�ld�kat felvonultat� „csin�lj belőle nyelvet” tervez�si iskola meggyőződ�ses partiz�nja vagyok, mint az Emacs, a HTML �s sz�mos adatb�zismotor, rendszerint m�gsem lelkesedem az angolhoz hasonl� szintaxis�rt.

A programoz�k hagyom�nyosan a prec�z, kompakt �s egy�ltal�n nem redund�ns vez�rlő szintaxist szokt�k kedveli. Ez m�g azokb�l az időkből sz�rmaz� kultur�lis �r�ks�g, amikor a sz�m�t�si erőforr�sok dr�g�k voltak, �gy az elemz�ssel elt�lt�tt l�p�seknek min�l olcs�bbaknak �s egyszerűbbeknek kellett lenni�k. Az angol az 50% sz�zal�k k�r�li redundanci�j�val akkor rendk�v�l rossz modellnek l�tszott.

Nem is ez az oka, hogy �ltal�ban ker�l�m az angolra hasonl�t� szintaxisokat, ezt az �rvet csak az�rt eml�tettem, hogy egyben le is romboljam. Az olcs� ciklusok idej�ben nem a t�m�rs�gre kellene t�rekedni. Manaps�g sokkal fontosabb egy nyelv k�nyelmess�ge az emberek sz�m�ra a g�p erőforr�saival val� takar�koskod�sn�l.

De marad m�g okunk az �vatoss�gra. Az egyik az elemz�si l�pcsőfok �sszetetts�g�nek k�lts�ge, ezt nem akarhatod od�ig emelni, ahol m�r �nmag�ban is a hib�k �s felhaszn�l�k zavarodotts�g�nak jelentős forr�s�v� v�lik. Egy m�sik ok, hogy egy nyelv szintaxis�t az angol�hoz hasonl�v� tenni azzal j�r, hogy a nyelv �ltal l�trehozott „angol” ugyancsak kitekert lesz, �gy a term�szetes nyelvhez val� felsz�ni hasonl�s�g legal�bb olyan zavar� lesz, mint amilyen a hagyom�nyos szintaxis lett volna. (Ezzel a beteges jelens�ggel tal�lkozhatunk t�bb �gynevezett „negyedik gener�ci�s” kereskedelmi adatb�zis-lek�rdező nyelvben.)

A fetchmail vez�rlő szintaxisa �gy tűnik, hogy elker�lte ezeket a probl�m�kat, mert a nyelvi tartom�nya rendk�v�l korl�tozott. A nyom�ba sem �r egy �ltal�nos c�l� nyelvnek, a rajta kifejezett dolgok nem t�l komplik�ltak, �gy kev�s az es�lye annak, hogy �sszet�vesztj�k az angol egy picike r�szhalmaz�t mag�val a vez�rlőnyelvvel. Szerintem ebből a k�vetkező tanuls�got szűrhetj�k le:

16. Ha a nyelved k�zel sem Turing-teljes, akkor a szintaxissal kifejezőbb� teheted.

Van itt m�g egy tanuls�g a bizonytalans�ggal el�rt biztons�gr�l. N�h�ny fetchmail-felhaszn�l� k�rte, hogy olyan m�dos�t�sokat v�gezzek, amelyek lehetőv� teszik a jelszavak titkos�tott t�rol�s�t is az rc f�jlban, �gy az ut�nuk szagl�sz�k v�letlen�l sem l�thatj�k meg azokat.

Nem teljes�tettem a k�r�st, mert ez nem jelentene t�nyleges v�delmet. B�rki, aki megszerezte a jogosults�gokat ahhoz, hogy beleolvasson az rc f�jlba, k�pes arra is, hogy annak tulajdonos�hoz hasonl�an futtassa a fetchmailt. Ha pedig a jelsz� kell nekik, akkor k�pesek kiszedni az ehhez sz�ks�ges dek�dert a fetchmail forr�sk�dj�b�l.

A .fetchmailrc-ben l�vő jelszavak titkos�t�sa a biztons�g hamis �rzet�t kelten� bizonyos emberekben. Az �ltal�nos szab�ly teh�t:

17. Egy biztons�gi rendszer csak annyira biztons�gos, amennyire a titkai azok. �vakodj az �ltitkokt�l.

A baz�r sz�ks�ges előfelt�telei

Az essz� korai b�r�l�i �s tesztk�z�ns�ge folyamatosan k�rd�seket tett fel a sikeres baz�r st�lus� fejleszt�s előfelt�teleiről, tov�bb� a projektvezető k�pzetts�g�ről, valamint a k�d �llapot�r�l a nyilv�noss�gra hozatalkor, illetve a t�rsfejlesztői k�z�ss�g ki�p�t�s�nek kezdeteiről.

Az eg�szen vil�gos, hogy senki nem kezdhet neki a baz�r st�lus� k�dol�snak az alapokn�l [IN]. Tesztelni, hib�t keresni �s tov�bbfejleszteni lehet �gy, de igen neh�z egy projektet l�trehozni a baz�r m�dszer�vel. Linus sem pr�b�lta. �n sem. A kialakul�ban l�vő fejlesztői k�z�ss�gednek sz�ks�ge van valami futtathat�, tesztelhető j�t�kszerre.

Amikor k�z�ss�g�p�t�sbe kezdesz, fel kell tudnod mutatni egy tetszetős �g�retet. Nem kell a programodnak k�l�n�sebben j�l műk�dnie, lehet durva, hib�s, befejezetlen �s gyeng�n dokument�lt. De (a) futnia kell, �s (b) meg kell győznie a lehets�ges t�rsfejlesztőket arr�l, hogy valami igaz�n klassz dologg� fejlődhet bel�that� időn bel�l.

A Linux �s a fetchmail is erős, megnyerő alapszerkezettel ker�lt a nyilv�noss�g el�. Sokan azok k�z�l, akik �gy gondolkodnak a baz�r modellről, ahogy azt bemutattam, helyesen tekintik ezt l�nyegesnek, �s ebből arra k�vetkeztet�sre jutnak, hogy j� tervez�si elő�rzetek �s az intelligencia a projektvezető n�lk�l�zhetetlen tulajdons�gai.

De Linus az alapokat a Unixb�l vette, �n pedig a popclientből (b�r ez k�sőbb jelentősen megv�ltozott, sokkal nagyobb ar�nyban, mint amiről a Linux eset�n besz�lhetn�nk). Teh�t a baz�r st�lben val� fejleszt�s vezetőj�nek vagy koordin�tor�nak val�ban kiv�teles tervez�si tehets�ggel kell rendelkeznie, vagy elegendő felkarolnia m�sok tehets�g�t?

Szerintem az nem fontos, hogy a koordin�tor k�pes legyen kiv�telesen brili�ns tervek l�trehoz�s�ra, az viszont abszol�te fontos, hogy a koordin�tor k�pes legyen m�s j� tervez�si �tleteinek a felismer�s�re.

Ezt bizony�tja a Linux �s a fetchmail projekt is. Linus, ahogy ezt kor�bban m�r t�rgyaltam, nem egy l�tv�nyosan eredeti tervező, de rendk�v�l j�rtas a j� tervez�si �tletek felismer�s�ben, �s azok Linux kernelbe integr�l�s�ban. Azt is bemutattam, hogy a fetchmail legjobb �tlete (az SMTP-tov�bb�t�s) valaki m�st�l sz�rmazik.

Az essz� korai k�z�ns�ge azzal j�rt a kedvemben, hogy azt sugallta, szer�nyen al�becs�l�m a baz�r projektekben a tervez�s eredetis�g�t, mert ebből bennem sok van, �s ez�rt term�szetesnek veszem. Lehet, hogy ebben van n�mi igazuk, a tervez�s, a k�dol�ssal �s a hibakeres�ssel ellent�tben, a legerősebb oldalam.

A szoftvertervez�sben okosnak �s eredetinek lenni az�rt probl�m�s, mert szok�ss� v�lik, �nk�ntelen�l is agyaf�rt �s �sszetett dolgokat kezdesz k�sz�teni, akkor is, amikor egyszerűnek �s szil�rdnak kellene lenni�k. Voltak olyan projektjeim, amelyek lefulladtak, mert elk�vettem ezt a hib�t, a fetchmaillel azonban el tudtam ker�lni.

�gy gondolom, hogy a fetchmail projekt sikere r�szben azon is m�lt, hogy visszafogtam magam; ez egy �rv a baz�r projektekben n�lk�l�zhetetlen tervez�si eredetis�g ellen. Vagy gondoljunk csak a Linuxra. Tegy�k fel, hogy Linus Torvalds az oper�ci�s rendszerek tervez�s�nek alapvető �j�t�sait pr�b�lgatta volna fejleszt�s k�zben. Van annak egy�ltal�n val�sz�nűs�ge, hogy az eredm�ny�l kapott kernel olyan megb�zhat� �s sikeres lett volna, mint amilyen most?

A tervez�sben �s k�dol�sban val� j�rtass�g egy bizonyos szintje persze elengedhetetlen, de �gy gondolom, hogy j�form�n ak�rki, aki komolyan gondolkodik egy baz�r projekt elind�t�s�n, m�r t�ll�pett ezen a szinten. A ny�lt forr�sk�d� k�z�ss�g belső tekint�lyviszonyai finom nyom�st gyakorolnak azokra az emberekre, akik nem k�pesek fejleszt�si t�rekv�seik megval�s�t�s�ra, �s ez eddig eg�szen j�l műk�d�tt.

Van egy m�sik tulajdons�g is, amit viszont �ltal�ban nem kapcsolnak �ssze a szoftverfejleszt�ssel, pedig szerintem legal�bb olyan fontos a baz�r projektek eset�ben, mint a tervez�si intelligencia, sőt tal�n fontosabb is ann�l. A projektvezetőnek vagy koordin�tornak j�l kell tudnia kezelni az embereket, �s j� kommunik�ci�s k�szs�ggel kell b�rnia.

Ennek nyilv�nval�nak kellene lennie. Ahhoz, hogy egy fejlesztői k�z�ss�get �p�ts, fel kell keltened az emberek figyelm�t, �rdekess� kell tenned sz�mukra a munk�d, �s el�gedetts�gben kell őket tartanod, hogy az �ltaluk v�gzett munka megfelelő. A műszaki �rdekess�gek sokat seg�tenek ennek el�r�s�ben, de ez messze nem elegendő. Az �ltalad kivet�tett szem�lyis�g is fontos.

Nem v�letlen, hogy Linus remek fick�, akit szeretnek, �s akinek seg�teni akarnak az emberek. Az sem v�letlen, hogy er�lyes, kifel� fordul� ember vagyok, aki �lvezi a t�rsas munk�t, van humor�rz�ke, �s elő tudja mag�t adni. A baz�r modell műk�d�s�t seg�ti, ha legal�bb egy kis j�rtass�god van az emberek elbűv�l�s�ben.

A ny�lt forr�sk�d� szoftver szoci�lis kontextusa

J�l �rtam, a legjobb k�dok a szerző mindennapi probl�m�inak szem�lyes megold�saik�nt indulnak, �s elterjednek, mert a probl�m�r�l kider�l, hogy egy nagyobb felhaszn�l�i csoport sz�m�ra sem ismeretlen. Ez az első sz�m� szab�lyunkhoz vezet vissza, tal�n egy kiss� gyakorlatiasabban �jrafogalmazva:

18. Egy �rdekes probl�ma megold�s�hoz tal�lj elősz�r egy olyan probl�m�t, amely sz�modra �rdekes.

�gy volt ez Carl Harris �s a r�gi popclient eset�ben, illetve velem �s fetchmaillel is. De ezt m�r r�g�ta tudjuk. Az �rdekes dolog, az, amire a Linux �s a fetchmail t�rt�nete is megk�v�nja, hogy figyelj�nk, a k�vetkező l�pcsőfok: a szoftver fejlőd�se egy nagy �s akt�v felhaszn�l�i, illetve t�rsfejlesztői k�z�ss�g jelenl�t�ben.

A The Mythical Man-Month-ban Fred Brooks azt a megfigyel�st tette, hogy a programoz�k ideje nem v�lthat� ki, egy elcs�szott szoftverprojektbe �jabb fejlesztők bevon�sa tov�bbi cs�sz�st eredm�nyez. Ahogy l�ttuk kor�bban, ő amellett �rvelt, hogy egy projekt �sszetetts�ge �s kommunik�ci�s k�lts�ge a fejlesztők sz�m�val n�gyzetesen emelkedik, m�g az elv�gzett munka csup�n line�risan n�vekszik. Brooks t�rv�ny�re �ltal�ban elcs�pelt igazs�gk�nt gondolnak. De ezen essz�ben megvizsg�ltunk sz�mos olyan ny�lt forr�sk�d� fejleszt�si elj�r�st, amely r�c�fol ezekre a felt�telez�sekre, �s a gyakorlatban, ha Brooks t�rv�nye teljesen lefedn� a val�s�got, a Linux nem l�tezhetne.

Gerald Weinberg klasszikus műve, a The Psychology of Computer Programming tartalmazta azt, amit ut�lagosan Brooks alapvető kiigaz�t�sak�nt �rt�kelhet�nk. Az „�nn�lk�li programoz�s” t�rgyal�sa sor�n Weinberg megfigyelte, hogy azokban a műhelyekben, ahol a fejlesztők nem gyakorolnak hatalmat a k�djuk felett, �s az azon v�gzett hibakeres�sre, tov�bbfejleszt�sre b�tor�tanak m�sokat, a fejlőd�s l�nyegesen gyorsabb, mint m�shol. (�jabban Kent Beck „extr�m programoz�si” technik�j�t – amikor a k�dol�k p�rokban figyelik egym�st – foghatjuk fel �gy, mint egy k�s�rletet ezen hat�s kik�nyszer�t�s�re.)

A Weinberg �ltal haszn�lt terminol�gia tal�n megg�tolta elemz�s�nek olyan m�rt�kű elterjed�s�t, amilyet meg�rdemelt volna – megmosolyogtat� az internetes hackerek „�nn�lk�li”-nek nevez�se –, �gy gondolom, hogy az �rvei ma vonz�bbak, mint eddig b�rmikor.

A baz�r m�dszer az „�nn�lk�li programoz�s” teljes erej�t felhaszn�lva erősen csillap�tja Brooks t�rv�ny�nek hat�sait. Brooks t�rv�ny�nek alapelvei j�k, de nagy fejlesztők�z�ss�g �s olcs� kommunik�ci� mellett a hat�sait elnyomj�k az egy�bk�nt l�thatatlan, versengő nemlinearit�sok. Ez a newtoni �s az einsteini fizika viszony�ra eml�keztet, a r�gebbi rendszer m�g �rv�nyes alacsony energi�k mellett, de el�g nagy t�meg �s a sebess�g eset�n olyan meglepet�sek �rhetnek, mint a nukle�ris robban�s vagy a Linux.

A Unix t�rt�net�nek fel kellett volna k�sz�tenie minket arra, amit a Linuxt�l tanulunk (�s amit k�s�rletileg ellenőriztem kisebb m�retekben Linus m�dszereinek tudatos m�sol�s�val [EGCS]). Vagyis m�g a k�dol�s alapvetően mag�nyos tev�kenys�g marad, az igaz�n j� megold�sok teljes k�z�ss�gek intelligenci�j�t �s figyelm�t ig�nylik. Az a fejlesztő, aki csak a saj�t elm�j�t haszn�lja egy elz�rt projektben, elmarad am�g�tt, aki tudja, hogyan hozzon l�tre ny�lt evol�ci�s k�rnyezetet, amelyben a tervez�si lehetős�gekre vonatkoz� visszajelz�sek, a hozz�j�rul�s a k�dhoz, a hib�k kisz�r�sa �s az egy�b fejleszt�s t�bb sz�z (esetleg t�bb ezer) ember seg�ts�g�vel t�rt�nik.

De a hagyom�nyos unixos vil�got sz�mos t�nyező akad�lyozta ennek a megk�zel�t�snek a felkarol�s�ban. Az egyik a k�l�nf�le licencek, �zleti titkok �s kereskedelmi �rdekek szor�t�sa volt, a m�sik pedig az (�gy ut�lag), hogy az internet m�g nem volt el�g j�.

Az olcs� internet előtt voltak f�ldrajzilag behat�rolt k�z�ss�gek, amelyek kult�r�ja seg�tette Weinberg „�nn�lk�li” programoz�s�t, �s egy fejlesztő k�nnyen tal�lhatott k�pzett seg�ts�get �s t�rsfejlesztőket. A Bell Labs, az MIT AI �s LCS laborjai, az UC Berkeley – ezek a helyek legend�s, m�ig hat� �j�t�sok otthonaiv� v�ltak.

A Linux volt az első projekt, amely sz�m�ra egy �ntudatos �s sikeres t�rekv�s a vil�gb�l b�rhonnan sz�rmaz� tehets�get el�rhetőv� tette. Nem hiszem, hogy az v�letlen, hogy a Linux korai fejlőd�s�nek időszaka egybeesett a World Wide Web sz�let�s�vel, �s hogy a Linux t�ll�pett a gyermekkor�n ugyanezen időszakban, 1993-94-ben, amikor beindult az internetszolg�ltat�si ipar, �s robbant az internet ir�nti �rdeklőd�s. Linus volt az első, aki megtanulta, hogyan kell az �ltal�noss� v�l� internetel�r�ssel egy�tt �rkező �j szab�lyok szerint j�tszani.

Noha az olcs� internet a Linux modellben sz�ks�ges felt�tel volt a fejlőd�shez, szerintem �nmag�ban nem volt elegendő felt�tel. Fontos t�nyező volt egy bizonyos vezet�si st�lus, illetve azon egy�ttműk�d�si szok�sok kifejlőd�se, amelyek �ltal a fejlesztők megragadhatt�k a t�rsfejlesztőket, �s a legt�bbet hozhatt�k ki az internetes k�zegből.

De mi ez a vezet�si st�lus, milyenek ezek a szok�sok? Nem lehet őket hatalmi viszonyokra �p�teni – m�g ha lehetne is, a vezetők k�nyszerrel nem �rhetn�k el az �ltalunk l�tott eredm�nyt. Weinberg a t�m�val kapcsolatban id�zi Pjotr Alekszejevics Kropotkin, 19. sz�zadi orosz anarchista �n�letrajz�t, az Egy forradalm�r feljegyz�seit:

Jobb�gytart� csal�dban nevelkedve l�ptem a tev�keny �letbe, �s mint minden fiatalember az �n időmben, erősen b�ztam az ir�ny�t�s, az utas�t�s, a szid�s, b�ntet�s �s ehhez hasonl�k sz�ks�gess�g�ben. De amikor, egy korai szakaszban, fontos v�llalkoz�sokat kellett igazgatnom, �s [szabad] emberekkel b�nnom, amikor minden egyes hiba azonnali komoly k�vetkezm�nyekkel j�rt volna, elkezdtem becs�lni a parancselven, fegyelem alapj�n v�grehajtott tettek, illetve az �ltal�nos meg�llapod�s elv�n v�grehajtott tettek k�zti k�l�nbs�get. Az első nagyszerűen műk�dik egy katonai bemutat�n, de semmit nem �r ott, ahol val�di �letről van sz�, �s a c�l csak sok egyező akarat komoly t�rekv�s�vel �rhető el.

A „sok egyező akarat komoly t�rekv�s�vel” pontosan az, amire a Linuxhoz hasonl� projekteknek sz�ks�ge van, m�g a „parancselvet” gyakorlatilag lehetetlen alkalmazni az internetnek h�vott anarchista paradicsom �nk�ntesein�l. A hat�kony műk�d�s �s verseny �rdek�ben azoknak a hackereknek, akik egy�ttműk�dő projektet szeretn�nek vezetni, meg kell tanulniuk, hogyan toborozzanak �s mozgassanak meg hat�kony, �rdeklődő k�z�ss�get Kropotkin „meg�llapod�selve” alapj�n. Meg kell tanulniuk haszn�lni Linus t�rv�ny�t [SP].

Kor�bban eml�tettem a Delphoi-effektust, mint lehets�ges magyar�zatot Linus t�rv�ny�re. De enn�l jobb anal�gi�k k�n�lkoznak az adapt�v rendszerekkel a biol�gi�ban �s a k�zgazdas�gtanban. A linuxos vil�g sok tekintetben a szabadpiachoz hasonl�an műk�dik, vagy �lől�nyek �s k�rnyezet�k, a hasznuk maximaliz�l�s�ra t�rekvő �nző �gensek csoportj�hoz hasonl�an, amelyek a folyamatba egy spont�n, a k�zponti tervez�ssel el�rhetőn�l kimunk�ltabb �s hat�konyabb �njav�t� rendet visznek. Egy ilyen helyen kereshetj�k a „meg�llapod�s elv�t”.

A Linux-hackerek �ltal v�gsőkig fokozott, nem klasszikus gazdas�gi �rtelemben vett „hasznos műk�d�s” ink�bb �nmaguk kiel�g�t�s�t �s a hackert�rsak k�z�tti megbecs�l�st c�lozza. (Ezt a motiv�ci�t �nzetlennek is nevezhetn�nk, de akkor nem venn�nk tudom�st arr�l a t�nyről, hogy az �nzetlens�g �nmag�ban is az �n kiel�g�t�s�nek egy form�ja.) Az ilyen m�don műk�dő �nk�ntes kult�r�k nem ritk�k, egy m�sik – amelynek magam is r�szese vagyok – a science-fiction rajong�k t�bora, ebben a hackerek�től elt�rően m�r r�g�ta vil�gosan kirajzol�dott az „egoboo” (az �n n�vel�se, �nmagunk h�rnev�nek fokoz�sa ez egy�b rajong�k k�z�tt), mint az �nk�ntes tev�kenys�gek alapvető mozgat�rug�ja.

Linus azzal, hogy sikeresen pozicion�lta mag�t egy olyan projekt őrzőjek�nt, amelyben a fejleszt�st j�r�szt m�sok v�gezt�k, �s fenntartotta a projekt ir�nti �rdeklőd�st, am�g az �nfenntart�v� nem v�lt, j�l megragadta Kropotkin „megosztott meg�rt�s elv�t”. A linuxos vil�g e f�lig gazdas�gi szeml�lete lehetőv� teszi, hogy l�ssuk, hogyan alkalmazhat� ez a meg�rt�s.

Linus m�dszer�re tekinthet�nk �gy, mint egy hat�kony „egoboo”-piacot l�trehoz� m�dszerre, amely a lehető legfinomabban kapcsolja �ssze a hackerek egy�ni �nz�s�t olyan bonyolult c�lok�rt, amelyek csak a kooper�ci� fenntart�s�val �rhetőek el. A fetchmail projekttel megmutattam (b�r csak kicsiben), hogy ezek az elj�r�sok j� eredm�nnyel m�solhat�ak. Tal�n n�mileg m�g n�la is �ntudatosabban �s rendszeresen csin�ltam.

Sokan (k�l�n�sen akik nem b�znak a szabadpiacokban) arra sz�m�tan�nak, hogy az �nmagukat ir�ny�t� egoist�k kult�r�ja t�redezett, fels�gter�letekre osztott, pazarl�, titkol�z� �s ellens�ges lesz. Erre a v�rakoz�sra azonban, hogy csak egyetlen p�ld�t eml�tsek, r�c�fol a linuxos dokument�ci�k minős�ge, meglepő soksz�nűs�ge �s m�lys�ge. Megbocs�that� t�ny, hogy a programoz�k gyűl�lik a dokument�l�st, hogyan fordulhat akkor elő, hogy a linuxos hackerek ennyi dokument�ci�t �ll�tanak elő? A Linux t�rekvő �nekből �ll� szabadpiaca nyilv�nval�an k�nnyebben hoz l�tre �rt�kes, m�sok �ltal k�v�natosnak tartott viselked�st, mint a kereskedelmi szoftvergy�rt�k j�l megalapozott dokument�ci�s műhelyei.

A fetchmail �s a Linux kernel projekt is azt mutatja, hogy m�s hackerek eg�j�nak megfelelő elismer�s�vel egy erős fejlesztő/koordin�tor kihaszn�lhatja a t�rsfejlesztők előnyeit az interneten kereszt�l an�lk�l, hogy a projekt kaotikus �sszevisszas�gba esne. Ez�rt a k�vetkezőt javaslom Brooks t�rv�ny�vel szemben:

19. T�bb ember k�ts�gtelen�l jobb egyn�l, ha a fejleszt�s koordin�tor�nak legal�bb olyan j� kommunik�ci�s k�zeg �ll a rendelkez�s�re mint az internet, �s k�pes a k�nyszer n�lk�li vezet�sre.

A ny�lt forr�sk�d� szoftverek j�vője szerintem egyre ink�bb azokon az embereken m�lik, akik tudj�k, hogyan j�tssz�k Linus j�t�k�t, azokon, akik a baz�r�rt otthagyj�k a katedr�list. Ez nem azt jelenti, hogy az egyedi �rt�kek t�bb� nem fognak sz�m�tani. Sokkal ink�bb jelenti azt, hogy a vezető ny�lt forr�sk�d� szoftverek m�g�tt olyan emberek �llnak majd, akik az egyedi l�t�sm�djukat, �rt�keiket �nk�ntes k�z�ss�gek l�trehoz�s�val erős�tik.

Tal�n ez nem csak a ny�lt forr�sk�d� szoftverek j�vője. A z�rt k�d� vil�gban nem k�pesek egy probl�m�ra annyi tehets�get �ldozni, amennyit a Linux-k�z�ss�g tud ugyanarra ford�tani. Rendk�v�l kevesen engedhetik meg maguknak m�r azt a 200-n�l (1999-ben 600, 2000-ben 800) t�bb embert is, akik a fetchmail fejleszt�s�ben k�zreműk�dtek.

V�g�l tal�n a ny�lt forr�sk�d� kult�ra győzedelmeskedik, nem az�rt, mert a kooper�ci� mor�lisan helyes, m�g a szoftver műk�d�s�nek elrejt�se el�t�lendő, hanem egyszerűen az�rt, mert a z�rt k�d� szoftverek k�ptelenek győzni egy evol�ci�s fegyverkez�si versenyben a probl�m�kra nagys�grendekkel t�bb szak�rtői időt �ldozni k�pes ny�lt k�d� k�z�ss�gek ellen�ben.

A vezet�sről �s a Maginot-vonalr�l

A katedr�lis �s a baz�r 1997-es eredeti sz�vegv�ltozata az előbbi v�zi�val v�gződ�tt – a programoz�k/anarchist�k h�l�zatra kapcsolt el�gedett seregei a versenyben legyőzik �s elnyomj�k a konvencion�lis, z�rt szoftverek hierarchikus vil�g�t.

Ugyanakkor ez rengeteg szkeptikust nem győz�tt meg, �s az �ltaluk felvetett k�rd�sekkel �rdemes foglalkozni. A baz�r melletti �rvek ellen�rveinek legt�bbje szerint al�becs�lj�k a konvencion�lis vezet�s termel�kenys�get t�bbsz�r�ző hat�s�t.

A hagyom�nyos be�ll�totts�g� szoftverfejleszt�si vezetők gyakran hangs�lyozz�k, hogy azt a lazas�g, amellyel a ny�lt forr�sk�d� vil�gban a projekteket alkot� csoportok szerveződnek, v�ltoznak �s felbomlanak, jelentősen ellens�lyozza a l�tsz�lagos sz�mbeli előnyt, amellyel a ny�lt forr�sk�d� k�z�ss�g rendelkezik a z�rt k�d� szoftvereket fejlesztőkkel szemben. Azt is megjegyezhetik, hogy a szoftverfejleszt�s ter�let�n val�ban �lland� a t�rekv�s a fogyaszt�k �ltal elv�rt időtartam� �s m�rt�kű folyamatos befektet�sre a fontos term�kek eset�ben, �s nem csup�n arr�l van sz�l, hogy h�ny ember dobott be valamit a k�z�s faz�kba, �s hagyta megfőni.

K�ts�gk�v�l van ebben az �rvel�sben valami. Arra jutottam a The Magic Cauldron c�mű essz�mben, hogy az elv�rhat� j�vőbeli szolg�ltat�sok kulcsfontoss�g�ak a szoftvertermel�s gazdas�gi rendszer�ben.

Ugyanakkor az �rvel�s fontos rejtett probl�m�t tartalmaz, azt az implicit felt�telez�st, hogy a ny�lt forr�sk�d� fejleszt�si modell nem k�pes ilyen t�rekv�sek fenntart�s�ra. Val�j�ban azonban l�teznek ny�lt forr�sk�d� projektek, amelyek k�vetkezetes ir�nyban haladnak, �s hossz� időn �t fenntartj�k hat�kony karbantart� k�z�ss�g�ket a konvencion�lis vezet�s �ltal n�lk�l�zhetetlennek tartott �szt�nző strukt�r�k �s szervezeti kontroll n�lk�l is. A GNU Emacs szerkesztőprogram fejleszt�se sz�lsős�ges �s tanuls�gos p�ld�ja ennek, az Emacs t�bb sz�z k�zreműk�dő 15 �ven �t tart� hozz�j�rul�sait olvasztotta egys�ges szerkezetbe. Tette ezt a nagy fejlesztői forgalom, �s azon t�ny ellen�re, hogy csak egyetlen ember (a program eredeti szerzője) maradt folyamatosan akt�v mind a 15 �ven �t. Nincs olyan z�rt k�d� szerkesztő, amelyik ilyen hossz� �letű lett volna.

Ez azt sugallja, hogy okunk van megk�rdőjelezni a hagyom�nyosan ir�ny�tott szoftverfejleszt�s olyan előnyeit, amelyek nem f�ggenek a katedr�lis �s a baz�r m�dszer egy�b k�rd�seitől. Ha a GNU Emacs 15 �ven �t k�pes volt egys�ges szerkezetet felmutatni, vagy p�ld�ul egy olyan oper�ci�s rendszer, mint a Linux k�pes volt ugyanerre 8 �ven �t, a gyorsan v�ltoz� hardverplatformok �s technol�gi�k ellen�re, �s ha sz�mos j� fel�p�t�sű ny�lt forr�sk�d� szoftver j�tt l�tre az elm�lt t�bb mint �t �vben, akkor okkal t�prenghet�nk el azon, hogy mi haszna van a hagyom�nyosan ir�ny�tott fejleszt�s fenntart�s�nak.

B�rmiről is legyen sz�, nagyon ritka az olyan ir�ny�tott projekt, amely el�ri a megb�zhat� programműk�d�st a hat�ridőre, belef�r a k�lts�gvet�s�be, �s minden, az elő�r�snak megfelelő funkci�t tartalmaz, sőt az is ritkas�g, hogy ezekből egyetlen felt�tel teljes�l. Az ilyen projektek az �lettartamuk alatt �ltal�ban nem k�pesek j�l alkalmazkodni a technol�giai �s a gazdas�gi k�rnyezet v�ltoz�saihoz sem. A ny�lt forr�sk�d� k�z�ss�g ebben l�nyegesen hat�konyabb. (Ezt b�rki k�nnyed�n ellenőrizheti az internet harminc�ves t�rt�net�nek, illetve a v�djegyzett h�l�zati technol�gi�k gyors felez�si idej�nek �sszevet�s�vel – vagy a Microsoft Windows alatti 16-r�l a 32 bitre val� �t�ll�s k�lts�geinek, �s az ugyanabban az időszakban k�l�n�sebb megerőltet�s n�lk�l zajl�, �m hasonl� jelentős�gű Linux alatti v�ltoz�sok [k�lts�geinek] �sszevet�s�vel, amelyek egy�bk�nt nemcsak az Intel, hanem t�bb mint egy tucat hardverplatformon t�rt�ntek, k�zt�k a 64 bites Alph�n is.)

Sokan gondolj�k azt, hogy a hagyom�nyos m�dszer előnye, hogy a t�rv�ny előtt is felelőss� tesz valakit, akitől lehetős�g van k�rp�tl�st k�vetelni, ha a projekt elv�ti az ir�nyt. Ez azonban ill�zi�, a legt�bb szoftverlicenc �gy van meg�rva, hogy kiz�rja m�g az eladhat�s�gi garanci�t is, a teljes�tm�nyről m�r nem is sz�lva, �s a szoftverek hib�s műk�d�se miatti sikeres k�rp�tl�si �gyek sz�ma eleny�szően csek�ly. De ha gyakoriak is lenn�nek, az �rz�s, hogy valaki perelhető, nem oldana meg semmit. Műk�dő szoftvert szeretn�nk, nem peresked�st.

Akkor teh�t mi haszna a hagyom�nyos vezet�si rendszernek?

Hogy ezt meg�rts�k, meg kell ismern�nk, hogy mit gondolnak a szoftverfejleszt�si vezetők a munk�jukr�l. Egy munk�j�ban sikeresnek tűnő ismerős h�lgy elmondta, hogy a szoftverprojekt-menedzsmentnek �t funkci�ja van:

C�lok kitűz�se, �s a munkat�rsak azonos c�l fel� ir�ny�t�sa.
Megfigyel�s, illetve annak biztos�t�sa, hogy nem maradnak ki fontos r�szletek.
Az emberek motiv�l�sa az unalmas, de sz�ks�ges egyhang� feladatokra.
A produktivit�st legjobban előseg�tő fel�p�t�s megszervez�se.
A projekt fenntart�s�hoz sz�ks�ges erőforr�sok megszerz�se.

Nyilv�nval�an kiv�l� c�l mindegyik, de a ny�lt forr�sk�d� modellben �s az azt k�r�lvevő szoci�lis k�rnyezetben k�l�n�sen jelent�ktelennek tűnhetnek. L�ssuk őket ford�tott sorrendben.

Az ismerős�m szerint az erőforr�sok megszerz�se gyakran v�dekez�s. Ha egyszer rendelkez�sre �llnak az emberek, a g�pek �s az irodahelyis�g, akkor ezeket meg kell v�deni az ugyanezek�rt az erőforr�sok�rt versengő t�rsvezetőktől �s a magas beoszt�s� vezetőktől, akik a korl�tozott erőforr�sokat lehető leghat�konyabban pr�b�lj�k elosztani.

A ny�lt forr�sk�d� vil�g fejlesztői �nk�ntesek, �rdeklőd�s�k �s k�pess�geik alapj�n j�rulnak hozz� projektjeik munk�j�hoz (�s ez �ltal�ban akkor is igaz marad, ha fizet�st kapnak a ny�lt forr�sk�d� programoz�s�rt). Az �nk�ntes szellemis�g feleslegess� teszi az erőforr�sszerz�st, az emberek a saj�t erőforr�saikat teszik az asztalra. �gy nincs sz�ks�g v�dekező vezetőre a hagyom�nyos �rtelemben.

Egy�bk�nt az olcs� PC-k �s a gyors internetkapcsolatok vil�g�ban az egyetlen korl�tozott erőforr�s a szak�rtői figyelem. A ny�lt forr�sk�d� projektek felboml�sa alapvetően sosem sz�m�t�g�pek, h�l�zati kapcsolatok vagy irodahelyis�gek miatt t�rt�nik, csak akkor m�lnak ki, amikor a fejlesztők maguk vesztik el az �rdeklőd�s�ket.

Ha �gy �ll a helyzet, akkor dupl�n fontos, hogy a ny�lt forr�sk�d� hackerek az �nkiv�laszt�s �ltal a maxim�lis teljes�tm�ny el�r�s�re szerveződjenek. Az ilyen k�z�ss�gek szoci�lis k�rnyezete a kompetencia alapj�n k�m�letlen�l v�logat. Az ismerős�m szerint, aki egyar�nt ismeri a ny�lt forr�sk�d� vil�got �s a nagy, z�rt projekteket, a ny�lt forr�sk�d r�szben az�rt sikeres, mert kult�r�ja csup�n a programoz�ssal foglalkoz� popul�ci� legtehets�gesebb 5 sz�zal�k�t fogadja el. Ő az idej�nek nagyobb r�sz�ben a marad�k 95 sz�zal�kb�l val�kat szervezi, �gy első k�zből tapasztalta meg a legjobb programoz�k �s a puszt�n kompetensek termel�kenys�ge k�z�tti sz�zszoros elt�r�st.

Az ilyen m�rt�kű elt�r�s mindig f�lveti a k�nos k�rd�st, hogy a z�rt k�d� projektek a h�tter�kkel egy�tt, nem lenn�nek-e jobb helyzetben a kev�sb� tehets�gesek t�bb mint 50 sz�zal�ka n�lk�l? A komoly vezetők r�g�ta tudj�k, hogy ha a konvencion�lis szoftver-menedzsment egyetlen funkci�ja a kev�sb� r�termettekből sz�rmaz� nett� vesztes�g csek�ly nyeres�gg� alak�t�sa lenne, az eg�sz j�t�k nem �rn� meg a f�rads�got.

A ny�lt forr�sk�d� k�z�ss�g sikere meglehetősen s�lyoss� teszi a k�rd�st, azt bizony�tva, hogy gyakran olcs�bb �s hat�konyabb �njel�lt �nk�ntesek toborz�sa az internetről, mint olyan fel�p�tm�nyek ir�ny�t�sa, amelyek tele vannak valami m�ssal sz�vesebben foglalkoz� emberekkel.

Ezzel ak�r �t is t�rhet�nk a motiv�ci� k�rd�s�re. A ismerős�m �ltal mondott dolgok gyakran hallhat� �jrafogalmaz�sa, hogy a hagyom�nyos szoftverfejleszt�s-menedzsment a gyeng�n motiv�lt �s m�sk�nt j� munk�ra k�ptelen programoz�k kompenz�l�s�hoz sz�ks�ges.

Ez az �ll�t�s �ltal�ban azzal j�r egy�tt, hogy a ny�lt forr�sk�d� k�z�ss�gre csak szexi, műszakilag �rdekes munka eset�n lehet sz�m�tani, b�rmi m�s befejezetlen�l marad (vagy gyenge minős�gben k�sz�l el), hacsak nem k�sz�tik el a vezetők �ltal korb�ccsal hajtott mel�sok puszt�n a p�nz�rt. Homesteading the Noosphere c�mű essz�mben pszichol�giai �s t�rsadalmi �rveket sorakoztatok fel ezen �ll�t�ssal szemben, most azonban �gy gondolom, hogy sokkal �rdekesebb lesz, ha r�mutatunk az �ll�t�s elfogad�s�nak k�vetkezm�nyeire.

Amennyiben a hagyom�nyos, z�rt k�d�, erősen ir�ny�tott szoftverfejleszt�si m�dszert val�ban csak egyfajta Maginot-vonal v�di az unalmas probl�m�kt�l, az fenntarthat� marad minden alkalmaz�si ter�leten eg�szen addig, am�g valaki nem tal�lja ezeket a probl�m�kat val�ban �rdekesnek, �s m�s sem akad olyan utakra, amelyeken megker�lhetőek lenn�nek. Mivel ebben a pillanatban megjelenik egy „unalmas” szoftver ny�lt forr�sk�d� vet�lyt�rsa, a fogyaszt�k tudni fogj�k, hogy v�gre olyasvalaki oldotta meg a dolgot, akit m�r maga a probl�ma is elbűv�lt – ez a szoftverek ter�let�n �pp�gy, mint b�rmilyen egy�b, kreativit�st ig�nylő ter�leten sokkal hat�konyabb �szt�nző, mint a p�nz �nmag�ban.

Ilyenkor a hagyom�nyos vezet�si szerkezet fenntart�sa puszt�n a motiv�ci� c�lj�b�l tal�n j� taktika, de rossz strat�gia, r�vid t�von nyeres�g, de hossz� t�von biztosabb vesztes�g.

Eddig teh�t a konvencion�lis fejleszt�s-menedzsment k�t szempontb�l is rossz v�laszt�snak tűnik a ny�lt forr�sk�ddal szemben (erőforr�sszerz�s, szervez�s), egy harmadikb�l vizsg�lva pedig csak r�vidt�v� előnyei vannak (motiv�ci�). A szeg�ny, sarokba szor�tott konvencion�lis vezetőt nem seg�ti ki a megfigyel�s t�m�ja sem, a ny�lt forr�sk�d� k�z�ss�g legerősebb �rve, hogy a decentraliz�lt, mindenki �ltal gyakorolhat� vizsg�lat �ti a r�szletek kihagy�s�nak elker�l�s�re ir�nyul� megszokott elj�r�sokat.

Tal�n a c�lok kitűz�se igazolhatja a konvencion�lis szoftverprojekt-menedzsment l�tez�s�t. Tal�n. De ehhez j� indokot kell szolg�ltatniuk arra, hogy vezetős�gi bizotts�gok �s v�llalati �titervek sikeresebben hat�rozz�k meg a k�z�s, �rdemes c�lokat, mint a ny�lt forr�sk�d� vil�gban hasonl� szerepet bet�ltő projektvezetők vagy a „t�rzs �regjei”.

Ez első pillant�sra kem�ny d�nt�snek tűnik. Nem is annyira a ny�lt forr�sk�d� oldala (az Emacs hossz� �lete, Linus Torvalds fejlesztők seregeit megmozgat� k�pess�ge) teszi neh�zz�, ink�bb a konvencion�lis mechanizmusok itt bemutatott borzalmass�ga a szoftverprojektek c�ljainak meghat�roz�s�ban.

A szoftvertervez�s j�l ismert �ltal�nos b�lcsess�ge, hogy a konvencion�lis szoftverprojektek 60-75 sz�zal�ka nem �ri el a c�lj�t, vagy a megc�lzott felhaszn�l�k visszautas�tj�k az eredm�nyt. Ha ez a tartom�ny az igazs�g k�zel�ben van (soha nem tal�lkoztam olyan tapasztalt vezetővel, aki ezt vitatta volna), akkor t�bb projekt el� tűznek ki (a) re�lisan megval�s�thatatlan (b) vagy egyszerűen csak rossz c�lokat, mint ah�ny el� nem.

Minden m�s probl�m�n�l erősebb indok ez arra, hogy a mai szoftvertervezői vil�gban a „vezetői bizotts�g” kifejez�stől bors�ddz�k a k�z�ns�g h�ta, m�g – vagy tal�n k�l�n�sen akkor – ha vezetők is vannak k�zt�k. Azok az idők, amikor mindezt csak a programoz�k �rtett�k, elm�ltak, a Dilbert k�preg�nyek („Dilbert a technol�gi�t a technol�gia miatt szereti. Val�j�ban jobban szereti a technol�gi�t, mint az embereket, �s egy eg�ral�t�t szoci�lis k�pess�geivel rendelkezik” – www.dilbert.com, a ford.) ma m�r a vezetők asztalai f�l�tt l�gnak.

V�laszunk teh�t a hagyom�nyos szoftverfejleszt�si vezető sz�m�ra egyszerű: ha a ny�lt forr�sk�d� k�z�ss�g val�ban al�becs�lte a konvencion�lis vezet�s �rt�keit, akkor mi�rt vetik meg olyan sokan �n�k k�z�l is a saj�t elj�r�saikat?

Csak ism�telni tudom, hogy a ny�lt forr�sk�d� k�z�ss�g p�ld�ja tov�bb s�lyosb�tja ezt a k�rd�st – mert mi �r�met lel�nk abban, amit csin�lunk. Kreat�v j�t�kunk műszaki, piaci �s szakmai sikerei elk�pesztőek. Nemcsak azt bizony�tjuk, hogy jobb szoftverek �r�s�ra vagyunk k�pesek, hanem azt is, hogy az �r�m tőke.

Az essz� első v�ltozata ut�n k�t �s f�l �vvel a legradik�lisabb gondolat, amivel z�rhatok m�r nem a ny�lt forr�sk�d �ltal uralt szoftvervil�g v�zi�ja, az ma m�r sok megfontolt, nyakkendős ember sz�m�ra k�zenfekvőnek tűnik.

Arra eml�keztetn�k ink�bb, ami �ltal�nosan �rv�nyes lehet a szoftverekre (�s tal�n mindenfajta kreat�v vagy szakmai munk�ra). Az emberi l�nyek �ltal�ban akkor �lveznek egy feladatot, ha az egyfajta optim�lis kih�v�si z�n�ba esik, nem el�g egyszerű ahhoz, hogy unalmas legyen, de nem is t�l neh�z megval�s�tani. Az el�gedett programoz�t nem alkalmazz�k k�pess�gei alatt, �s nem is terhelik rosszul megfogalmazott c�lokkal �s stresszes munkafolyamatokkal. Az �lvezet megelőlegezi a hat�konys�got.

A saj�t feladatainkkal kapcsolatos f�lelmeinkre �s �dzkod�sunkra (m�g ha olyan ironikus m�don is t�rt�nik, mint Dilbert k�preg�nyek kiaggat�sa) �gy kellene tekinten�nk, mint a feladat csődj�nek a jel�re. Az �lvezet, a humor, a j�t�koss�g k�ts�gtelen�l tőke. Nem v�letlen�l eml�tettem a fejezet elej�n az „el�gedett seregeket”, �s az sem vicc csup�n, hogy a Linux jelk�pe, kabal�ja egy ennival� kis pingvin.

Az is kider�lhet, hogy a ny�lt forr�sk�d siker�nek legfontosabb hat�sa az lesz, hogy megtan�t mindny�junkat a kreat�v munka gazdas�gilag legink�bb hat�kony m�dj�ra.

Epil�gus: a Netscape �s a baz�r

K�l�n�s �rz�s arra �bredni, hogy seg�tesz t�rt�nelmet csin�lni. 1998. janu�r 22-�n, k�r�lbel�l h�t h�nappal A katedr�lis �s a baz�r első publik�l�sa ut�n a Netscape Communications Inc. bejelentette a Netscape Communicator forr�sk�dj�nak kiad�s�r�l sz�l� terveit. Azt v�gk�pp nem gondoltam volna, hogy ez m�r a bejelent�s előtti napon meg is t�rt�nik.

Eric Hahn, a Netscape aleln�ke �s műszaki vez�rigazgat�ja nem sokkal ezut�n a k�vetkező levelet k�ldte nekem: „Mindenki nev�ben itt a Netscape-n�l szeretn�m megk�sz�nni �nnek, hogy seg�tett nek�nk id�ig eljutni. D�nt�s�nket az �n gondolkod�sm�dja �s �r�sai alapvetően befoly�solt�k”.

A k�vetkező h�ten a Szil�cium-v�lgybe rep�ltem a Netscape megh�v�s�ra, egynapos strat�giai konferenci�ra (1998. febru�r 4-�n) a felsővezetőikkel �s műszaki szakembereikkel. Egy�tt tervezt�k meg a Netcape forr�sk�dkiad�si strat�gi�j�t �s licenc�t.

N�h�ny nappal k�sőbb a k�vetkezőket �rtam:

A Netscape a baz�r modell nagy �s val�s�gos k�s�rlet�t fogja v�grehajtani a kereskedelmi vil�gban. A ny�lt forr�sk�d� kult�r�nak szembe kell n�znie azzal a vesz�llyel, hogy amennyiben a Netscape k�s�rlete nem v�lik be, a ny�lt forr�sk�d� koncepci� �rt�kvesztett� v�lhat, �gy a kereskedelmi vil�g nem ny�l hozz� egy �jabb �vtizedig.

Ugyanakkor ez egy l�tv�nyos lehetős�g, a l�p�st a Wall Streeten �s m�shol is �vatosan, de pozit�van fogadt�k. Kaptunk egy es�lyt a bizony�t�sra. Ha a Netscape jelentős piaci r�szesed�st szerez vissza ezzel a l�p�ssel, akkor az egy r�gen megk�sett forradalmat ind�that el a szoftveriparban.

A k�vetkező �v bizony�ra tanuls�gos �s �rdekes lesz.

Az is volt. 2000 nyar�n annak a fejleszt�se, amit k�sőbb Mozill�nak neveztek, csak m�rs�kelt siker volt. El�rte ugyan a Netscape az eredeti c�lj�t, amely a Microsoft megakad�lyoz�sa volt a b�ng�szőpiac monopoll� alak�t�s�ban, �s bizonyos ter�leteken komoly sikereket is el�rt (k�l�n�sen az �j gener�ci�s Gecko megjelen�tőmotor kiad�s�val).

Ugyanakkor nem vonzott jelentős fejlesztői erőt a Netscape-en k�v�lről, pedig a Mozilla alap�t�i eredetileg ebben is rem�nykedtek. A probl�ma tal�n az volt, hogy a Mozilla k�zz�t�tele a baz�r modell egyik alapvető szab�ly�t megszegte, nem volt ugyanis benne semmi olyasmi, amit a k�zreműk�dők k�nnyen futtathattak, �s műk�dni l�thattak. (T�bb mint egy �vvel a k�d kiad�sa ut�nig a Mozilla forr�sk�db�l val� fel�p�t�s�hez sz�ks�g volt a v�djegyzett Motif programk�nyvt�r licenc�re).

A legnagyobb hiba (k�v�lről szeml�lve) az volt, hogy a Mozilla munkacsoport k�t �s f�l �vvel a projekt indul�sa ut�n m�g mindig nem adott ki haszn�lhat� b�ng�szőt, illetve 1999-ben a projekt egyik vezetője keltett egy kis szenz�ci�t azzal, hogy visszal�pett, �s a gyenge vezet�sre, illetve az elszalasztott lehetős�gekre panaszkodott. „A ny�lt forr�sk�dnak” – figyelte meg helyesen – „nincs var�zsereje”.

T�nyleg nincs. A Mozilla hossz� t�v� kil�t�sai azonban l�nyegesen jobbnak tűnnek most (2000 november�ben), mint Jamie Zawinski felmond�levele idej�ben – az ut�bbi n�h�ny h�tben az automatikus �jszakai kiad�sok el�rt�k a haszn�lhat�s�g hat�r�t. De Jamie-nek abban igaza volt, hogy a ny�ltt� v�l�s nem felt�tlen�l ment meg egy rossz c�lokkal, rossz k�ddal, vagy egy�b szoftvertervez�si betegs�gekkel terhes projektet. A Mozilla egyszerre p�ld�ja annak, hogy a ny�lt forr�sk�d hogyan lehet sikeres �s sikertelen.

Idők�zben a ny�lt forr�sk�d egy�b sikereket �rt el, �s m�shol is t�mogat�kra tal�lt. A Netscape kiad�sa �ta hatalmas robban�s t�rt�nt a ny�lt forr�sk�d� modell ir�nti �rdeklőd�sben, a trendet a Linux oper�ci�s rendszer folyamatos sikerei t�pl�lj�k. A Mozilla �ltal elind�tott �ramlat egyre jelentősebb� v�lik.

Jegyzetek

Bibliogr�fia

K�sz�netnyilv�n�t�s

Essz�m sz�mos emberrel val� besz�lget�s sor�n fejlőd�tt, akik seg�tettek hib�inak kijav�t�s�ban. K�l�n�s k�sz�nettel tartozom Jeff Dutkynak <[email protected]>, aki „hibakeres�s p�rhuzamos�that�s�ga” megfogalmaz�st javasolta, �s seg�tett a jelens�g elemz�s�ben. K�sz�n�m Nancy Lebovitznak <[email protected]> a javaslatot, hogy Weinberget k�vessem Kropotkin id�z�s�vel. Figyelmes kritik�t kaptam Joan Eslingertől <[email protected]> �s Marty Franzt�l <[email protected]> az �ltal�nos technol�giai list�r�l. Glen Vandenburg <[email protected]> az �nkiv�laszt�s fontoss�g�ra mutatott r� a k�zreműk�dő popul�ci�kban �s gy�m�lcs�ző javaslatot tett arra, hogy a sok fejleszt�s helyrehozza a „mulaszt�si hib�kat”, m�g Daniel Upper <[email protected]> pedig term�szetes anal�gi�kkal szolg�lt ugyanerre. H�l�s vagyok a PLUG-nak, a Philadelphiai Linux-felhaszn�l�k Csoportj�nak, ők voltak essz�m első nyilv�nos v�ltozat�nak tesztk�z�ns�ge. Paula Matuszek <[email protected]> a szoftvermenedzsment gyakorlati oldal�r�l vil�gos�tott fel. Phil Hudson <[email protected]> arra eml�keztetett, hogy a hacker-kult�ra t�rsas szerveződ�se az �ltaluk k�sz�tett szoftverek fel�p�t�s�t t�kr�zi �s ford�tva. John Buck <[email protected]> r�mutatott, hogy a MATLAB az Emacs-hez hasonl� p�lda. Russell Johnston <[email protected]> seg�tett tudatos�tani azokat a mechanizmusokat, amelyekről „A sok szem cs�kkenti a komplexit�st” fejezet sz�l. V�g�l Linus Torvalds megjegyz�sei �s korai hozz�j�rul�sa rendk�v�l b�tor�t� volt.

A katedr�lis �s a baz�r

Tartalomjegyz�k

Kivonat