Kategoria: Open Source

OpenCode v1.3.5: Drobne, ale kluczowe poprawki dla stabilności i wydajności AI
Choć cyfrowe światy inżynierii oprogramowania często rozbrzmiewają fanfarami przy zapowiedziach wielkich, przełomowych wydań, to prawdziwa siła dojrzałego projektu często leży w systematycznych, drobiazgowych udoskonaleniach. Najnowsza, stosunkowo niewielka aktualizacja OpenCode do wersji 1.3.5, opublikowana 29 marca 2026 roku, jest doskonałym tego przykładem. Skupiając się na dwóch konkretnych, lecz fundamentalnych obszarach, zespół deweloperski dostarcza poprawki, które bezpośrednio wpływają na codzienne doświadczenia milionów programistów korzystających z tego open-source'owego asystenta AI.

Naprawa asynchronicznych haków wtyczek: Fundament stabilności ekosystemu

Pierwszym i najważniejszym punktem wydania jest naprawa mechanizmu plugin hooks w celu prawidłowej obsługi operacji asynchronicznych. Aby zrozumieć wagę tej zmiany, trzeba zagłębić się w architekturę OpenCode. Haki wtyczek to potężne punkty integracji, które pozwalają zewnętrznym rozszerzeniom na wstrzykiwanie własnej logiki do rdzenia aplikacji, modyfikując lub rozszerzając jej zachowanie.

Problem z nieprawidłową obsługą asynchroniczności mógł prowadzić do subtelnych, lecz uciążliwych błędów. W praktyce nowoczesne wtyczki często wykonują operacje, które z natury są asynchroniczne: pobieranie danych z API, komunikacja z bazami danych, przetwarzanie plików czy wykonywanie zapytań sieciowych. Jeśli mechanizm haków nie zarządzał poprawnie obietnicami (Promises) lub operacjami async/await, skutki mogły być różnorodne: od „wiszących” wątków i częściowo wykonanych zadań, przez wycieki pamięci, po całkowite zawieszenie się konkretnych funkcjonalności. Dla użytkownika końcowego objawiało się to jako niedeterministyczne błędy, trudne do zdebugowania i zakłócające płynność pracy.

Poprawka w wersji 1.3.5 stabilizuje więc sam fundament, na którym budowany jest cały ekosystem rozszerzeń. Jest to szczególnie istotne w kontekście zautomatyzowanych procesów DevOps oraz środowisk produkcyjnych, gdzie powtarzalność i niezawodność są wartościami nadrzędnymi. Wzmocnienie tej warstwy zwiększa zaufanie deweloperów do zaawansowanych konfiguracji opartych na wtyczkach.

Udoskonalone prompty GPT: Koniec z irytującymi odniesieniami do plików

Drugi filar tej aktualizacji dotyczy interakcji z modelami językowymi. Zespół OpenCode dostosował prompty systemowe dla modeli GPT, które nie są wariantami Codex (takich jak GPT-4o czy GPT-4 Turbo), czyniąc je bardziej minimalistycznymi. Co to oznacza w praktyce? Prompt systemowy to ukryta instrukcja wysyłana do modelu przed właściwą konwersacją użytkownika, która nadaje kontekst, ton i określa sposób działania asystenta.

Poprzednia wersja promptów mogła prowadzić do irytujących zachowań, szczególnie w kontekście odwołań do plików. Asystent mógł nadmiernie komentować ścieżki plików, niepotrzebnie je powtarzać lub w nietypowy sposób formatować odniesienia w swojej odpowiedzi, co rozpraszało uwagę programisty i zaśmiecało output. Nowy, odchudzony prompt ma na celu wyeliminowanie tych drobnych niedogodności, sprawiając, że komunikacja z modelem jest bardziej bezpośrednia, efektywna i skupiona na meritum – generowanym kodzie.

Warto zauważyć, że prompt został wymodelowany na podstawie sprawdzonego wzorca z Codex CLI, co wskazuje na pragmatyczne podejście zespołu: wykorzystanie istniejących, skutecznych rozwiązań zamiast wymyślania koła na nowo. To dostosowanie bezpośrednio przekłada się na wyższą jakość współpracy człowiek-AI, redukując zbędne obciążenie poznawcze podczas sesji programistycznych.

Kontekst szerszych wysiłków rozwojowych

Choć wersja 1.3.5 zawiera tylko dwie oficjalne zmiany, nie istnieje w próżni. Jest częścią intensywnej serii wydań (1.3.x), która koncentruje się na refaktoryzacji architektury wewnętrznej w kierunku wykorzystania biblioteki Effect. Ten paradygmat programowania, skupiony na czystych funkcjach i zarządzaniu efektami ubocznymi, ma na celu radykalne poprawienie niezawodności, testowalności i obsługi błędów w całym systemie. Poprawki dotyczące asynchroniczności w plugin hooks są naturalnym owocem tych głębszych prac architektonicznych.

Ponadto wcześniejsze i późniejsze wydania z linii 1.3.x wprowadzają liczne ulepszenia pokrewne do stabilności wersji 1.3.5, takie jak: poprawa wydajności startowej aplikacji, lepsze zarządzanie pamięcią przez TypeScript LSP, niezawodniejsze migracje magazynu danych (storage) zapobiegające ich uszkodzeniu oraz zaawansowane mechanizmy obsługi błędów połączeń sieciowych (MCP, web fetches).

Dlaczego to ma znaczenie dla społeczności?

OpenCode nie jest już niszowym eksperymentem. Z ponad 140 tysiącami gwiazdek na GitHubie, 850 współtwórcami i 6,5 milionami deweloperów korzystających z narzędzia miesięcznie, projekt stał się kluczową infrastrukturą w ekosystemie AI-assisted development. W tej skali nawet pozornie drobna niestabilność lub błąd w interfejsie może wpłynąć na produktywność tysięcy osób. Dlatego każda aktualizacja, która eliminuje źródło błędów lub usprawnia komunikację, ma realny, pozytywny wpływ na globalną społeczność programistyczną.

Systematyczne udoskonalanie podstaw – jak stabilizacja haków wtyczek i wygładzenie interakcji z AI – jest tym, co odróżnia dojrzałe, zrównoważone projekty open source od tych, które pozostają w fazie eksperymentalnej. Wersja 1.3.5, choć skromna w zapowiedziach, jest kolejnym solidnym krokiem OpenCode w kierunku bycia niezawodnym, niezbędnym narzędziem w arsenale każdego programisty przyszłości.

Źródła
2026-04-09
AI „Vibe Coding” – czy otwarte oprogramowanie przetrwa zalew sztucznej inteligencji?
Otwarte oprogramowanie przeżywa kryzys egzystencjalny. Jego główni bohaterowie – wolontariusze i opiekunowie projektów – zamykają drzwi przed światem. Niektórzy opiekunowie zawieszają długoletnie programy nagród za zgłaszanie błędów. Inni wprowadzają zakazy kodu generowanego przez AI w swoich projektach. Jeszcze inni decydują się na automatyczne zamykanie zewnętrznych próśb o scalenie kodu (pull requesty). To nie jest lokalny incydent. To reakcja na zalew automatycznych, niskiej jakości treści, z którymi ludzie nie są w stanie już wygrać.

Problem jest jednak głębszy niż tylko chwilowe znużenie. Pod powierzchnią kryje się systemowe zagrożenie dla całego modelu rozwoju open source. Chodzi o zjawisko delegowania interakcji z otwartym oprogramowaniem na asystentów AI.

Czym jest to zjawisko i dlaczego niszczy społeczność?

Delegowanie interakcji z OSS na AI to w skrócie sytuacja, w której programista nie czyta dokumentacji, nie zagląda na GitHub Issues, nie rozmawia z opiekunami. Zamiast tego, agent AI samodzielnie dobiera potrzebne paczki, próbuje łączyć kod i generuje prośby o zmiany. Użytkownik jest odcięty od społeczności.

To łamie podstawową zasadę, na której przez dekady stało open source: ekonomię uwagi i uznania. Opiekunowie projektu rzadko zarabiają na nim bezpośrednio. Ich nagrodą jest reputacja, uznanie społeczności, możliwości zawodowe czy darowizny. A te rosną dzięki bezpośrednim interakcjom: gdy ktoś przeczyta dokumentację, zgłosi przemyślany błąd, wystawi gwiazdkę na GitHubie, wreszcie – prześle wartościową poprawkę.

Delegowanie interakcji do AI omija ten cały obieg. AI korzysta z kodu, ale nie angażuje się społecznie. Masowe upowszechnienie się tej praktyki może tworzyć negatywną pętlę sprzężenia zwrotnego. Im więcej użytkowników-delegatów, tym mniej spojrzeń na dokumentację, mniej ludzkich raportów błędów, a w konsekwencji – mniej motywacji dla opiekunów do dalszej pracy. Ekosystem może się kurczyć.

Zalew niskiej jakości treści – codzienność opiekunów projektów

Teoria przekłada się na bolesną praktykę. Opiekunowie są bombardowani przez „sztuczny szum”.

** Niektórzy opiekunowie zamykają programy bug bounty, obserwując znaczący wzłos liczby zgłoszeń generowanych przez AI, które są trudne do odróżnienia od ludzkich i obniżają ogólny wskaźnik trafnych raportów.** Niektóre projekty otrzymują ogromne prośby o scalenie kodu (PR). Kod bywa poprawny składniowo, ale pozbawiony głębszego zrozumienia. Gdy opiekunowie zapytają autora o wyjaśnienia, ten nie potrafi odpowiedzieć. Złamany zostaje społeczny kontrakt, oparty na wzajemnym zrozumieniu.
- Jak opisują niektórzy opiekunowie, zmieniła się rola etykiety „good first issue”. Kiedyś przyciągała początkujących, którzy z czasem stawali się pełnoprawnymi współtwórcami. „Teraz oznaczamy coś jako 'good first issue' i w mniej niż 24 godziny jesteśmy absolutnie zalewani niskiej jakości szumem, który odbiera czas na prawdziwą pracę” – mówi jeden z nich.
Czas to kluczowy zasób. AI wygeneruje kod w sekundy, ale opiekun potrzebuje 30 minut lub więcej, by zweryfikować, czy to nie jest bezsensowna halucynacja, nie łamie architektury i czy w ogóle ma sens. Ta dysproporcja jest druzgocąca.

Odpowiedź społeczności: od zakazów do izolacji

Reakcje są różne, ale łączy je frustracja i chęć odzyskania kontroli.
- Zero tolerancji: Niektórzy opiekunowie wprowadzają zakaz zgłaszania kodu z AI bez uprzedniej zgody. „To nie jest stanowisko anty-AI. To jest stanowisko anty-idiotyczne. Chcemy wartościowych wkładów, niezależnie od tego, jak są tworzone” – tłumaczą.
- Całkowita izolacja: Inni, po odkryciu, że ich własne skrypty AI generowały nieprecyzyjne zgłoszenia, które potem inni karmili swoim AI, decydują się zamknąć projekt na zewnętrzne PR. Ich pytanie jest fundamentalne: „Jeśli pisanie kodu jest łatwą częścią, po co miałbym chcieć, żeby pisał go ktoś inny?”. Dla nich prawdziwą wartością jest zrozumienie problemu, a nie sama linijka kodu.
- Ograniczenia systemowe: Niektóre projekty wprowadzają całkowity zakaz używania kodu generowanego przez AI w oficjalnych repozytoriach. To radykalne, ale jasne stanowisko.
Problem w tym, że wykrywanie naruszeń takich zakazów za rok czy dwa może stać się funkcjonalnie niemożliwe. AI będzie pisać coraz bardziej „ludzko”.

Gdzie leży przyczyna? Niewspółmierne bodźce platform

Opiekunowie walczą nie tylko z algorytmami, ale też z logiką platform, na których działają ich projekty. Niektórzy diagnozują to brutalnie: „Zalew niskiej jakości treści z AI to atak na opiekunów open source, a platformy hostingujące projekty OSS nie mają bodźców, żeby to zatrzymać. Wręcz przeciwnie, są zmotywowane, by pompować statystyki AI-generowanych kontrybucji, żeby pokazać 'wartość’ swoim akcjonariuszom”.

Platformy mogą wprowadzać funkcje generowania zgłoszeń przez asystentów AI, nie dając opiekunom wystarczających narzędzi do ich filtrowania. Dla platformy każda aktywność – nawet bezwartościowa – jest punktem w dashboardzie, dowodem na „żywotność” ekosystemu. Dla opiekuna to kolejna godzina straconego czasu.

W ten sposób platformy mogą czerpać wartość z open source (np. trenowanie na nim modeli AI, pozyskiwanie użytkowników), ale nie inwestować w jego zrównoważony rozwój. Przecina się więź między użytkownikiem a twórcą.

Ekonomia bez zaangażowania: co dalej z open source?

Na scenie działają dwie przeciwstawne siły.

Z jednej strony są korzyści efektywnościowe. AI obniża koszty korzystania i budowania na OSS. To może przyciągać więcej programistów i zwiększać podaż kodu, dając krótkoterminowy zastrzyk produktywności.

Z drugiej strony jest przesunięcie popytu. Użytkownicy delegujący wszystko do AI odcinają opiekunów od źródeł ich wynagrodzenia (w rozumieniu reputacji, pracy). To może prowadzić do długoterminowej kontrakcji: wyższe bariery wejścia dla nowych projektów, zanikanie średniej wielkości bibliotek, spadająca ilość i jakość oprogramowania.

Pojawiają się obserwacje, że:
** Niektóre platformy Q&A odnotowują spadek aktywności po premierze zaawansowanych czatów AI, ponieważ pytania przenoszą się do prywatnych konwersacji.** Niektóre projekty notują rosnącą liczbę pobrań, ale spadający ruch w dokumentacji i przychody komercyjne. Sukces metryczny nie przekłada się na nagrodę dla twórców.

Pojawiają się propozycje rozwiązań systemowych, jak model redystrybucji przychodów, gdzie platformy AI przekazywałyby część przychodów do projektów, z których korzystają ich modele. Obliczenia pokazują jednak, że użytkownicy delegujący interakcje do AI musieliby płacić znaczną część tego, co generują bezpośredni użytkownicy – co może być mało realne.

Podsumowanie: przyszłość w rękach (ludzkich) decydentów

Kryzys związany z delegowaniem interakcji do AI to nie opowieść o technologii, która wyręcza człowieka. To historia o systemie, który może przestać działać, gdy zabrano z niego ludzkie zaangażowanie. Otwarte oprogramowanie zawsze było bardziej społecznością niż zbiorem plików. AI, używane bezmyślnie, może rozpuścić tę społeczność w kwasie krótkoterminowej wygody.

Skutki mogą być nierówne: „Popularne biblioteki wciąż znajdą sponsorów. Mniejsze, niszowe projekty najprawdopodobniej ucierpią. Ale wiele obecnie udanych projektów zaczynało się od jednej osoby, która chciała rozwiązać konkretny problem. Jeśli opiekunowie małych projektów się poddadzą, kto stworzy następny wielki projekt?”.

Odpowiedź na to pytanie pisze się teraz. Przez decyzje opiekunów, którzy zamykają swoje projekty, oraz przez brak działań platform, które mogą woleć liczyć sztuczne interakcje niż chronić prawdziwą współpracę. Przyszłość open source zależy od tego, czy uda nam się na nowo zdefiniować wartość ludzkiego wkładu w świecie, który kod może już generować, ale wciąż nie potrafi go rozumieć.
2026-03-02
Kiedy AI odcina dopływ tlenu: jak „vibe coding” dusi open source i zniechęca jego twórców
Daniel Stenberg, główny twórca i opiekun projektu cURL, którego narzędzia używa praktycznie cały internet, podjął w styczniu 2026 roku bolesną decyzję. Zakończył trwający od lat program nagród za zgłaszanie błędów, który został zamknięty pod koniec stycznia 2026 roku. Mitchell Hashimoto, współzałożyciel HashiCorp, wprowadził w swoim nowym projekcie Ghostty całkowity zakaz kodu generowanego przez AI. Steve Ruiz poszedł jeszcze dalej: w jego bibliotece tldraw wszystkie zewnętrzne prośby o włączenie kodu (pull requests) są teraz zamykane automatycznie.

To nie są odosobnione przypadki zgorzkniałych programistów. To desperackie reakcje obrońców twierdzy, której fundamenty – oparte na współpracy, uznaniu i wspólnym wysiłku – są systematycznie podmywane przez nową falę. Falę, którą niektórzy analitycy nazywają „AI Slopageddon” – prawdziwe apokalipsy AI-owego „szmelcu”. U jej źródła leży zjawisko zwane „vibe coding”.

Czym jest "vibe coding" i dlaczego to nie tylko "lenistwo"?

„Vibe coding” to potoczny termin na praktykę, w której deweloperzy wykorzystują asystentów AI (agenty) do automatycznego wybierania, łączenia i implementowania gotowych pakietów open source. Brzmi efektywnie? W teorii tak. Problem leży w tym, co w tym procesie zostaje pominięte.

Klasyczny model open source opierał się na pętli sprzężenia zwrotnego: programista, chcąc użyć biblioteki, (1) czytał dokumentację, (2) napotykał problem i zgłaszał buga lub (3) miał pytanie i wpisywał je na Stack Overflow. W ten sposób opiekun projektu (maintainer) otrzymywał bezcenne sygnały: widział, że jego praca jest używana, mógł poprawiać błędy, a przez to zyskiwał reputację, co często przekładało się na oferty pracy, kontrakty konsultingowe czy darowizny.

„Vibe coding” tę pętlę zrywa. AI wybiera pakiet, AI go implementuje, a developer nawet nie wie, jakiej biblioteki użył. Nie odwiedzi strony dokumentacji, nie zgłosi błędnie sformułowanego komunikatu o błędzie. Z punktu widzenia maintainera, jego projekt nagle stał się niewidzialny, mimo że jest używany częściej niż kiedykolwiek.

„AI slop prowadzi atak DDoS na opiekunów open source, a platformy hostingujące projekty nie mają żadnej motywacji, żeby to powstrzymać. Wręcz przeciwnie, są zmotywowane, żeby napompować statystyki AI-generowanych kontrybucji, żeby pokazać ‘wartość’ swoim akcjonariuszom” – mówi Stefan Prodan, główny opiekun projektu Flux CD.

Ekonomia niewidzialnego zużycia: błędne koło

Analizy ekonomiczne tego zjawiska pokazują samonapędzające się błędne koło.

Z jednej strony, AI obniża koszty tworzenia oprogramowania, co teoretycznie powinno zachęcić więcej osób do publikowania swoich pakietów (wzrost podaży). Jednak kluczowy jest przesunięcie popytu. Użytkownicy, dzięki AI, omijają bezpośrednią interakcję z projektem. To zmniejsza wszystkie tradycyjne motywacje maintainera: mniej odsłon dokumentacji, mniej zgłoszeń błędów, mniej rozpoznawalności w społeczności.

W efekcie, utrzymywanie projektu, które już wcześniej było często czynnością charytatywną, staje się jeszcze mniej opłacalne. Twórcy się wypalają i porzucają projekty. W dłuższej perspektywie, jeśli ten efekt „przesunięcia popytu” będzie dominujący, runie cała środkowa półka ekosystemu. Przetrwają tylko giganty (jak Linux, React) z silnym sponsoringiem oraz maleńkie, niszowe skrypty. Zniknie cała warstwa wartościowych, dojrzałych, ale mniej popularnych bibliotek, które są kręgosłupem nowoczesnego rozwoju.

Indywidualna, krótkoterminowa wygoda programisty, który nie chce „marnować czasu” na czytanie dokumentacji, prowadzi do długoterminowego spadku ogólnej dostępności i jakości oprogramowania dla wszystkich – podsumowują analitycy.

Dowody w działaniu: liczby, które nie kłamią

Trend jest już wyraźnie widoczny w danych:
- Stack Overflow odnotował spadek liczby pytań po premierze ChatGPT. Pytania przeniosły się do prywatnych czatów z AI.
- Tailwind CSS, popularny framework CSS, notuje rosnącą liczbę pobrań, ale jednocześnie spadek ruchu w dokumentacji i przychodów komercyjnych. Użycie rośnie, ale twórcy nie odnoszą z tego żadnych korzyści.
- W przypadku cURL, decyzja Daniela Stenberga przyszła, gdy program bug bounty został zalany niskiej jakości zgłoszeniami, w tym generowanymi przez AI. Po wypłaceniu ponad 90 000 dolarów nagród za 81 luk, stało się to po prostu nieopłacalne.
Platformy, zamiast pomagać, często problem pogłębiają. GitHub uruchomił funkcję Copilot Issue Generation, która automatycznie tworzy zgłoszenia problemów z kodu. Nie dał jednak maintainerom żadnych narzędzi do filtrowania tych generowanych przez AI, zalewając ich skrzynki jeszcze większą ilością „szumu”.

Reakcje obronne: od zero tolerancji po całkowitą izolację

Opiekunowie nie są bierni. Ich reakcje układają się w spektrum od stanowczych po radykalne.
- Mitchell Hashimoto (Ghostty) wprowadził politykę „zero tolerancji”. „To nie jest stanowisko anty-AI. To stanowisko anty-idiotyczne” – tłumaczy. „Ghostty jest pisany z dużą pomocą AI i wielu naszych opiekunów używa AI na co dzień. Po prostu chcemy jakościowych kontrybucji, niezależnie od tego, jak są tworzone”. Za złamanie zakazu grozi permanentny ban.
- Steve Ruiz (tldraw) doszedł do jeszcze bardziej fundamentalnego wniosku. Zdał sobie sprawę, że jego własne skrypty AI generują kiepsko sformułowane zgłoszenia, które następnie ludzie wklejają do swoich narzędzi AI, by te – bazując na błędnych założeniach – tworzyły bezużyteczne prośby o włączenie kodu. Jego decyzja? Całkowite zamknięcie projektu na zewnętrzne kontrybucje. „Jeśli napisanie kodu jest łatwą częścią, to dlaczego miałbym chcieć, żeby pisał go ktoś inny?” – pyta retorycznie.
- Craig McLuckie*, współzałożyciel Stacklok, opisuje jak zmienił się świat: „Kiedyś oznaczenie czegoś jako ‘good first issue’ (dobry pierwszy problem) przyciągało inżynierów, którzy potem rośli w stałych współtwórców. Teraz… w ciągu 24 godzin jesteśmy absolutnie zalewani niskiej jakości ‘szmelcem’ z vibe codingu, który tylko odbiera nam czas od prawdziwej pracy”.
Czy jest jakieś wyjście? Model Spotify i ślepe uliczki

Niektórzy proponują ekonomiczne rozwiązanie: „model Spotify” dla open source. Platformy AI (jak GitHub z Copilotem) pobierałyby opłaty subskrypcyjne, a następnie redystrybuowałyby je do autorów bibliotek na podstawie faktycznego użycia przez AI. To teoretycznie sprawiedliwe.

Jednak obliczenia pokazują skalę wyzwania: aby utrzymać dotychczasowy poziom motywacji dla maintainerów, użytkownicy „vibe coding” musieliby generować dla nich znaczną część wartości, jaką generują dziś tradycyjni, zaangażowani użytkownicy. To próg trudny do osiągnięcia.

Tymczasem duże organizacje open source skupiają się na innych aspektach. Fundacja Linuxa zajmuje się zgodnością licencji. Fundacja Apache zaleca dodawanie do kodu znacznika „Generated-by:”. Żadne z tych rozwiązań nie pomaga w faktycznym odsianiu potopu niskiej jakości treści. Niektóre projekty poszły na całość i po prostu zakazały wszystkich kontrybucji generowanych przez AI. Ale jak zauważają niektórzy, wykrywanie naruszeń tego zakazu za rok czy dwa stanie się funkcjonalnie niemożliwe.

Szerszy kontekst: erozja kompetencji i pogoń za dokumentacją

Kryzys w open source nie jest odosobniony. To część większej układanki, w której poświęcamy długoterminową biegłość dla krótkoterminowej wydajności.

Badania z udziałem inżynierów pokazują, że ci, którzy intensywnie korzystają z asystentów AI, mogą zdobywać mniej punktów na testach rozumienia kodu. Ci, którzy całkowicie delegują zadania, osiągają gorsze wyniki, podczas gdy ci, którzy używają AI konceptualnie, angażując swój mózg – lepsze. Jak komentował jeden z ekspertów: „Wymieniasz uczenie się i erozję kompetencji na zastrzyk produktywności, który nie zawsze tam jest”.

Równolegle giganty technologiczne pracują nad serwerami MCP (Model Context Protocol), które mają zapewnić AI agentom dostęp do aktualnej, oficjalnej dokumentacji w czasie rzeczywistym. To wyścig zbrojeń: AI popełnia błędy, bo trenuje na nieaktualnych danych, więc firmy próbują jej te dane dostarczyć. To jednak nie rozwiązuje problemu odcięcia maintainera od użytkownika.

Podsumowanie: co tracimy, gdy znikają maintainerzy

Ostatecznie, zagrożenie nie dotyczy tylko dzisiejszych popularnych bibliotek. Te pewnie sobie poradzą. Niebezpieczeństwo jest głębsze i bardziej subtelne.

„Popularne biblioteki wciąż znajdą sponsorów” – mówi Miklós Koren, współautor badania. „Mniejsze, niszowe projekty są bardziej narażone. Ale pamiętajmy, że wiele dziś sukcesywnych projektów, jak Linux, git, TeX czy grep, zaczynało się od jednej osoby, która chciała podrapać swój własny świąd. Jeśli opiekunowie małych projektów się poddadzą, kto stworzy następnego Linuxa?”.

W tej chwili maintainerzy jak Stenberg, Hashimoto i Ruiz odpowiadają na to pytanie w jeden sposób: zamykając drzwi swojego projektu, jeden po drugim. Bronią resztek swojej produktywności i zdrowia psychicznego przed „AI Slopageddon”. A społeczność programistów, choć może tego jeszcze nie widzieć, już traci coś bezcennego: przyszły fundament, na którym miał stanąć kolejny przełomowy projekt.
2026-02-26