Catedrala si Bazarul
de Eric S. Raymond
tradusa de Mihai Moldovanu (mihaim LA tfm PUNCT ro)
Disec un proiect free-software de succes, fetchmail, care a fost condus ca test al unor teorii surprinzatoare despre dezvoltarea softului sugerate de istoria Linuxului. Discut aceste teorii ca doua stiluri de dezvoltare fundamental diferite, “catedrala” (modelul marii majoritati in lumea comerciala) vis a vis de “bazar” (modelul lumii Linuxului). Arat ca aceste modele deriva din principii opuse asupra naturii software-debugging task. Apoi sustin afirmatia “cu destui ochi, toate bug-urile sint reduse” cu argumente din experienta Linuxului, sugerez analogii productive cu alte sisteme auto-corectante ale agentilor individuali si concluzionez cu o explorare a implicatiilor acestui punct de vedere pentru viitorul softului.
1. Catedrala si Bazarul
Linuxul este subversiv. Cine s-ar fi gindit, chiar acum 5 ani, ca un sistem de operare world-class s-ar putea realiza ca prin minune datorita hackinguluipart-time al citorva mii de developeri raspinditi pe tot globul, uniti numai prin slabele legaturi ale Internetului ?
Eu sigur nu. Pina cind Linuxul a aparut pe radarul meu la inceputul lui 1993,deja fusesem implicat de 10 ani in dezvoltarea Unixului si free-softului. Am fost unul din primii GNU contributors la mijocul anilor 80.Pusesem o multzime de free software pe internet, dezvoltind singur sau cu altii mai multe programe (nethack, Emacs VC si GUD, xlife, etc.) care inca se mai folosesc. Credeam ca stiam cum se face.
Linux a rasturnat multe din cunostintele mele. Am propovaduit utilitarele mici, obtinerea rapida a prototipurilor si programarea evolutiva din Unix ani de zile. Dar am crezut ca exista un grad de complexitate critic, de la care este necesara o abordare o abordare mai centralizata. Credeam ca softul cel mai important (sisteme de operare si utilitarele cu adevarat mari cum ar fi Emacs) necesita o constructie tip catedrala, fiind concepute cu grija de un vrajitor sau de grupuri mici de magi in izolare, beta fiind lansate cind le vine timpul si nu inainte.
Stilul de dezvoltare al lui Linus Torvald – release devreme si des, delega tot ce poti, fii deschis pina la dezordine – a fost o surpriza. Aici nu exista o constructie de catedrala, in liniste shi cu respect – mai curind, comunitatea Linux seamana cu un mare bazar agitat, cu agende de lucru si abordari diferite (simbolizat din plin de siteurile archive Linux, care ar inscrie pe oricine) din care ar parea ca un sistem coerent si stabil ar putea aparea numai printr-o succesiune de miracole.
Adevarul ca acest stil de bazar parea sa mearga si a fost un soc ca inca bine. Pe masura ce ma orientam, am lucrat nu numai la proiecte individuale, ci am si incercat sa inteleg de ce lumea Linux nu numai ca nu se dezintegra in confuzie, ba chiar devenea tot mai puternica cu o viteza greu de conceput pentru stilul Catedrala.
Catre mijlocul anului 1996 am crezut ca incep sa inteleg. Sansa mi-a oferit-o metoda perfecta de a-mi testa teoria, sub forma unui proiect free-software pe care am putut sa incerc sa-l conduc in stilul Bazar. Asa am si facut – si a fost un succes semnificativ.
In restul articolului voi povesti acest proiect si-l voi folosi pentru a propune citeva aforisme despre dezvoltarea efectiva a free-software. Nu am aflat toate astea in lumea Linux, dar vom vedea cum lumea Linux le particularizeaza. Daca am dreptate, va vor ajuta sa intelegeti exact ce face comunitatea Linux o sursa de soft bun – si sa deveniti mai productivi.
2. Mailul trebuie sa treaca
Din 1993 m-am ocupat de partea tehnica a unui free-access ISP mic, numit Chester County InterLink (CCIL) in West Chester, Pennsylvania (am fost unul din fondatorii CCIL si am scris singurul nostru software BBS multiuser – puteti verifica prin telnet la locke.ccil.org. Azi suporta aproape 3000 de useri pe 19 linii). Serviciul mi-a permis acces pe net 24 de ore din 24 prin linia de 56K a CCIL – practic, mi l-a impus ca o necesitate.
Asadar, ma obisnuisem cu email instantaneu pe Internet. Din motive complexe, a fost greu sa fac SLIP sa lucreze intre acasa (snark.thyrsus.com) si CCIL. Cind am reusit in cele din urma, m-am trezit ca telnet la locke periodic pentru mail era enervant. Ce vroiam era ca mailul sa vina la snark astfel
incit biff(1) sa ma anunte cind sosea.
Simplul forward sendmail n-ar fi mers, pentru ca snark nu e intotdeauna pe net si nu are o adresa statica IP. Ce-mi trebuia era un program care ar fi ajuns prin conexiunea mea SLIP si mi-ar fi trimis mailul local. Stiam ca exista asa ceva si majoritatea foloseau un protocol simplu numit POP (Post Office Protocol). Si aproape sigur era deja un server POP3 inclus in sistemulde operare BSD/OS al lui locke.
Aveam nevoie de un utilizator POP3. Asa ca am mers pe net si am gasit unul. De fapt, am gasit 3 sau 4. Am folosit pop-perl o vreme, dar ii lipsea ceea ce parea o trasatura evidenta, capacitatea de a modifica adresa la fetched mail astfel incit raspunsul sa functioneze corect.
Problema era: presupunind ca cineva pe nume “Joe” de pe locke imi trimiteamail. Daca transferam mailul pe snark si apoi incercam sa raspund, mailerul meu ar fi incercat sa trimita raspunsul la un “Joe” inexistent de pe snark. Scrierea adreselor de mina @ccil.org a devenit repede o suferinta serioasa.
Asta ar fi trebuit sigur sa faca computerul pentru mine (de fapt, in conformitate cu RFC1123 sectiunea 5.2.18, sendmail ar fi trebuit s-o faca). Dar niciunul din utilizatorii POP existenti nu stia cum ! Si asta ne aduce la prima lectie:
Orice treaba buna in domeniul softului incepe prin a rezolva o
problema personala a developerului
Poate ca ar fi trebuit sa fie evident (e proverbial ca “Necesitatea este mama inventiilor”), dar prea des developerii de software isi petrec timpul asteptind plata unor programe de care nu au nevoie si la care nu tin. Dar asta nu se intimpla in lumea Linux – ceea ce ar putea explica de ce calitatea softului produs in aceasta lume este atit de buna.
Deci, m-am lansat eu imediat intr-un virtej dezlantuit pentru a crea un nou utilizator POP3 care sa concureze cu cei existenti ? Niciodata ! Am cautat cu grija intre utilitarele POP pe care le aveam la indemina, intrebindu-ma “care e cel mai aproape de ceea ce vreau ?”. Pentru ca :
Programatorii buni stiu ce sa scrie. Cei foarte buni stiu ce sa
rescrie (si refoloseasca)
In timp ce n-am pretentia ca as fi un foarte bun programator, incerc sa imit unul foarte bun. O trasatura importanta a celor foarte buni este lenea constructiva. Ei stiu ca nota maxima se obtine prin rezultate, nu prin efort si e aproape totdeauna mai usor cu acest punct de plecare decit sa pornesti de la zero.
Linus, de exemplu, n-a incercat sa scrie Linuxul de la inceput. A inceput prin a refolosi code si idei din Minix, un OS Unix-like mic pentru 386. In cele din urma, Minix code a disparut sau a fost complet rescris – dar cit a fost, a fost structura pentru puiul care in final a devenit Linux.
Pe aceeasi idee, am cautat un utilitar POP existent care era suficient de bine scris, pentru a crea o baza.
Traditia de source-sharing din lumea Unix a fost intotdeauna deschis pentru refolosirea code (de aceea proiectul GNU a ales Unix ca OS de baza, in ciuda rezervelor asupra OS insusi). Lumea Linux a dus aceasta traditie aproape de limita tehnologica; are terrabytes de surse deschise si accesibile. Asa ca ai mai multe sanse de a gasi un aproape-suficient in lumea Linux decit oriunde in alta parte.
Si mie mi-a mers. Cu ce gasisem deja, a doua cautare a dus la un total de 9 candidate – fetchpop, pop Tart, get-mail, gwpop, pimp, pop-perl, popc, popmail si upop. Primul pe care l-am instalat a fost “fetchpop” de Seung-HongOh. Am folosit rescrierea headerelor si am facut alte imbunatatiri pe care autorul le-a acceptat in varianta 1.9.
Totusi, dupa citeva saptamini, am dat peste “popclient” code de Carl Harris si am descoperit ca am o problema. Desi fetchpop avea citeva idei originale bune (cum ar fi daemon mode-ul), nu mergea decit POP3 si era destul de amator scris (Seung-Hong era un programator destept dar fara experienta, ceea ce se vedea in ambele variante). Code-ul lui Carl era mai bun, profesionist si solid, dar ii lipseau destul de multe caracteristici fetchpop importante si greu de implementat (inclusiv cele pe care le scrisesem eu).
Sa perseverez sau sa schimb ? Daca schimbam, renuntam la tot ce facusem deja pentru o baza de implementare mai buna.
Un motiv practic pentru schimbare era suportul multiple-protocol. POP3 este cel mai folosit intre protocoalele de posta, dar nu singurul. Fetchpop si celelalte nu mergeau pe POP2, RPOP sau APOP si eu deja ma gindeam ca as putea adauga, poate, IMAP (Internet Message Access Protocol, cel mai nou si mai puternic protocol de posta) de amorul artei.
Dar aveam si un motiv teoretic sa cred ca schimbarea in sine ar fi buna, ceva ce am invatat mult inainte de Linux.
“Planuieste sa arunci intr-o singura directie; oricum o vei face”
(Fred Brooks, “Miticul Om-Luna” capitolul 11)
Altfel spus, nu intelegi intr-adevar problema pina cind nu gasesti o solutie.A doua oara, poate ca vei sti suficient ca s-o rezolvi. Asa ca daca vrei sa rezolvi ceva, fii pregatit sa o iei de la capat cel putin o data. Ei bine (m-am gindit), schimbarile la fetchpop au fost prima mea incercare.
Asa ca am schimbat.
Dupa ce am trimis primul set de corecturi la popclient la Carl Harris pe 25 iunie 1996, am aflat ca el isi pierduse de ceva timp interesul pentru popclient. Code-ul era putin prafuit, cu bug-uri minore. Am avut de facut multe schimbari si am cazut de acord ca logic era sa preiau eu programul.
Fara sa bag de seama, proiectul crescuse. Nu ma mai gindeam numai la schimbari minore la un POP client existent. M-am angajat la crearea unuia intreg si imi forfoteau idei in cap care ar fi dus probabil la schimbari majore.
Intr-o cultura soft care incurajeaza code-shearing-ul, asta este modul natural de evolutie al unui proiect. Mergeam pe ideea:
Daca ai atitudinea corecta, te vor gasi probleme interesante.
Dar atitudinea lui Carl Harris a fost chiar mai importanta. El a inteles ca:
Atunci cind iti pierzi interesul pentru un program, ultima ta datorie fata de el
este sa-l predai unui succesor competent
Fara sa discutam vreodata despre asta, Carl si eu stiam ca avem scopul comun de a gasi cea mai buna solutie. Singura intrebare pentru fiecare dintre noi era daca eu puteam dovedi ca intra pe miini bune. Odata ce am facut-o, el a reactionat cu eleganta si promptitudine. Sper ca si eu voi reactiona la fel cind imi va veni rindul.
3. Importanta de a avea useri
Si asa am mostenit popclient. La fel de important, am mostenit baza de useriai popclient. E minunat sa ai useri si nu numai pentru ca demonstreaza ca satisfaci o nevoie, ca faci ceva bine. Corect tratati, pot deveni co-developeri.
O alta forta a traditiei Unix, si din nou una pe care Linuxul o impinge la o extrema fericita, este aceea ca multi useri sint si hackeri – si pentru ca sursa code este la indemina, ei pot fi hackeri efectiv. Asta poate fi extrem de folositor pentru scurtarea timpului de debugging. Cu putine incurajari, userii vor gasi probleme, vor sugera solutii si vor ajuta la imbunatatirea code-ului mult mai repede decit ai putea fara ajutor.
Sa-ti tratezi userii ca co-developeri este cea mai comoda cale catre
ameliorarea rapida a code-ului shi debugging-ul eficient
Puterea acestui efect poate fi usor subestimata. Intr-adevar, cam toti din lumea free-softului am subestimat drastic cit de bine se poate creste cu numarul de useri si contra complexitatii sistemului pina cind ne-a demonstrat Linuxul ca ne inselam.
Intr-adevar, cred ca partea cea mai desteapta, determinanta, a Linuxului nu a fost constructia kernel-ului, ci mai curind inventarea modelului de dezvoltare. Cind mi-am exprimat aceasta opinie in prezenta lui, a zimbit si a repetat ceva ce spunea frecvent: “Sint structural o persoana foarte lenesa careia ii place sa culeaga meritele de pe urma unor lucruri pe care de fapt le fac altii”. Lenes ca o vulpe. Sau, cum ar fi putut spune Robert Heinlein, prea lenes pentru a rata.
Retrospectiv, un precedent al metodelor si succesului Linuxului poate fi vazut in dezvoltarea librariei GNU Emacs Lisp si arhivelor Lisp code. Spre deosebire de stilul “catedrala” al nucleului Emacs C si al majoritatii celorlalte FSF tools, evolutia Lisp code a fost fluida si condusa de useri. Idei si prototipuri au fost rescrise frecvent de 3-4 ori inainte de a obtine o forma finala stabila. Si colaborari laxe-asociate, permise de Internet, au fost frecvente.
Intr-adevar, cel mai bun hack facut de mine inainte de fetchmail a fost probabil stilul Emacs VC, o colaborare similara Linuxului prin email cu alte 3 persoane, dintre care pina astazi am intilnit numai una (Richard Stallman).A fost un front-end pentru SCCS, RCS si, mai tirziu, CVS din cadrul Emacs care oferea operatii de controlul versiunilor “one-touch”. A evoluat dintr-un sccs.el mode mic, brut, scris de altcineva. Si VC s-a dezvoltat pentru ca, spre deosebire de Emacs, Emacs Lisp code a putut trece prin generatii de release/test/imbunatatire foarte repede.
(Un efect secundar neasteptat al politicii FSF de a incerca sa adauge code in GPL este acela ca devine procedural mai greu pentru FSF sa foloseasca stilul bazar, intrucit cred ca trebuie sa obtina copyright pentru fiecare contributie individuala din mai mult de 20 de linii pentru a asigura GPLed code de pretentii asociate legii copyrightului. Userii BSD si MIT X . Licentele consortiilor nu au aceasta problema intrucit ei nu incearca sa rezerve drepturi pe care cineva ar putea sa le ceara.)
4. “Release” devreme si des
Release-urile cit mai devreme si mai des sint o parte esentiala a modelului de dezvoltare Linux. Majoritatea developerilor (inclusiv eu) credeau ca este o politica proasta pentru proiecte mai mari pentru ca primele versiuni sint, prin definitie, pline de bugguri si nu se doreste exasperarea userilor.
Aceasta idee a intarit angajarea in stilul de dezvoltare “catedrala”. Daca obiectivul final era ca userii sa gaseasca cit mai putine bugguri, de ce sanu existe un release la 6 luni (sau mai rar) si intre release-uri sa muncestica un ciine la debugging. Asa a fost dezvoltat Emacs C. Libraria Lispnu – pentru ca erau arhive Lisp active in afara controlului FSF, unde puteai gasi versiuni code noi, dezvoltate independent de ciclul de release al Emacs.
Cea mai importanta dintre acestea, arhiva Ohio State elisp, a anticipatspiritul si multe din caracteristicile arhivelor Linux de azi. Dar putini s-au gindit intr-adevar la ce faceam sau la ce sugera chiar existenta acelei arhive despre problemele din modelul de dezvoltare “catedrala” din FSF. Am facut o incercare serioasa prin 1992, sa obtin mult din acest code in libraria oficiala Emacs Lisp. Am intrat intr-o problema de politica si n-am avut nici un succes.
Dar un an mai tirziu, cind Linuxul a devenit vizibil pe scara larga, a devenit clar ca acolo se petrecea ceva diferit si mult mai sanatos. Politica de dezvoltare deschisa a lui Linus era exact opusul stilului “catedrala”. Sunsite-ul si arhivele tsx-11 cresteau, erau lansate distributii multiple. Si totul era condus de o frecventa de release nemaiauzita.
Linus isi trata userii ca fiind co-developeri in modul cel mai eficient posibil:
Release devreme. Release frecvent. Si asculta-ti clientii.
Inovatia lui Linus nu a constat atit din idee in sine (ceva asemanator era traditia lumii Unix de mult timp), ci din aducerea ei la o intensitate care se potrivea cu complexitatea proiectului pe care il dezvolta. La inceput nu era neobisnuit sa dea mai mult de un nou kernel release pe zi! Si, pentru ca si-a cultivat baza de co-developeri si utiliza internetul mai mult decit oricine altcineva pentru colaborari, a functionat.
Dar cum a functionat ? Si era ceva ce puteam face si eu, sau se baza pe geniul unic al lui Linus ?
Nu credeam. Cu siguranta, Linus e un hacker al naibii de bun (citi dintre noi ar putea constitui un intreg OS kernel productie-calitate ?). Dar Linux nu reprezenta nici un salt uimitor inainte. Linus nu este (sau cel putin nu inca) un geniu inovativ de genul Richard Stallman sau James Gosling. Linus mi se pare mai curind un geniu al inginerie, cu un al saselea simt in evitarea bugurilor si liniilor moarte in dezvoltare si un adevarat talent in a gasi calea cea mai usoara de la A la B. Intr-adevar, intregul design al Linuxului degaja aceasta calitate si oglindeste stilul lui Linus esential conservator si simplificator.
Deci, daca release-uri rapide si utilizarea Internetului la maxim nu erau accidente, ci parti integrale ale stilului lui Linus genial de a gasi calea cea mai usoara, ce amplifica ? Ce pusese el la lucru ?
Pusa astfel, intrebarea contine raspunsul. Linus isi tinea hacker/user-ii stimulati si rasplatiti permanent – stimulati prin perspectiva de a avea o parte a lor sa le satisfaca ego-ul, rasplatiti prin urmarirea imbunatatirilor(chiar zilnic) a muncii lor.
Linus tintea direct la maximalizarea numarului de persoane-ore ocupate cu debuggingul si dezvoltarea, chiar cu posibilul pret al instabilitatii in code si baza de useri epuizati in cazul in care un bug serios se dovedea nerezolvabil. Linus se comporta ca si cum ar fi crezut ceva de genul:
Cu o baza de beta-testeri si co-developeri suficient de mare, aproape orice problema va fi gasita rapid si va avea o solutie evidenta pentru cineva.
Sau, mai putin formal, “cu destui ochi, toate bugurile sint reduse”. Asta numesc “legea lui Linus”
Formularea mea initiala a fost ca orice problema “va fi transparenta pentru cineva”. Linus a constatat ca persoana care intelege si rezolva o problema nu este obligatoriu, nici macar de obicei, cea care o gaseste. El spune “Cineva gaseste problema si altcineva o intelege. Si sustin ca gasirea ei este cea mai mare provocare”. Dar important este ca totul se intimpla repede.
Aici, cred eu, este diferenta esentiala intre stilurile “catedrala” si “bazar”. In stilul catedrala, bugurile si problemele de dezvoltare sint inselatoare, ascunse, profunde. Este nevoie de luni de cautari ale putinilor developeri pentru a crede ca toate au fost eliminate. De aici rarele release-uri si dezamagirea inevitabila atunci cind release-urile mult asteptate nu sint perfecte.
In stilul “bazar”, pe de alta parte, presupui ca bugurile sint reduse, sau, cel putin, se reduc foarte repede cind sint prezentate miilor de co-developeri care asteapta nerabdatori fiecare nou release. Asa, apare efectul benefic al corecturilor frecvente si e mai putin de pierdut daca accidental iese o gafa.
Si asta este. Ajunge. Daca “legea lui Linus” e falsa, atunci nici un sistem complex ca kernel-ul Linux, modificat de atitea miini, ar fi trebuit sa se prabuseasca sub greutatea unor interactiuni proaste si unor buguri nedescoperite, ascunse. Pe de alta parte, daca e adevarata, e suficienta pentru a explica lipsa relativa de buguri din Linux.
Si poate n-ar fi trebuit sa fie asa o surpriza. Sociologii au descoperit cu ani in urma ca opinia medie a maselor de observatori la fel de experte (sau ignorante) e un factor de predictie mai bun decit un observator ales aleator.Au numit asta “efectul Delphi”. Se pare ca Linus a aratat ca se aplica si debugging-ului unui OS – ca efectul Delphi explica complexitatea dezvoltarii chiar la nivelul complexitatii unui OS kernel.
Ii sint dator lui Jeff Dutky dutky@wam.umd.edu[1] pentru ca a aratat ca legea lui Linus poate fi reformulata ca “debugging-ul este paralelizabil”. Jeff observa ca desi pentru debugging este necesar ca debuggerii sa comunice cu un developer coordonator, nu este necesara o coordonare semnificativa intre debuggeri. Astfel nu mai este atit de greu si nu mai are costuri atit de mari de management sa adaugi developeri.
In practica, pierderea teoretica de eficienta datorata duplicarii muncii debuggerilor, nu pare sa fie o problema aproape niciodata in lumea Linux. Un efect al “politicii release-urilor devreme si des” este acela de a minimaliza aceasta duplicare, propagind feed-back rapid cu corecturile.
Brooks a facut chiar o observatie legata de a lui Jeff: “Costul total de intretinere a unui program larg folosit este de obicei 40% sau mai mult din costul dezvoltarii lui. Surprinzator, acest cost este puternic afectat de numarul de useri. Mai multi useri gasesc mai multe buguri”. (concluzia mea)
Mai multi useri gasesc mai multe buguri deoarece userii aduc moduri diferite de utilizare a sistemului. Acest efect este amplificat atunci cind userii sint co-developeri. Fiecare abordeaza sarcina de gasire a bugurilor cu instrumente usor diferite conceptual si analitic, un unghi diferit de abordare al problemei. “Efectul Delphi” pare sa functioneze tocmai datorita acestei variatii. In contextul specific al debugging-ului, variatia tinde si sa scada duplicarea efortului.
Asa ca adaugarea de beta-testeri nu reduce complexitatea bugului “cel mai adinc” din P.O.V.-ul developerului, dar creste probabilitatea ca uneltele cuiva sa se potriveasca problemei astfel incit bugul este mic pentru acea persoana.
Linus amelioreaza si el solutiile. In cazul in care exista buguri serioase, versiunile de linux astfel incit userii pot alege intre ultima varianta declarata “stabila” sau sa se aventureze pe marginea prapastiei cu riscul bugurilor pentru a obtine caracteristici noi. Aceasta tactica nu este preluata formal de majoritatea hackerilor, dar poate ar trebui preluata; faptul ca ambele variante sint accesibile le face mai atractive pe amindoua.
5. Cind un trandafir nu este un trandafir ?
Studiind comportamentul lui Linus si creind o teorie asupra succesului lui, am luat decizia constienta de a testa aceasta teorie cu noul meu proiect (sigur mult mai simplu si mai putin ambitios).
Dar primul lucru pe care l-am facut a fost sa reorganizez si sa simplific mult popclient. Implementarea lui Carl Harris a fost foarte solida, dar prezenta un fel de complexitate nenecesara, comuna multor programatori C. El a tratat code-ul ca centru si structurile de date ca suport pentru code. Astfel, code-ul era frumos, dar designu-ul structurii de date era ad-hoc si detul de urit (cel putin dupa standardele inalte ale acestui batrin LISP
hacker).
Totusi am avut si alt scop rescriind, in afara imbunatatirii code-ului si design-ului structurii de date. Acela de a evolua la ceva ce intelegeam complet. Nu merge sa fii responsabil de repararea bugurilor intr-un program pe care nu-l intelegi.
Cam o luna a urmat pur si simplu implicatiile design-ului de baza al lui Carl. Prima schimbare serioasa pe care am facut-o a fost sa adaug suport IMAP. Am facut-o reorganizind protocolul intr-un driver generic si trei tabele de metode (pentru POP2, POP3 si IMAP). Asta si schimbarile anterioare ilustreaza un principiu general la care programatorii ar face bine sa se gindeasca, mai ales in limbaje ca C, care normal nu scriu dinamic:
Structuri de date destepte si code prost merg mult mai bine decit invers.
Din nou Fred Brooks, capitolul 11: “Arata-mi [code] si ascunde [data structures], si voi continua sa ma insel. Arata-mi [data structures] si in mod normal nu voi avea nevoie de [code]; va fi evident.” De fapt, el a spus “flowcharts”si “tables”. Dar tinind cont de cei 30 de ani de schimbari terminologice si culturale, e cam acelasi lucru.
In acel moment (la inceputul lui septembrie 1996, dupa 6 saptamini) am inceput sa ma gindesc ca ar tebui schimbat numele – la urma urmei, nu mai era doar POP client. Dar am ezitat pentru ca nu era nimic absolut nou in design. Versiunea mea de popclient trebuia sa-si dezvolte o identitate proprie.
Problema s-a schimbat radical atunci cind fetchmail a invatat ca ms trimite mailul la portul SMTP. Ajung la asta imediat. Inainte: am spus mai sus ca ma hotarisem sa folosesc acest proiect pentru a-mi testa teoria despre ce facuse corect Linus Torvalds. Cum (ati putea intreba) am facut-o ? Astfel:
- Release devreme si des (aproape niciodata mai rar de 10 zile; in perioadele de dezvoltare intensa, o data pe zi)
- Am marit lista beta adaugind pe toti cei care ma contactasera in legatura cu fetchmail
- Am trimis anunturi chat la cei de pe lista beta la fiecare release, incurajind lumea sa participe
- Am ascultat beta-testerii, intrebindu-i in legatura cu deciziile de design si raspunzind oricind trimiteau raspunsuri si sugestii
Rasplata acestor masuri simple a fost imediata. Inca de la inceputul proiectului, am primit atentionari de buguri de o calitate pentru care majoritatea developerilor ar fi facut orice, frecvent cu solutii bune atasate. Am primit critici constructive, mail de la cei carora le-a placut, sugestii inteligente asupra caracteristicilor. Ceea ce duce la :
Daca iti tratezi beta-testerii ca pe cea mai valoroasa resursa, vor
raspunde devenind cea mai valoroasa resursa.
O masura interesanta a succesului fetchmailului este simpla marime a listei beta a proiectului, prietenii fetchmail. In timpul scrierii are 249 membri
si creste cu 2-3 pe saptamina.
Acum, cind revad lista la sfirsitul lui mai 1997, lista incepe sa scada dintr-un motiv interesant. Mai multi membri mi-au cerut sa-i scot de pe lista pentru ca fetchmail merge atit de bine din punctul lor de vedere incit nu mai au nevoie sa vada evolutia! Poate ca asta este ciclul normal de viata al unui proiect matur in stilul bazar.
6. Popclient devine Fetchmail
Adevarata rascruce a proiectului a fost atunci cind Harry Hochheiser mi-a trimis code-ul lui pentru trimiterea mailului la portul SMTP al clientului. Am inteles imediat ca o implementare sigura a acestei caracteristici ar face ca toate celelalte moduri de trimitere sa fie aproape nesemnificative.
Multe saptamini am facut mici modificari la fetchmail, simtind ca designul interetei era comod, dar neslefuit – neelegant si cu prea multe optiuni aparind peste tot. Optiunile de a pune mailul intr-un mailbox sau output standard ma deranjau in mod special, dar nu-mi dadeam seama de ce.
Ce am inteles cind m-am gindit la forward SMTP a fost ca popclient incercase sa faca prea multe. Fusese conceput sa fie atit un agent de transport pentru mail (MTA) cit si agent de distributie local (MDA). Cu forwardul SMTP, putea sa nu mai fie MDA, ci MTA pur, transmitind mailul altor programe pentru
livrare locala, exact ca sendmail.
De ce sa te incurci cu configurarea complexa a agentului de livrare a mailului sau sa aranjezi lock-and-append la mailbox cind portul 25 e garantat oricum aproape la orice sistem cu TCP/IP ? Mai ales atunci cind inseamna ca mailul luat este garantat sa apara ca mail initiat normal de cel
care trimite mail SMTP, ceea ce vroiam de fapt.
Sint mai multe lectii aici. In primul rind, ideea acestui SMTP-forwarding a fost cea mai mare recompensa independenta pe care am primit-o din incercarea de repetare constienta a metodelor lui Linus. Un user mi-a dat o idee minunata – tot ce trebuia sa fac era sa inteleg consecintele.
Cel mai bun lucru dupa a avea idei bune este sa recunosti ideile bune ale
userilor. Uneori mai tirziu e mai bine.
Destul de interesant, afli destul de repede ca daca esti complet sincer in ceea ce priveste cit datorezi celorlalti, toata lumea te va trata ca si cum ai fi facut tu absolut totul si esti modest in ceea ce priveste genialitatea ta. Puteti vedea cit de bine a mers in cazul lui Linus!
(Cind am prezentat aceasta lucrare la conferinta Perl din august 1997, Larry Wall statea in primul rind. Cind am ajuns la ideea asta, a strigat intr-un
stil revigorant “spune, spune, frate!”. Tot publicul a ris pentru ca stiau ca a mers si pentru inventatorul Perl-ului.)
Si dupa citeva saptamini de conducere a proiectului in acelasi stil, am inceput sa primesc aceeasi recunostere nu numai de la useri, ci si de la cei
care au aflat despre el. Am pus de-o parte ceva din emailul ala; ma voi uita la el daca vreodata ma voi intreba daca am facut ceva in viata );.
Dar sint doua lectii mai importante, non-politice, valabile pentru orice fel de design.
Solutiile cele mai izbitoare si novatoare apar din intelegerea faptului ca
conceptul initial a fost gresit.
Am incercat sa rezolv o problema gresita continuind sa dezvolt popclient ca o combinatie MTA/MDA cu tot felul de moduri de livrare ciudate. Designul fetchmailului trebuia regindit de la inceput ca MTA pur, o parte a SMTP normal.
Cind te lovesti de un zid in dezvoltare – cind te trezesti in dificultate gindindu-te ce vei face mai departe – este momentul sa te intrebi daca intrebarea e corecta, nu daca raspunsul e corect. Poate ca problema trebuie reformulata.
Ei bine, mi-am reformulat problema. Evident, ce trebuia facut era (1) transformarea suportului de forward SMTP intr-un driver generic, (2) crearea unui default mode si (3) eventual aruncate celelalte moduri de livrare, mai ales optiunile de livrare la file si standard output.
Am ezitat ceva timp in ceea ce priveste (3), temindu-ma sa nu supar useri vechi de popclient care depindeau de mecanisme alternative de livrare. Teoretic, puteau trece imediat la forward file sau la echivalente non-sendmail pentru a obtine ceva. Practic, tranzitia putea fi problematica.
Dar cind am facut-o, beneficiile s-au dovedit enorme. Partile cele mai greoaie din driver code au disparut. Configurarea a devenit mult mai simpla – gata cu tatonarea pentru MDA si mailboxul userului, gata cu grijile legate de posibilitatea OS-ului de a suporta file locking.
De asemenea a disparut singura cale prin care se putea pierde mail. Daca specificai livrarea la anume file si discul se umplea, mailul se pierdea. Nu se poate intimpla cu SMTP forwarding pentru ca SMTP listener nu raspunde OK decit daca mesajul poate fi livrat sau macar pastrat pentru a fi livrat mai tirziu.
De asemenea, s-au imbunatatit performantele (n-ai crede ca se vede din prima). Alt beneficiu semnificativ a fost ca pagina-manual a devenit mult mai simpla.
Mai tirziu, a trebuit sa permit livrarea printr-un MDA local specificat de user pentru a rezolva situatii ciudate legate de SLIP dinamic. Dar am gasit o metoda mult mai simpla de rezolvare.
Morala ? Nu ezita sa arunci caracteristici supraspecializate cind te poti descurca fara ele, fara sa pierzi eficienta. Antoine de Saint-Exupery (pilot si contructor de avioane cind nu era autor de carti clasice pentru copii) spunea:
“Perfectiunea (in design) este atinsa nu atunci cind nu mai ai ce adauga,
ci mai curind atunci cind nu mai ai ce elimina.”
Cind code-ul devine atit mai bun cit si mai simplu, atunci stii ca este corect. Si pe parcurs, fetchmail a dobindit o identitate proprie, diferita
de popclientul initial.
Era momentul sa se schimbe numele. Noul design arata mai mult ca dual de sendmail decit arata vechiul popclient; ambele sint MTA, dar in timp ce sendmail impinge apoi livreaza, popclient trage apoi livreaza. Deci, dupa 2 luni, l-am numit fetchmail.
7. Fetchmail creste
Aveam un design curat si novator, code care mergea bine, stiam asta pentru ca il foloseam in fiecare zi, si aveam o lista beta infloritoare. Mi-am dat seama treptat ca nu mai lucram la un program personal care ar fi putut folosi, intimplator, si altora. Aveam un program de care avea intr-adevar nevoie orice hacker cu Unix box si conexiune de mail SLIP/PPP.
Cu caracteristica de forward SMTP, a trecut destul de departe in fruntea competitiei celor care ar putea deveni “category killer”, unul din programele clasice care isi ocupa locul atit de bine incit alternativele nu numai ca sint discreditate, sint chiar uitate.
Cred ca n-as putea tinti sau planui un astfel de rezultat. Trebuie sa fii tras acolo prin idei atit de puternice incit rezultatele ulterioare par inevitabile, naturale, chiar predestinate. Singura cale de a cauta astfel de idei este sa ai foarte multe idei – sau sa ai capacitatea de a duce ideile altora dincolo de limitele gindite de cei de la care au pornit.
Andrew Tanenbaum a avut ideea de a construi un Unix simplu pentru 386, ca unealta de invatare. Linus Torvalds a impins conceptia Minixului dincolo de
ce crezuse Andrew ca ar putea face – si s-a transformat in ceva minunat. La fel (la o scara mai mica), am luat idei ale lui Carl Harris si Harry Hochheiser si le-am impins cu putere. Niciunul dintre noi nu a fost “original” in felul romantic in care este conceput geniul. Dar, pe de alta parte, cea mai mare parte a dezvoltarii in stiinta, inginerie si soft nu apare de la un geniu original, mit al domeniului, ci dimpotriva.
Rezultatele erau totusi de frunte – de fapt, succesul pentru care traieste orice hacker! Si asta insemna ca trebuia sa-mi ridic standardele chiar mai mult. Pentru a face fetchmailul atit de bun pe cit vedeam acum ca putea fi, trebuia sa tin cont nu numai de necesitatile mele, ci sa includ si necesitatile celor din afara cercului meu. Si s-o fac mentinind programul simplu si robust.
Prima si de departe cea mai importanta trasatura pe care am scris-o dupa ce am inteles asta a fost un suport multidrop – abilitatea de a prelua mailul de la mai multe mailboxes si sa-l adun de la un grup de useri, apoi sa trimit fiecare mail la destinatarul individual.
Am hotarit sa adaug acest suport in parte pentru ca unii useri il doreau, dar in principal pentru ca credeam ca voi scapa de buguri fortindu-ma sa ma descurc cu orice fel de adresare. Si asa a fost. Pentru a aranja RFC822 parsing mi-a trebuit foarte mult timp, nu din cauza ca partile sint grele, ci pentru ca implica o groaza de amanunte importante si interdependente.
Dar si designul acesta s-a dovedit a fi o decizie excelenta. Iata cum am stiut:
Orice utilitar ar trebui sa fie folositor dupa cum se asteapta de la el, dar unul foarte bun se arata folositor cum nu te-ai fi asteptat
Utilitatea neasteptata pentru multi-drop fetchmai este utilizarea listelor de mail pastrind lista, folosind extensia de alias, pe conexiunea SLIPP/PPP de partea userului. Asta inseamna ca cineva care isi folosea computerul personal credea ca o conexiune ISP poate da lista de mail fara continuarea accesului la aliasurile ISP-ului.
Alta schimbare importanta ceruta de beta-testerii mei a fost cea de suport pentru 8-bit MIME operation. Asta era destul de usor de facut pentru ca am avut grija sa pastrez code-ul 8-bit curat. Nu pentru ca anticipasem cererea, ci mai curind urmind o alta regula:
Cind scrii gateway software de orice fel, straduieste-te sa tulburi curentul de date cit mai putin – si niciodata nu arunca informatii cu exceptia cazului in care esti obligat.
Daca nu urmam aceasta regula, suportul 8-bit MIME ar fi fost dificil si plin de buguri. Asa, tot ce trebuia sa fac era sa citesc RFC 1652 si sa adaug o parte foarte mica de header-generation logic.
Unii useri europeni m-au pisat sa adaug o optiune de limitare a numarului demesaje luate per sesiune (astfel incit ei sa poata controla preturile din retelele lor telefonice scumpe). M-am opus mult timp si nici acum nu sint multumit cu ideea. Dar daca scrii pentru lume, trebuie sa-ti asculti clientii – si asta nu se schimba numai pentru ca nu te platesc cu bani.
8. Inca citeva lectii de la Fetchmail
Inainte de a ne intoarce la probleme generale de conceperea softlui, sint citeva lectii mai specifice de evaluat din experienta fetchmail.
Sintaxa rc file include cuvinte-cheie “zgomotoase” optionale, care sint complet necunoscute sistemului de analiza gramaticala. Sintaxa similara limbii engleze pe care o permite e mult mai usor citibila decit asocierea clasica cuvint cheie-valoare ce ramine dupa ce le elimini.
A inceput ca un experiment noaptea tirziu cind am observat cite din rc file declarations incepeau sa semene unui minilimbaj imperativ. (Tot din aceasta
cauza am schimbat cuvintul-cheie “server”, original din popclient cu “poll”).
Mi se parea ca folosirea acestui limbaj imperativ ar fi mai usoara daca as incerca sa-l fac mai asemanator cu engleza. Desi sint partizan convins al scolii de design “fa-l limbaj”, dupa cum se vedela Emacs si HTML si multe utilitare pentru baze de date, in mod normal nu sint fan al sintaxelor “English-like”.
Programatorii traditionali au avut tendinta sa favorizeze sintaxe de control foarte precise si compacte si care n-au deloc redundanta. Asta este o
mostenire culturala de pe vremea cind resursele pentru computere erau mici, asa ca fazele de analiza gramaticala trebuiau sa fie cit mai simple si mai
mici consumatoare posibil. Engleza, cu o redundanta de aproximativ 50%, parea atunci un model foarte nepotrivit.
Dar nu asta este motivul meu de a nu adopta sintaxe English-like; l-am mentionat numai pentru a-l elimina. Cu programe mici consumatoare, concizia
nu ar trebui sa fie esentiala. Astazi e mai important ca un limbaj sa fie convenabil pentru oameni decit sa consume putin din resursele computerului.
Totusi, exista motive serioase pentru a fi econom. Unul este costul complexitatii fazei de analiza – nu se doreste sa ajunga sursa semnificativa de buguri si confuzie pentru user. Altul este faptul ca incercarea de a face o sintaxa a limbajului English-like necesita o “engleza” intr-o forma foarte proasta, astfel incit asemanarea aparenta cu limba naturala devine la fel de confuza cum fusese sintaxa traditionala. (Se vede intr-o multime de 4GL-uri si limbaje de cautare pentru baze de date comerciale.)
Sintaxa de control a fetchmailului pare sa evite aceste probleme pentru ca domeniul de limba este foarte mic. Nu e nici pe departe un limbaj pentru scopuri generale; ceea ce spune simplu nu e foarte complicat, deci exista un potential mic de confuzie prin trecerea mentala de la un mic subset de engleza la limba actuala. Cred ca este o lectie mai larga aici:
Cind limbajul nu se apropie nici pe departe de Turing-complete, zaharul sintactic iti poate fi prieten.
Alta lectie este despre securitate prin obscuritate. Unii useri fetchmail mi-au cerut ca schimb softul pentru a pune parole criptate in rc file, astfel incit cei care-si baga nasul sa nu poata sa le vada intimplator.
N-am facut-o, pentru ca nu creste intr-adevar gradul de protectie. Oricine a primit permisiunea sa-ti citeasca rc file va putea rula fetchmail ca si tine oricum – si daca vrea parola ta, va putea sa gaseasca ce-i trebuie pentru decodare in insusi code-ul fetchmail.
Orice criptare de parola fetchmailirc ar fi dat un fals sentiment de securitate celor care nu se gindesc foarte bine. Regula generala este:
Un sistem de securitate e atit de sigur pe cit e de secret. Fereste-te de pseudo-secrete.
9. Preconditii necesare pentru stilul bazar
Primele critici si teste de audienta pentru aceasta lucrare au ridicat intrebari legate de preconditiile dezvoltarii bune in stil bazar, inclusiv calificarea conducatorului de proiect si statusul code-ului in momentul in care devine public si incepe sa incerce constructia unei comunitati de co-developeri.
E destul de clar ca nu se poate construi de la zero in stilul bazar. Se poate testa, se pot elimina bugurile si se poate imbunatati in stilul bazar, dar ar fi foarte greu sa incepi un proiect in stilul bazar. Linus n-a incercat. Nici eu. Comunitatea de developeri in formare are nevoie de ceva ce merge si poate fi testat pentru a se juca.
Cind incepi constructia comunitatii, ceea ce trebuie prezentat este o promisiune plauzibila. Programul nu trebuie sa mearga prea bine. Poate fi aspru, plin de buguri, incomplet si prost documentat. Ceea ce nu trebuie ratat este convingerea potentialilor co-developeri ca programul poate evolua in ceva foarte misto intr-un viitor previzibil.
Linux si fetchmail au iesit amindoua cu design de baza puternic si atractiv. Multi din cei care s-au gindit la modelul bazar prezentat de mine au considerat acest lucru ca fiiind critic, de unde au ajuns la concluzia ca pentru proiect este indispensabil un conducator cu un grad mare de intuitie si istetime in design.
Dar Linus si-a luat designul de la Unix. Eu l-am luat pe al meu initial de la popmail (desi ulterior s-a schimbat mult, mult mai mult proportional vorbind decit Linuxul). Deci trebuie neaparat ca leaderul sa aiba un talent exceptional sau il poate prelua de la altii ?
Nu cred ca este neaparat necesar sa fie un coordonator capabil sa creeze designuri exceptionale, dar este neaparat necesar sa fie in stare sa recunoasca ideile bune in design ale altora.
Atit proiectul Linux cit si fetchmail au evidentiat asta. Linus, in timp ce nu era (dupa cum am discutat) un designer spectaculos, a dovedit un fler puternic in a recunoaste un design bun si a-l introduce in kernelul Linux. Si eu am spus deja ca cea mai buna idee de design in fetchmail (SMTP forwarding) a venit de la altcineva.
Primii cititori ai acestei lucrari m-au laudat sugerind ca am tendinta sa subevaluez originalitatea designului proiectelor in stilul bazar pentru ca eu sint foarte talentat si de-asta tind s-o consider de la sine inteleasa. S-ar putea sa fie ceva adevarat; designul (contrar programarii sau eliminarii bugurilor) este cu siguranta cel mai mare talent al meu.
Dar problema in a fi destept si original in designul softului este ca devine un obicei – incepi reflex sa faci lucruri dragute si complicate cind ar
trebui sa le pastrezi simple si robuste. Am ratat proiecte din aceasta cauza, dar am reusit sa n-o fac cu fetchmail.
Deci cred ca proiectul fetchmail a reusit in parte pentru ca mi-am infrint tendinta de a fi destept; asta este un argument (cel putin) impotriva ideii
ca originalitatea designului este esentiala pentru proiectele in stil bazar. Si ginditi-va la Linux. Presupunind ca Linus Torvalds incercase sa aduca
inovatii fundamentale in designul OS in timpul dezvoltarii; pare probabil ca kernelul rezultat sa fie atit de stabil si de bun pe cit este ?
Sigur ca este necesar un anumit nivel in design si programare, dar cred ca toti cei care s-ar gindi serios sa lanseze un astfel de proiect ar depasi limita minima. Piata interna a comunitatii free-software exercita o presiune subtila asupra oamenilor sa nu se lanseze in eforturi de dezvoltare pe care nu le pot sustine in continuare. Pina acum se pare ca a mers destul de bine.
Exista un alt fel de talent, care in mod normal nu e asociat cu dezvoltarea softului, pe care il consider la fel de important pentru proiectele stil bazar ca si istetimea in design – si ar putea fi chiar mai important. Un coordonator de proiect trebuie sa aiba capacitatea de a comunica cu oamenii bine.
Ar trebui sa fie evident. Pentru a construi o comunitate de dezvoltare, trebuie sa atragi oamenii, sa-i interesezi in ceea ce faci si sa-i mentii multumiti in legatura cu cantitatea de effort pe care o depun. Realizarea tehnica va face mult in acest scop, dar nu e nici pe departe tot. Conteaza si personalitatea pe care o proiectezi.
Nu este o coincidenta ca Linus e un tip simpatic care ii transforma pe oameni si ii face sa vrea sa-l ajute. Nu e o coincidenta ca eu sint un extrovertit energic caruia-i place sa munceasca in multime si are ceva din prezenta si instinctul unui comic de marca. Pentru ca modelul bazar sa mearga, ajuta enorm sa ai un cit de mic talent sa farmeci oamenii.
10. Contextul social al Free Software
E adevarat ce se spune: cele mai bune programe incep ca solutie la problemele personale, de fiecare zi, ale autorului si se raspindesc pentru ca problemele se dovedesc a fi tipice pentru o mare categorie de useri. Asta ne duce inapoi la regula 1, reformulata intr-un mod mai folositor probabil:
Pentru a rezolva o problema interesanta, incepe prin a gasi o problema
care te intereseaza
Asa a fost cu Carl Harris si popclient, asa a fost si cu mine si fetchmail. Dar asta s-a inteles de mult timp. Partea interesanta, cea asupra careia Linux si fetchmail par sa ne ceara sa ne concentram, este etapa urmatoare – evolutia softului in prezenta unei comunitati mari si active de useri si co-developeri.
In “Miticul om-luna”, Fred Brooks a observat ca timpul uni programator nu este inlocuibil; adaugarea developerilor la un proiect intirziat il face sa intirzie mai mult. A argumentat prin faptul ca costul complexitatii si comunicarii intr-un proiect creste cu patratul numarului de developeri, in timp ce cantitatea de munca creste numai linear. De atunci, aceasta idee a devenit “legea lui Brooks” si e considerata in general un adevar. Dar daca legea lui Brooks ar cuprinde tot, Linux ar fi fost imposibil.
Citiva ani mai tirziu, clasicul “Psihologia programarii computerelor” de Gerald Weiberg a furnizat ceea ce putem privi ca corectura vitala la Brooks. In discutia lui despre “programarea neegoista”, Weinberg a constatat ca in magazinele unde developerii nu sint posesivi cu code-ul lor si ii incurajeazape altii sa caute buguri si imbunatatiri posibile, imbunatatirea apare mult mai repede decit in alte parti.
Alegerea terminologiei lui Weinberg a impiedicat cistigarea meritelor pe care analiza le merita – oricine ar zimbi la gindul ca hackerii de pe Internet ar putea fi considerati “dezinteresati”. Dar cred ca acest argument pare astazi mai real ca intotdeauna.
Istoria Unixului ar fi trebuit sa ne pregateasca pentru ceea ce invatam din Linux (si ce am verificat experimental la o scara mai mica copiind deliberat
metodele lui Linus). Adica, in timp ce programarea ramine o activitate esential solitara, programele cu adevarat importante apar din angajarea atentiei si puterii de gindire unor comunitati intregi. Developerul care foloseste numai propriul creier intr-un proiect inchis va ramine in urma developerului care stie sa creeze un context deschis, evolutiv in care gasirea bugurilor si imbunatatirile sint realizate de sute de oameni.
Dar lumea Unix traditionala a fost impiedicata de mai multi factori sa impinga aceasta abordare pina la capat. Unul a fost reprezentat de limitarile legale ale diferitelor licente, schimbul de secrete si interese comerciale. Altul a fost acela ca Internetul nu era suficient de bun inca.
Inaintea Internetului ieftin, existau comunitati geografice compacte unde cultura incuraja programarea “neegoista” a lui Weinberg si un developer putea atrage cu usurinta o multime de chibiti talentati si co-developeri. Bell Labs, MIT AI Lab, UC Berkeley – au devenit casa inovatiilor, sint legendare si inca puternice.
Linux a fost primul proiect care a facut un efot continuu si constient pentrua folosi intreaga lume ca sursa de talente. Nu cred ca este o coincidenta faptul ca perioada de gestatie a Linuxului a coincis cu nasterea WWW-ului si ca Linuxul si-a terminat copilaria in aceeasi perioada 1993-1994 in care s-a vazut pornirea industriei ISP si explozia curentului principal de interes in Internet. Linus a fost primul care a invatat cum sa joace dupa noile reguli pe care le-a facut posibile noul Internet permeabil.
In timp ce un Internet ieftin era necesar pentru evolutia modelului Linuxului, cred ca nu era si o conditie suficienta. Alt factor vital a fost dezvoltarea stilului de conducere si aranjarea obiceiurilor de cooperare care puteau permite developerlor sa atraga co-developeri si sa obtina pirghiile maxime pentru mediu.
Dar ce este stilul de conduceresi ce sint aceste obiceiuri ? Nu se pot baza pe relatii de putere – si chiar daca ar putea, conducerea prin obligare nu ar produce rezultatele pe care le vedem. Weinberg citeaza autobiografia lui Kropotkin, un anarhist rus din secolul19, (“Memoriile unui revolutionar”) pentru un efect bun la acest subiect:
“Fiind crescut de familia unui proprietar de sclavi, am intrat in viata activa, ca toti tinerii din vremea mea, cu multa incredere in necesitatea de a comanda, ordona, ocari, pedepsi si altele asemenea. Dar atunci cind, devreme, a trebuit sa ma ocup de treburi serioase si sa ma descurc cu oameni [liberi], si cind fiecare greseala ar fi dus la consecinte serioase, am inceput sa apreciez diferenta intre a actiona pe baza principiului de comanda si disciplina si a actiona pe principiul intelegerii reciproce. Cel
anterior functioneaza admirabil intr-o parada militara, dar nu valoreaza nimic in viata reala si scopul poate fi atins numai prin effort serios si interese comune.”
Inainte m-am referit la “efectul Delphi” ca o posibila explicatie pentru legea lui Linus. Dar analogii mai puternice, irezitibile, apar cu sisteme adaptative din biologie si economie. Lumea Linux se comporta, din multe puncte de vedere, ca o piata libera sau un sistem ecologic, o colectie de agenti egoisti care incearca sa maximalizeze utilitatea, ceea ce produce o ordine spontana auto-corectanta mai elaborata si eficienta decit ar putea realiza vreo planificare centrala. Atunci aici este locul unde trebuie
cautat “principiul intelegerii”.
“Functia utilitate” pe care o maximalizeaza hackerii Linux nu este clasica economic, dar este intangibilul propriei lor auto-satisfactii si reputatiei intre hackeri. (S-ar putea spune ca sint “altruisti”, dar s-ar ignora faptul ca altruismul insusi este o forma de auto-satisfactie pentru altruist). Culturile voluntariatului care functioneaza asa nu sint tocmai rare; o alta din care am facut parte mult timp este lumea fanilor science fiction, care, spre deosebire de lumea hackerilor, recunoaste explicit “egoboo” (amplificarea reputatiei cuiva intre ceilalti fani) ca fiind principala motivatie a activitatii voluntare.
Linus, pozitionindu-se cu succes ca paznic al unui proiect in care dezvoltarea este facuta in principal de altii si hranind interesul pentru proiect pina cind a devenit auto-sustinut, a demonstrat un simt acut al “principiului interesului comun” al lui Kropotkin. Aceasta vedere pseudo-economica asupra lumii Linux ne permite sa vedem cum este aplicata intelegerea.
Putem privi metoda lui Linus ca o metoda de a crea o piata eficienta in “egoboo” – conectarea cit mai puternica a lipsei de egoism individuala a hackerilor pentru a face lucruri dificile, care pot fi realizate numai prin cooperare sustinuta. Cu proiectul fetchmail am aratat (la o scara mai mica) ca metodele lui pot fi duplicate cu rezultate bune. Poate ca eu am facut-o un pic mai constient si mai sistematic decit el.
Multi (mai ales cei care nu au incredere politic in pietele libere) s-ar astepta ca o lume de egoisti egocentristi sa fie fragmentata, teritorializata, in pierdere, secretoasa si ostila. Dar aceste asteptari sint falsificate clar de (numai un exemplu) varietatea, calitatea si profunzimea uimitoare a documentarii Linux. E un dat sfint faptul ca programatorii urasc documentarea; atunci cum se face ca hackerii Linux produc atit de multa ? Evident ca piata libera a Linuxului in lumea egoboo reuseste mai bine sa genereze un comportament virtuos, directionat spre altii, decit producatorii de soft comercial cu documentatiile lor bine platite.
Atit proiectul kernelului fetchmail cit si Linux arata ca recompensind corespunzator egourile multor altor hackeri, un coordonator puternic poate folosi Internetul pentru a avea beneficiile generate de multi co-developeri fara ca proiectul sa se prabuseasca in haos. Deci contra-propunerea mea la
legea lui Brooks este:
Fiind dat un coordonator de dezvoltare cu un mediu cel putin la fel de bun ca Internetul si stie sa conduca fara coercitie, multe capete sint inevitabil mai bune decit unul.
Cred ca viitorul free software-ului va apartine tot mai mult celor care stiu cum sa joace jocul lui Linus, celor care parasesc catedrala si patrund in bazar. Asta nu inseamna ca viziune si talentul individual nu vor mai conta; mai curind, cred ca limita free software-ului va apartine celor care pornesc de la viziunea si talentul individual, apoi le amplifica prin constructia efectiva a unor comunitati de interese bazate pe voluntariat.
Si poate nu numai viitorul free software. Niciun developer comercial nu poate egala multimea de talente pe care comunitatea Linux o poate mobiliza in rezolvarea unei probleme. Foarte putini si-ar putea permite doar sa inchirieze mai mult de 200 de oameni, citi au contribuit la fetchmail!
Poate ca in final cultura free software va trumfa, nu din cauza ca cooperarea este corecta din punct de vedere moral sau “ingradirea” softului este gresita din punct de vedere moral (presupunind ca credeti ultima afirmatie, ceea ce nu credem nici eu nici Linus), ci pur si simplu pentru ca lumea comerciala nu poate invinge o specie evolutiva cu comunitati de free-software care poate mobiliza la timp grupuri mult mai talentate pentru rezolvarea unei probleme.
11. Recunoasteri
Aceasta lucrare a fost imbunatatita datorita conversatiilor cu un mare numar de oameni care m-au ajutat s-o corectez. Multumesc in mod special lui Jeff
Dutky dutky@wam.umd.edu[2], care a sugerat formularea “debugging is parallelizable” si a ajutat la analiza ce a aparut din aceasta idee. De
asemenea lui Nancy Lebovitz nancyl@universe.digex.net[3] pentru sugestiile de a-l explica pe Weinberg citind din Kropotkin. Critici constructive au
venit si de la Joan Eslinger wombat@kilimanjaro.engr.sgi.com[4] si Marty Franzmarty@net-link.net[5] de la lista General Techmatrics. Paul Eggert
eggert@twinsun.com[6] a observat conflictul dintre GPL si modelul bazar. Sint recunoscator membrilor PLUG, grupului de useri Philadelphia Linux pentru
ca mi-au furnizat testul de audienta pentru prima varianta publica a acestei lucrari. In final, Linus Torvald m-a ajutat prin comentarii si m-a incurajat
sustinindu-ma.
De citit in continuare
Am citat mai multe bucati din clasicul “miticul om-luna” de Frederick P. Brooks pentru ca, din multe puncte de vedere, se pot aduce inca imbunatatiri prin imaginea redata de el. Recomand din toata inima a 25-a editie aniversara de la Addison-Wesley (ISBN 0-201-83595-9), care cuprinde si lucrarea din 1986 “Fara glont de argint”.
Noua editie e adusa la zi printr-o retrospectiva nepretuita de 20 de ani in care Brooks recunoaste, pe drept, ca sint citeva judecati in textul original
care nu au suportat testul timpului. Am citit prima data retrospectiva dupa ce aceasta lucrare era aproape gata, si am fost surprins sa vad ca Brooks
atribuie practicile stil bazar Microsoftului!
Psihologia programarii computerelor de Gerald P. Weinberg (New York, Van Nostrand Reinhold 1971) a introdus conceptul, destul de nefericit etichetat,
de “egoless programming”. Cind nu era nici pe departe primul care intelegea superficialitatea conceptului “principle of command”, era probabil primul care recunostea si sustinea ideea in legatura cu dezvoltarea softului.
Richard P. Gabriel, observind cultura Unix din perioada pre-Linux, a sustinut superioritatea unui model stil bazar primitiv in lucrarea Lisp din 1989: “vesti bune, vesti proaste si cum sa cistigi mult”. Desi depasit din anumite puncte de vedere, acest eseu este sarbatorit inca intre fanii Lisp (inclusiv eu). Un corespondent mi-a amintit ca sectiunea intitulata “Mai rau e mai bine” apare aproape ca o anticipare a Linuxului. Lucrarea este accesibila pe WWW la http://alpha-bits.ai.mit.edu/articles/good-news.html[7]
Peopleware de De Marco si Lister: Proiecte si echipe productive (New York; Dorset House, 1987; ISBN 0-932633-05-6) este o nestemata subapreciata si am
fost incintat sa vad ca Fred Brooks cita din ea in retrospectiva. In timp ce putin din ce au de spus autorii este aplicabil direct la Linux sau comunitatile free-software, privirea asupra conditiilor necesare muncii creative sint actuale si meritorii pentru oricine incearca sa importe din meritele modelului bazar intr-un context mai comercial.
In final, trebuie sa recunosc ca aproape am numit aceasta lucrare “The Cathedral and the Agora”, ultimul termen fiind grecescul pentru piata deschisa sau loc public de intilnire. Lucrarile rodnice “sisteme agorice” de Mark Miller si Eric Drexler, descriind proprietatile emergente ale sistemelor de computere market-like, m-au ajutat sa imi fac o imagine clara despre fenomene analoge in cultura free-softwareatunci cind am dat cu nasul de ele, datorita Linuxului, cinci ani mai tirziu. Aceste lucrari sint
accesibile pe WWW la http://www.agorics.com/agorpapers.html[8]
Istoria versiunilor si schimbarilor
Am adaugat bibliografia la 7 iulie 1997 in 1.20.
Am adaugat anecdota Perl Conference la 18 noiembrie 1997 in 1.27.
Alte nivele de revizuire au adus modificari editoriale si de marcaj.
Datorita schimbarilor majore in tree-ul de development am decis sa nu mai facem release la TFM 3.0 ci sa trecem in stadiul de development pentru 3.1 cu un release plan mai strict in schimb. Astfel in acest moment se accepta feature requests / feature changes atit pentru workstation cit si pentru server.
