Jak powstał Linux? The Processes Behind Managing 13,500 Developers

Prawdopodobnie używałeś dziś Linuksa – zwłaszcza jeśli nie masz iPhone’a. A jeśli przeglądałeś dziś strony internetowe, jest duża szansa, że strona, którą odwiedziłeś, również była obsługiwana przez Linuksa.

Linux jest systemem operacyjnym, ale w przeciwieństwie do oprogramowania takiego jak Microsoft Windows i macOS, Linux został opracowany przez samoorganizującą się społeczność wolontariuszy.

Z czasem, dzięki wysiłkowi ponad 10 000 programistów i ewoluującym procesom zarządzania skalą pracy, jądro Linuksa rozrosło się do ponad 20 000 000 linii kodu. Stanowi ono stabilną podstawę dla…

• Każdego telefonu i tabletu z systemem Android na naszej planecie
• 66% światowych serwerów
• 100% z 500 najlepszych superkomputerów

Ta technologia nie pochodzi od zgranego zespołu z grubą księgą zasad i warstwami zarządzania. Pochodziła z kilku starannie dobranych i osadzonych w kulturze polityk oraz wspólnej misji.

W tym poście przyjrzę się, jak technologia tak istotna, złożona i ważna mogła zostać wyprodukowana tak skutecznie bez tradycyjnej struktury zarządzania. Ale najpierw…

Dlaczego jądro Linuksa jest tak imponujące?

Jądro to sam rdzeń systemu operacyjnego. Jest to orkiestrator wszystkich innych procesów oprogramowania na komputerze lub smartfonie, dzieląc zasoby i zapewniając sposób dla sprzętu i oprogramowania do komunikacji.

W słowach G. Pascal Zachary, jądro systemu operacyjnego można porównać do „szefa personelu domowego, który był tak pilny, że służył rodzinie na górze w każdej chwili, noc lub dzień na wezwanie, obsługując każdą prośbę”. Jądro utrzymuje maszynę w ruchu, bez względu na to, na co się natknie. Był to niezbędny skok od świata, w którym komputery mogły uruchamiać tylko jedną aplikację na raz, do świata, który znamy dzisiaj.

Jądro Linux, oparte na UNIX, zostało opracowane na początku lat 90. przez Linusa Torvaldsa.

Do roku 1991, Torvalds opublikował pierwszą wersję – zaledwie 10,000 linii kodu – i wywołał podniecenie w społeczności programistów skromnym ogłoszeniem pocztą elektroniczną, widocznym powyżej.

Umocniony przez potęgę współpracy w Internecie, po raz pierwszy w historii, programiści wnieśli swoje umiejętności kodowania i czas na testowanie za darmo, podczas gdy baza użytkowników jądra eksplodowała w rozmiarze. Jeśli byli chętni do eksperymentowania, użytkownicy mogli próbować sklecić łatę, jeśli stwierdzili, że coś jest zepsute, i dyskutować jak ulepszyć oprogramowanie.

Jak Eric S. Raymond patrzy na to w swojej książce o wczesnym oprogramowaniu open source, The Cathedral and The Bazaar, zarządzanie programistami jądra przez Linusa Torvaldsa stało się wydajne, samoorganizujące się i bardziej niż zdolne do produkcji prawdopodobnie jednego z najbardziej złożonych i szeroko używanych kawałków oprogramowania na planecie.

W tym artykule przyglądam się procesom i zasadom, które pojawiły się jako niezbędne wsparcie dla projektu jądra Linuksa, jak ewoluował przez lata.

Jak, bez formalnego procesu, jako 21-letni student informatyki, Torvalds poprowadził projekt jądra na wyżyny, które osiągnął…

…I co jest takiego trudnego w zarządzaniu programistami?

Według badań przeprowadzonych przez Geneca, ponad 75% kierowników firm i działów IT uważa, że ich projekty oprogramowania są skazane na porażkę. Trudności związane z produkcją niezawodnego oprogramowania i zarządzaniem tymi, którzy to robią, zaowocowały niezliczonymi książkami o zarządzaniu, badaniami produktywności i ramami przywództwa.

„Sama złożoność oprogramowania oznacza, że niemożliwe jest przetestowanie każdej ścieżki”, pisze Paul Smyth, dyrektor generalny Kynetix, w serwisie Finextra. „Aplikacja programowa jest jak góra lodowa – 90% jej powierzchni nie jest widoczna. Główna złożoność aplikacji leży poniżej linii wodnej”.

Każdy projekt oprogramowania o znaczących rozmiarach, czy to CRM, czy system operacyjny taki jak Microsoft Windows, jest zbyt duży, aby zmieścić się w głowie jednej osoby. Wymaga on wspólnej wiedzy i współpracy wielu współpracowników. Oznacza to, że programiści pracują nad wyspecjalizowanymi częściami aplikacji, jednocześnie musząc zrozumieć, jak ich praca wpływa na całość.

„Żaden umysł nie jest w stanie ogarnąć tego wszystkiego”, zauważył kierownik zespołu 250 programistów Microsoftu podczas budowania systemu operacyjnego od podstaw, według G. Zachary’ego w Show stoppers! książce, która opowiada historię zespołu programistów Microsoftu ścigających się, by ukończyć Windows NT w 1993 r.

Im większy projekt, tym wolniej można wprowadzać zmiany. Badania Steve’a McConnella dowodzą tego, stwierdzając, że kod jest pisany w tempie 5-10x wolniejszym w projektach liczących ponad 10 000 000 linii. Co więcej, badanie praktyk rozwoju Microsoftu ujawniło, że na każde 1000 linii kodu przypada około 10-20 błędów.

Mimo wielkości projektu i liczby współpracowników, rozwój jądra Linuksa przebiega szybko, a jego duża, entuzjastyczna baza użytkowników wyłapuje błędy i pisze poprawki, aby szybko wprowadzać ulepszenia.

W początkowym okresie rozwoju – około 1991 roku – nie było niczym niezwykłym dla Torvaldsa wydanie więcej niż jednego nowego jądra dziennie. Teraz, na bardziej dojrzałym etapie, na którym opiera się 80% smartfonów i większość serwerów internetowych, pożądany okres wydania wynosi od 8 do 12 tygodni. Każde wydanie, jądro widzi średnio 10,000 poprawek od 2,000 deweloperów – wszyscy zmagają się z ponad 20,000,000 linii kodu.

Jakie są techniki zarządzania i procesy wymagane do orkiestracji tego poziomu współpracy i produktywności? Cóż, nie zostały one napisane przez kierownika działu ani autora książki biznesowej. Rozwijały się organicznie, z przewodnictwem „życzliwego dyktatora” projektu, Linusa Torvaldsa.

Nawet w swojej rodzącej się formie, nad jądrem Linuxa pracowały setki ochotników, którzy przedkładali swoją pracę bezpośrednio Torvaldsowi do przejrzenia. Jak haker o złym usposobieniu, antyspołeczny, zarządzał sporami, wkładem i komunikacją między tysiącami programistów przez prawie dwie dekady?

Jak dokumentowane są polityka, proces i 15 000 000 linii kodu

W przeciwieństwie do tradycyjnej organizacji, nowi programiści jądra nie są ściśle „wprowadzani” do społeczności, ale oczekuje się od nich, że w pełni przeczytają i zrozumieją dokumentację wprowadzającą. Skupienie się projektu jądra na dokumentacji było koniecznością zarówno z powodu technicznej złożoności, jak i samej liczby deweloperów.

Numeryczne FAQ, how-tos i przewodniki jak zacząć istnieją w repozytorium dokumentacji jądra, a jeszcze więcej w wiki stworzonych i utrzymywanych przez deweloperów jądra na całym świecie.

Sposób w jaki dokumentacja jest pisana i ulepszana odzwierciedla sposób w jaki jądro jest rozwijane; wspólnie, otwarcie i przyrostowo.

Dzięki wykorzystaniu spojrzeń i specjalizacji ogromnej grupy ludzi, dokumentacja może być tworzona, testowana i sprawdzana o wiele wydajniej niż gdyby była tworzona przez mniejszy, dedykowany zespół. Aby nagiąć Prawo Linusa do terminów, które redaktor treści może lepiej zrozumieć: z wystarczającą ilością oczu, wszystkie literówki są oczywiste.

Oprócz materiałów dla wsparcia technicznego, społeczność rozwijająca jądro stworzyła bibliotekę dokumentacji procesu zaprojektowaną, aby wygładzić ludzką stronę współpracy.

Na stronie indeksu „A guide to the Kernel Development Process”, akapit brzmi:

„Celem tego dokumentu jest pomoc deweloperom (i ich menedżerom) w pracy ze społecznością deweloperską z minimalną ilością frustracji. Jest to próba udokumentowania sposobu działania tej społeczności w sposób przystępny dla tych, którzy nie są dobrze zaznajomieni z rozwojem jądra Linuksa (lub, w rzeczy samej, z rozwojem wolnego oprogramowania w ogóle).”

Nikt nie rodzi się z wrodzoną wiedzą na temat systemu kontroli wersji git, lub jak wysłać łatkę na listę mailingową. Dlatego właśnie proces rozwoju musi być udokumentowany – wyjaśnianie tych samych podstawowych informacji jednej osobie na raz nie ma skali!

Jak zarządzana jest komunikacja między tysiącami deweloperów

Rozmowy między deweloperami odbywały się jawnie, na listach dyskusyjnych rozwoju jądra. Do dziś, e-mail jest nadal preferowanym narzędziem z powodu swojej prostoty. Te listy mailingowe były archiwizowane i organizowane, tworząc ciało żywej dokumentacji i historii.

Efekt publicznego komunikowania się ma efekt podobny do korzyści płynących z używania narzędzia takiego jak Slack dzisiaj – każda informacja staje się bezpieczna i przeszukiwalna, zamiast wyparować. Aby jednak zapanować nad takim firehose informacji, projekt kernela opracował politykę komunikacji i rozpowszechnił ją jako część dokumentacji.

Komunikacja i współpraca na taką skalę nie była możliwa przed Internetem, więc wczesne projekty, takie jak ten, musiały napisać i rozpowszechniać szybkie i skuteczne rozwiązania dla zarządzania społecznością, etykiety i problemów z prezentacją kodu.

Dokumentacja jądra zawiera zasady wysyłania łatek, aby ułatwić innym przeglądanie, edytowanie i testowanie kodu. Oznacza to, że poprawki muszą być wysyłane pocztą elektroniczną w postaci zwykłego tekstu, a nie załączników. Łatki muszą być wysyłane tylko raz na e-mail i muszą przestrzegać określonych wytycznych stylu kodowania:

Ta sztywna standaryzacja jest absolutnie konieczna dla projektu tak dużego jak jądro, tak jak dla projektów każdego rozmiaru. Pomaga zredukować błędy w przestrzeni, gdzie pojedynczy błąd może mieć efekt falowania, który produkuje niestabilny kod w przyszłości, lub marnuje czas wielu testerów i deweloperów.

Jak krytyczne decyzje są (nie) podejmowane

Cytując Torvaldsa:

„The name of the game is to avoid having to make a decision. W szczególności, jeśli ktoś mówi ci „wybierz (a) lub (b), naprawdę potrzebujemy, żebyś się na to zdecydował”, masz kłopoty jako menedżer. Ludzie, którymi zarządzasz, powinni znać szczegóły lepiej niż ty, więc jeśli przyjdą do ciebie po decyzję techniczną, masz przechlapane. Najwyraźniej nie jesteś kompetentny, aby podjąć tę decyzję za nich.” – Linux Kernel Development Documentation

Oprócz unikania hierarchii menedżerskiej, projekt Linux posiadał jasne zasady i dokumentację, które pomagały w podejmowaniu decyzji bez potrzeby dyskusji, debat lub (wielu) list mailingowych flame wars. Spojrzenie na archiwa pokaże wam, że część z wojnami płomieni nie zawsze jest możliwa, ale to co jest możliwe to stworzenie polityki, która neguje ciężar decyzji.

„Tak więc kluczem do uniknięcia wielkich decyzji staje się unikanie robienia rzeczy, które nie mogą być cofnięte. Nie daj się zapędzić w róg, z którego nie możesz uciec. Szczur zapędzony w róg może być niebezpieczny – zapędzony w róg menedżer jest po prostu żałosny.”

Show Stoppers! ujawnia, że filozofia Billa Gatesa jest podobna. Podziwiał on programistów i niezmiennie powierzał im kierowanie projektami, w których mogli zarówno zarządzać, jak i programować, aby uniknąć sytuacji, w której profesjonalni menedżerowie, bez doświadczenia w programowaniu lub z nieaktualną wiedzą, sprawowaliby władzę”.

Jak współpracownicy są zorientowani wokół silnego wspólnego celu

W przypadku Linuksa, jak to jest z wieloma popularnymi projektami open source, jądro nie powstało po tym jak zostało zaprojektowane wspólnie przez dużą grupę współpracowników; raczej, było ulepszane przyrostowo bez podejmowania decyzji, które destabilizują silną bazę dotychczasowej pracy. To dobrze łączy się z filozofią Torvaldsa na temat podejmowania decyzji w zarządzaniu, ale także z filozofią osadzoną w samym kodzie.

Linux jest oparty na UNIX, który jest wcześniejszym systemem operacyjnym zaprojektowanym wokół zestawu zasad przypominających zen. Jak wyraźnie stwierdzono w Filozofii UNIX:

„Projektuj i buduj oprogramowanie, nawet systemy operacyjne, aby wypróbować je wcześnie, najlepiej w ciągu kilku tygodni. Nie wahaj się wyrzucić niezdarnych części i przebudować ich.”

Zarówno Torvalds, jak i Raymond (który starał się powtórzyć sukces Torvaldsa w budowaniu społeczności) odkryli, że wczesne i częste wypuszczanie oprogramowania pomogło zgromadzić współpracowników wokół ekscytującego, rozwijającego się projektu, w którym widzą przyszłość. Raymond sprowadził to do dwóch kluczowych rzeczy, których projekt nie może nie robić, gdy jest wypuszczany w świat:

1. Uruchomić
2. Przekonać potencjalnych współtwórców (użytkowników), że projekt może zostać wkrótce przekształcony w coś wielkiego

To właśnie z tymi samymi zasadami startuje wiele dzisiejszych startupów – w tym Process Street:

Powyżej znajduje się Process Street w 2014 roku. Załóż konto, aby zobaczyć, jak daleko zaszliśmy.

Czy jest to proces powtarzalny?

Na pierwszy rzut oka, nagłe połączenie jednego z najbardziej skomplikowanych ludzkich tworów wydaje się być alchemią. Ale, rozbierając na części składowe, łatwiej jest dostrzec proces leżący u podstaw. W czasie, gdy pisał „Katedrę i Bazar”, Eric S. Raymond prowadził jednocześnie prace nad otwartym klientem poczty elektronicznej. Otwierając go, Raymond próbował powtórzyć zaangażowanie społeczności i ostateczny sukces projektu jądra.

Wiele z podstawowych założeń modelu Bazaru, jak go określił, będzie natychmiast znanych każdemu w świecie startupów:

• Każda dobra praca nad oprogramowaniem zaczyna się od podrapania osobistego swędzenia programisty.
• Traktowanie użytkowników jak współtwórców jest najmniej kłopotliwą drogą do szybkiego ulepszania kodu i skutecznego debugowania.
• Wypuszczaj wcześnie. Wypuszczaj często. I słuchaj swoich klientów.
• Dzięki wystarczająco dużej bazie beta-testerów i współtwórców, prawie każdy problem zostanie szybko scharakteryzowany, a poprawka będzie dla kogoś oczywista.
• Jeśli traktujesz swoich beta-testerów tak, jakby byli twoim najcenniejszym zasobem, odpowiedzą ci, stając się twoim najcenniejszym zasobem.
• Następną najlepszą rzeczą do posiadania dobrych pomysłów jest rozpoznawanie dobrych pomysłów od swoich użytkowników. Czasami to drugie jest lepsze.
• Często najbardziej uderzające i innowacyjne rozwiązania pochodzą z uświadomienia sobie, że Twoja koncepcja problemu była błędna.
• Aby rozwiązać interesujący problem, zacznij od znalezienia problemu, który jest dla Ciebie interesujący.
• Pod warunkiem, że koordynator rozwoju ma medium komunikacyjne co najmniej tak dobre jak Internet, i wie, jak prowadzić bez przymusu, wiele głów jest nieuchronnie lepszych niż jedna.

W skrócie, jest to proces powtarzalny. I to taki, który został z powodzeniem zaadoptowany ze świata open source do mentalności startupów. Przejawia się on w agile, lean, six sigma, oraz w postawach i polityce, którą rozwinęły dzisiejsze startupy. Chociaż nie jest to często wspominane w tej samej rozmowie, metodologia, która rozwinęła się wokół wczesnych systemów operacyjnych, dzieli wiele z dzisiejszą ideą iteracji minimalnego produktu wykonalnego.