Red Hat rozwiewa wątpliwości: IBM nie zaszkodzi Linuksowi

Kamil J. Dudek, dobreprogramy: Zacznijmy od razu od najczęstszych podejrzeń, na które można się natknąć w internecie. IBM, podobnie jak wielu głównych graczy na dzisiejszym rynku IT, kojarzy się niektórych ze złowrogą korporacją, która wchłonie Red Hata, narzuci swój porządek i stłamsi społeczności open source, forsując swoje rozwiązania.

Potencjalnie ucierpieć miałby w ten sposób Projekt Fedora, dzieląc los projektów open source dotkniętych niegdyś przez Oracle oraz ich "odwrotny dotyk Midasa". Zatem najbardziej oczywistym pytaniem na otwarcie jest: co się stanie z Open Source i Fedorą w erze mariażu Red Hata z IBM?

Jan Wildeboer, Red Hat: Krótka odpowiedź na to pytanie brzmi "nic się nie zmienia" i nie jest to tylko czcza obietnica bez pokrycia. Projekt Fedora będzie się dalej rozwijać nie z powodu dobroci serca Red Hata albo zabiegów marketingowych. Wierzymy, że opieka nad społecznością jest kluczowym elementem sukcesu naszych rozwiązań. Wiele naszych produktów mogłoby nie zdobyć swojej obecnej popularności, gdyby nie to, że ich administratorzy i programiści funkcjonowali w społeczności open source, na bazie której te rozwiązania powstały. Istnieją firmy, które czerpanie korzyści z open source ograniczają tylko do postaci redystrybucji i recenzji dostarczanych kodów źródłowych. Jawnie wzbraniają się one przed budowaniem i opieką nad społecznościami. Takie podejście jest szkodliwe dla sprawy, nasz model zakłada coś przeciwnego i decyzja ta sprawdza się od lat. Ponadto Linuksy, w tym linuksowy desktop, bez roli Red Hata znajdowałyby się jakościowo w zupełnie innym miejscu.

Obawy społeczności biorą się zapewne właśnie z postawy owych "innych firm". Choć IBM również jest obiektem branżowych przysłów, Oracle zasłużył sobie na te mniej chlubne, jak np. "Oracle nie ma klientów, tylko zakładników i nie ma programistów, a sam dział prawny". Jest to oczywiście dramatyzm i przesada, ale z drugiej strony skąd czerpać pewność, że IBM nie zachowa się podobnie do Oracle w kwestii open source?

Oracle stosuje przeciwieństwo postawy IBM wobec oprogramowania open source. Poszli oni w stronę przepakowania kodu. Oracle Linux jest budowany z kodu RHEL. Ich podejście nie jest jednak zwycięską strategią, Oracle nie jest liderem systemów linuksowych. Ich polityka open source ewidentnie się nie sprawdza, wystarczy zobaczyć, co się stało z MySQL. Jest też cała historia Solarisa i jego otwartej postaci. Oczekiwania rynku się zmieniły, produkty tego typu nie są już oczekiwane. IBM i Red Hat nie idą w tę stronę, a rynek odchodzi od oraclowskich alternatyw. Amazon niedawno wyłączył swoje bazy Oracle, oceniając to jako osiągnięcie.

IBM to dziś głównie świat biznesu. Red Hat również dostarcza rozwiązania do budowania oprogramowania dla firm oraz infrastruktur do produktów komercyjnych. Czy takie połączenie jeszcze mocniej nie oddali szans na popularyzację systemów linuksowych u użytkowników indywidualnych, skoro obiektywnie "nie ma w tym pieniędzy"?

Powód, dla którego Linux dla użytkowników końcowych, czyli niesławny "rok Linuksa na desktopie" nie wypalił, to po części również kwestia porażki środowiska w kwestii docierania do użytkowników z jednoznacznym przekazem. Nie istnieje sprawdzona ścieżka "serwisowania" takiej instalacji. I nie chodzi tu tylko o sterowniki, wsparcie OEMów czy brakujące (nie każdemu przecież) oprogramowanie. Osoba napotykająca problemy z instalacją Linuksa, upraszczając, "nie ma gdzie szukać pomocy". To nie jest problem fragmentacji, a raczej społeczności. Nie krytykuję nikogo za posiadanie silnych opinii, ale potrafią one skutecznie odstraszyć.

A więc Linux nie ma się czego obawiać? RHEL często obrywa za stosowanie korporacyjnych, unikatowych rozwiązań.

Optyka oparta o dawne przenośnie, jak ortodoksyjna "filozofia Uniksa" lub metody rozwoju oprogramowania w stylu "katedra vs bazar" są już nieaktualne. Systemy działają w inny sposób, bo potrzeby są definiowane w inny sposób. Niesławny systemd jest potrzebny. Obniża koszty administracji systemów linuksowych i dostarcza rzeczy, które wcześniej w ogóle nie były możliwe. Zresztą przyjęły go potem inne dystrybucje. To, że stereotypowy "brodaty admin Uniksa" potrafiłby osiągnąć zbliżony efekt "po uniksowemu" nie jest myśleniem w kategoriach biznesowych.

Ciężki, niejawny i korporacyjny proces, o którego forsowanie czasem posądza się IBM, dziś już po prostu nie istnieje. Wszystko jest oprogramowaniem, całe infrastruktury są definiowane jako oprogramowanie, model dostarczania (devops) również jest zupełnie inny. Dziś jesteśmy bliżej "bazaru" niż kiedykolwiek wcześniej, więc dawne uniksowo-hakerskie metafory i nostalgie są już dziś całkowicie nieaktualne.

**Silne opinie wzbudza między innymi warstwa zarządzania systemami oraz właśnie ten niesławny systemd. W opozycji do niego jest na przykład społeczność OpenBSD. **

Mam wiele szacunku do projektu OpenBSD, a ich projekty i rozwiązania są architekturalnie godne podziwu i uznania. Ale finalnie dziś używamy głównie Linuksów, a nie BSD i jest tak nie bez powodu. Nielubiany przez wielu Lennart Poettering i jego zdecydowane poglądy na pewne kwestie, niekoniecznie uniwersalnie słuszne, wyróżniają się pewną ważną cechą, jaką jest jednoznaczny przekaz pozbawiony fałszywego wstydu. Gdy OpenBSD przestrzega przed tworzeniem "nieuniksowych", niemal monolitycznych rozwiązań trudnych do przeszczepienia do innych Uniksów (podobnie, jak robi to Apple i macOS), Poettering ma na to gotową odpowiedź. Brzmi ona "tak, nie będzie działać, ale wybaczcie nam – jesteśmy Linuksem. Nie miejcie do nas pretensji o to, że chcemy używać swojego stosu technologicznego". Oznacza to, że ta walka jest bezproduktywna. Tworzy też waśnie: jak się okazuje, zwolennicy radykalnie odmiennych rozwiązań, użytkownicy Debiana, Red Hata i BSD, to często dobrzy znajomi, którzy doskonale się dogadują przy piwie. Niestety, przekaz wychodzący dla społeczności może zostać odebrany inaczej, jako niemal plemienna walka.

Ci brodaci administratorzy niekoniecznie boją się filozoficznego braku Uniksa, ale także ucieczki zbyt wielu rozwiązań w chmurę. Ponieważ IBM dostarcza swoje IBM Cloud, może to wyglądać jak zastawiona na przyszłość pułapka.

Red Hat w ogóle nie planuje zamykać przyszłych użytkowników w IBM-owskiej chmurze. Co więcej, nasza oferta jest dostosowana do tego, by w pewnym sensie osiągać przeciwny skutek. Dostarczamy rozwiązania serwujące API i platformę dla aplikacji, które można wdrożyć na dowolnej chmurze. Konsultujemy z potencjalnymi klientami scenariusze wdrożenia, które mają ich uchronić przed zjawiskiem "vendor lockdown", w którym są skazani na raz obraną strategię wdrożeń. Uczulamy na to, że właściwe stosowanie np. języka Java pozwala uniknąć sytuacji, w których np. nie da się przeskoczyć z WebLogic na JBoss. Wiele naszych rozwiązań, jak OpenShift, można migrować między chmurami, a także zahostować samodzielnie, jako on-prem, bo na to zawsze będzie zapotrzebowanie. Jednym z elementów strategii Red Hata jest przedstawienie niezależności od rodzaju chmury jako mechanizmu redundancji. Wszak nie chodzi tylko o skalowalność wdrożenia, przezroczyste naprawy czy fizyczną nadmiarowość. Przeprowadzając się do chmury, wprowadzamy jakiś poziom zależności od zewnętrznego czynnika. Możliwość taniego przemigrowania z całym rozwiązaniem na inną platformę (cloud failover) i inną chmurę również można rozpatrywać w kategoriach niezawodności rozwiązania. Zdecydowanie więc Red Hat nie chce zamykać ludzi w chmurze.

Popularność chmury nie oznacza zatem, że Red Hat chce się powoli wycofywać z wdrożeń lokalnych, promując przede wszystkim rozwiązania działające w chmurze?

Tak jest. Chmura nigdy nie zastąpi w całości rozwiązań utrzymywanych samodzielnie. To marketingowy mit znikąd, bo tak nie twierdzą nawet operatorzy chmur. Niektórych rzeczy zwyczajnie nie da się przenieść w chmurę, jak systemów bezpieczeństwa publicznego, rozwiązań medycznych albo ogólnie pojętych elementów zajmujących się GDPR (RODO). Skupienie na chmurze, jeden z punktów sprzedaży dla systemu Red Hat Enterprise Linux 8, nie polega na tym, żeby wszystkich do tej chmury przegonić, a raczej na tym, żeby dostarczyć klientom komfortu i świadomości tego, jak łatwo jest stworzyć narzędzia chmurowo hybrydowe oraz łatwo wędrujące między instalacjami w chmurze, a instalacjami samodzielnymi on-prem.

A co z klasycznymi, firmowymi serwerami?

Tak, pozostaje też kwestia tych "najnudniejszych" rozwiązań korporacyjnych, jak instalacje nienadzorowane stacji roboczych i scentralizowane zarządzanie tożsamością. Czasy kontrolerów domeny, jak Active Directory i firmowy LDAP to już przeszłość. I podobnie, jak Microsoft otwiera się na Federation Services i Azure AD, Red Hat wciąż utrzymując Satellite i Ansible, pracuje nad nowymi formami zarządzania tożsamością, jak projekt ID2020 i wsparcie dla OAuth. To kolejny dowód na to, że nie żegnamy się z żadnym dzisiejszym produktem.

IBM sfinalizował przejęcie firmy Red Hat w lipcu b.r. Dziękujemy za możliwość przeprowadzenia rozmowy.