Kim jest Linus Torvalds i co stworzył

Istnieje wersja tej historii opowiadana jako biografia i uważam ją za najmniej ciekawą. Jeden fiński student, słynny post, dekady przewodzenia, reputacja szorstkiego. Robi z tego dobry artykuł i nie tłumaczy prawie nic z tego, dlaczego kernel napisany na domowy komputer wylądował pod większością technologii świata.

Użyteczniejsze pytanie jest mechaniczne, a nie osobiste: jak projekt rozchodzi się do miejsc, o których jego autor nie myślał, i działa tam przez dekady, bez firmy, która nim steruje? Ten proces ma kształt i warto ten kształt rozumieć, bo tłumaczy sporo na temat tego, które technologie zostają.

Właściwość, która uczyniła go przenośnym

Oryginał był napisany pod jeden konkretny procesor i tam by został, gdyby to się nie zmieniło. Zmieniło to świadome rozdzielenie: części rozmawiające z konkretnym rodzajem sprzętu zostały oddzielone od części wykonujących ogólną robotę systemu operacyjnego.

Brzmi jak szczegół implementacyjny. Jest całym powodem, dla którego ta rzecz jest wszędzie. Obsługa nowego rodzaju układu staje się kwestią napisania małego fragmentu sprzętowego zamiast przepisywania systemu, co znaczy, że producent z nietypowym sprzętem może to uruchomić w tygodnie zamiast w lata. Zrób tak wystarczająco wiele razy, a skończysz działając na procesorach, których nikt nie zaprojektował, kiedy ten kod powstawał.

Połącz to z licencją pozwalającą każdemu spróbować bez pytania o zgodę, a wzorzec przyjęcia wynika automatycznie. Nikomu nie trzeba było niczego sprzedawać. Inżynier z problemem mógł po prostu spróbować, a jeśli działało, było już wdrożone, zanim jakikolwiek dział zakupów o tym usłyszał.

Gdzie to faktycznie wylądowało

Nie na pulpicie, który wszyscy uznawali za nagrodę w tym wyścigu. Wszędzie indziej.

Najpierw serwery, przez końcówkę lat dziewięćdziesiątych, po cichu. Potem infrastruktura sieci w miarę jej rośnięcia. Potem telefony, przez Androida, co włożyło kernel do kieszeni sporego ułamka ludzkości. Potem wszystko wbudowane — telewizory, routery, samochody, kamery, sterowniki przemysłowe, bankomaty, sprzęt medyczny. A na górnym końcu każdy bez wyjątku z najszybszych superkomputerów świata, co jest twierdzeniem o całości, a nie o części, i jedną z dziwniejszych statystyk w informatyce.

Wspólnym wątkiem jest to, że żadne z tych miejsc nie jest miejscem, w którym użytkownik wybiera system operacyjny. To miejsca, w których inżynier wybiera rzecz dającą się dostosować do nietypowego sprzętu, zbadać, gdy zaczyna wariować, i wdrożyć bez negocjowania licencji na sztukę. Trzy wymagania, a wybierają tę samą odpowiedź za każdym razem.

Dlaczego to się nie rozpadło

To jest część, którą uważam za naprawdę niezwykłą, i to w niej jednostka jednak ma znaczenie.

Każdy może wziąć kod i pójść własną drogą. Tysiące firm miały i możliwość, i handlowy powód, żeby utrzymywać własną prywatną wersję, a wiele próbowało. A mimo to wciąż istnieje jeden główny kernel, do którego wraca praca wszystkich, co nie jest typowym przebiegiem — mnóstwo otwartych projektów rozpadło się nieodwracalnie o mniej.

Trzymały to razem dwa mechanizmy. Licencja uczyniła prywatną wersję kosztowną, a nie niemożliwą: możesz zatrzymać zmiany dla siebie tylko wtedy, gdy nigdy nie rozpowszechniasz produktu, a firma wypuszczająca urządzenia rozpowszechnia. Tanią ścieżką było więc wysłanie zmian do głównego projektu i przestanie utrzymywania ich osobno, co jest bodźcem czysto ekonomicznym, a nie moralnym.

Drugim była struktura opiekunów z ostatecznym rozjemcą. Ktoś decyduje, co wchodzi. Ta rola była pełniona publicznie i w sporze przez trzy dekady, a choć szorstkość bywała krytykowana — czasem słusznie — funkcja, którą pełniła, była realna: projekt bez sposobu rozstrzygania sporów pęka, a ten zawsze miał sposób.

Co z tego biorę

Dwie rzeczy, a pierwsza dotyczy mojego zawodu. Powód, dla którego mogę postawić system na maszynie porzuconej przez producenta, jest taki, że trzydzieści pięć lat obsługi sprzętu nagromadziło się w jednym miejscu, zamiast w trzydziestu pięciu osobnych, zamkniętych wersjach. To nagromadzenie nie było nieuchronne. Wyprodukowała je decyzja licencyjna i struktura zarządzania, a obie mogły łatwo pójść w drugą stronę.

Druga jest ogólniejsza i wciąż do niej wracam. To nie wygrało przez bycie lepszym w jakimkolwiek porównaniu, które ktoś przeprowadził. Wygrało przez bycie dostępnym w momencie, w którym ktoś miał problem, wystarczająco tanim, żeby spróbować bez pozwolenia, i wystarczająco otwartym, żeby naprawić, gdy nie pasowało. Te trzy cechy pokonywały lepszy produkt z procedurą zakupową, raz za razem, przez trzy dekady. To najbardziej powtarzalny wzorzec, jaki znam w tej branży, i stosuje się do znacznie więcej niż systemów operacyjnych.