Cum a fost creat Linux? Procesele din spatele gestionării a 13.500 de dezvoltatori

Probabil că ați folosit Linux astăzi – mai ales dacă nu aveți un iPhone. Și dacă ați navigat pe internet astăzi, există o mare probabilitate ca și site-ul web pe care l-ați vizitat să fi fost deservit de Linux.

Linux este un sistem de operare, dar, spre deosebire de software precum Microsoft Windows și macOS, Linux a fost dezvoltat de o comunitate autoorganizată de voluntari.

De-a lungul timpului, cu efortul a peste 10.000 de dezvoltatori și cu procese în evoluție pentru a gestiona amploarea muncii, nucleul Linux a crescut la peste 20.000.000 de linii de cod în total. Acesta formează fundația stabilă pentru…

• Toate telefoanele și tabletele Android de pe planetă
• 66% din serverele din lume
• 100% din primele 500 de supercalculatoare

Această tehnologie nu a venit de la o echipă orchestrată cu o carte de politici groasă și straturi de management. Ea a venit de la câteva politici atent alese și integrate cultural și de la o misiune comună.

În această postare, analizez modul în care o tehnologie atât de esențială, complexă și importantă a putut fi produsă atât de eficient fără o structură de management tradițională. Dar mai întâi…

De ce este nucleul Linux atât de impresionant?

Un nucleu este chiar nucleul unui sistem de operare. Este orchestratorul tuturor celorlalte procese software de pe computerul sau smartphone-ul dumneavoastră, împărțind resursele și oferind o modalitate de comunicare între hardware și software.

În cuvintele lui G. Pascal Zachary, nucleul unui sistem de operare poate fi comparat cu „un șef de personal casnic care era atât de sârguincios încât servea familia de la etaj în orice moment, noaptea sau ziua la datorie, rezolvând orice solicitare”. Kernelul face ca mașina să funcționeze, indiferent de ceea ce întâmpină. A fost un salt esențial de la lumea în care computerele puteau rula o singură aplicație la un moment dat, la lumea pe care o cunoaștem astăzi.

Kernelul Linux, bazat pe UNIX, a fost dezvoltat la începutul anilor 1990 de Linus Torvalds.

Până în 1991, Torvalds a lansat prima versiune – doar 10.000 de linii de cod – și a stârnit entuziasmul comunității de dezvoltare de software cu umilul anunț prin e-mail văzut mai sus.

Puterniciți de puterea de colaborare a internetului pentru prima dată în istorie, dezvoltatorii au contribuit gratuit cu propriile abilități de codificare și timp de testare, în timp ce baza de utilizatori a kernelului a explodat în mărime. Dacă erau dispuși să experimenteze, utilizatorii puteau să încerce să pună laolaltă un patch dacă descopereau că ceva era stricat și să discute despre cum să îmbunătățească software-ul.

Așa cum Eric S. Raymond analizează în cartea sa despre software-ul open source timpuriu, The Cathedral and The Bazaar (Catedrala și bazarul), managementul dezvoltatorilor de kernel al lui Linus Torvalds a ajuns să fie eficient, auto-organizat și mai mult decât capabil să producă probabil una dintre cele mai complexe și mai utilizate bucăți de software de pe planetă.

În acest articol, analizez procesele și politicile care au apărut ca suport necesar pentru proiectul kernelului Linux, pe măsură ce acesta a evoluat de-a lungul anilor.

Cum, fără un proces formal, pe când era un student la informatică în vârstă de 21 de ani, Torvalds a ghidat proiectul kernelului până la înălțimile pe care le-a atins…

…Și totuși, ce este atât de greu în a gestiona dezvoltatorii?

Potrivit unei cercetări efectuate de Geneca, peste 75% dintre directorii de afaceri și IT cred că proiectele lor software sunt sortite eșecului. Dificultatea de a produce software fiabil și de a-i gestiona pe cei care o fac a dat naștere la nenumărate cărți de management, studii de productivitate și cadre de conducere.

„Complexitatea pură a software-ului înseamnă că este imposibil să testezi fiecare cale”, scrie Paul Smyth, CEO-ul Kynetix, pe Finextra. „O aplicație software este ca un iceberg – 90% din ea nu este vizibilă. Complexitatea majoră a aplicației se află sub linia de plutire”.

Care proiect software de dimensiuni semnificative, fie că este vorba de un CRM sau de un sistem de operare precum Microsoft Windows, este prea mare pentru a încăpea în capul unei singure persoane. Necesită cunoștințele comune și colaborarea mai multor colaboratori. Acest lucru înseamnă că dezvoltatorii lucrează la părți specializate ale aplicației, trebuind în același timp să înțeleagă modul în care munca lor afectează întregul.

„Nicio minte nu poate cuprinde totul”, a remarcat managerul unei echipe de 250 de dezvoltatori de software Microsoft în timp ce construiau un sistem de operare de la zero, potrivit lui G. Zachary în Show stoppers! o carte care spune povestea unei echipe de dezvoltatori de software Microsoft care se grăbea să finalizeze Windows NT în 1993.

Cu cât proiectul este mai mare, cu atât mai lent pot fi implementate schimbările. Cercetările lui Steve McConnell dovedesc acest lucru, constatând că codul este scris într-un ritm de 5-10 ori mai lent în proiectele de peste 10.000.000 de linii. Mai mult, un studiu al practicilor de dezvoltare ale Microsoft a dezvăluit că există aproximativ 10-20 de bug-uri pentru fiecare 1.000 de linii de cod.

În ciuda dimensiunii proiectului și a numărului de contribuitori, dezvoltarea nucleului Linux are loc rapid, iar baza sa mare și entuziastă de utilizatori prinde bug-uri și scrie patch-uri pentru a livra rapid îmbunătățiri.

În primele zile de dezvoltare – în jurul anului 1991 – nu era ceva neobișnuit ca Torvalds să lanseze mai mult de un nou nucleu pe zi. Acum, aflat într-un stadiu mai matur și de care depind 80% dintre smartphone-uri și majoritatea serverelor de internet, perioada de lansare dorită este de 8 până la 12 săptămâni. La fiecare lansare, nucleul vede în medie 10.000 de patch-uri de la 2.000 de dezvoltatori – toți luptându-se cu peste 20.000.000 de linii de cod.

Care sunt tehnicile și procesele de management necesare pentru a orchestra acest nivel de colaborare și productivitate? Ei bine, ele nu au fost redactate de un șef de departament sau de un autor de carte de afaceri. Ele s-au dezvoltat organic, sub îndrumarea „dictatorului binevoitor” al proiectului, Linus Torvalds.

Încă în forma sa incipientă, la nucleul Linux colaborau sute de voluntari care își trimiteau lucrările direct lui Torvalds pentru revizuire. Cum a reușit un hacker irascibil și antisocial să gestioneze disputele, contribuțiile și comunicarea între mii de dezvoltatori timp de aproape două decenii?

Cum sunt documentate politica, procesul și 15.000.000 de linii de cod

În mod diferit de o organizație tradițională, noii dezvoltatori de kernel nu sunt strict „îmbarcați” în comunitate, ci se așteaptă de la ei să fi citit și înțeles pe deplin documentația introductivă. Accentul pus de proiectul kernel pe documentație a fost o necesitate atât din cauza complexității tehnice, cât și a numărului mare de dezvoltatori.

Numeroase întrebări frecvente, instrucțiuni și ghiduri de inițiere există în depozitul de documentație al kernelului și chiar mai multe în wiki-urile create și întreținute de dezvoltatorii kernelului din întreaga lume.

Modul în care este scrisă și îmbunătățită documentația reflectă modul în care este dezvoltat kernelul; în mod colaborativ, deschis și incremental.

Prin valorificarea globilor oculari și a specializărilor unui grup uriaș de oameni, documentația poate fi creată, testată și revizuită mult mai eficient decât dacă ar fi realizată de o echipă mai mică, dedicată. Pentru a plia legea lui Linus în termeni pe care un editor de conținut i-ar putea înțelege mai bine: cu suficienți globi oculari, toate greșelile de scriere sunt evidente.

Pe lângă materialele de suport tehnic, comunitatea de dezvoltare a kernelului a creat o bibliotecă de documentație de proces, concepută pentru a netezi latura umană a colaborării.

Pe pagina de index a „Ghidului pentru procesul de dezvoltare a kernelului”, un paragraf spune:

„Scopul acestui document este de a ajuta dezvoltatorii (și managerii lor) să lucreze cu comunitatea de dezvoltare cu un minim de frustrare. Este o încercare de a documenta modul de lucru al acestei comunități într-un mod accesibil celor care nu sunt familiarizați îndeaproape cu dezvoltarea kernelului Linux (sau, de fapt, cu dezvoltarea de software liber în general).”

Nimeni nu se naște cu o cunoaștere înnăscută a sistemului de control al versiunilor git, sau cum să trimită un patch la o listă de discuții. De aceea, procesul de dezvoltare trebuie să fie documentat – explicarea acelorași informații de bază unei singure persoane la un moment dat nu se scalează!”

Cum este gestionată comunicarea între 1000 de dezvoltatori

Conversațiile dintre dezvoltatori au avut loc în aer liber, în listele de discuții pentru dezvoltarea kernelului. Până în ziua de azi, e-mailul este încă instrumentul preferat datorită simplității sale. Aceste liste de discuții au fost arhivate și organizate, alcătuind un corp de documentație și istorie vie.

Efectul comunicării în public are un efect similar cu beneficiile utilizării unui instrument precum Slack în zilele noastre – orice informație este pusă în siguranță și poate fi căutată, în loc să se evapore. Cu toate acestea, pentru a gestiona un astfel de furtun de informații, proiectul kernel a dezvoltat o politică de comunicare și a distribuit-o ca parte a documentației.

Comunicarea și colaborarea la o asemenea scară nu erau posibile înainte de internet, așa că primele proiecte ca acesta trebuiau să scrie și să distribuie soluții rapide și eficiente pentru problemele de gestionare a comunității, de etichetă și de prezentare a codului.

Documentația kernelului include reguli pentru trimiterea de patch-uri, astfel încât să fie mai ușor pentru alții să revizuiască, să editeze și să testeze codul contribuit. Aceasta înseamnă că patch-urile trebuie să fie trimise prin e-mail în text simplu, nu atașate. Patch-urile trebuie să se limiteze la o singură dată pe e-mail și să respecte liniile directoare specifice privind stilul de codare:

Această standardizare rigidă este absolut necesară pentru un proiect atât de mare precum kernelul, așa cum este și pentru proiectele de orice dimensiune. Ajută la reducerea erorilor într-un spațiu în care o singură eroare poate avea un efect de undă care produce cod instabil în viitor, sau irosește timpul multor testeri și dezvoltatori.

Cum se iau (nu se iau) deciziile critice

Pentru a-l cita pe Torvalds:

„Numele jocului este să eviți să fii nevoit să iei o decizie. În special, dacă cineva îți spune „alege (a) sau (b), chiar avem nevoie ca tu să te decizi în această privință”, ai probleme ca manager. Oamenii pe care îi conduci ar fi bine să cunoască detaliile mai bine decât tine, așa că, dacă vin la tine pentru o decizie tehnică, ești terminat. Este clar că nu ești competent să iei acea decizie în locul lor.” – Documentația de dezvoltare a nucleului Linux Kernel

Pe lângă faptul că a evitat o ierarhie managerială, proiectul Linux a avut reguli și documentație clare care au ajutat la luarea deciziilor fără a fi nevoie de discuții, dezbateri sau (multe) războaie de foc pe listele de discuții. O privire în arhive vă va arăta că partea cu războiul de flăcări nu este întotdeauna posibilă, dar ceea ce este posibil este crearea unei politici care să anuleze povara deciziei.

„Astfel, cheia pentru a evita deciziile mari devine doar evitarea de a face lucruri care nu pot fi anulate. Nu vă lăsați împinși într-un colț din care nu puteți scăpa. Un șobolan încolțit poate fi periculos – un manager încolțit este pur și simplu jalnic.”

Show Stoppers! dezvăluie că filozofia lui Bill Gates este similară. El „admira programatorii și îi punea invariabil în fruntea proiectelor, unde puteau atât să gestioneze, cât și să programeze, pentru a evita o situație în care managerii profesioniști, fie fără experiență în programare, fie cu cunoștințe depășite, dețineau controlul”.

Cum sunt orientați contributorii în jurul unui obiectiv comun puternic

În cazul Linux, așa cum se întâmplă în cazul multor proiecte populare cu sursă deschisă, nucleul nu a apărut după ce a fost proiectat în colaborare de un grup mare de contribuitori; mai degrabă, a fost îmbunătățit treptat, fără a se lua decizii care să destabilizeze baza solidă de lucru de până atunci. Acest lucru se leagă foarte bine de filozofia lui Torvalds privind luarea deciziilor în management, dar și de o filozofie încorporată în codul însuși.

Linux se bazează pe UNIX, care este un sistem de operare anterior conceput în jurul unui set de principii de tip zen. Așa cum se afirmă în mod explicit în filosofia UNIX:

„Proiectați și construiți software, chiar și sisteme de operare, pentru a fi testate devreme, în mod ideal în câteva săptămâni. Nu ezitați să aruncați părțile neîndemânatice și să le reconstruiți.”

Atât Torvalds, cât și Raymond (care a căutat să reproducă succesul de construire a comunității lui Torvalds) au descoperit că lansarea timpurie și frecventă a ajutat la ralierea contribuitorilor în jurul unui proiect interesant, în creștere, în care aceștia pot vedea un viitor. Raymond a redus totul la două lucruri cheie pe care un proiect nu poate să nu le facă atunci când este lansat în lume:

1. Run
2. Convinge potențialii co-dezvoltatori (utilizatori) că proiectul poate evolua în curând în ceva măreț

Cu aceleași principii se lansează multe dintre start-up-urile de astăzi – inclusiv Process Street:

Acesta este Process Street în 2014. Înscrieți-vă pentru un cont pentru a vedea cât de departe am ajuns.

Este acesta un proces repetabil?

La suprafață, reunirea bruscă a uneia dintre cele mai complicate creații umane pare a fi o alchimie. Dar, despărțind componentele, este mai ușor de observat un proces subiacent. În momentul în care a scris „The Cathedral and The Bazaar”, Eric S. Raymond conducea în același timp dezvoltarea unui client de e-mail open source. Prin deschiderea acestuia, Raymond încerca să reproducă implicarea comunității și succesul final al proiectului kernel.

Multe dintre principiile de bază ale modelului Bazaar, așa cum a fost inventat de el, vor fi imediat familiare oricui din lumea start-up-urilor:

• Care lucrare bună de software începe prin a zgâria mâncărimea personală a unui dezvoltator.
• Tratarea utilizatorilor dvs. ca și co-dezvoltatori este calea cea mai puțin complicată spre îmbunătățirea rapidă a codului și depanarea eficientă.
• Relake early. Eliberați des. Și ascultați-vă clienții.
• Dacă dispuneți de o bază suficient de mare de beta-testeri și co-dezvoltatori, aproape fiecare problemă va fi caracterizată rapid și soluția va fi evidentă pentru cineva.
• Dacă vă tratați beta-testerii ca și cum ar fi cea mai valoroasă resursă, ei vor răspunde devenind cea mai valoroasă resursă.
• Cel mai bun lucru după a avea idei bune este să recunoști ideile bune de la utilizatorii tăi. Uneori, aceasta din urmă este mai bună.
• De multe ori, cele mai izbitoare și inovatoare soluții vin din realizarea faptului că conceptul dvs. de problemă era greșit.
• Pentru a rezolva o problemă interesantă, începeți prin a găsi o problemă care este interesantă pentru dvs.
• Cu condiția ca coordonatorul de dezvoltare să dispună de un mijloc de comunicare cel puțin la fel de bun ca internetul și să știe cum să conducă fără constrângere, mai multe capete sunt inevitabil mai bune decât unul singur.

În concluzie, este un proces repetabil. Și unul care a fost adoptat cu succes din lumea surselor deschise în mentalitatea startup. Se manifestă în agile, lean, six sigma și în atitudinile și politica pe care le-au dezvoltat startup-urile de astăzi. Deși nu este adesea menționată în aceeași conversație, metodologia care a evoluat în jurul primelor sisteme de operare are multe în comun cu ideea de astăzi de a itera pe un produs minim viabil.

.