Katedra i bazar... czyli jak metodyka przełożyła się na skalowanie międzymordzia

Katedrę Notre-Dame w Paryżu budowano 180 lat (obraz i dane podaję za Wikipedią), czy w dzisiejszych czasach możliwe byłoby coś takiego?

Świat przyspieszył w wielu dziedzinach i dzisiaj chciałbym przybliżyć klasykę, czyli jak można tworzyć oprogramowanie (użyte zostanie odniesienie do bazaru i katedry) i porównać w kilku słowach to co mamy teraz do tego co widziałem w 2010:

Katedra

W wielkim skrócie - budujemy długo, a osoby postronne nie mają zbyt wielkiego wpływu na produkt i nie widzą elementów pośrednich (bo nie mają wstępu na plac budowy).

Ten model wykorzystują szczególnie wielkie firmy i my widzimy ciszę, czasem jakieś przecieki (oczywiście zawsze "przypadkowe"), a potem jest wielka premiera i fanfary:

Panie i panowie, ladies and gentleman, there is one more thing!

Tak się dzieje z produktami, które wymagają dziesiątek prototypów, są zerowane, wchodzą w ślepe uliczki, a my mamy zobaczyć dopiero doskonały efekt końcowy i rzucić się do sklepów.

Ten model był stosowany zwłaszcza w czasie, gdy nie było Internetu:

...obecnie pewne elementy wydostają się miesiące wcześniej, poza tym projekty wymagają coraz większej ilości inżynierów czy specjalistów z różnych dziedzin i niemożliwe jest utrzymanie tajemnicy...

I tu dochodzimy do problemów katedry - trzeba mieć funduszę na opłacenie zasobów (jak to się ładnie mówi w nonomowie), do tego w różnych przypadkach efekt końcowy widoczny jest dopiero po dłuższym czasie (co oczywiście nie wpływa zbyt dobrze na morale zespołów, które miesiącami są tylko "kosztem"), a efekt końcowy może być porażką (skoro docelowi użytkownicy nie widzą produktu, nie mogą wyrazić o nim opinii i wskazać oczywistych błędów).

Szczególnie ta ostatnia kwestia jest ważna - jeżeli CEO firm są charyzmatyczni i mają wizję i wiedzę, to są w stanie ustawić właściwie projekty, a jeżeli nie, to cóż - ilość wpadek wzrasta dramatycznie: proszę popatrzeć na sytuację Apple po pierwszym odejściu Jobsa, Windows Vista i 8 po odejściu Billa Gatesa, itd.

Może więc bazar?

Wyobraźmy sobie miejsce, gdzie wszyscy mogą dodawać swoje idee (zdjęcie za Wikipedią)... a co więcej - produkt powstały z ich połączenia jest widoczny od razu, z jego problemami i zaletami.

Pomysł niby wspaniały i skutkujący często mnogością opcji (obrazek poniżej pokazuje ile układów polskiej klawiatury miało Ubuntu już w 2010), ale użytkownicy tak stworzonego oprogramowania często muszą mieć wiedzę techniczną po to, aby go uruchomić... albo ustawić pod swoje potrzeby.

Jeśli chodzi o tworzenie, to również z tym bywa różnie - zdarzają się projekty, gdzie jakość woła o pomstę do nieba, gdyż za kodowanie zabrali się totalni marzyciele albo ignoranci (przy dobrze wykonanej katedrze chyba częściej zdarza się dobierać ludzi, którzy rzeczywiście mają coś do powiedzenia, gdyż właściciele środków przeznaczonych na ich opłacenie częściej kontrolują stan swojej inwestycji).

W tym momencie dochodzimy do obrazka z początku wpisu - w 2010 na Ubuntu 10.04 tak wyglądało zużycie zasobów wraz ze środowiskiem Ubuntu Netbook Edition 2D opartym na Gnome i uruchomionym Firefox 3.6.3:

Jak się zmieniły popularne środowiska graficzne pingwina, nie muszę chyba mówić - z kronikarskiego obowiązku dodam, że samo Ubuntu bez żadnych "udziwnień" w wersji 64‑bit zajmuje na starcie ok. 1 GB RAM (i szczerze mówiąc w 2019 nie chce mi się tego optymalizować).

Do czego dążę?

Oprogramowanie z bazaru może nigdy nie mieć wersji stabilnej, może nie mieć wsparcia, może być kalekie i szczerze mówiąc urągające wszelkim normom... a ja w takim wypadku odpowiam, że "to proszę albo przesiąść się na coś innego, albo zgłosić błąd albo napisać poprawkę".

Normą jest również istnienie wielu wersji (jakkolwiek tego nie nazwać, chodzi mi tutaj o niezgodne ze sobą forki z kodem powstałe z jednego rodzica), plusem w tym wypadku często jest cena, a ja sam mogę mieć pretensję jedynie sam do siebie, że nie chce mi się szukać alternatywy.

Zgadzam się, że ten model na pewno nie jest tak "sexi" jak katedra - w wielu projektach nie ma takiej kompatybilności wstecznej i użytkownicy reagują wręcz nerwowym "znooowwwu jakaś zmiana" i "coś mi przestało działać", często i gęsto nie ma efektu "wow", pamiętajmy jednak, że celem wielu z tych perełek nie jest działanie na milionach maszyn ale np. pokazanie dróg rozwoju, a ich prawdziwą siłą jest praktycznie zawsze dostępność kodu źródłowego.

W takim modelu próbuje się pisać chociaż ReactOS czy Haiku - myślę, że biorąc pod uwagę niezbyt chyba duże środki na ich rozwój (w porównaniu do oryginałów) to należałoby docenić co potrafią na dzień dzisiejszy:

Tak należy traktowac również chociażby Servo Mozilli...

I pośrodku

A teraz wyobraźmy sobie, że chcemy połączyć te dwie metody (katedrę i bazar).

I tak mamy np. jądro linuksowe, do którego doklejamy kod własnościowy (a po ludzku - najczęściej sterowniki napisane przez firmy, które nie chcą pokazać kodu źródłowego).

Pojawia się problem - skoro na bazarze wszystko szybko się zmienia, to elementy z katedry mogą nie pasować... i nie pasują, co widać na przykładzie jądra linuksowego użytego w Androidzie, a ponieważ nikt tego nie kontroluje, to firmy idą na łatwiznę (często i gęsto producenci poprzestają na publikacji konkretnej zmienionej przez siebie wersji z dodanym binarnym kodem nie troszcząc się o dodanie poprawek do wersji ogólnej).

Wiem, że to zabrzmi naiwnie, ale jedyne co może tutaj pomóc to pisanie maili do Intela, NVidii, AMD, Samsunga czy Qualcomma (czyli mówiąc wprost trucie czterech liter, żeby wymusić zmianę ich strategii działania).

W tym wypadku model katedry ma zaletę - firmy tworzące systemy operacyjne (a więc np. Microsoft czy Apple) mają większą siłę przekonywania i dzięki swojemu zaangażowaniu i podpisanym umowom część sprzętu ma szansę działać lepiej z ich produktami.

Nawiasem mówiąc problem ze zmianą metodyki ma Microsoft - kiedyś używali lekko koślawej katedry (problemy z technologią x86, potem z bezpieczeństwem kodu zwłaszcza przed Windows XP SP2), następnie ją poprawili, teraz podgryzani przez konkurencję próbują iść w stronę częściowego bazaru (Windows 10), ale ograniczeni są patentami, kompatybilnością wsteczną... i brakiem starej kadry inżynierskiej.

Szczerze mówiąc śmieszy mnie również narzekanie na Androida czy Chrome, skoro pisane są również w dużej mierze w modelu katedry (oczywiście są pewne elementy bazaru i można sobie zrobić fork kodu, ale zmiany w głównej gałęzi muszą być zaakceptowane przez nadzorcę jakim najczęściej jest Google).

Podam krótki przykład - zaproponowałem swego czasu, żeby w okienku historii w Chrome na Androidzie można było zwijać konkretne dni (błąd 962309), całość zakodowałem (CL 1608741) i na dzień dzisiejszy nie wiadomo, czy ktoś się nad tym pochyli i "klepnie", że jest to zgodne z wolą korporacji.

Zmiana banalna (video) i nie piszę tego, żeby się pochwalić, tylko chcę zwrócić uwagę na fakt, że metoda katedry ma swoje zalety, ale również ogromne wady.

Pójdźmy dalej:

To jest zrzut ekranu z 2011 pokazujący uprawnienia jednej z aplikacji pobieranych z Google Play (artykuł był tutaj) - nadzorca Androida, jakim jest Google, zdecydował o takim a nie innym podziale uprawnień i w modelu katedry narzucił go milionom użytkowników (byłoby to znacznie trudniej zrobić przy bazarze).

Jak to się skończyło, nie muszę chyba mówić (z drugiej strony Apple narzucił użytkownikom pewne określone sposoby "wyłączania" Wi‑Fi czy Bluetooth, co dokładnie tak samo pokazało wadę i zaletę tego modelu)

I moje pięć groszy

W dzisiejszych czasach ludzie chcą mieć wszystko za darmo (najlepiej, żeby jeszcze samo przyszło i wszystko zrobiło).

To se ne da pane Havranek!

Rozwój wymaga pracy, konkretnej i zero-jedynkowej (coś jest zrobione albo dobrze albo źle) i praca ta jest przeniesiona na producenta softu (katedra) albo na użytkowników (bazar).

To nie jest tak, że przyjdą małe elektroniczne krasnoludki i zrobią Linuksa na desktopy - system Windows ma elementy sięgające lat osiemdziesiątych poprzedniego wieku, a te wszystkie Gnomy i KDE niekoniecznie (poza tym wszystko ostatecznie sprowadza się do tego ilu fachowców nad nimi pracowało, a z tym bywa naprawdę różnie).

Na pewno oba modele rozwoju oprogramowania są niezbędne i jeżeli jednego brakuje przy tworzeniu jakieś klasy programów, to pojawią się problemy dla nas zwykłych użytkowników - wyobraźmy sobie, że Firefox się kończy i wszystkie przeglądarki opierają się na Chromie albo wyobraźmy sobie, że na rynku jest tylko iOS.

Tego chyba nie chcemy, a przedsmak mamy np. w AppStore i blokadzie używania innych enginów HTML niż jedyny słuszny.

Bez linuksa, bazaru, open-source, GNU, ale również iOS, Windows, katedry i tysiąca innych rozwiązań nie mielibyśmy dziś postępu... i konkurencji i na przykład Mac OS mógłby wyglądać tak:

Właśnie dlatego cieszmy się, że jest okropny Windows i niedobry Linux, niefajny Android i paskudny iOS, bo tylko dzięki temu nasze życie jest inne niż dziesięć czy dwadzieścia lat temu (a na pewno nie jest takie nudne) i tylko dzięki temu firmy mogą oferować nowe rozwiązania (np. konkretne urządzenia z odpowiednio skrojonym firmware) i dostajemy odpowiedniki software, który został porzucony przez producenta (np. FreeDOS może zastąpić MS‑DOS, free pascal Turbo-Pascala, itp.)

PS. Pisanie tekstów typu Mandźaro chcę zaro uważam za klasyczny klickbait z uwagi na formę i brak informacji jak poradzić sobie z opisanym tam problemem, dodatkowo przepraszam za uproszczenia, które wynikły z mojej dostępności i formy blogowej.

PS2. Pisałem już o katedrze i bazarze w 2013, nie uprawiam również ewangelizacji i wskazywałem zalety i BOLĄCZKI Ubuntu już w 2010 (np. tutaj i tutaj), miałem podobną serię artykułów o Windows (np. tutaj).