Dzisiejsza edycja będzie z gatunku tematycznych, ponieważ wszystkie dzisiejsze cztery newsy posłużą nam do rozmowy na jeden, bardzo konkretny temat – pieniędzy. Każdy z nich posłuży nam bowiem pozwoli nam zerknąć, skąd w ogóle biorą się pieniądze na te wszystkie fajne rzeczy, które każdego tygodnia mam okazję opisywać.
1. Przyszłość projektu Vavr: Od wygaśniętej domeny do poszukiwań nowego opiekuna
Mink, schmink, money, schmoney
Think your hot now don’t ya honey
What have you got if you haven’t got love?
A zaczniemy sobie od dość popularnej w moich kręgach, ale in the great scheme of things jednak dość niszowej biblioteki. A opowieść zaczniemy od wygaśniętej domeny.
Początkiem grudnia strona internetowa Vavr.io przestała działać 2023 roku, co wywołało dyskusję na temat przyszłości projektu Vavr i jego utrzymania. Lider projektu, Daniel Dietrich, potwierdził problem ze stroną i wykorzystał okazję, aby wyrazić chęć wycofania się z projektu, podkreślając potrzebę znalezienia nowego właściciela i większej ilości aktywnych współtwórców. Mimo bowiem ich dość licznej „na papierze” grupy, Daniel wskazał na rozbieżność między liczbą współtwórców a odpowiedzialnościami, które są gotowi przejąć – projekt w dużej mierze opierał się więc na jego zaangażowaniu w podejmowanie decyzji strategicznych, utrzymanie jakości kodu i ogólne zarządzanie. Zapoczątkowana w grudniu dyskusja ujawniła, że choć społeczność ceni sobie projekt, przejście na nowe kierownictwo jest konieczne, aby zapewnić jego trwałość i ciągły rozwój.
No dobra, ale czym ogólnie jest Vavr? Wcześniej znany jako Javaslang (zmiana nazwy to jest w ogóle temat na swoją własną opowieść), to biblioteka zaprojektowana aby umożliwić programistom Javy korzystanie z paradygmatów programowania funkcyjnego. Vavr wprowadza niemutowalne kolekcje i struktury takie jak Option
, Try
, Either
, i Lazy
, które pomagają w zarządzaniu błędami, wyjątkami, czy polami nullowalnymi, a także masę różnych funkcyjnych utili. To sprawia, że Vavr jest narzędziem dla programistów, którzy twierdzą, że standardowe API JDK nie są wystarczająco funkcyjne.
Bo po prawdzie, to czasem nie są:
import java.util.Arrays;
import java.util.List;
public class Main {
public static void main(String[] args) {
List<Integer> userIds = Arrays.asList(1, -1, 0);
userIds.stream().forEach(userId -> {
try {
String userData = getUserData(userId);
try {
String result = processUserData(userData);
System.out.println(result);
} catch (Exception e) {
System.out.println("Error processing user data");
}
} catch (Exception e) {
System.out.println("Error fetching user data");
}
});
}
public static String getUserData(int userId) throws Exception {
if (userId <= 0) {
throw new Exception("Invalid user ID " + userId);
}
return "John Doe";
}
public static String processUserData(String userData) throws Exception {
if (userData.isEmpty()) {
throw new Exception("User data is empty");
}
return "User name is " + userData;
}
}
vs
import io.vavr.control.Either;
import java.util.Arrays;
import java.util.List;
public class Main {
public static void main(String[] args) {
List<Integer> userIds = Arrays.asList(1, -1, 0);
userIds.stream()
.map(Main::getUserData)
.map(userDataResult -> userDataResult.flatMap(Main::processUserData))
.forEach(result -> {
result.peek(System.out::println)
.peekLeft(System.out::println);
});
}
public static Either<String, String> getUserData(int userId) {
if (userId <= 0) {
return Either.left("Error fetching user data");
}
return Either.right("John Doe");
}
public static Either<String, String> processUserData(String userData) {
if (userData.isEmpty()) {
return Either.left("Error processing user data");
}
return Either.right("User name is " + userData);
}
}
Pewnie ktoś mi powie, że przykłady pod tezę – ale wiecie o co chodzi 😉.
Na domenie sprawa się jednak nie skończyła. Końcem maja Daniel Dietrich ogłosił swoją decyzję o zaprzestaniu aktywnego zaangażowania w projekt i jego rozwoju – w tym utrzymywania strony internetowej i dokumentacji – określając najnowszą wersję Vavr 0.10.4 jako 'kompletną’ pod względem funkcjonalności. Pomimo wcześniejszych rozważań dotyczących przekazania projektu fundacji Eclipse Foundation, Daniel postanowił zachować własność całości i zamrozić projekt, sugerując, że zainteresowani powinni samodzielnie zforkować kod Vavr, (który jest dostępny na licencji Apache 2.0) i rozwijać go niezależnie. Powody tej decyzji wynikają z potrzeby nowego początku dla Vavr’a. Daniel uważa, że projekt wymaga nowego opiekuna z pasją do programowania funkcyjnego, który poświęci czas i energię, by opracować i skutecznie komunikować nowy kierunek oraz podnieść zaangażowanie społeczności.
Oczywiście, decyzja spotkała się jak zwykle z głośnym sprzeciwem społeczności, niezadowolonej z takiej a nie innej decyzji twórcy. Dlatego w ramach pewnej wolty, Daniel w kolejnym poście zdecydował się zaoferować możliwość sponsorowanej pracy nad projektem. Ta nowa opcja pozwala zainteresowanym firmom po prostu zatrudnić go do pracy nad rozwojem funkcji, naprawą błędów lub aktualizacją dokumentacji, a także korzystania z usług konsultingowych związanych z Vavrem.
Cała sytuacja świetnie wpisuje się w obecny obraz open source, gdzie pojedynczy twórcy wykonują ogromną pracę, ale trudno znaleźć chętnych na sponsoring ich wysiłków. W dobie cięć inwestycji i redukcji kosztów, nawet największe firmy tną wydatki na rozwiązania, które nie przynoszą natychmiastowych zysków. Dla wielu managerów rozwiązania open source mogą wydawać się takim „tłuszczykiem”, który można zredukować. Mimo że projekty takie jak Vavr są cenione przez społeczność, brak stabilnego finansowania i wsparcia może prowadzić do ich zamrożenia lub całkowitego porzucenia. Przypadek Vavr jest zatem doskonałym przykładem wyzwań, przed którymi stoją twórcy oprogramowania open source, starając się zrównoważyć pasję z rzeczywistością finansową.
Ogólnie, w Javie historycznie większość projektów finansowana była na dwa sposoby – albo wspierane było przez wszelkiej maści fundacje, albo komercyjne firmy. Często powodem zresztą nie są tylko pieniądze. Czasem równie ważna pozostaje chęć stania się rynkowym standardem. I chyba właśnie z takim przypadkiem mamy do czynienia w Quarkusie, o czym przeczytanie już w następnej sekcji…
Zainstaluj teraz i czytaj tylko dobre teksty!
2. Quarkus szuka nowego domu: Przeniesienie projektu pod opiekę fundacji
Listen here
Now that ain’t workin’ that’s the way you do it
You play the guitar on the MTV
That ain’t workin’, that’s the way you do it
Money for nothin’ and your chicks for free
…Quarkus szuka bowiem dla siebie nowego domu, a tym domem ma być fundacja.
Od momentu wydania w marcu 2019 roku, Quarkus rozwijany był pod egidą Red Hat, tworząc w koło siebie ekosystem ponad 700 rozszerzeń. Dlatego też, zauważając wpływ i szerokie przyjęcie w społeczności, zespół Quarkus, pod przewodnictwem Maxa Rydahla Andersena, proponuje przejście projektu pod opiekę fundacji. Ten ruch ma na celu zwiększenie tempa adopcji, poprawę przejrzystości i uniezależnienie projektu od jednej, konkretnej korporacji, co umożliwi szerszą współpracę i uczestnictwo wielu różnych dostawców.
W poście Quarkus in a Fundation Andersen szczegółowo opisując wizję dwuetapowego procesu, który rozpocznie się od bardziej otwartego zarządzania — polepszając przejrzystość i komunikację w ramach projektu. Obejmuje to zapewnienie społeczności większej widoczności procesów decyzyjnych i większe możliwości zaangażowania w zarządzanie projektem. Kolejnym krokiem będzie zaś oficjalne przeniesienie Quarkus do zewnętrznej fundacji, przy dalszym wsparciu ze strony Red Hata. Kryteria wyboru nowego domu dla projektu to zapewnienie utrzymaniu szybkiego tempa dostaw, widoczności, niezależności technologicznej oraz elastyczności licencyjnej. Ten strategiczny ruch ma na celu zabezpieczenie pozycji Quarkus jako de facto standardu dla aplikacji natywnych chmorowo aplikacji javowych.
Ludzie czasami nie doceniają, jak silne jest znaczenie marki Apache lub Eclipse w dużych przedsiębiorstwach i jak bardzo te przedsiębiorstwa obawiają się uzależnienia od jednego dostawcy, gdy taka fundacja jest nieobecna. Ułatwi to wiele rozmów, zwłaszcza że, mimo iż cenię Red Hat, mają oni w swojej historii kilka kontrowersyjnych ruchów.
Moim zdaniem, to świetna wiadomość, całość brzmi bowiem podobnie do niedawnej sytuacji z EclipseStore i MicroStream. MicroStream nadal wykonuje dużą część pracy, ale będąc częścią Eclipse, obstawiają, że w przyszłości staną się standardem – co nie byłoby możliwe, gdyby nadal było rozwijane pod marką MicroStream. Miejmy tylko nadzieję, że to nie będzie klasyczny przypadek „śmierci przez open-sourcing” i że wszystko będzie dobrze.
Computer sentences Quarkus to death… by snu snu
Po prostu chciałbym zobaczyć przyszłość, w której Quarkus staje się graczem równym Springowi. A skoro mowa o Spring, przejdźmy do następnej sekcji…
3. Spring I/O 2024, State of Spring i szersze konsekwencje przejęcia VMware przez Broadcom
Niedawno miała miejsce bowiem doroczna konferencja Spring I/O, czyli najważniejsza impreza poświęcona Springowi. Jego Keynote znajdziecie tutaj:
Sam nie będę tutaj listował tutaj poruszanych tematów, ponieważ wyręczy newsletter Tech Talks Weekly, na którym znajdziecie tam listę najpopularniejszych talków wraz z ich Vox Populi. Ogólnie jak zawsze polecam do subskrybowania, zostawmy te rzeczy specjalistom.
Ostatnio wypuszczone zostały też wyniki State of Spring Survey. Pozwolę sobie zatem szybkim rzutem oka zobaczyć, co znajdziemy w opracowaniu:
12% respondentów już integruje Generative AI w aplikacjach Spring, mimo wczesnej wersji projektów takich jak Spring AI. Wskazując na rosnące zainteresowanie i adopcję AI w środowisku Spring i chyba całym ekosystemie. Nie bez przyczyny pewnie coraz częściej wpadam na termin RAGOps.
Jednym z głównych wyzwań jest utrzymanie aktualności oprogramowania; 41% respondentów nadal używa Spring Boot 2.7, mimo że dostępne są nowsze wersje. 65% respondentów przeprowadza aktualizacje ręcznie, co pokazuje potrzebę lepszych narzędzi do automatyzacji – może właśnie do tego uda nam się tego całego AI zaprzęgnąć.
GraalVM i Project Leyden są postrzegane jako technologie o dużym potencjale, jednak ich adopcja jest ograniczona ze względu na wyzwania techniczne, takie jak problemy z kompatybilnością (51%) i długie czasy kompilacji (22%).
Kubernetes jest używany w 65% środowisk Spring, z czego 52% uruchamia własną dystrybucję Kubernetes, a 33% korzysta z platform opartych na Kubernetes, takich jak OpenShift.
Ogólnie, raczej mało rzeczy wybijających z bucików, ale rzut oka na szerszy ekosystem zawsze na propsie. Jedyne na co trzeba uważać, to na to, że tak naprawdę w badaniu wzięło udział poniżej 1.5 tysiąca uczestników i to pewnie jednak mocniej „zainwestowanych”, ale to już problem z każdymi danymi.
To teraz wpasujmy to jeszcze w nasz przewodni temat. Dla nikogo zaskoczeniem nie będzie, że duże projekty Open-Source w dzisiejszych czasach zwykle posiadają swoich korporacyjnych sponsorów, a wielu ludzi rozwijających je robią to w ramach firmowych etatów. Pivotal Software, stojący za Springiem i specjalizujący się w rozwoju platformy chmurowej i narzędzi programistycznych, został pierwotnie założony jako niezależna firma przez EMC Corporation, która posiadała także większościowy udział w VMware, lidera w branży wirtualizacji i infrastruktury chmurowej. W 2012 roku VMware i EMC wspólnie zainwestowały w Pivotal, a w 2013 roku Pivotal został oficjalnie wydzielony jako oddzielna firma. W 2019 VMware przejęło Pivotal, co nie tylko pogłębiło ich związek, ale także wzmocniło pozycję VMware w obszarze rozwoju aplikacji i usług chmurowych, korzystając z ekspertyzy Pivotal w tym zakresie – jak choćby ich rozwiązań Cloud Foundry.
Tu jednak historia się nie kończy. Broadcom, znany głównie z produkcji półprzewodników, podjął decyzję o rozszerzeniu swojej działalności na rynku oprogramowania, co było częścią szerszej strategii dywersyfikacji firmy. Wybór padł na VMware, jako że firma uznawana jest za lidera w dziedzinie wirtualizacji i infrastruktury chmurowej, co stanowiło atrakcyjny kierunek rozwoju dla Broadcom. Przejęcie rozpoczęte w maju 2022, a będące jedną z większych transakcji tego typu opiewającą na 69 miliardów dolarów domknięto 22 listopada. Bardzo szybko po transakcji doszło też do serii zwolnień w firmie.
Po przejęciu VMware przez Broadcom na początku 2024 roku, nastąpiły znaczące zmiany w modelu licencjonowania. Broadcom zrezygnował z licencji wieczystych na rzecz subskrypcji, co ma na celu uproszczenie oferty produktowej oraz zapewnienie przewidywalnych modeli wydatków dla klientów. Klienci posiadający aktywne umowy licencyjne mogą korzystać z obecnych licencji do końca okresu obowiązywania umowy, po czym będą musieli przejść na model subskrypcyjny. Dodatkowo, zmieniono licencjonowanie z bazującego na procesorach na bazujące na rdzeniach procesorów, co może prowadzić do wzrostu kosztów dla klientów z mniejszymi konfiguracjami CPU. Broadcom wprowadził też istotne zmiany w sieci partnerów i resellerów VMware, zmniejszając ich liczbę i przejmując bezpośrednią obsługę dużych kont strategicznych, co może wpłynąć na relacje i koszty dla klientów.
Społeczność technologiczna zareagowała w różnorodny sposób, głównie z obawami i niezadowoleniem – zmiana wywołała liczne kontrowersje, zwłaszcza wśród klientów, którzy preferowali jednorazowe opłaty za licencje. Ci obawiają się zwiększonych kosztów, co potwierdzają raporty o wzrostach cen licencji nawet do 1200%. To wywołało poszukiwania alternatyw dla VMware, takich jak Proxmox czy Microsoft Azure. Dodatkowo, zmiany w strukturze partnerów i resellerów VMware przez Broadcom spowodowały niepokój wśród mniejszych partnerów, którzy mogą stracić możliwość sprzedaży produktów VMware.
Jakie z tego wnioski co do Springa? Na razie absolutnie żadne, ale wydaje mi się, że historia z VMWare jest na tyle głośna, że warto aby szerzej przecieknęła też w nasze JVM-owe rejony.
Jednakże, mimo całej swojej doniosłości, Broadcom i Spring muszą ustąpić miejsca jeszcze większemu gigantowi. Na koniec zostawiłem sobie więc wisienkę na korporacyjnym torcie: Oracle.
Zainstaluj teraz i czytaj tylko dobre teksty!
4. Oracle w akcji: Audyty, AI i partnerstwa chmurowe
Oh no, not me
I never lost control
You’re face to face
With the man who sold the world
Kiedy zobaczyłem, że Java znowu wylądowała na szczytach technologicznych redditów, wiedziałem co się święci…
Shit… here we go again.
Według theregister.com, Oracle po raz pierwszy wysłał listy audytowe dotyczące Javy do firm z listy Fortune 200. Zmiany te wynikają z nowej struktury licencyjnej wprowadzonej w styczniu 2023 roku, nazwanej Java SE Universal Subscription. Nowy model oferuje jednolitą, niskokosztową miesięczną subskrypcję obejmującą licencję i wsparcie Java SE na różnych platformach, ale wymaga licencjonowania oprogramowania na pracownika, co czyni go znacznie droższym – według szacunków Gartnera od dwóch do pięciu razy droższym niż poprzedni model. Oracle, wcześniej skupiający audyty na mniejszych firmach, teraz kontroluje również większe korporacje. Craig Guarente z Palisade Compliance ujawnił, że audyty obejmują zarówno długoletnich subskrybentów Javy, jak i firmy wcześniej niepłacące za Javę. Te zmiany wywołały dyskusje na temat kosztów licencyjnych, z prognozami, że większość aplikacji Java może przejść na środowiska uruchomieniowe stron trzecich do 2026 roku z powodu wzrostu kosztów.
Jest to już kolejny przykład, gdy temat licencji Oracle trafia na topki agregatorów, aczkolwiek tym razem całość wydaje się szczególnie kuriozalna. Bo wiecie, to nie jest tak, że firmy z listy Fortune 200 nie wiedzą, jakie modele licencyjne ma ich oprogramowanie i że próbują coś ukryć przed Oracle. Jeśli pojawiają się problemy z audytem, to raczej z powodu ogólnego bałaganu, a nie dlatego, że nikt się Oracle nie spodziewał. Te firmy to przecież główni klienci Oracle, płacący za bazy danych, systemy HR i inne usługi. I o ile mogę sobie wyobrazić, że taki list mógłby przestraszyć startup i stać się medialnym wydarzeniem, to tutaj naprawdę nie wiem, dlaczego to zdobywa tyle klików, poza standardowym „Oracle złe”.
Ale myślę, że w Oracle nikt się nie przejął, bo firma odniosła ostatnio kilka interesujących sukcesów. Firma ogłosiła bowiem współpracę z OpenAI i Microsoftem, zapewniając rozszerzenie platformy Microsoft Azure AI na infrastrukturę Oracle Cloud Infrastructure (OCI) i zwiększając możliwości operacyjne OpenAI – OCI ma zaoferować OpenAI do 64 tys. procesorów NVIDIA Blackwell GPU lub superchipów GB200 Grace Blackwell. Larry Ellison podkreślił, że współpraca ta zaspokoi rosnące zapotrzebowanie na potężną infrastrukturę AI, pozycjonując OCI jako czołowy wybór dla rozwoju AI.
Dodatkowo, Oracle i Google Cloud ogłosiły partnerstwo, które umożliwi klientom łączenie technologii Oracle Cloud Infrastructure (OCI) z Google Cloud. Oracle Interconnect dla Google Cloud zostanie wprowadzony na 11 rynkach, umożliwiając wdrażanie aplikacji bez dodatkowych opłat za transfer danych między chmurami. Dodatkowo, jeszcze w tym roku zostanie wprowadzona nowa usługa Oracle Database@Google Cloud, usprawniająca działanie bazy Oracle w GCP, zapewniając na niej możliwości zbliżone do tych oferowanych przez OCI. Co ciekawe, Sundar Pichai, CEO Google i Alphabet, podkreślił, że partnerstwo pomoże wspólnym klientom korzystać z bazy danych Oracle i aplikacji w połączeniu z… możliwościami AI Google Cloud. Nie wiem czy nie będę za jakiś czas odszczekiwał, ale Oracle wygląda na czarnego konia w bitwie chmurze obliczeniowej i podejrzewam, że będziemy ich widzieć coraz więcej w przestrzeni enterprise. Przez lata zbudowali tam wiele relacji i wydają się być bardzo „neutralnym” partnerem, z którym łatwo jest w zasadzie każdemu zawierać strategiczne sojusze.
Oczywiście to nie tak, że czego Oracle się dotknie zamienia się w złoto. Przykładowo, Oracle Advertising, spółka niegdyś warta 2 miliardy dolarów, zostaje zamknięta z powodu spadku przychodów do 300 milionów dolarów w roku fiskalnym 2024. Decyzja ta odzwierciedla strategiczne wycofanie się Oracle z biznesu reklamowego w obliczu surowszych norm prywatności i malejących zysków z danych użytkowników, co wydaje się być szerszym trendem w całej branży. Jednocześnie, w dobie powyższych ogłoszeń, giełda reaguje na działania Oracle bardzo pozytywnie.
Ogólnie dlaczego ogólnie o tym pisze? Bo jeśli śledzicie jak wychodzą kolejne JEPy, to zobaczycie, że jednak większość osób które nad nimi pracują, to są osoby pracujące w Oracle. Więc choć to nie jest tak, że Java umrze bez tej firmy (za dużo inwestycji na całym świecie), to jednak z pewnością cały ekosystem miałby pod górkę.
I to wszystko na ten tydzień, Tarnished Ones. Mam pewne plany na weekend.
PS: Dostałem piękny prezent na Dzień Ojca od mojej żony i córki, który obchodzimy w Polsce w tę niedzielę. Rano odwiedzą kuzynkę żony i wrócą wieczorem, a ja będę mógł zostać sam w domu 🎮