IntroducereCele mai multe proiecte de software gratuit eșuează.Nu auzim prea multe despre eșecuri. Numai proiectele cu succes
atrag atenția dar există atât de multe proiecte de software gratuit
SourceForge.net, un site cunoscut de găzduire, înregistrase
79225 de proiecte până la mijlocul lunii aprilie 2004. Desigur că numărul
acesta nu se apropie de numărul total de proiecte existente pe Internet;
reprezintă doar numărul celor care au ales să utilizeze SourceForge.
încât chiar dacă numai un procentaj mic au succes
tot va rezulta un număr mare de proiecte vizibile. De asemenea nu auzim
de eșecuri pentru că eșecul nu este un eveniment în sine. Nu există un
moment anume de timp în care un proiect încetează să mai fie util;
oamenii se îndepărtează de el și încetează să mai lucreze la el. Poate
exista un moment când se face o ultimă modificare la un proiect dar cei
care au făcut-o de obicei nu știu că aceasta este ultima. Nu există
nicio definiție clară a momentului în care se consideră că un proiect
a expirat. Să fie când la un proiect nu s-a mai lucrat timp de șase luni?
Sau când numărul de utilizatori nu mai crește fără a fi depășit
capacitatea numărului de dezvoltatori de a întreține proiectul? Dar dacă
dezvoltatorii unui proiect îl abandonează pentru că realizează că
replicau efortul unui altul—și dacă se alătură acelui alt
proiect, apoi îl extind pentru a putea să includă o parte a efortului
anterior? Primul proiect s-a încheiat s-au și-a schimbat doar locul? Această complexitate duce la imposibilitatea stabilirii
unei rate exacte a eșecului. Dar dovezile anecdotice strânse după
mai mult de un deceniu de open-source, puțină navigare pe SourceForge.net
și câteva căutări pe Google duc toate la aceeași concluzie: rata este
extrem de mare, probabil ajungând la 90–95%. Numărul crește
dacă includem proiectele existente dar disfuncționale: acele care
produc cod executabil dar care nu sunt plăcute
utilizatorului sau care nu progresează la fel de rapid sau de fiabil
cum ar putea.
Această carte vorbește despre evitarea eșecului. Examinează nu
numai cum se fac lucrurile corect dar și cum se fac în mod greșit pentru
a putea recunoaște și corecta problemele din timp. Sper că, după citirea
cărții, veți avea un repertoriu de tehnici nu numai pentru a evita
problemele uzuale din dezvoltarea open-source dar și pentru a vă ocupa
de creșterea și întreținerea unui proiect de succes. Succesul nu este un
joc cu sumă zero și această carte nu este despre cum să câștigi sau să
îți întreci adversarii. Din contră, o parte importantă a conducerii
unui proiect open-source o constituie interfațarea simplă cu proiecte
înrudinte. Pe termen lung, fiecare proiect de succes contribuie la
binele corpului mondial de software gratuit.Ar fi tentant de spus faptul că proiectele de software gratuit
eșuează din aceleași categorii de motive ca și proiectele de software
proprietar. Cu siguranță, software-ul gratuit nu deține monopolul asupra
cerințelor nerealiste, cerințelor vagi, administrării deficitare a
resurselor, fazelor insuficiente de design sau altor pitici deja
bine cunoscuți în industria software. Există deja destule scrieri pe
aceste teme și nu voi încerca să le reproduc în această carte. În schimb,
voi încerca să descriu problemele caracteristice software-ului gratuit.
Când un proiect de software gratuit dispare se întâmplă de obicei
pentru că dezvoltatorii (sau managerii) nu au apreciat problemele unice
ale dezvoltării de software open-source deși poate că erau destul de bine
pregătiți pentru dificultățile dezvoltării closed-source.Una dintre cele mai frecvente greșeli este de a avea așteptări
nerealiste de la avantajul unei surse deschise. O licență deschisă nu
garantează faptul că hoarde de dezvoltatori activi își vor oferi brusc
timpul lor proiectului și nici transformarea unui proiect în open-source
nu îi rezolvă în mod magic problemele. De fapt, se poate întâmpla chiar
contrariul: deschiderea unui proiect poate adăuga complexitate și poate
costa mai mult pe termen scurt decât păstrarea
codului închis. Deschiderea către public presupune aranjarea codului
astfel încât să poată să fie înțeles de străini, stabilirea unui site de
dezvoltare și a unor liste de e-mail și adesea scrierea documentației
pentru prima dată. Toate acestea presupun multă muncă. Desigur, dacă
totuși apar apar noi dezvoltatori, există povara
suplimentară de a le răspunde la întrebări pentru o vreme înainte de a
beneficia de pe urma prezenței lor. După cum spunea și dezvoltatorul
Jamie Zawinski despre problemele din primele zile ale proiectului
Mozilla:
Open source-ul funcționează dar nu este un panaceu.
Dacă există un un înțeles în această poveste este că nu se poate
presăra praful magic "open-source" pe un proiect aflat pe moarte
și totul să funcționeze în mod magic. Software-ul este complicat.
Problemele nu sunt atât de simple.(sursa: )
O greșeală înrudită este aceea de a sări peste partea de prezentare
și împachetare, considerând că acestea pot fi făcute mai târziu, când
proiectul a demarat deja de ceva vreme. Prezentarea și împachetarea
aplicației cuprind destul de multe etape care toate se învârt în
jurul ideei de a reduce dificultatea intrării. Pentru ca proiectul să fie
deschis celor neinițiați trebuie scrisă documentația pentru utilizatori
și dezvoltatori, trebuie creat un site web care să ofere informațiile
necesare celor care sunt noi, trebuie automate procesele de compilare
și instalare a software-ului, etc. Din păcate mulți programatori
consideră că această muncă este de mai puțină importanță decât codul în
sine. Există câteva motive pentru care se întâmplă acest lucru. În primul
rând poate să pară muncă inutilă pentru că beneficiile ei sunt mai
degrabă vizibile celor mai puțin familiarizați cu proiectul și invers.
Oamenii care dezvoltă codul nu au nevoie neapărat de acest proces de
ambalare. Ei deja știu să instaleze, administreze și să folosească
aplicația pentru că au scris-o. În al doilea rând, deprinderile
necesare pentru a realiza bine prezentarea și împachetarea aplicației
sunt complet diferite de cele de care e nevoie pentru a scrie cod.
Oamenii tind să se concentreze pe lucrurile la care sunt buni chiar dacă
ar fi mai bine pentru proiect să petreacă și puțin timp făcând ceva
care li se potrivește mai puțin. discută în detaliu procesele de realizare
a prezentării și împachetării aplicației și explică de ce e crucial
ca ele să fie o prioritate încă de la începutul proiectului.Următoarea pe lista noastră de greșeli frecvente sunt presupunerile
greșita că în open-source nu e nevoie de management de proiect, că e
nevoie de foarte puțin sau că aceleași practici de management folosite
la dezvoltarea în cadrul unei firme vor funcționa la fel de bine la un
proiect open-source. Administrarea unui proiect deschis nu este
întotdeauna foarte vizibilă utilizatorilor dar în proiectele de succes
aceasta are loc în culise într-o formă sau alta. Un mic exercițiu de
gândire ajunge pentru a demonstra de ce. Un proiect open-source cuprinde
un grup aleator de programatori—deja o categorie cunoscută pentru
firea independentă—care, cel mai probabil, nu s-au întâlnit
niciodată unii cu alții și care pot să urmărească fiecare scopuri
diferite prin munca lor de la proiect. Exercițiul constă doar în a ne
imagina ce s-ar întâmpla cu un astfel de grup fără
management. Dacă nu luăm în considerare miracolele, un astfel de grup
s-ar destrăma foarte repede. Lucrurile pur și simplu nu se vor așeza
singure, indiferent cât am dori noi să fie invers. Dar partea de
management, deși poate fi destul de activă, e adesea lipsită de
formalitate și subtilă. Singurul lucru care menține coeziunea unui grup
de dezvoltare este credința comună că pot face mai multe împreună
decât fiecare individual. Astfel, scopul procesului managerial este
de a se asigura faptul că ei împărtășesc în continuare acest crez prin
eliminarea marginalizării dezvoltatorilor datorate idiosincraziei și,
în general, făcând proiectul unul la care dezvoltatorii să vrea să se
întoarcă. Tehnicile specifice pentru realizarea acestui scop sunt
discutate pe parcursul cărții.Ultima categorie este a acelor probleme care ar putea fi denumite
"eșecuri ale navigației culturale". Acum zece ani, poate chiar cinci,
ar fi fost prematur să vorbim despre o cultură globală a software-ului
gratuit. Ulterior a apărut o cultură ușor de recunoscut care nu este
monolitică—este la fel de predispusă la conflicte interne ca și
orice altă cultură delimitată geografic— dar are un miez consistent.
Majoritatea proiectelor de succes prezintă unele dintre aceste
caracteristici comune. Ele recompensează anumite tipuri de comportament și
pedepsesc altele; creează o atmosferă care încurajează participarea
neplanificată, uneori cu riscul reducerii gradului de coordonare; au
concepte de politețe și impolitețe care pot să difere substanțial de cele
care există în alte locuri. Cel mai important, cei care participă pe
termen lung internalizează aceste standarde astfel încât să existe un
consens vis-a-vis de conduita așteptată de la membri. Proiectele lipsite
de succes deviază puternic de la acest miez de idei, chiar dacă
neintenționat, și adeseori nu prezintă un consens în legătură cu
ideea de comportament rezonabil. Asta înseamnă că, atunci când apar
probleme, situația poate să deterioreze rapid de vreme ce participanților
le lipsește un set de reflexe culturale la care să recurgă pentru
rezolvarea diferențelor.Această carte nu este un ghid practic, nu un studiu antropologic
sau o istorie. Totuși e nevoie de cunoașterea originilor culturii
free software din ziua de astăzi pentru a crea orice fel de sfaturi
practice. O persoană care înțelege cultura poate să ajungă departe în
lumea open-source, întâlnind multe variații locale în obiceiuri și
dialect, rămânând capabilă să participe confortabil și efectiv oriunde.
O persoană care nu înțelege această cultură va considera procesul de
organizare sau participare la un proiect dificil și plin de surprize.
De vreme ce numărul de oameni care dezvoltă software gratuit crește
cu salturi și limite, există mulți oameni în această a doua categorie
—aceasta este, în mare, o cultură a imigranților recenți și va fi
la fel timp de ceva vreme. Dacă vă considerați a fi unul dintre ei,
următoarea secțiune furnizează informațiile de bază pentru discuțiile
pe care le veți întâlni ulterior, atât în această carte cât și pe Internet.
(Pe de altă parte, dacă deja lucrați cu software open-source de ceva
vreme, s-ar putea să știți deja destule despre istoria mișcării așa
că puteți sări liniștiți peste această secțiune.)IstorieFolosirea de software în comun există de aproape la fel de mult
ca și noțiunea de software în sine. În primele zile ale calculatoarelor
fabricanții au simțit că avantajele competitive puteau să apară doar
în inovația hardware și nu au fost atenți la folosirea software-ului ca
un bun comercial. Mulți dintre clienții pentru aceste mașini timpurii
erau oameni de știință sau tehnicieni care erau capabili să modifice sau
să extindă aplicațiile care erau livrate cu mașinile. Clienții uneori
distribuiau propriile patch-uri nu doar producătorului ci și
proprietarilor unor sisteme similare. Producătorii de multe ori tolerau
și chiar încurajau acest fenomen: în ochii lor, îmbunătățirile aduse
soft-ului, indiferent de sursa de proveniență, făceau mașinile mai
atractive pentru potențialii clienți.Deși această perioadă seamănă cu ceea ce se întâmplă astăzi în
cultura software-ului gratuit, diferă în două aspecte cruciale. În primul
rând, încă nu exista o standardizare a hardware-ului—era o perioadă
de înflorire pentru inovația în design-ul calculatoarelor, dar
diversitatea arhitecturilor de calcul însemna că totul era incompatibil
cu orice altceva. Astfel, aplicațiile scrise pentru o mașină nu funcționau
pe altele. Programatorii acumulau expertiza într-o arhitectură sau o
familie de arhitecturi (în ziua de astăzi devin experți într-un limbaj
de programare sau într-o familie de limbaje de programare, știind că
expertiza lor va fi ușor de transferat pe orice arhitectură hardware cu
care au ocazia să lucreze). Pentru că experiența era specifică unui
anumit tip de calculator, acumularea de expertiză avea efect asupra
atractivității calculatorului pentru persoana respectivă și colegii ei.
Astfel, era în cel mai bun interes al producătorului să se disemineze
cât mai departe codul și cunoștințele specifice unei anumite mașini.În al doilea rând, nu exista Internet. Deși existau mai puține
restricții legale decât în ziua de astăzi, existau mai multe de ordin
tehnic: modalitățile de a transfera date dintr-un loc în altul erau
neconvenabile și greoaie în comparație cu ziua de astăzi. Existau niște
rețele micil, locale, bune pentru diseminarea informației între angajații
de la același laborator de cercetare sau dintr-o companie. Dar existau
bariere de depășit dacă o persoană ar fi vrut să împartă ceva cu toată
lumea, indiferent unde se aflau. Aceste bariere erau depășite
în multe cazuri. Uneori diferite grupuri intrau în legătură
unele cu altele în mod independent, trimițând dischete sau casete prin
poștă, uneori fabricanții serveau ei înșiși ca și puncte centrale de
transmisie a patch-urilor. A fost de ajutor și faptul că mulți dintre
primii dezvoltatori software lucrau la universități unde era de așteptat
ca fiecare să-și publice cunoștințele. Dar realitatea de ordin fizic în
transmiterea datelor însemna că întotdeauna exista un obstacol în calea
distribuției, o problemă direct proporțională cu distanța (dificultăți
reale sau de ordin organizațional) pe care aplicația trebuia să o parcurgă
până la destinație. Nu era posibilă împărțirea pe scară largă, cum se
întâmplă în ziua de astăzi.Apariția software-ului proprietar și a celui gratuitPe măsură ce industria s-a maturizat, mai multe schimbări
interrelaționale au avut loc simultan. Diversitatea modelelor hardware
a făcut loc câtorva câștigători—prin tehnologie superioară,
marketing superior sau o combinație a celor două. În același timp, și
nu în întregime printr-o coincidență, dezvoltarea așa-numitelor limbaje
de programare "de nivel înalt" însemna că se puteau scrie programe o
singură dată, într-un limbaj, care să fie apoi traduse automat
("compilate") pentru a rula pe diferite tipuri de calculatoare.
Implicațiile acestui fapt nu au rămas necunoscute pentru producătorii
de hardware: un client putea acum să inițieze un proiect de inginerie
software de mare anvergură fără a fi nevoie să rămână blocați într-o
anumită arhitectură de calculator. Când acest lucru s-a combinat cu
reducerea treptată a diferenței de performanță dintre diferitele
calculatoare, pe măsură ce modelele mai puțin eficiente au dispărut,
un producător care își trata hardware-ul ca fiind singurul bun comercial
aflat la dispoziție putea să se aștepte la o descreștere a ratei
profitului în viitor. Puterea de calcul pură devenea un bun fungibil
pe când software-ul devenea un diferențiator. Vânzarea de aplicații, sau
cel puțin tratarea acestora ca o parte integrală a vânzării de hardware,
începea să pară o strategie bună.Asta însemna că producătorii trebuiau să impună mai strict reguli
de copyright asupra codului sursă. Dacă utilizatorii continuau pur și
simplu să împartă codul și să-l modifice liberi între ei, ar fi putut să
reimplementeze în mod independent unele dintre îmbunătățirile care
erau vândute acum ca și "valoare adăugată" de către furnizor. Mai rău,
codul putea să ajungă în mâinile concurenței. Ironia face ca acest
fenomen să aibă loc exact în perioada în care Internetul făcea primii
pași. Când împărțirea neobstrucționată a software-ului devenea posibilă
tehnic, schimbările din industria computerelor o făceau nedorită
economic, cel puțin din punctul de vedere al oricărei companii. Furnizorii
au închis aceste portițe prin refuzul de a permite accesul utilizatorilor
la codul care rula pe mașinile lor, sau prin impunerea unor
acorduri de nedivulgare a secretului care făceau utilizarea la comun
a codului imposibilă.Rezistența conștientăPe măsură ce lumea care efectua schimburi nelimitate de cod
dispărea încet, în mintea a cel puțin un programator s-a cristalizat
o contrareacție. Richard Stallman a lucrat în Laboratorul de Inteligență
Artificială de la Institutul de Tehnologie din Massachusetts în anii '70
și la începutul anilor '80, în timpul a ceea ce s-a dovedit a fit epoca
de aur și locul potrivit pentru folosirea în comun a codului. Laboratorul
de Inteligență Artificială avea o „etică de lucru” puternică. Stallman folosește cuvântul „hacker” pentru a se referi la „cineva
căruia îi place să programeze și să facă lucrul acesta într-un mod
inteligent” și nu în sensul modern de „persoană care compromite
securitatea unui computer”. și oamenii nu erau
încurajați dar se aștepta de la ei să îi înștiințeze pe restul de
modificările pe care le făceau sistemului. După cum a scris mai târziu
Stallman:
Nu ne intitulam aplicațiile ca fiind „software
gratuit” pentru că termenul nu exista; dar asta era în realitate.
Oricând oamenii de la o altă universitate sau companie voiau să
transforme și să folosească un program, îi lăsam fericiți să o facă.
Dacă vedeai pe cineva care folosea un program necunoscut dar
interesant, puteai întotdeauna să ceri să vezi codul sursă astfel
încât să poți să-l citești, să-l modifici sau să folosești părți
din el pentru a face un nou program.
(sursa )
Această comunitate Edenică s-a prăbușit în jurul lui Stallman
puțin după 1980, când schimbările care aveau loc în restul industriei
au ajuns și în laborator. O companie start-up a angajat mulți dintre
programatorii Laboratorului pentru a lucra la un sistem de operare
asemănător cu ceea ce lucrau acolo numai că, de data aceasta, totul
se făcea sub o licență exclusivă. În același timp, Laboratorul achiziționa
echipament nou care venea cu un sistem de operare proprietar.Stallman observa modelul mare a ceea ce se întâmpla:
Calculatoarele moderne ale erei, cum ar fi VAX sau
68020, aveau propriile sisteme de operare dar niciunul dintre ele
nu era software gratuit: trebuia să semnezi un act de
confidențialitate numai pentru a obține o copie executabilă.
Asta însemna că primul pas pentru a folosi un
calculator era să promiți să nu-ți ajuți vecinul. Comunitatea
cooperantă era interzisă. Regula făcută de proprietarii soft-ului
proprietar era: „dacă împarți cu vecinii, ești un pirat; dacă vrei
modificări, imploră-ne să le facem.”
Printr-o ciudățenie de personalitate, el s-a decis să reziste
modei. În loc să lucreze în continuare la acum-decimatul Laborator de
Inteligență Artificială sau să-și ia o slujbă scriind cod la una dintre
noile companii, unde rezultatele muncii lui ar fi rămas închise într-o
cutie, a demisionat de la laborator și a inițiat Proiectul GNU și
Fundația pentru Software Gratuit (Free Software Foundation - FSF).
Scopul GNUvine de la „GNU is not Unix” — GNU nu
este Unix— și GNU în extensia aceasta vine de la... același lucru.
era să dezvolte un sistem de operare complet gratuit
și deschis și un corp de software în care utilizatorii nu erau niciodată
împiedicați să modifice codul sau să împartă modificările cu alții. El,
în esență, încerca să recreeze ceea ce se distrusese la laborator, dar la
o scară globală și fără vulnerabilitățile care făcuseră cultura
laboratorului AI susceptibilă la dezintegrare.Pe lângă faptul că lucra la un sistem de operare nou, Stallman a
creat o licență de copyright ai cărei termeni garantau faptul că
sursele aplicațiilor create urmau să fie întotdeauna libere. Licența
Generală Publică GNU (GPL) este o piesă inteligentă de judo legal: spune
că sursele pot fi copiate și modificate fără restricții și că atât copiile
cât și lucrările derivate (i.e. versiunile modificate) trebuie să fie
distribuite sub aceeași licență ca și originalul, fără niciun fel de
restricții adiționale. Prin urmare, folosește legea copyright-ului pentru
a obține un efect contrar aceluia al copyright-ului tradițional: previne
ca oricine, chiar și autorul, să poată să limiteze
accesul la cod. Pentru Stallman era mai bine decât să dea drumul codului
în domeniul public. Dacă ar fi fost proprietate din domeniul public, orice
copie particulară putea fi copiată într-un program proprietar (după cum
s-a întâmplat deja cu licențele de copyright puțin restrictive). În timp
ce această încorporare nu ar diminua deloc disponibilitatea codului
original, ar fi însemnat că eforturile lui Stallman puteau beneficia
dușmanului— software-ul proprietar. Licența GPL poate fi văzută ca
o formă de protecționism pentru software-ul gratuit pentru că previne ca
aplicațiile comerciale să folosească la maximum codul creat sub licență
GPL. Licența și relația ei cu alte licențe software sunt discutate în
detaliu în
.Cu ajutorul multor programatori, dintre care unii împărtășeau
ideologia lui Stallman iar alții pur și simplu voiau să vadă mult cod
gratuit disponibil, proiectul GNU a început să elibereze aplicații
gratuite care să înlocuuiască multe dintre componentele critice ale
unui sistem de operare. Mulțumită standardizării la scară largă care
exista deja, era posibil pentru a folosi aplicații GNU pe alte sisteme,
care nu erau gratuite, iar mulți oameni au ales să facă asta. Editorul
de text GNU (Emacs) și compilatorul C (GCC) aveau cel mai mare succes,
adunând mulți utilizatori nu pe motive ideologice ci datorită meritelor
lor tehnice. Până în jurul anului 1990, GNU produsese deja cea mai mare
parte a unui sistem de operare gratuit, cu excepția kernel-ului—
partea pe care mașina o inițializează la pornirea sistemului de operare
și care gestionează memoria, hard-disk-ul și alte resurse. Din păcate, proiectul GNU a ales un design de kernel care s-a
dovedit a fi mai greu de implementat decât se aștepta inițial. Întârzierea
care a urmat a împiedicat Fundația pentru Software Liber să lanseze primul
sistem de operare în întregime gratuit. Ultima bucată a fost pusă la
locul ei de Linus Torvalds, un student în calculatoare finlandez care,
cu ajutorul voluntarilor din jurul lumii, a terminat un kernel folosind
un design mai conservator. L-a denumit Linux și astfel, când l-a combinat cu
programele GNU existente, a rezultat primul sistem de operare complet
gratuit. Pentru prima dată puteai să-ți pornești calculatorul și
să faci asta fără a folosi niciun fel de software proprietar.
Din punct de vedere tehnic, Linux nu a fost primul. Un
sistem de operare gratuit pentru computere compatibile cu sistemul IBM,
numit 386BSD, a apărut cu puțin timp înainte de Linux. Totuși, era mult
mai greu de pornit 386BSD. Linux a avut un asemenea succes nu doar pentru
că era gratuit ci și pentru că avea o șansă bună de a reuși să pornească
atunci când îl instalai.O parte mare din software-ul acestui sistem de operare nou nu era
produs de proiectul GNU. De fapt, GNU nu nici măcar singurul grup
care lucra la crearea unui sistem de operare gratuit (de exemplu, codul
care a devenit ulterior NetBSD și FreeBSD deja era în curs de dezvoltare
la acest moment). Importanța Fundației pentru Software Gratuit nu era
doar în codul scris ci în retorica politică. Vorbind despre software liber
ca și despre o cauză în loc de un bun, au făcut destul de greu ca un
programator să nu aibă o poziție politică pe această
temă. Chiar și cei care nu erau de-acord cu Fundația erau nevoiți să
dezbată tema, chiar dacă numai pentru a susține o poziție diferită.
Eficiența Fundației ca și element de propagandă se afla în legarea codului
lor de un mesaj, cu ajutorul GPL și a altor texte. Pe măsură ce codul
lor se răspândea, se răspândea și acel mesaj.Rezistența accidentalăExistau destul de multe lucruri care se întâmplau pe scena nașterii
software-ului liber dar puține erau explicite în mod ideologic, cum era
proiectul GNU al lui Stallman. Unul dintre cele mai importante era
Berkeley Software Distribution
(BSD), o reimplementare treptată a sistemului de
operare Unix— care, până la sfârșitul anilor 70, era un proiect
de cercetare în mare parte proprietar al celor de la AT&T—de
către programatorii de la Universitatea din California de la Berkeley.
Grupul BSD nu făcea afirmații politice deschise despre nevoia ca
programatorii să se strângă la un loc și să împartă codul unii cu alții
dar ei practicau această idee cu fler și entuziasm,
coordonând un efort de dezvoltare distribuit masiv în care s-au rescris
de la zero toate utilitarele Unix de linie de comandă, librăriile de cod
și, ulterior, inclusiv nucleul sistemului de operare prin munca
voluntarilor. Proiectul BSD a devenit un exemplu de primă mână de
dezvoltare de software gratuit neideologică și a servit ca și teren de
antrenament pentru mulți dezvoltatori care urmau să rămână activi în
lumea open source.Un alt exemplu de dezvoltare cooperativă a fost primul
Sistem de ferestre X, un mediu de calcul grafic gratuit și
transparent la existența unei rețele, dezvoltat la MIT la mijlocul anilor
1980 în parteneriat cu producătorii hardware care aveau un interes comun
în a fi capabili să ofere clienților lor un sistem de ferestre. Departe
de a se opune software-ului proprietar, licența X permitea în mod
intenționat extensii proprietare peste miezul gratuit— fiecare
membru al consorțiului dorea să aibă ocazia de a extinde distribuția de
bază X și de a câștiga un avantaj competitiv peste alți membri. X Windows
Era preferat apelativul de "X Window System", dar, în
practică, oamenii îi spuneau doar "X Windows" pentru că trei cuvinte
erau prea multe. reprezenta, în sine, un software
gratuit dar era în principal un mod de a nivela terenul de joc între
interesele de afaceri aflate în concurență, nu o dorință de a termina
dominația software-ului proprietar. Un alt exemplu, care preceda GNU
cu câțiva ani, era TeX, sistemul gratuit de tehnoredactare pentru calitatea
publicației realizat de Donald Knuth. El l-a lansat cu o licență care
permitea oricui să modifice și să distribuie codul dar să nu denumească
rezultatul TeX decât dacă trecea de un set foarte strict de teste de
compatibilitate (acesta este un exemplu al unei clase de licențe
gratuite care „protejează marca”, discutate mai mult în
) Knuth nu era de o parte a barierei sau de alta
în lupta dintre software proprietar și liber, el avea nevoie doar de un
sistem mai bun de tehnoredactare pentru a-și realiza adevăratul
țel—o carte despre programarea calculatoarelor —
și nu vedea niciun motiv pentru care să nu pună sistemul lui la
dispoziția întregii lumi după ce era terminat.Fără a pune pe listă fiecare proiect și fiecare licență, putem
spune cu siguranță că, până la sfârșitul anilor 1980, exista deja destul
de mult software gratuit sub o gamă largă de licențe. Diversitatea
acestora din urmă reflecta o gamă largă de motive corespondente. Chiar
și unii dintre programatorii care au ales licența GNU GPL erau mult mai
puțin orientați ideologic decât proiectul GNU în sine. Deși le făcea
plăcere să lucreze la software gratuit, majoritatea nu considerau
aplicațiile proprietare ca fiind un rău social. Existau oameni care
simțeau un impuls moral de a scăpa lumea de „software hoarding” (termenul
lui Stallman pentru aplicațiile comerciale), dar alții erau mai motivați
de interesele tehnice sau de plăcerea de a lucra alături de colaboratori
care gândeau la fel sau pur și simplu dintr-o nevoie umană simplă de
glorie. Totuși, aceste motivații diverse nu prea interacționau în moduri
destructive. Aceasta se datorează în mare parte faptului că, spre
deosebire de proză sau arte vizuale, software-ul trebuie să treacă de
teste obiective pentru a fi considerat de succes: trebuie să ruleze și să
fie, în mare parte, lipsit de erori. Asta dă majoritatea participanților
la un proiect un fel de teren comun automat, un motiv și o fundație pentru
colaborare fără a-și face prea multe griji pentru altfel de calificări
decât cele de ordin tehnic.Dezvoltatorii mai aveau un motiv pentru a rămâne împreună: s-a
dovedit că în lumea software-ului liber se producea niște cod de calitate
foarte bună. În unele cazuri, s-a demonstrat a fi tehnic superior celor
mai apropiate alternative comerciale; în alte cazuri era cel puțin
comparabil dar costa întotdeauna mai puțin. Deși doar puțini oameni erau
motivați să ruleze software gratuit din rațiuni pur filosofice, mulți
oameni erau bucuroși să-l folosească pentru că făcea o treabă mai bună.
Dintre cei care îl foloseau, unii erau întotdeauna dornici să-și doneze
timpul și abilitățile pentru a ajuta la întreținerea și îmbunătățirea
aplicațiilor.Această tendință de a produce cod bun nu era, desigur, universală
dar se întâmpla cu o frecvență crescândă în proiectele libere din jurul
lumii. Afacerile care depindeau din greu de software au început să
observe acest fenomen. Multe dintre ele au descoperit că deja foloseau
astfel de aplicații în funcționarea de zi cu zi și nu au știut (conducerea
nu știe întotdeauna ce se întâmplă în departamentele de IT). Corporațiile
au început să ia o poziție publică și mai activă în dezvoltarea de
proiecte libere, contribuind timp și echipament, uneori chiar finanțând
în mod direct dezvoltarea de aplicații gratuite. Astfel de investiții
puteau, în cele mai bune cazuri, să se răsplătească de mai multe ori.
Sponsorul plătește doar un număr mic de programatori experți care să
se dedice proiectului full-time dar câștigă de pe urma beneficiilor
aduse de contribuția oricui, inclusiv de pe urma
muncii realizate de voluntari neplătiți și chiar de programatori
plătiți de alte corporații."Gratuit" Versus "Sursă deschisă"Pe măsură ce lumea corporatistă dedica din ce în ce mai multă
atenție software-ului gratuit, programatorii se loveau de o noi probleme
cu prezentarea. Una dintre acestea era cuvântul „gratuit” în sine. La
auzul cuvintelor „software gratuit” mulți oameni se gândesc doar la
„software fără cost”. E adevărat că toate aplicațiile libere sunt
lipsite de costse poate cere o taxă pentru copii
de software liber dar, cum nu se poate impune celui care îl ia să nu
îl dea mai departe fără cost, prețul scade la zero imediat. dar nu tot software-ul gratuit e complet liber. De exemplu,
în timpul „bătăliei browserelor” din anii 1990, atât Netscape cât și
Microsoft își ofereau browserele fără cost, în graba de a câștiga cotă
de piață. Niciunul dintre browsere nu era liber. Nu se putea face rost
de codul sursă al aplicației și, chiar dacă ai fi reușit, nu aveai dreptul
de a îl modifica sau redistribui.Codul sursă al aplicației
Netscape Navigator a fost, în cele din urmă, eliberat
sub o licență open-source în 1998 și a devenit fundația pentru
browser-ul web Mozilla. Vezi . Nu se putea face mai
mult decât să downloadezi un executabil și să îl rulezi. Browserele nu
erau mai libere decât software-ul care se putea cumpăra din magazine; pur
și simplu aveau un preț mai mic.Această confuzie datorată termenului „free” se datorează
unei ambiguități nefericite din limba Engleză. Majoritatea limbilor fac
distincția între prețul mic și libertate (diferența dintre
gratis și libre este clară
tuturor vorbitorilor de limbi romanice, de exemplu). Dar poziția
limbii engleza ca și limbă care unește de facto Internetul înseamnă că
o problemă cu limba engleză este, într-o anumită măsură, o problemă
pentru toată lumea. Confuzia creată în jurul acestui termen a fost atât
de mare încât programatorii de software liber și-au creat un răspuns
standard: „E liber ca în
liberate—gândiți-vă la libertatea
cuvântului și nu la bere gratuită."
Totuși, necesitatea de a explica încă și încă o dată acest lucru e
obositoare. Mulți programatori au simțit, cu un anumit grad de
justificare, că natura ambiguă a cuvântului „free” îngreuna înțelegerea
publicului pentru acest tip de software.Dar problema mergea mai adânc de atât. Cuvântul „free” aduce cu el
o conotație morală de care nu se poate scăpa: dacă libertatea era un
scop, nu conta dacă software-ul liber era și mai bun sau mai profitabil
pentru anumite afaceri în anumite condiții. Acesta era pur și simplu un
efect secundar plăcut al unei motivații care, la origini, nu era nici
tehnică nici mercantilă ci morală. Mai departe, poziția de „liber ca și
în cuvântul libertate” a forțat corporațiile care voiau să sprijine
anumite programe libere să fie inconsistente într-o parte din afacerile
lor în timp ce continuau să vândă software proprietar în alta.
Aceste dileme s-au pus unei comunități care se afla deja în fața
unei crize de identitate. Programatorii care
scriu software liber nu au avut niciodată o singură
părere despre scopul per ansamblu, dacă există un astfel de scop, al
mișcării pentru software liber. Chiar dacă am spune că părerile trec
dintr-o extremă într-alta tot am induce în eroare deoarece am sugera
că avem de-a face cu un domeniu liniar când, în realitate, avem o
împrăștiere multidimensională. Totuși, două categorii largi de păreri pot
fi distinse, dacă dorim să ignorăm temporar nuanțele. Un grup e de
părerea lui Stallman, că libertatea de a distribui și modifica e cea mai
importană și că, de aceea, dacă nu se mai vorbește de libertate s-a
pierdut elementul central. Alții cred că software-ul însuși este cel
mai important argument în favoarea lui și nu se simt confortabil în a
cataloga software-ul proprietar ca fiind rău din oficiu. Unii, dar nu
toți, dintre programatorii de software liber cred că autorul (sau
angajatorul, în cazul muncii plătite)
ar trebui să aibă dreptul de a controla termenii
sub care e permisă distribuirea și că nu trebuie să fie atașată o
judecată morală alegerii unor anumiți termeni.Pentru multă vreme, aceste diferențe nu trebuiau să fie atent
examinate sau articulate, dar succesul software-ului liber în lumea
afacerilor au făcut tema imposibil de evitat. În 1998, termenul
open source a fost creat ca o alternativă
la „liber” de către o coaliție de programatori care au devenit în cele
din urmă Inițiativa Open-Source (OSI).
OSI se găsește pe Internet la adresa . OSI consideră
nu doar că termenul „free software” poate cauza confuzie dar și că
folosirea cuvântului „free” e doar o simptomă a problemei generale:
că mișcarea are nevoie de un program de marketing pentru a se lega de
lumea corporatistă și că discuția despre moralitate și beneficiile sociale
ale distribuirii gratuite nu ar avea niciodată succes în sălile de ședință
corporatiste. În propriile lor cuvinte:
Inițiativa Open-Source este un program
de marketing pentru software liber. E un teren de tratare a
software-ului liber pe un teren solid și pragmatic în locul
ideologiilor extremiste. Elementul câștigător nu s-a schimbat
ci doar atitudinea și simbolismul care duceau la înfrângere.
...Explicația care trebuie dată majorității celor
din domeniul tehnic nu este despre conceptul open source ci
despre nume. De ce să nu se numească, așa cum a fost în mod
tradițional, software liber?Un motiv este că termenul de software liber
poate fi ușor înțeles în moduri care generează conflict.
;...Dar adevăratul motiv pentru re-etichetare
este unul de marketing. Noi încercăm să lansăm un nou concept
către lumea corporatistă. Avem un produs câștigător, dar poziționarea
noastră din trecut a fost groaznică. Termenul de software liber
a fost prost înțeles de către oamenii de afaceri, care confundă
dorința de a îpărți cu alții cu anti-comercialismul sau, chiar mai
rău, cu furtul.Directorii și responsabilii tehnici ai corporațiilor
nu vor cumpăra niciodată software liber. Dar dacă luăm aceeași
tradiție, aceiași oameni și aceleași licențe pentru software liber
și schimbăm eticheta în „open source”? Așa ceva vor cumpăra.
Unora dintre hackeri li se va părea greu de crezut
așa ceva dar asta e doar pentru că ei sunt oameni tehnici, care
gândesc în termeni concreți, cu substanță, și nu înțeleg
cât de importantă e imaginea atunci când vinzi ceva.
În marketing, învelișul reprezintă realitatea.
Imaginea pentru care suntem dispuși să coborâm de pe baricade
și să lucrăm pentru lumea corporatistă contează la fel de mult
ca și realitatea comportamentului nostru, a convingerilor
noastre și a software-ului nostru.(din
și )
Vârfurile mai multor iceberg-uri de controversă sunt vizibile
în acest text. Se referă la „convingerile noastre” dar evită în mod
inteligent să scrie care sunt acestea. Pentru unii, ar putea fi convingerea
că aplicațiile dezvoltate într-un proces deschis vor fi mai de calitate;
pentru alții, convingerea că toată informația trebuie să fie distribuită
liber. Termenul de „furt” se folosește pentru referirea la copierea
(presupusă) ilegală—o întrebuințare la care există multe obiecții,
motivând că nu e furt dacă proprietarul original încă are obiectul
după copiere. Există o indicație că mișcarea pentru software liber poate
fi acuzată în mod greșit de anti-comercialism dar textul lasă
neexaminată întrebarea dacă o astfel de acuzație are vreo bază reală.
Nu trebuie înțeles că site-ul OSI e inconsistent sau că induce în
eroare Mai degrabă, e un exemplu a ceea ce OSI susține că a lipsit
din mișcarea pentru software liber:marketing-ul bun, unde „bun” înseamnă
viabil în mediul de afaceri. Inițiativa open-source a dat multor oameni
exact ceea ce căutau—un vocabular care să le permită să vorbească
despre software-ul liber ca de o metodologie de dezvoltare și o strategie
de afaceri în loc de o cruciadă morală.Apariția inițiativei open-source a schimbat mediul software-ului
liber. A formalizat o dihotomie care era de multă vreme nenumită și
astfel a forțat mișcarea să accepte faptul că ea are atât politici
interne cât și externe. Efectul în ziua de astăzi este că amândouă taberele
trebuie să găsească un teren comun, de vreme ce majoritatea proiectelor
includ programatori veniți din ambele tabere și participanți care nu
aparțin clar niciunei categorii. Asta nu înseamnă că oamenii nu vorbesc
niciodată de motivația morală—de exemplu, de multe ori sunt aduse
în discuție lipsuri din tradiționala „etică a hacker-ului”. Dar rareori
un dezvoltator de software liber/cu surse deschise va provoca motivațiile
de bază ale altor participanți la un proiect. Contribuția e mai importantă
decât contribuitorul. Dacă o persoană scrie cod bun, nu îi întrebi dacă
o fac din motivație morală sau pentru că pentru asta i-a plătit angajatorul
sau pentru că își construiesc un curriculum vitae sau pentru alte motive.
Le evaluezi contribuția în termeni tehnici și le răspunzi tot în termeni
tehnici. Chiar și organizațiile politice în mod explicit, cum ar fi
proiectul Debian, al cărui scop e de a oferi un mediu de lucru 100%
liber (cu sensul de „liber ca și în libertate”) sunt destul de relaxate
când vine vorba de integrarea cu cod non-liber și colaborarea cu
programatori care nu împărtășesc întocmai acest scop.Situația astăziCând conduci un proiect de software liber, nu trebuie să discuți
probleme filosofice atât de dificile zilnic. Porgramatorii nu vor insista
ca toată lumea care participă la proiect să fie de-acord cu modul în
care văd ei lucrurile (cei care insistă descoperă repede că nu pot
lucra la niciun proiect). Dar trebuie să fii conștient de diferența dintre
„liber” și „cu surse deschise”, în special pentru a evita să spui lucruri
care ar putea fi potrivnice unor participanți dar și pentru că înțelegerea
motivațiilor dezvoltatorilor este cel mai bun mod—dacă nu chiar
singurul
mod—de a conduce un proiect.Software-ul liber este o cultură proprie. Pentru a te integra
cu succes în ea, trebuie să înțelegi de ce oamenii au ales să facă parte
din ea în primul rând. Tehnicile coercitive nu vor funcționa. Dacă
oamenii sunt nefericiți într-un proiect, vor trece imediat la altul.
Software-ul liber e remarcabil chiar și între comunitățile de voluntari
pentru ușurința de a investi. Majoritatea persoanelor implicate nu s-au
întâlnit niciodată cu celelalte persoane față în față și pur și simplu
donează bucăți din timpul lor atunci când au chef. Circuitele normale
prin care oamenii se leagă unii de alții și creează grupuri statornice
sunt reduse la un canal minuscul: cuvântul scris, transmis prin fire de
curent electric. Din acest motiv, poate dura ceva vreme până se creează
un grup strâns și dedicat. Invers, e foarte ușor pentru ca un proiect
să piardă un potențial voluntar în primele cinci minute de făcut
cunoștință. Dacă un proiect nu lasă o primă impresie bună, nou-veniții
rareori îi dau o a doua șansă.Caracterul efemer, sau potențiala
efemeritate a relațiilor este, poate, cea mai dificilă problemă aflată
în calea unui nou proiect. Ce îi va convinge pe toți acești oameni
să stea împreună suficient de mult timp încât să producă un lucru util?
Răspunsul la această întrebare este destul de complex încât să ocupe restul
acestei cărți dar, dacă ar trebui să fie exprimat într-o singură
propoziție, ea ar fi aceasta:
Oamenii trebuie să simtă că legătura lor cu un
proiect și influența asupra acestuia este direct proporțională cu
contribuția lor.
Niciun grup de dezvoltatori, sau de potențiali dezvoltatori, nu ar
trebui să se simtă ignorat sau discriminat din motive non-tehnice. În mod
clar, proiectele cu sponsorizare corporatistă și/sau dezvoltatori
salariați trebuie să aibă foarte mare grijă în acest sens, după cum se
discută în detaliu aici: . Desigur, asta nu
înseamnă că, dacă nu există finanțare corporatistă, nu există niciun motiv
de îngrijorare. Banii reprezintă doar unul dintre mulții factori care pot
afecta succesul unui proiect. Există și întrebări legate de limbajul
care va fi folosit, de licență, procesele de dezvoltare, ce fel de
infrastructură se pune la punct, cum se face publicitate începerii
proiectului și multe altele. Cum se începe un proiect cu dreptul înainte
se dezbate în capitolul următor
.