Microsoft nadal nie umie w Open Source

Open Source jest wszędzie wokół nas i zapewne bez tej inicjatywy świat nie byłby taki sam. Nie ma sensu rozpisywać się o zaletach otwartego oprogramowania, bo te są jasne i klarowne. W tym wpisie chciałbym przedstawić jednak punkt widzenia programisty .NET, który przez Microsoft został nieraz już wprowadzony w maliny. Powodem tego jest ciągle chyba brak zrozumienia i większej współpracy Microsoftu w kluczowych dla tego giganta projektach Open Source.

Microsoft Open Source'm stoi

Microsoft z Open Source miał trochę pod górkę. Steve Ballmer kiedyś powiedział "Linux jest rakiem" w kwestii GNU GPL. Dziś zapewne gigant z Redmond chciałbym o tym zapomnieć, gdyż Microsoft od jakiegoś już czasu jest firmą Open Source.

Pierwszą zmianą na plus było zatrudnienie w 2004 roku Billa Hilfa, lidera działu Open Source w IBM. Jak sam twierdzi, Microsoft zatrudnił go, gdyż firma nie wiedziała czym jest i jak działa idea otwartego oprogramowania. Zaś już od 2006 roku Microsoft był kontrybutorem w projektach takich jak Apache, PHP czy Eclipse, a od 2009... w samym piekle, czyli w projekcie Linuxa.

Od strony deweloperów .NET wszystko zmieniło się w momencie objęcia stanowiska przez Satya Nadellę w roku 2014. To wówczas ogłoszono, że kolejna rewolucja w święcie .NET - .NET Core - będzie Open Source. Od tego momentu Microsoft stał się firmą, która dla swoich deweloperów .NET coraz więcej miała do zaoferowania poprzez ideę Open Source. To sprawiło, że z drugiej strony otworzyły się drzwi do projektów, które do tej pory były zamknięte. Zaraz potem Microsoft przejął oazę Open Source - GitHuba. Ten ostatni krok pozwolił przenieść projekty ze stajni z Redmond, które były do tej pory hostowane na CodePlexie (jakie to było toporne...). Te wszystkie kroki sprawiły, że już w 2019 roku na Azure Linux był częściej używany niż Windows Server. A projektów o otwartych źródłach jest w Microsofcie bardzo wiele, tak samo jak projektów, w których gigant z Redmond jest kontrybutorem: Open Source w MS.

Trzeba to jasno powiedzieć, że Microsoft dostał olbrzymi zastrzyk innowacyjności, świeżości i różnorodności dzięki Open Source.

Jak to Open Source Microsoft'owi dał pstryczka w nos

Jako deweloper .NET widzę jednak, że nie do końca chyba jeszcze Microsoft zaważył, że projekty Open Source to nie tylko nowe możliwości i ogrom zalet, ale również mogą pojawić się tu komplikacje. Zaś zaciągnięty dług w społeczności otwarto źródłowej będzie trzeba kiedyś spłacić. Przedstawię tutaj moje TOP 3 przykładowych projektów Open Source dla ekosystemu .NET, z których Microsoft korzysta(ł) dość mocno w ostatnich latach, a które pokazały Microsoftowi czerwoną kartkę. Można by nawet rzec, że Microsoft zbytnio wyeksploatował każdy z tych.

Docker - świetna wirtualizacja, która stała się płatna

Docker jest jednym z bardziej (czy nawet najbardziej) znanym oprogramowaniem Open Source do wirtualizacji/konteneryzacji aplikacji. Microsoft już w 2014 roku ogłosił wsparcie w swoich projektach dla Dockera. Był to moment, gdy .NET Framework był klocem ściśle związanym z Windowsem, którego wrzucenie do Dockera było w teorii niemożliwe (w praktyce da się to zrobić, ale obraz runtime jest po prostu wówczas pełnym systemem Windows, można ale nie ma to większego sensu). Możliwe, że był to jeden z impulsów, aby zacząć tworzyć .NET Core, a w szczególności ASP.NET Core od zera, porzucając stary kod i powiązania z systemem Windows.

Docker stał się szybko jednym z filarów nowego środowiska .NET Core. Był świetnym przykładem na to, iż nowy runtime jest fatycznie tym czym .NET powinien być od początku. Docker szybko stał się popularny na lokalnych środowiskach deweloperskich, testerskich, czy na Azure. Microsoft wciągnął w Dockera nawet MS SQL i przygotował olbrzymią ilość obrazów w repozytorium Dockera, gotową do użytku. Sielanka trwała w najlepsze.

Microsoft szedł w Dockeryzację dalej. Prezentacje, kursy, oficjalna dokumentacja MS, wszystko bazowało na Dockerze. Gotowe szablony w Visual Studio do ASP.NET Core były przygotowane do lokalnego odpalenia aplikacji web w Dockerze. Przykładowe projekty odnośnie pisania microserwisów również bazowały na konfiguracji pod jedno tylko środowisko do konteneryzacji: Docker.

Redmond przygotował również WSL (Windows Subsystem for Linux), czyli w skrócie Linuxa działającego pod Windowsem (streszczając to do jednego zdania). Trzeba jasno przyznać, że był to strzał w dziesiątkę dla developerów. Możliwość bezpośredniej pracy z Linuxiem pod Windows jest olbrzymią wygodą, ale również, jak się może okazać, ratunkiem w przypadku konteneryzacji. Tutaj także Docker był priorytetem. Przeglądając GitHuba WSL można odnieść ciągle wrażenie, że był on tworzony z myślą o natywnej konteneryzacji Linuxowego Dockera pod Windows. Nawet szablon do zgłoszeń błędów w WSL zawiera w sobie pole do wstawienia wersji Dockera jaką posiadamy.

Deweloperzy .NET mogli błędnie przypuszczać, że Docker jest jedynym źródłem dokeryzacji. Microsoft tak bardzo skupił się na Dockerze i tak mocno go eksploatował, że zapomniał o tym, że stał się ofiarą vendor lock-in, czyli uzależnienia się od jednego dostawcy.

Pod koniec sierpnia tego roku Docker oznajmił, iż kończy z darmowym oprogramowaniem dla większych firm. Zgodnie z nową licencją duże firmy muszą wykupić płatny, miesięczny dostęp. Darmowy Docker Desktop (!) będzie dostępny jedynie dla użytku niekomercyjnego i/lub małych firm. Autorzy dają czas na migrację do nowej licencji do końca stycznia 2022 roku. Za wprowadzeniem zmian stoją oczywiście pieniądze, a dokładniej "potrzeba skalowania biznesu i dostarczania nowych ficzerów dla wszystkich subskrypcji Dockera".

Jak wygląda kwestia WSL w przypadku konteneryzacji różnej niż Docker i czy nadal Docker będzie tą jedyną oficjalną droga w przypadku kontenerów czy może Microsoft szykuje już jakąś inną alternatywę? Najbardziej na lodzie zostają deweloperzy .NET pod Windows, gdyż prócz Docker Desktop zbytnio nic sensownego nie istnieje na rynku (patrz wyżej pytanie o WSL)?

Wiele firm zapewne jest w dość niespodziewanym szachu. Do tej pory darmowa, otwarta technologia promowana przez Microsoft stała się płatna. Ewidentnie Microsoft trochę zaspał i skupił się na jednym dostawcy. Docker zauważył jak bardzo partner, w postaci giganta z Redmond, wypromował go pośród deweloperów .NET i uzależnił od siebie.

W ramach ciekawostek dodajmy jeszcze, że Kubernetes z różnych powodów odstawił na bok Dockera z końcem roku 2020.

IdentityServer - domyślne uwierzytelnianie w ASP.NET Core właśnie przestało być darmowe

ASP.NET Core jest krokiem milowym w aplikacjach mobilnym do Microsoftu. Tak na prawdę to nowa era, która wypromowała rozwiązanie, które działa na wielu platformach, jest szybkie, elastyczne, używane przez miliony, a jednocześnie bezpłatne i... Open Source.

Microsoft wiedząc o tym jak bardzo dobrym produktem jest ASP.NET Core, postanowił uwierzytelnianie oprzeć w nim o Open Sourcowe rozwiązanie IdentityServer bazujące na OpenID Connect i OAuth 2.0.

IdentityServer stał się niemal integralną częścią ASP.NET Core. Wszelakie prezentacje, cała dokumentacja oraz nawet szablony tworzenie gotowego projektu od Microsoftu bazowały na IdentityServer. Wielu deweloperów .NET zapewne nawet do teraz nie jest świadomych tego, że ich uwierzytelnianie bazuje na kodzie spoza oficjalnych paczek od Microsoftu.

I w tym momencie sielanka nie trwała w nieskończoność. Twórcy projektu oznajmili w 2020 roku, że IdentityServer4 będzie wspierane tylko do końca listopada 2022. Jednocześnie zakładają firmę, która skupia się już w obecnej chwili na IdentityServer5, które nie jest już darmowe na potrzeby produkcyjne.

Microsoft podobnie jak z Dockerem został z ręką w... czymś niemiłym. Twórcy IS przyznali, że przez ostatnie 3 lata dostali sumarycznie tylko $60,000 wpłat od 75 sponsorów (tylko od 12 firm). Jednocześnie ilość użytkowników projektu wystrzeliła do góry. Z tym wiąże się także większa ilość zgłoszeń błędów czy propozycji zmian, a także konfiguracji do przetestowania.

Mimo, że nikt tego nie mówi oficjalnie, wygląda na to, że Microsoft chyba zbyt mocno wydusił ten projekt jednocześnie nie dając wymiernego wsparcia od siebie. Twórcy tylko przyznają, że większość firm nadal nie liczy się, z odpowiednim wspięciem projektów Open Source.

Microsoft po ponad 7 miesiącach przyznał, że mają problem. Pomimo zmian w licencji nadal nadchodzący ASP.NET Core 6 będzie bazował na IS4. Microsoft jednocześnie wykłada karty na stół i oświadcza, że nie wie co zrobić z tym fantem dalej, jako iż IS4 traci zaraz wsparcie, a za IS5 trzeba zapłacić. Przyszłość autoryzacji w .NET 7 stoi pod znakiem zapytania. Firma z Redmond jest na tyle świadoma, że wiedzą iż na ten moment nie mają zasobów i wiedzy, aby pociągnąć wsparcie dla IS4 samemu lub stworzyć konkurencyjne rozwiązanie. Czekamy zatem co dalej.

Microsoft w przypadku IdentityServer4 ewidentnie trochę chyba zapomniał o autorach i społeczności skupionej pod tym, jakże ważnym w przypadku ASP.NET Core, projektem do uwierzytelniania użytkowników. Musimy zatem poczekać cierpliwie co stanie się z IS4 w 2022 (a może szybciej). Tworząc zaś nowy projekt ciężko powiedzieć czy iść w IS4, które już jest w stanie utrzymania tylko, czy szukać czegoś nowego.

Ocelot - Gateway API, na które Microsoft nie miał czasu

Ocelot to ciekawy projekt, który stał się kluczowym elementem pod wszelakie mikroserwisy tworzone w .NET. Microsoft mocno promował te rozwiązanie we wszelakich przykładach dobrego kodowania, prezentacjach i webinariach. Projekt faktycznie cieszył się sporym wzięciem i dość mocno był wykorzystywany w architekturach SaaS/mikroserwisów.

Jak zapewne się domyślacie i na ten projekt przyszedł koniec. Ostatnie wydanie pochodzi z grudnia 2020, a na GitHubie wisi duża ilość otwartych bugów i równie spora ilość Pull Requestów gotowych do code review/wrzucenia. Wszyscy zastanawiali się co się dzieje z tak kluczowym i promowanym projektem. Po kilku miesiącach ciszy autor na Twitterze przyznał, że nie ma czasu na dalszy rozwój projektu.

W tym przypadku Microsoft próbuje wyjść jednak obronną ręką i tworzy od zera projekt YARP (Yet Another Reverse Proxy). Niestety nadal jest on jeszcze w wersji, jak określają autorzy, nie do użytku na produkcji. Zatem zostaje stworzenie czegoś mniejszego samemu, stricte na potrzeby naszego projektu i czekanie na finalną wersję YARP. Szkoda, że Microsoft nie wsparł tego jakże ciekawego projektu i nie rozwijał go dalej, razem z całkiem sporą społecznością.

Podsumowanie

Tych kilka przykładów pokazuje głównie jak ciężko jest prowadzić współpracę ze społecznością Open Source w kwestii projektów, które stanowią podwaliny pod systemy komercyjne.

Nawet Microsoft, który przez ostatnie lata stał się znacznym kontrybutorem i propagatorem idei otwartego oprogramowania ma z tym problemy, przez co nieraz ma z tego powodu ciężki orzech do zgryzienia.

Oczywiście nie mam tutaj nic przeciwko spieniężaniu pracy włożonej w Open Source. Chcę zaznaczyć, że nawet duże firmy, jak Microsoft, ciągle mają problemy z tym jak współpracować i opiekować się projektami Open Source, które są na tyle wolne, że mogą odejść w dość niespodziewaną stronę w każdej chwili.