Problem „zaufaj nam” w cyfrowych usługach

W codziennym życiu coraz więcej załatwiamy przez internet: komunikujemy się, zdobywamy informacje, płacimy rachunki, korzystamy z edukacji i usług zdrowotnych. Większość tych cyfrowych usług działa jednak na zasadzie „zaufaj nam” – oprogramowanie i algorytmy są zamknięte, a użytkownik musi wierzyć na słowo ich dostawcy. To rodzi asymetrię władzy: garstka właścicieli technologii zyskuje bezprecedensową kontrolę nad tym, co miliardy ludzi czytają, oglądają i kupują. My – zwykli użytkownicy – nie mamy wglądu w kod źródłowy ani w logikę działania tych systemów, więc musimy ufać, że działają uczciwie. Niestety, historia ostatnich lat pokazuje, że to zaufanie bywa nadużywane. 

Przykłady z życia: Rodzic nie wie, jak algorytm ustala, jakie treści widzi jego dziecko w mediach społecznościowych – czy faktycznie dba o bezpieczeństwo, czy raczej podsuwa wciągające filmiki, by zwiększyć oglądalność? Senior korzystający z aplikacji finansowej musi wierzyć, że ta nie ukrywa żadnych opłat ani haczyków w regulaminie napisanym drobnym drukiem. Właściciel małej firmy zależy od wyszukiwarki lub marketplace’u, który może bez ostrzeżenia zmienić algorytm pozycjonowania ofert – i nagle klient przestaje go znajdować w wynikach. Dziennikarz publikujący w internecie liczy na uczciwy zasięg swoich treści, ale jeśli platforma ma zamknięty kod, to nigdy nie ma pewności, czy jego artykuły nie są gdzieś filtrowane lub degradowane. Pacjent korzystający z e-porady czy aplikacji zdrowotnej nie ma pewności, czy algorytm priorytetyzujący zgłoszenia działa według jasnych kryteriów medycznych, czy np. faworyzuje tych, którzy wykupili płatną subskrypcję. Kierowca włączający nawigację ufa, że aplikacja nie sprzeda danych o jego trasach lub nie poprowadzi go tak, by minął więcej reklam po drodze. Twórca internetowy polega na platformie streamingowej, wierząc, że przejrzyste zasady regulują monetyzację – lecz gdy algorytm demonetyzuje film bez podania przyczyny, twórca jest bezradny. 

We wszystkich tych sytuacjach użytkownik musi zawierzyć dostawcy usługi, bo brakuje mu narzędzi kontroli. Kod i modele AI pozostają tajemnicą korporacji, a decyzje podejmowane przez algorytmy są często nieprzejrzyste. Jeśli system popełni błąd lub nas skrzywdzi – np. zablokuje konto bez powodu, pominie ważną wiadomość, błędnie odrzuci wniosek o kredyt – nie mamy jak tego samodzielnie zweryfikować ani dochodzić praw. Ta nierównowaga informacji oznacza nierównowagę władzy: dostawca wie wszystko o naszym zachowaniu (śledząc kliknięcia, lokalizacje, preferencje), my zaś nie wiemy prawie nic o mechanizmach, które kierują usługą. W efekcie rośnie kryzys zaufania – coraz trudniej uwierzyć, że technologia działa w naszym interesie. Zwłaszcza gdy na jaw wychodzą przypadki nadużyć: wycieki danych osobowych, algorytmy promujące dezinformację i treści skrajne dla zysku z reklam, aplikacje śledzące każdy nasz ruch (tzw. kapitalizm inwigilacji, czyli model biznesowy oparty na zbieraniu i monetyzacji danych o użytkownikach). 

Brak wglądu w kod to także niemożność niezależnego audytu – zewnętrzni eksperci czy organy nadzoru nie mogą sprawdzić, co naprawdę robi dana aplikacja. Przykładowo, czy komunikator rzeczywiście szyfruje wiadomości (jak twierdzi), czy może ma furtki dla reklamodawców lub służb? Czy aplikacja do nauki faktycznie chroni prywatność ucznia, czy raczej gromadzi dane o wynikach i czasie nauki, by sprzedać je dalej? Bez dostępu do kodu pozostaje nam tylko wierzyć na słowo. Taka sytuacja sprzyja nadużyciom, bo pokusa wykorzystania władzy bywa zbyt duża – jak powiedział pewien amerykański sędzia, „Ufność jest dobra – kontrola lepsza”.

Open source jako infrastruktura publiczna

Czy da się odwrócić tę asymetrię i zbudować cyfrowe usługi tak, by obywatel miał nad nimi realną kontrolę, podobnie jak ma nad publiczną infrastrukturą? Open source (otwarte oprogramowanie) oferuje taką możliwość. Kod otwarty to kod dostępny dla wszystkich – można go sprawdzać (audytować), modyfikować i wykorzystywać wspólnie. Dzięki temu open source może pełnić rolę infrastruktury publicznej w XXI wieku, porównywalnej do dróg czy wodociągów, ale w świecie cyfrowym. 

Analogii do infrastruktury jest wiele: Drogi i mosty buduje się z publicznych środków i każdy może z nich korzystać – nie są one własnością jednej firmy, która mogłaby nagle je zamknąć albo dowolnie zmienić zasady ruchu. Podobnie otwarte oprogramowanie może być wspólnym dobrem: dostępne dla wszystkich i podlegające jasnym regułom ustalonym przez społeczność, a nie sekretnym algorytmom prywatnego właściciela. Wodociągi i sieci kanalizacyjne działają według norm bezpieczeństwa, są też okresowo kontrolowane – nikt nie oczekuje od mieszkańców, by „zaufali” wodociągom w kwestii jakości wody, tylko niezależne laboratoria regularnie ją badają. W świecie cyfrowym open source pozwala na podobną kontrolę jakości: kod jest jawny, więc niezależni eksperci mogą wychwycić „zanieczyszczenia” – np. fragment kodu zagrażający prywatności – i alarmować o tym całą społeczność. 

W gastronomii istnieje system HACCP, który nakłada na restauracje obowiązek transparentności procesów i zapobiegania zagrożeniom: każdy etap przygotowania jedzenia ma być monitorowany i udokumentowany. Dzięki temu jako konsumenci nie musimy ufać na ślepo każdej restauracji – wiemy, że stosuje ona standardy higieny weryfikowane przez inspektorów. W przypadku oprogramowania open source pełni podobną rolę: jawny kod pozwala prześledzić „przepis” działania aplikacji od początku do końca i upewnić się, że nie ma tam zepsutych składników. Gdy system jest audytowalny, błędy i nadużycia można wykryć, zanim wywołają „zatrucie” użytkowników. 

Wreszcie, nasze auta muszą przechodzić regularne przeglądy techniczne – to nie kwestia zaufania do producenta, tylko obowiązek zapewnienia bezpieczeństwa wszystkim na drodze. Wyobraźmy sobie podobny model dla kluczowych systemów cyfrowych: otwarte oprogramowanie umożliwia ustanowienie niezależnych przeglądów kodu, certyfikacji, że np. aplikacja do głosowania elektronicznego jest bezpieczna i wolna od manipulacji. Zamknięte aplikacje działają jak samochody bez możliwości zajrzenia pod maskę – mieliśmy wierzyć producentowi, że hamulce działają, ale nikt poza nim nie mógł ich obejrzeć. 

Open source to nie „za darmo”, tylko „do wspólnego użytku i kontroli”. Często panuje błędne przekonanie, że „jak coś jest open source, to znaczy że darmowe i pewnie gorsze”. Tymczasem sedno nie tkwi w cenie, lecz w wolności i transparentności. Otwartość kodu oznacza, że koszt wytworzenia oprogramowania może być pokrywany ze wspólnych funduszy (np. publicznych), ale za to efekt – kod – pozostaje dobrem wspólnym, które każdy może zweryfikować i wykorzystać ponownie. To trochę tak, jak budowa biblioteki czy parku z pieniędzy podatników: płacimy za stworzenie wartościowego dobra, które potem służy wszystkim i nie jest czyjąś prywatną własnością. Infrastruktura cyfrowa oparta na open source może działać na zasadzie „sprawdzalne i wspólne”: obywatele (lub ich przedstawiciele) mogą zajrzeć w mechanizmy działania usługi, a także współdecydować o jej rozwoju. 

Warto podkreślić: otwartość kodu buduje zaufanie. Gdy użytkownik wie, że w każdej chwili można skontrolować działanie systemu, łatwiej mu zaufać, że system nie ukrywa żadnych „haków”. To tak, jak z recepturą leku – fakt, że jest ujawniona i podlega niezależnym badaniom, daje pacjentom spokój, że lek jest bezpieczny (nawet jeśli sami nie rozumieją wzoru chemicznego). Podobnie jawny algorytm np. w serwisie społecznościowym oznacza, że jeśli platforma nagle zacznie promować szkodliwe treści, eksperci szybko to zauważą i nagłośnią. Transparentność buduje zaufanie – technologia służy ludziom, a nie odwrotnie.

Ryzyka i kontrargumenty

Oczywiście, idea open source jako nowej infrastruktury publicznej rodzi pytania i wątpliwości. Warto je uczciwie omówić: 

„Open source nie gwarantuje bezpieczeństwa”. To prawda – samo upublicznienie kodu nie czyni go automatycznie wolnym od błędów. Czasem słyszy się argument, że skoro kod jest jawny, to hackerzy łatwiej znajdą w nim luki. Jednak bezpieczeństwo to funkcja całego procesu: jakości programowania, testów, szybkości łatania błędów. Kod otwarty daje szansę na lepsze bezpieczeństwo, bo więcej oczu może go sprawdzić (słynne prawo Linusa: „przy wystarczającej liczbie oczu żaden błąd nie ukryje się długo”). Ale nic nie dzieje się automatycznie – projekty open source muszą dbać o audyty, przeglądy i mechanizmy zachęcające ekspertów do wyszukiwania błędów. Praktyki takie jak bug bounty (nagrody za znalezienie błędu) motywują do przeglądu kodu przez niezależnych specjalistów. Ważne są reproducible builds (powtarzalne kompilacje) – czyli metoda, by każdy mógł sprawdzić, że skompilowany program dokładnie odpowiada opublikowanemu kodowi źródłowemu. Dobre projekty otwarte publikują także changelogi (listy zmian) do każdej aktualizacji, co utrudnia przemycenie złośliwej funkcji bez zauważenia. Podsumowując: open source pozwala na bezpieczeństwo poprzez przejrzystość, ale wymaga solidnych procesów inżynierskich i społeczności czuwającej nad projektem. Zdarzały się spektakularne wpadki – np. luka Heartbleed w bibliotekach OpenSSL w 2014 pokazała, że krytyczne otwarte komponenty mogą latami zawierać błąd, którego nikt nie wyłapał. Społeczność jednak zareagowała wtedy błyskawicznie: luka została załatana, a wielkie firmy zrzuciły się na fundusz audytów dla utrzymania bezpieczeństwa kluczowych projektów open source. W modelu zamkniętym takie błędy też się zdarzają – tylko często nie wiemy o nich, dopóki ktoś ich nie wykorzysta. Otwartość przynajmniej daje szansę, by wcześniej je wykryć i naprawić. 

„Kto za to zapłaci?” – czyli jeśli nie korporacje zarabiające na reklamach i danych, to skąd wziąć środki na budowę i utrzymanie otwartej infrastruktury? Opcji jest kilka. Po pierwsze, fundacje i granty: wiele kluczowych projektów open source jest rozwijanych przez organizacje non-profit, finansowane grantami rządowymi lub filantropijnymi. Przykładem może być Fundacja Mozilla (przeglądarka Firefox) czy różne fundacje linuxowe. Po drugie, pieniądze publiczne: skoro mówimy o infrastrukturze publicznej, naturalnym źródłem finansowania mogą być podatki i zamówienia publiczne. Istnieje hasło: “Public Money? Public Code!” – skoro oprogramowanie powstaje za publiczne pieniądze, kod powinien być dostępny publicznie. Rządy mogą finansować tworzenie otwartego oprogramowania tak, jak finansują drogi czy szkoły. W praktyce może to oznaczać zlecanie wykonania konkretnych modułów firmom w ramach przetargów, ale z wymogiem otwartości kodu. Po trzecie, model składkowy i abonamentowy: społeczność użytkowników lub interesariuszy (np. uczelnie, samorządy, firmy) może zrzucać się na utrzymanie projektu – coś w rodzaju cyfrowej spółdzielni. Przykładowo, wiele bibliotek open source utrzymuje się z dobrowolnych wpłat firm, które z nich korzystają (bo wolą zapłacić, niż utracić wsparcie projektu). Możliwa jest też certyfikacja i usługi wokół open source: firmy mogą zarabiać na wsparciu technicznym, hostingu czy certyfikowaniu, że dana instalacja jest bezpieczna – podobnie jak firmy serwisujące infrastrukturę publiczną. Ważne jest, by uświadomić decydentom, że koszty i tak ponosimy – tylko dziś płacimy je pośrednio (np. wysokimi marżami monopolistów, naszymi danymi czy reklamami). Przekierowanie części tych istniejących nakładów na model open source może dać porównywalne środki na rozwój, a korzyści społeczne będą większe, bo efekty pracy nie znikną za paywallem. 

„Fragmentacja i forki – czy grozi chaos?” Krytycy mówią: jeśli wszystko będzie open source, każdy będzie mógł skopiować projekt (zrobić fork) i powstanie sto wersji konkurencyjnych, niekompatybilnych ze sobą. Rzeczywiście, prawo do forka to fundament open source – daje wolność skopiowania kodu i rozwijania go niezależnie. Może to rodzić pewne zamieszanie (np. mnogość dystrybucji Linuksa bywa dla początkujących niejasna). Jednak praktyka pokazuje, że udane projekty rzadko są masowo forkowane bez powodu. Fork jest zazwyczaj zabezpieczeniem na wypadek, gdy główny projekt zboczy w złą stronę lub przestanie być rozwijany. To jak plan awaryjny: jeśli społeczność nie zgadza się z decyzjami liderów projektu, może pójść własną drogą, nie zaczynając od zera. W ten sposób fork chroni przed monopolem również w świecie open source – nikt nie może na trwałe zawłaszczyć projektu, bo inni zawsze mogą użyć kopii i wprowadzić własne poprawki. Przykładem pozytywnego forka jest LibreOffice – powstał, gdy Oracle przejęło OpenOffice i społeczność obawiała się komercjalizacji. LibreOffice szybko prześcignął pierwowzór i dziś to on jest głównym otwartym pakietem biurowym, a oryginalny OpenOffice praktycznie zamarł. Z drugiej strony, nadmiar forków może rozproszyć zasoby i podzielić społeczność. Dlatego w dojrzałych ekosystemach wypracowano mechanizmy koordynacji: projekty ustanawiają rady techniczne, głosowania nad kierunkiem rozwoju, starają się osiągać konsensus, by unikać niepotrzebnego rozłamu. Jeśli jednak rozłam jest nieunikniony – bo np. część społeczności ma inną wizję – open source daje temu bezpieczny wentyl. W świecie zamkniętym taki konflikt kończy się często porzuceniem produktu lub wojną prawną; w open source – powstaniem alternatywy, z której użytkownik może skorzystać, wybierając tę, która lepiej mu służy. Ważne jest też zapewnienie interoperacyjności – otwarte standardy i formaty danych pozwalają, by nawet różne implementacje (forki) mogły ze sobą współpracować. To jak różne modele samochodów na drogach: konkurują, ale wszystkie muszą trzymać się wspólnych zasad ruchu i standardu szerokości jezdni. 

„Czy to nie utopia?” – czyli czy wizja pełnego ekosystemu usług publicznych opartych na open source nie jest zbyt piękna, by była realna. Rzeczywiście, nie mówimy o zmianie, która wydarzy się z dnia na dzień. To pewien proces, etapowa ścieżka rozwoju. Najpierw powstają pojedyncze moduły – MVP (Minimum Viable Product) – które pokazują w praktyce działanie idei. Może to być np. otwarty komunikator dla urzędu miasta, albo lokalny portal społecznościowy w małej gminie, gdzie kod jest jawny. Takie pilotażowe wdrożenia pozwalają zebrać doświadczenia, zbudować społeczność i udowodnić, że to działa. Potem kolejne instytucje i społeczności mogą adoptować te rozwiązania, łączyć je w większy ekosystem. Być może nie od razu zastąpimy globalne platformy Big Tech ich publicznymi odpowiednikami – ale krok po kroku możemy tworzyć alternatywną sieć usług, które szanują użytkownika. W planowaniu infrastruktury publicznej też zaczyna się od priorytetów: najpierw buduje się główne drogi, potem lokalne, wreszcie drobne ścieżki. Tu podobnie – można zacząć od kluczowych usług (np. komunikacja, informacja), a bardziej niszowe rozwiązania dołączać później. Ważne, by myśleć długofalowo: utopia to coś nierealnego tu i teraz, ale może stać się rzeczywistością za dekadę, jeśli dziś zrobimy pierwszy krok. W latach 80. internet też brzmiał jak utopia garstki akademików – światowa sieć łącząca wszystkich ludzi. Dziś jest faktem (choć skrzywionym przez modele komercyjne). Open source już teraz napędza sporą część krytycznej infrastruktury (serwery, systemy operacyjne, protokoły internetowe) – pytanie, czy potrafimy przenieść te sukcesy na poziom usług dla zwykłych obywateli. Droga wiedzie przez kolejne fazy: od prototypów, przez wdrożenia lokalne, krajowe, aż po ekosystem globalny, w którym usługi publiczne różnych państw i społeczności współpracują dzięki otwartym standardom. To nie utopia, to wyzwanie organizacyjne i polityczne. Tak jak walka o zmiany klimatyczne czy prawa człowieka – duże cele realizuje się małymi krokami.

Projekt Avalon – audytowalny ekosystem w praktyce

Aby lepiej zobrazować powyższe idee, przyjrzyjmy się projektowi Avalon – tworzonemu jako przykład otwartej, transparentnej platformy społeczno-cyfrowej. Avalon to wizja globalnego „intranetu ludzi”: uniwersalnej aplikacji integrującej kluczowe funkcje internetu (media społecznościowe, komunikator, wideo, zakupy, usługi publiczne) w jednym ekosystemie działającym non-profit. Kluczowe cechy, które odróżniają Avalona od dzisiejszych komercyjnych platform, to:

• 100% otwarty kod źródłowy – cała infrastruktura, algorytmy i nawet modele AI są jawne i dostępne do wglądu. Dzięki temu każdy (lub przedstawiciele społeczeństwa, np. naukowcy) może audytować kod i upewnić się, że nie ma tam ukrytych mechanizmów manipulacji, śledzenia czy stronniczego promowania treści. Transparentność ma tu budować zaufanie: technologia służy ludziom, nie odwrotnie, bo cokolwiek system robi – robi to na oczach społeczności ekspertów.
• Zweryfikowane tożsamości użytkowników – Avalon wprowadza zasadę jedna osoba = jedno konto, rejestrowane na prawdziwe nazwisko po weryfikacji (podobnie jak wyrobienie dowodu osobistego). Oznacza to koniec anonimowych armii botów i fikcyjnych profili trolli: każdy użytkownik jest realną, odpowiedzialną osobą. To drastycznie utrudnia szerzenie dezinformacji i nadużyć, bo nie da się w nieskończoność zakładać nowych tożsamości po zbanowaniu. Kultura dyskusji podnosi się, gdy ludzie piszą pod własnym nazwiskiem – mniej jest mowy nienawiści czy oszustw. Oczywiście pojawia się pytanie o prywatność – Avalon zakłada, że choć tożsamość jest zweryfikowana, użytkownik może posługiwać się np. pseudonimem publicznie, ale w razie nadużyć wiadomo, że za kontem stoi konkretna osoba (jak list polecony – pseudonim na kopercie, ale poczta zna nadawcę). Taki model wymaga dużych zabezpieczeń danych osobowych, ale eliminuje plagę botów.
• Brak reklam i ekonomii uwagi – Avalon ma być finansowany ze środków publicznych i społecznych, nie przez reklamodawców. Dzięki temu nie ma pokusy projektowania algorytmów pod kliknięcia i sensację. W Avalonie nie znajdziemy sponsorowanych postów politycznych ani mechanizmów sztucznego podbijania zasięgów za opłatą. To zamyka drogę do modelu „płać, aby użytkownicy zobaczyli Twój przekaz” – który dziś bywa wykorzystywany do propagandy. W połączeniu z weryfikacją użytkowników daje to efekt: dużo trudniej zalewać przestrzeń publiczną dezinformacją, a jeśli ktoś to robi, łatwiej go zidentyfikować i pociągnąć do odpowiedzialności.
• Jawne algorytmy i modele AI – w Avalonie nawet moduły sztucznej inteligencji (np. podpowiadające treści) są otwarte. Społeczność naukowa ma wgląd w ich działanie i może je korygować. Użytkownik w idealnym scenariuszu mógłby nawet wybrać, jaki algorytm mu sortuje wiadomości (np. chronologiczny vs. oparty na popularności vs. personalizowany) – bo skoro to open source, można oferować różne „wtyczki” algorytmiczne do wyboru. Ważne jest, że nic nie dzieje się w ukryciu: jeżeli np. feed wiadomości nie pokazuje jakichś treści, to można sprawdzić, czy to wynik jawnej reguły (np. ukrywania spamu), a nie ręcznej cenzury. Avalon zakłada także mechanizmy społecznej kontroli algorytmów – np. powołanie rady etycznej złożonej z naukowców, która zatwierdza zmiany w kodeksie algorytmicznym, podobnie jak dziś komisje kodyfikacyjne dbają o spójność prawa.
• Prawo do forka i federacja – Avalon ma być rozwijany centralnie jako dobro wspólne, ale z poszanowaniem możliwości odłączenia się społeczności, jeśli nie zgadzają się z kierunkiem rozwoju. Kodeks Avalonu (cyfrowa konstytucja platformy) gwarantuje prawo do niezależnego forka – czyli skopiowania kodu i założenia własnej instancji, jeśli ktoś uważa, że może zrobić to lepiej. Tym różni się to od dzisiejszych monopoli: jeśli np. Facebook zmieni regulamin na niekorzyść użytkowników, nie mamy innego wyjścia w ramach tej platformy; w open source zawsze istnieje konkurencja poprzez forki, co motywuje oryginalny projekt do uczciwości. Avalon przewiduje, że utrzyma spójność dzięki oferowaniu najlepszej jakości i wygody, ale jeśli zacznie zawodzić, społeczności lokalne czy tematyczne mogą uruchomić własne węzły (Avalon ma wspierać model federacyjny, coś jak rozproszone sieci Mastodona). Dzięki temu nikt nie „przywiąże” obywateli do jednej scentralizowanej aplikacji wbrew ich woli.

Podsumowując, Avalon jest próbą zbudowania kompleksowego ekosystemu zaufanych usług cyfrowych, który realizuje w praktyce hasło open source jako infrastruktura publiczna. Ma ograniczać boty, manipulacje i nadużycia przez połączenie technologii i zasad społecznych: jawności, odpowiedzialności i współodpowiedzialności użytkowników. Oczywiście to wciąż projekt w fazie rozwoju – przed nim wiele wyzwań technicznych i organizacyjnych. Ale już sam fakt, że powstaje, pokazuje, iż istnieje zapotrzebowanie na alternatywę wobec obecnego modelu sieci.

Mapa usług – od społeczności po zdrowie

Jak mogłaby wyglądać taka otwartoźródłowa infrastruktura usług cyfrowych w praktyce? Poniżej przedstawiamy mapę usług – kilkanaście modułów funkcjonalnych, odpowiedników dzisiejszych popularnych platform. Zamiast podawać nazwy konkretnych marek, opisujemy klasy usług, problemy z ich obecną (zamkniętą) formą oraz zasady, jakie powinien spełniać ich wariant open source.

• Publiczny feed społecznościowy (timeline) – czyli otwarta wersja tablicy z postami znajomych, wiadomościami i treściami od obserwowanych osób. Obecne nadużycia: Algorytmy popularnych sieci społecznościowych promują często treści skrajne, kontrowersyjne lub dezinformację, bo takie wywołują większe zaangażowanie użytkowników, przekładające się na zysk z reklam. Użytkownik nie wie, czemu pewne wpisy widzi wysoko, a inne są ukrywane – rodzi to bańki informacyjne i manipulacje opinią publiczną. Bywają też dark patterns zachęcające do niekończącego się scrollowania (endless scroll), co uzależnia uwagę. Zasady open source: Jawny algorytm sortowania treści – każdy może zobaczyć, na jakiej podstawie coś trafia na top feedu. Brak reklam eliminuje pokusę promowania czegokolwiek dla zysku. Możliwość przełączenia na tryb chronologiczny lub własne filtry sprawia, że użytkownik odzyskuje kontrolę nad tym, co ogląda. Wbudowane mechanizmy etykietowania dezinformacji (zamiast cenzury) – społeczność i eksperci mogą oznaczać, że dany post zawiera fałsz, co jest wtedy wyraźnie pokazane. Dzięki weryfikacji tożsamości, jeden użytkownik = jeden głos: koniec ze sztucznym podbijaniem popularności przez farmy botów. Algorytm w wariancie publicznym ma też wbudowane ograniczenia uzależniających funkcji – np. komunikat „oglądasz już 30 minut, może pora na przerwę?”, możliwość ustawienia limitu dziennego, itp. – bo celem nie jest maksymalnie długie utrzymanie nas w aplikacji.
• Komunikator (wiadomości tekst/voice/video) – otwarty odpowiednik komunikatorów typu WhatsApp, Messenger czy Signal. Obecne nadużycia: Większość komunikatorów należy do wielkich firm i choć część szyfruje treść, to zbierają mnóstwo metadanych (kto z kim, kiedy, jak długo) dla celów komercyjnych lub udostępniają je np. policji bez jasnych procedur. Niektóre komunikatory pokazują reklamy lub promują gry i boty komercyjne. Brak wspólnego standardu powoduje silos – użytkownicy są uwiązani do jednego dostawcy. Zasady open source: Pełne szyfrowanie end-to-end jako domyślne, audytowane przez niezależnych kryptografów (np. protokół Signal jest open source, co zwiększa zaufanie do jego szyfrowania). Minimalizm zbierania danych – komunikator open source nie magazynuje niepotrzebnych logów, nie prosi o dostęp do kontaktów czy lokalizacji bez uzasadnienia. Interoperacyjność – zastosowanie otwartego protokołu (np. Matrix) umożliwia, by różne aplikacje mogły się ze sobą komunikować. Dzięki temu instytucje publiczne mogą postawić własny serwer komunikatora, a obywatele korzystać dowolnym klientem, a jednak wszyscy mogą do siebie pisać (jak e-mail – różnych dostawców, ale działa wspólnie). Brak ukrytych opłat i reklam – finansowanie publiczne zapewnia utrzymanie serwerów, więc użytkownik nie jest produktem. Dodatkowo, w wersji publicznej można przewidzieć np. tryb rodzicielski: umożliwić opiekunom bezpieczny komunikator dla dzieci z nadzorem kontaktów (co dziś dzieje się przez zewnętrzne aplikacje lub nie dzieje się wcale).
• Wideo / Shorts / Live – platforma do dzielenia się filmami, krótkimi klipami i transmisjami na żywo (odpowiednik YouTube, TikTok, Twitch). Obecne nadużycia: Platformy wideo stosują agresywne algorytmy rekomendacji – użytkownik oglądający jeden filmik zaraz dostaje kilkanaście następnych dopasowanych tak, by go „wciągnąć”. Często prowadzi to dzieci i dorosłych w niebezpieczne rejony (np. teoria spiskowa po obejrzeniu jednego filmiku newsowego, bo algorytm znalazł „coraz bardziej angażujące” treści). Twórcy narzekają na niejasne zasady demonetyzacji – film może zostać wyłączony z reklam z powodu automatycznej decyzji AI i nie wiadomo dokładnie, czemu. Reklamy bywają uciążliwe, a cookies śledzą naszą historię oglądania po całym internecie. Zasady open source: Transparentne algorytmy rekomendacji – wiadomo, jakie czynniki decydują o polecanych filmach, a ich parametry są ustalane publicznie (np. „nie promujemy treści szerzących nienawiść, nawet jeśli mają dużo klików”). Brak reklam – platforma finansowana inaczej (np. dotacją, dobrowolną opłatą od widzów lub funduszem dla twórców) nie bombarduje treściami sponsorowanymi, zwłaszcza dzieci. Kontrola rodzicielska – otwartą platformę można wyposażyć w skuteczniejsze filtry wieku, bo społeczność może audytować i trenować modele rozpoznające treści nieodpowiednie (zamiast polegać na tajnych filtrach, które często zawodzą). Jasne zasady monetyzacji – jeśli twórcy mają otrzymywać wynagrodzenie, reguły są przejrzyste, a przy dochodach publicznych można wręcz utworzyć fundusz wsparcia twórców (np. z puli ministerstwa kultury) zamiast polegać na reklamach. Ważne też, by umożliwić przenoszenie swoich treści i odbiorców – open source ułatwi eksport filmów, opisów, list subskrybentów, tak aby twórca nie był niewolnikiem jednej platformy i mógł przenieść się gdzie indziej bez utraty całego dorobku.
• Marketplace (handel online) – platforma do zakupów online, łącząca sprzedawców z kupującymi (odpowiednik Amazon, Allegro, OLX). Obecne nadużycia: Wielkie platformy pobierają wysokie prowizje od sprzedawców i często faworyzują własne produkty lub partnerów w wynikach wyszukiwania. Fałszywe recenzje i podrabiane produkty zalewają marketplace’y – użytkownik nie wie, czy może ufać opiniom. Dane z zakupów bywają wykorzystywane, by profilować klientów (np. reklamy dopasowane do historii zakupów). Polityka zwrotów i reklamacji bywa arbitralna – gigant może zablokować konto sprzedawcy lub kupującego bez wiele wyjaśnień. Zasady open source: Tylko zweryfikowani sprzedawcy – platforma publiczna dopuszcza jedynie firmy/osoby, które potwierdziły swoją tożsamość i np. posiadają odpowiednie zezwolenia (co nie jest trudne, jeśli integrujemy to z e-administracją). Jawny system reputacji – oceny kupujących są publiczne i powiązane z ich wiarygodnym profilem (nie da się łatwo założyć tysiąca fikcyjnych kont, by wystawić sobie samemu pochwały). Dzięki temu recenzje zyskują na wiarygodności. Brak ukrytego pozycjonowania – algorytm sortujący oferty jest jawny i np. ustawiony domyślnie na najtrafniejsze (co można zdefiniować przejrzyście: np. kombinacja ceny, średniej ocen i dostępności), a użytkownik może zmienić na inny klucz (cena rosnąco, opinie malejąco itd.). Nie ma płatnych wyników „sponsorowanych” – reklamy nie wypychają na górę gorszych ofert. Otwarty standard danych o ofercie – sprzedawca może łatwo wyeksportować swoje produkty, opisy, oceny i przenieść do innego katalogu (konkurencja na usługę, nie na zasoby danych). Publiczny marketplace mógłby działać nawet federacyjnie – lokalne instancje (np. miejskie, branżowe) wymieniają się ofertami, zamiast jednego globalnego molocha. Bezpieczne płatności publiczne – np. integracja z krajowym systemem e-płatności, by uniknąć prowizji kartowych i dodatkowych opłat.
• Transport (przejazdy i komunikacja) – usługi związane z przemieszczaniem się: od zamawiania przejazdu (taksówka, ridesharing) po planowanie podróży komunikacją miejską. Obecne nadużycia: Aplikacje ridesharingowe (typu Uber) narzucają kierowcom wysokie prowizje i stosują dynamiczne ceny nie zawsze jasne dla pasażera (np. mnożniki cen podczas deszczu czy dużego popytu). Kierowcy są często pozbawieni praw pracowniczych, oceniani przez algorytm, który może ich dezaktywować. Dane o lokalizacji użytkowników trafiają na serwery prywatnych firm i bywały wykorzystywane w celach innych niż sama usługa (np. do analiz gdzie mieszka zamożna klientela). Planery transportu publicznego z kolei często są zamknięte, a ich rozwój zależy od budżetów miasta lub decyzji dużych dostawców (jak Google Maps), którzy mogą faworyzować określone usługi. Zasady open source: Platforma kooperatywna dla przejazdów – zamiast korporacji pobierającej 20-30% od każdej opłaty, system open source mógłby działać pod nadzorem np. miasta lub spółdzielni kierowców, pobierając minimalną opłatę na utrzymanie serwisu. Transparentny algorytm wyznaczania ceny – pasażer wie, z czego wynika kwota (stawka bazowa + ewentualny mnożnik X w godzinach szczytu – określony regulaminem, np. żeby zachęcić więcej kierowców na ulice, a nie dla zysku). Ochrona danych lokalizacyjnych – dane o przejazdach mogłyby być automatycznie anonimizowane i używane zbiorczo np. do planowania miejskiego, ale nie sprzedawane komercyjnie. Otwarte API do rozkładów i map – dzięki open source dane komunikacji publicznej i prywatnej mogą się integrować: niezależni deweloperzy mogą tworzyć aplikacje, które pokażą wszystkie opcje (autobus, pociąg, rower miejski, taksówka społeczna) w jednym miejscu. Model publiczny mógłby też wprowadzić standardy pracy – np. minimalne wynagrodzenie lub ubezpieczenie dla kierowców, co w prywatnych platformach wymaga regulacji odgórnych, a tu mogłoby być wpisane w logikę systemu (np. algorytm nie pozwoli, by kierowca zarobił w godzinę mniej niż X, dostosuje prowizję lub cenę).
• Dostawy (dania, zakupy, kurierzy) – platforma do zamawiania jedzenia, zakupów z dowozem lub crowdsourcingu dostaw (odpowiednik Uber Eats, Glovo, Dostawca.pl). Obecne nadużycia: Ponownie, gig economy – kurierzy pracują na niepewnych warunkach, platformy pobierają duże prowizje od restauracji (często 30% od wartości zamówienia, co zżera marżę małego biznesu). Aplikacje czasem manipulują użytkownikiem: np. domyślnie doliczają wysoki napiwek albo podają przy restauracji sztuczny licznik „średni czas dostawy: 45 min” by zmusić do decyzji. Dane o naszych zamówieniach spożywczych mogą trafiać do reklamodawców (np. sieć fastfood wie, że zamawiamy pizzę co piątek o 18). Zasady open source: Lokalna platforma dostaw – stworzona np. przez samorząd lub zrzeszenie restauratorów, działa non-profit, z minimalnymi opłatami na utrzymanie. Jawna ekonomia – restauracja widzi dokładnie, za co płaci (np. system pobiera 5% na utrzymanie + faktyczny koszt płatności online). Kurier ma wgląd w algorytm przydzielania zleceń – wie, że np. system stara się przydzielać zamówienia po kolei dostępnych dostawców i minimalizować dystans (a nie np. faworyzuje tych, którzy zgodzą się pracować za najniższą stawkę). Fair-trade danych – informacje o zwyczajach żywieniowych mieszkańców mogą służyć miastu (np. do planowania stref dostaw czy targów żywności), ale nie będą sprzedawane marketingowo. Brak dark patterns – aplikacja open source nie ukrywa opłat (jasno widać koszt dostawy, serwisu, napiwek – żaden domyślnie nie jest ukryty w cieniu), nie wywiera presji sztucznymi komunikatami („jeszcze tylko 2 minuty tej promocji!” jeśli to nieprawda).
• Edukacja online – platforma e-learningowa, zdalne lekcje, kursy, dzienniki elektroniczne (odpowiednik Google Classroom, Moodle, Khan Academy itd.). Obecne nadużycia: W czasie pandemii wiele szkół przeszło na narzędzia G Suite lub Microsoft Teams, oddając gigantom dostęp do danych uczniów. Choć formalnie są wersje „dla edukacji”, to buduje się przywiązanie do ekosystemu korporacji od najmłodszych lat. Dane o postępach nauki czy aktywności mogą potencjalnie być wykorzystywane do profilowania (np. firma mogłaby w przyszłości proponować danemu uczniowi płatne kursy z dziedziny, z której miał słabsze wyniki). Treści edukacyjne często są chronione prawem autorskim – nauczyciele muszą lawirować, by pokazywać fragmenty materiałów, a nie mają dostępu do pełnych zasobów. Zasady open source: Platforma e-learningowa publiczna – działająca na otwartym oprogramowaniu, hostowana przez krajowe centrum edukacji, gwarantująca brak reklam i niekomercyjne wykorzystanie danych. Otwarta biblioteka wiedzy – integracja z projektami typu Wikipedia czy Open Educational Resources, tak by nauczyciel miał w jednym miejscu legalne, otwarte materiały do zilustrowania lekcji. Prywatność by design – minimalne zbieranie danych o uczniu, brak śledzenia aktywności po lekcjach. Standardy wymiany danych – e-dziennik, platforma lekcji, system rekrutacji – wszystko korzysta z ujednoliconego, otwartego formatu, by np. rodzic nie musiał mieć pięciu różnych aplikacji do kontaktu ze szkołą. Dzięki audytowalności kodu rodzic może (za pośrednictwem np. stowarzyszeń) sprawdzić, że np. moduł egzaminu online nie faworyzuje określonych odpowiedzi algorytmicznie ani nie „podsłuchuje” z kamerki nic ponad to, co dozwolone.
• Zdrowie (e-zdrowie) – usługi medyczne online: umawianie wizyt, teleporady, aplikacje do monitoringu zdrowia, e-recepty, systemy diagnostyczne AI. Obecne nadużycia: Wrażliwe dane zdrowotne są niezwykle cenne – nic dziwnego, że firmy starają się je pozyskiwać. Aplikacje fitness czy diety śledzą naszą aktywność i odżywianie, by potem sprzedawać te dane ubezpieczycielom lub reklamodawcom. Sprzęt medyczny bywa na zamkniętym oprogramowaniu – pacjent nie ma dostępu do swoich własnych odczytów (np. surowych danych z urządzenia), bo producent zastrzegł protokół komunikacji. Wreszcie, pojawiają się algorytmy w medycynie – np. systemy segregacji pacjentów na SOR albo oceny zdjęć RTG – które są własnością firm i działają jak czarne skrzynki. Lekarz czy pacjent nie mogą zweryfikować, czemu np. AI nie przyznała komuś wysokiego priorytetu, a innej osobie tak. Zasady open source: E-zdrowie jako system publiczny – to w dużej mierze już następuje w wielu krajach (np. e-recepty, e-skierowania są państwowe), ale kluczowe jest, by całe oprogramowanie tych systemów było otwarte i audytowalne. W Estonii np. rozwiązania e-zdrowia są oparte na X-Road – otwartym protokole wymiany danych, co pozwala zapewnić bezpieczeństwo i spójność. Otwarte algorytmy diagnostyczne – jeśli szpital używa AI do wspomagania diagnozy, powinny obowiązywać regulacje jak dla leków: model musi być opisany i przebadany przez niezależne instytucje, a kod udostępniony przynajmniej do wglądu środowisku naukowemu. Dostęp pacjenta do danych – open source sprzyja wdrażaniu standardów, gdzie pacjent jest właścicielem swoich danych medycznych i może je pobrać w ustrukturyzowanej formie (np. historia choroby w formacie HL7/FHIR). Interoperacyjność urządzeń – oprogramowanie open source może stać się bazą dla ekosystemu urządzeń medycznych, gdzie liczy się kompatybilność, a nie zamykanie użytkownika w jednym ekosystemie producenta.
• Praca i gig economy – platformy do zleceń, ofert pracy stałej i dorywczej (od LinkedIn po Fiverr, Upwork). Obecne nadużycia: Serwisy pośrednictwa pracy bywały wykorzystywane do profilowania kandydatów także pod kątem cech niedozwolonych (np. algorytmy selekcji CV dyskryminowały ludzi po wieku czy płci, bo uczono je na stronniczych danych). W platformach gig (freelance) jest wyścig na zaniżanie stawek, a pośrednik i tak zabiera dużą prowizję. Często reputacja nie jest przenoszalna – jeśli kurier ma świetne oceny w jednej aplikacji, w innej zaczyna od zera. Zasady open source: Publiczna giełda zleceń – np. miejska lub branżowa platforma, gdzie ogłaszane są prace dorywcze i stałe, bez pobierania % od pensji. Finansowana np. ze środków urzędu pracy. Algorytmy rekrutacyjne pod kontrolą – jeśli używa się automatycznego odsiewania CV, to według otwartych kryteriów ustalonych publicznie (np. doświadczenie > X lat daje +5 pkt), bez dyskryminujących kryjówek. Portfel tożsamości zawodowej – open source pozwoli zbudować mechanizm, że pracownik ma własny profil z certyfikatami, ocenami, historią – przechowywany u niego (np. w aplikacji mobilnej) i uznawany przez różne platformy. Dzięki temu opinie zbierane o naszej pracy należą do nas, a nie do jednej korporacji.
• Twórcy i subskrypcje – system dla twórców internetowych do dystrybucji treści i zarabiania od fanów (analogiczny do Patreon, OnlyFans, Substack). Obecne nadużycia: Twórcy obecnie są zależni od platform – YouTube może zmienić reguły i uciąć przychody, Patreon może zbanować konto z powodów ideologicznych, a twórca traci kontakt ze swoimi subskrybentami. Platformy biorą też prowizje (typowo 5-10%), co samo w sobie nie jest złe, o ile usługa jest uczciwa. Problem w tym, że budują zamknięty silos: fan twórcy musi założyć konto na danej platformie i nie ma łatwej opcji przeniesienia subskrypcji na inną. Zasady open source: Fediverse dla twórców – wyobraźmy sobie system, gdzie twórcy publikują treści na własnych stronach lub w rozproszonym serwisie (np. ActivityPub jak Mastodon), a subskrybenci mogą śledzić ich poprzez dowolny klient. Płatności mogłyby być realizowane np. przez mechanizm „mikropłatności publicznych” – coś jak abonament biblioteczny: użytkownik płaci raz do wspólnego systemu, a on rozdziela twórcom wg oglądalności. Jawne regulaminy bez zaskoczeń – społeczność może uczestniczyć w tworzeniu zasad moderacji treści dla takiej platformy, więc nie ma mowy o nagłym banie za treść, która do tej pory była dozwolona (zmiana musiałaby przejść przez konsultacje). Własność kontaktu z fanami – kluczowe, by twórca posiadał listę swoich subskrybentów (przynajmniej emaile czy inne identyfikatory), tak by w razie czego móc ogłosić „przenoszę się na inną platformę, oto moje konto tam”. Open source i wspólne standardy umożliwią to technicznie, bo system zostanie tak zaprojektowany (dziś jest to celowo blokowane przez platformy, np. brak eksportu listy patronów).
• Repozytoria i wiedza – przestrzeń do dzielenia się wiedzą, projektami, plikami (od kodu źródłowego po artykuły i multimedia). Obecne nadużycia: Dominacja kilku platform (GitHub dla kodu, Wikipedia dla wiedzy, big techowe chmury dla plików) oznacza, że wiele cennych treści jest uzależnionych od polityk tych podmiotów. Np. programiści z krajów objętych sankcjami nagle stracili dostęp do swoich repozytoriów na GitHub, bo taka decyzja polityczna. Wiedza w Wikipedii jest otwarta, ale już np. wyniki badań naukowych często lądują za paywallem wydawców. Zwykły użytkownik szukając informacji polega głównie na Google, który ustala co zobaczymy na pierwszej stronie wyników – to też forma władzy nad wiedzą. Zasady open source: Distribuowane repozytoria kodu – w duchu fediverse powstają już alternatywy jak Gitea czy GitLab, które można federować (projekt w jednym miejscu może być forkiem z drugiego, a użytkownicy mogą zgłaszać zmiany między serwerami). Publiczna infrastruktura powinna wspierać hostowanie kodu o znaczeniu społecznym – np. oprogramowania tworzonego na uczelniach czy w administracji – na własnych serwerach, nie u komercyjnych dostawców. Otwarte repozytoria danych i wiedzy – idea danych otwartych (open data) i otwartej nauki zakłada, że wyniki badań finansowanych publicznie trafiają do publicznych baz. System powinien ułatwiać dostęp do tych zasobów, a także ich zrozumienie (np. publikacje naukowe w przetłumaczonej na język potoczny formie, co zresztą jest misją fundacji takich jak Open Digital Foundation). Neutralna wyszukiwarka – to duży temat, ale w ramach publicznej infrastruktury można by rozwijać silnik wyszukiwania, który nie profiluje użytkownika pod reklamy, nie manipuluje kolejnością wyników pod kątem zysku, tylko stawia na rzetelność i przydatność informacji. Trudne zadanie (skoro nawet Google ma z tym problemy), ale może w modelu non-profit i open algorytmy da się osiągnąć bardziej przejrzysty ranking.
• Asystent AI – osobisty asystent wspierany sztuczną inteligencją (jak Siri, Alexa, Asystent Google, ChatGPT). Obecne nadużycia: Dzisiejsze asystenty głosowe nagrywają nasze polecenia i odsyłają na serwery firm, gdzie bywały odsłuchiwane przez pracowników (by „usprawnić jakość” – co wyciekło parę lat temu). Modele językowe typu ChatGPT potrafią generować odpowiedzi, ale nie wiemy, na jakiej podstawie – mogą halucynować, przekazywać uprzedzenia zawarte w danych treningowych. Co gorsza, jeśli taki model jest kontrolowany przez jedną korporację, może stać się narzędziem wpływu: np. faworyzować w rekomendacjach produkty tej firmy, udzielać „porad” zgodnych z interesem biznesowym sponsora. Zasady open source: Otwarte modele AI – projekty typu BigScience pokazały, że można trenować duże modele językowe we współpracy międzynarodowej i je udostępnić (patrz model Bloom). Publiczny asystent AI mógłby korzystać z modeli, których architektura i dane treningowe są jawne, poddane audytowi etycznemu (np. czy nie dyskryminują). Lokalne działanie tam, gdzie możliwe – zamiast wysyłać wszystko w chmurę, asystent mógłby działać częściowo na urządzeniu użytkownika (zwłaszcza wrażliwe polecenia jak „pokaż moje zdjęcia z zeszłego lata”) – open source ułatwia niezależnym ekspertom potwierdzenie, że tak jest faktycznie. Neutralność i brak reklam – asystent publiczny nie podpowie nam „najbliższy sklep X (sponsorowany) jest za rogiem”, tylko np. wskaże listę wszystkich aptek dyżurnych bez preferencji. Jego celem jest służenie użytkownikowi, a nie monetyzacja. Co ważne, weryfikacja informacji – asystent mógłby być zaprojektowany, by zawsze pokazywać źródła swojej odpowiedzi (np. linki do baz wiedzy), i umożliwiać zgłaszanie/poprawianie błędów przez społeczność naukową. Transparentność modelu pozwoli zidentyfikować, dlaczego udzielił złej odpowiedzi (np. czytając wyuczone dane) – co dziś jest niemożliwe przy zamkniętych modelach.

Powyższa mapa nie wyczerpuje wszystkich usług, ale pokazuje kierunek: „wbudowana etyka” i kontrola społeczna zamiast polegania na obietnicach prywatnych firm. Każda usługa ma inne wyzwania, ale łączy je idea, że otwartość kodu i transparentne zasady to podstawa do odbudowania zaufania i bezpieczeństwa w cyfrowym świecie.

Open source w instytucjach – przykłady wdrożeń

Koncepcja open source jako publicznej infrastruktury nie jest czysto teoretyczna. W różnych miejscach świata podejmowano już próby wdrażania otwartego oprogramowania na poziomie państwowym czy samorządowym. Oto kilka przykładów z praktyki – zarówno sukcesów, jak i porażek, z których płyną cenne lekcje:

• Estonia – platforma X-Road: Estoński e-rząd opiera się na X-Road – otwartoźródłowej infrastrukturze wymiany danych między systemami państwowymi. Dzięki X-Road różne bazy (np. rejestr ludności, system zdrowia, policja) komunikują się bezpiecznie i spójnie. Co ważne, X-Road został udostępniony jako open source i przyjęty również przez inne kraje (Finlandia, Islandia, Japonia i in.). To świetny przykład współdzielenia infrastruktury cyfrowej między państwami: zamiast każde budować od zera zamknięte systemy, korzystają z rozwijanego wspólnie otwartego rozwiązania. Efekt to oszczędność czasu (Estonia szacuje, że dzięki cyfryzacji oszczędza 1400 lat pracy urzędników rocznie!) oraz większe bezpieczeństwo – kod jest jawny, więc audyty wykrywają luki szybciej.
• Francja – inicjatywa BlueHats: Francuski rząd postawił na budowę społeczności otwartoźródłowych deweloperów w administracji. Inicjatywa BlueHats (zainaugurowana w 2018) zrzesza urzędników-programistów i ochotników, którzy tworzą lub rozwijają oprogramowanie w sferze publicznej. To podejście oddolne: państwo zachęca pracowników IT sektora publicznego do dzielenia się kodem i współpracy na GitHubie. Powstały m.in. otwarte projekty w cyberbezpieczeństwie, edukacji, narzędziach dla samorządów. BlueHats pokazuje, że w administracji są kompetencje i chęci do open source – trzeba je tylko wydobyć z silosów instytucji i połączyć. W ślad za Francją podobne ruchy obserwujemy gdzie indziej. Co ważne, Francja poszła dalej: w 2023 oficjalnie poparła zasady ONZ dotyczące open source i zobowiązała się do preferowania wolnego oprogramowania w administracji. To pierwszy kraj na świecie z takim zobowiązaniem.
• Niemcy – pakiet biurowy Phoenix: Rząd Niemiec, szukając niezależności od korporacyjnych rozwiązań biurowych (Microsoft 365), rozpoczął projekt Phoenix – suita narzędzi oparta na istniejących otwartoźródłowych komponentach (Nextcloud, LibreOffice/Collabora, komunikator Matrix, Jitsi). Celem było stworzenie „Souveräner Arbeitsplatz” – suwerennego cyfrowego miejsca pracy dla urzędów, całkowicie opartego na wolnym oprogramowaniu. Projekt napotkał jednak trudności. Okazało się, że choć wykorzystuje open source, to integracja i rozwój były prowadzone mało transparentnie przez firmę Dataport. W 2023 r. organizacje (FSFE) alarmowały, że kod całości wciąż nie jest publicznie dostępny, a komunikacja z społecznością kuleje. Sprawa Phoenix stała się lekcją, jak nie robić open source w instytucji: nie wystarczy nakleić etykietki „open”, trzeba jeszcze faktycznie udostępnić kod i budować wokół niego otwartą społeczność. Niemcy wciąż nad tym pracują – powstało centrum kompetencji ZenDiS, które ma koordynować te wysiłki. Projekt Phoenix pokazuje, że polityczna deklaracja to jedno, a wdrożenie w praktyce – drugie. Mimo potknięć, idea jest w toku i być może z opóźnieniem, ale doczekamy się w Niemczech w pełni otwartego pakietu urzędowego. Dla nas to cenna wskazówka: przejście na open source wymaga dobrej koordynacji i zrozumienia filozofii otwartości, inaczej grozi tzw. open-washing (pozornej otwartości).
• Norwegia – otwarty NAV: Norweska administracja udowadnia, że open source może stać się naturalnym standardem działania instytucji publicznej. NAV, czyli norweski urząd pracy i polityki społecznej, tworzy oprogramowanie w sposób otwarty, dostępny na GitHubie. Mottem jest: „Skoro nasze systemy są finansowane przez podatników, kod powinien być wolnodostępny”. W praktyce oznacza to setki repozytoriów – od systemu zasiłków po wewnętrzne narzędzia – które każdy może przejrzeć. Norwegowie wierzą, że to poprawia jakość ich programów (więcej oczu może zgłaszać błędy) i sprzyja współpracy między agencjami. Takie podejście buduje też kulturę transparentności w urzędzie: programiści mają świadomość, że ich kod jest publiczny, więc przykładają się do dokumentacji, bezpieczeństwa i unikania skrótów. NAV organizuje nawet hackathony i dzieli się wiedzą ze społecznością open source w Norwegii. Efekt? Wiele innowacji powstałych w NAV trafia później do innych sektorów, a urząd unika zależności od pojedynczego dostawcy. To model „państwo jako współtwórca open source”, nie tylko bierny konsument.
• Fediverse – Mastodon i spółka: Sukcesem oddolnym, który zwrócił uwagę świata, jest rozwój fediverse – federacji serwisów społecznościowych takich jak Mastodon (mikroblogi), Pixelfed (zdjęcia, alternatywa dla Instagrama), PeerTube (wideo) itp. Wszystkie te platformy są open source i komunikują się wspólnym protokołem (ActivityPub). Mastodon zdobył rozgłos po turbulencjach związanych z Twitterem – kiedy prywatna platforma zaczęła wprowadzać kontrowersyjne zmiany, setki tysięcy użytkowników przeniosły się na Mastodona. Pod koniec 2022 Mastodon urósł z ok. 300 tys. do ponad 2,5 mln aktywnych użytkowników miesięcznie w ciągu kilku tygodni. Pokazało to, że istnieje apetyt na alternatywę bez reklam i algorytmów manipulujących zasięgami. Fediverse nie jest zarządzane przez żadną jedną firmę – to sieć tysięcy serwerów prowadzonych przez różne społeczności, które wzajemnie wymieniają się postami. Dzięki temu przypomina infrastrukturę publiczną: np. samorządy lokalne zakładają własne serwery Mastodona dla mieszkańców, instytucje kultury (jak muzeum czy biblioteka) komunikują się tam z odbiorcami, a jednocześnie wszyscy mogą rozmawiać globalnie. Pewną barierą jest nieco większa złożoność (trzeba wybrać serwer, nauczyć się nowej etykiety), przez co nie wszyscy z Twittera zostali na Mastodonie. Ale projekt trwa i rośnie – to dowód, że model federacyjny + open source może działać na masową skalę. Przy okazji wyszły też wyzwania: brak scentralizowanego nadzoru utrudnia moderację nadużyć (każdy serwer ma własnych moderatorów, różny poziom restrykcji), brakuje też jednego mechanizmu zarabiania dla twórców (co komercyjne platformy oferują). Mimo to fediverse stało się ważnym elementem dyskusji o przyszłości mediów społecznościowych.
• Protokół Matrix – bezpieczna komunikacja publiczna: Wspomniany już Matrix to otwarty protokół komunikatora działającego w modelu federacji (podobnie jak e-mail). Jego dojrzałość sprawiła, że rządy Francji i Niemiec wybrały go jako bazę dla swoich oficjalnych komunikatorów. Francuski system Tchap to aplikacja oparta na Matrixie, zbudowana dla urzędników państwowych – korzysta z niej już ponad 600 tysięcy pracowników administracji. Działa to on-premise (na serwerach rządowych), co daje Francji suwerenność komunikacyjną – nie jest zależna od zagranicznych komunikatorów. Kod Tchap również jest open source. Niemcy poszli w ich ślady z projektem BundesMessenger dla służby zdrowia i urzędów. Matrix z projektu geeków stał się więc elementem infrastruktury państwowej. Co więcej, Francja w 2025 dołączyła jako pierwszy kraj do fundacji Matrix, wspierając finansowo jego rozwój. To ważny precedens: rząd nie tylko używa open source, ale też współfinansuje jego rozwój jako wspólne dobro, wiedząc że korzystają na tym wszyscy (Matrix jest też używany przez firmy, organizacje pozarządowe i zwykłych obywateli szukających bezpiecznej komunikacji).
• Linux i open source w administracji – lekcje z przeszłości: Już kilkanaście lat temu niektóre miasta odważyły się przejść na otwarte oprogramowanie. Sztandarowy przykład to Monachium (Niemcy) z projektem LiMux – własną dystrybucją Linuksa wdrożoną na tysiącach komputerów urzędników. Projekt rozpoczęty w 2004 do 2013 objął większość wydziałów i pokazał, że technicznie da się uniezależnić od Windows. Niestety, późniejsze zmiany polityczne doprowadziły do odwrotu – w 2017 nowe władze podjęły decyzję o powrocie do oprogramowania Microsoftu. Powody były głównie polityczne i organizacyjne, nie czysto techniczne. Brak dostatecznego szkolenia użytkowników i lobbing korporacyjny zrobiły swoje. Monachium stało się często przywoływanym przykładem „nieudanej migracji”, choć w istocie przez kilkanaście lat system działał i zaoszczędził miastu około 11 mln euro. Wnioski? Open source w instytucji wymaga stałego wsparcia i adaptacji – nie można spocząć na laurach, bo pracownicy zmieniają się, pojawiają nowe potrzeby. Gdy brakuje strategii i liderów, łatwo o krok wstecz. Na szczęście Monachium nie zrezygnowało definitywnie z idei: po 2020 pojawiły się tam głosy, by jednak przy nowych wdrożeniach preferować open source. Inne miasta np. Barcelona, Walencja, Turyn również ogłosiły plany migracji na wolne oprogramowanie – z różnym skutkiem. Ważne, że idea żyje, a każde potknięcie uczy, jak robić to lepiej.

Podsumowując: światowe trendy wskazują na rosnące zainteresowanie otwartymi rozwiązaniami w sektorze publicznym. Unia Europejska promuje ideę technologicznej suwerenności, wprost rekomendując korzystanie z open source w administracji i publicznych zamówieniach. Pojawiają się nawet przepisy – np. Szwajcaria w 2023 przyjęła prawo nakazujące urzędom w pierwszej kolejności używać otwartego oprogramowania, a nowe kody pisane na zlecenie państwa publikować jako open source. To przełomowe podejście: tak jak budynek za publiczne pieniądze staje się własnością publiczną, tak samo kod finansowany z naszych podatków powinien być dostępny dla wszystkich – by go wykorzystać ponownie, sprawdzić i udoskonalić.

Co to znaczy „audytowalny kod”?

Audytowalny kod to taki, który można niezależnie sprawdzić pod kątem działania i bezpieczeństwa. W praktyce oznacza to pełną dostępność kodu źródłowego programu – czyli tego „przepisu”, według którego działa aplikacja. Jeśli kod jest otwarty i dobrze udokumentowany, można przekazać go do analizy specjalistom (np. zewnętrznej firmie audytorskiej, uniwersytetowi czy społeczności programistów). Taki audyt polega na przejrzeniu kodu linijka po linijce (często wspomaganym narzędziami automatycznymi), by znaleźć ewentualne błędy, luki bezpieczeństwa lub celowo złośliwe fragmenty. 

Dlaczego to ważne? Wyobraźmy sobie, że korzystamy z aplikacji do głosowania w wyborach. Jeśli jej kod nie jest audytowalny, musimy wierzyć producentowi na słowo, że np. sumuje głosy poprawnie i nikt nie manipulował wynikiem. Przy audytowalnym kodzie nie musimy wierzyć – możemy to zweryfikować. Eksperci mogą potwierdzić: „tak, algorytm zlicza głosy uczciwie, nie ma tajnych ‚tylnych drzwi’ umożliwiających zmiany wyniku”. 

Audytowalność kodu jest też kluczowa dla bezpieczeństwa. W przypadku np. aplikacji bankowej, niezależny audyt może wykryć lukę pozwalającą hakerom kraść dane – i to zanim hakerzy sami ją znajdą. W zamkniętym kodzie taka luka mogłaby latami pozostać nieznana (aż ktoś padnie ofiarą ataku). Otwartość przyśpiesza ujawnianie problemów: ktoś życzliwy zajrzy, powie „halo, tu jest błąd!” i można go załatać, zanim stanie się tragedia. 

Warto podkreślić: audyt kodu nie musi oznaczać, że każdy obywatel siada i czyta program (tak jak nie każdy czyta księgi finansowe miasta). Ważne, że może to zrobić dowolnie wybrany zaufany podmiot – np. NIK, certyfikowany audytor czy społeczność naukowców. Kod audytowalny to kod przejrzysty, a przejrzystość chroni nas przed niespodziankami. Właśnie dlatego programiści, którzy nic złego nie chcą ukrywać, często sami otwierają swój kod: zapraszają – „sprawdźcie mnie”. Jeśli producent wzbrania się przed pokazaniem kodu, trudno o lepszy znak ostrzegawczy. 

Podsumowując, audytowalny = sprawdzalny. To oprogramowanie jak most z przezroczystego szkła – każdy inżynier może ocenić, czy jest solidny, zanim na niego wjedziemy.

Co to jest „fork” i po co prawo do forka?

Słowo „fork” (dosłownie: widelec, rozwidlenie) w świecie oprogramowania oznacza skopiowanie istniejącego projektu i rozpoczęcie jego rozwoju niezależnie od oryginału. Wyobraźmy sobie, że oprogramowanie to przepis kulinarny. Mamy oryginalny przepis, ale ktoś postanawia zrobić własną wersję – bierze ten sam spis składników i instrukcje, po czym modyfikuje je według własnego pomysłu. To właśnie fork: nowa „gałąź” projektu, która ma wspólne korzenie, ale dalej może pójść w innym kierunku. 

Prawo do forka jest fundamentem licencji open source. Oznacza, że jeśli oprogramowanie jest otwarte, każdy ma prawo wziąć jego kod i wykorzystać go w własnym projekcie – nawet konkurencyjnym. W świecie zamkniętego software to niedopuszczalne (chronią tego licencje, prawo autorskie). W open source jest to celowe: dopuszczamy konkurencję i różnorodność, bo wierzymy, że wyjdzie to wszystkim na dobre. 

Po co forki? Jest kilka scenariuszy:

• Plan awaryjny: Gdy twórcy oryginalnego projektu przestają go rozwijać lub podejmują decyzje szkodliwe dla użytkowników. Wtedy społeczność może zrobić fork i kontynuować pracę nad swoją wersją, bez błędnych decyzji oryginału. Przykład: projekt OpenOffice zaczął tracić impet pod kontrolą korporacji Oracle, więc społeczność zrobiła fork o nazwie LibreOffice i ten rozkwitł, podczas gdy OpenOffice zamarł. Fork uratował więc ideę otwartego pakietu biurowego.
• Dopasowanie do potrzeb: Czasem jeden program nie może zadowolić wszystkich potrzeb. Fork pozwala zrobić wersję wyspecjalizowaną. Np. ktoś może wziąć otwarty kod systemu operacyjnego i utworzyć fork skoncentrowany na maksymalnym bezpieczeństwie (kosztem wygody), podczas gdy oryginał idzie w mainstream. Oba projekty mogą istnieć równolegle, trafiając do różnych grup odbiorców.
• Innowacja przez eksperyment: Niektóre społeczności używają forka do testowania radykalnych pomysłów. Robią odgałęzienie, wprowadzają duże zmiany i sprawdzają, co z tego wyjdzie. Jeśli się uda – oryginał może później zaadaptować te zmiany. Jeśli nie – główny projekt był cały czas stabilny. To trochę analogiczne do nauki: różne zespoły badają różne hipotezy, a potem dzielą się wnioskami.
• Bezpieczeństwo przed monopolizacją: Fork jest straszakiem na nieuczciwe praktyki. Jeśli firma prowadząca otwarty projekt zacznie np. dodawać do niego kod śledzący użytkowników, ktoś inny może natychmiast zrobić fork bez tych dodatków i wszyscy oburzeni użytkownicy przeniosą się na czystą wersję. Ta groźba motywuje, by nie psuć projektu – bo społeczność ma wyjście ewakuacyjne. To jak prawo do strajku u pracowników: rzadko używane ekstremum, ale samo jego istnienie wymusza dialog i dbanie o dobro wspólne.

Czy forki oznaczają chaos? Niekoniecznie. Większość udanych projektów open source woli trzymać się razem – fork to ostateczność, bo oznacza duży wysiłek (trzeba nagle samemu ogarniać wszystko). Zwykle społeczność próbuje najpierw dogadać się w ramach jednego projektu. Fork następuje, gdy dialog się nie udaje albo interesy się rozjeżdżają. Wtedy rozdział bywa zbawienny – każdy idzie swoją drogą, a użytkownicy wybiorą lepszy wariant. Z czasem jeden fork może zdobyć przewagę i drugi zaniknie, albo oba znajdą nisze. 

W kontekście infrastruktury publicznej prawo do forka zapewnia, że żaden wykonawca nie stanie się niezastąpiony. Gdy miasto zleci budowę otwartego systemu i dostawca zawiedzie (np. zacznie windować ceny wsparcia), inni mogą przejąć kod i kontynuować pracę. To zapobiega uzależnieniu (tzw. vendor lock-in) – zmorze wielu projektów IT w administracji. 

Podsumowanie: fork to wolność wyboru. Gwarancja, że zawsze istnieje plan B, C i D, bo wiedza zaklęta w kodzie należy do wszystkich, a nie do jednego podmiotu.

Open source

jako infrastruktura publiczna to inwestycja w wspólny kapitał cyfrowy. Tak jak poprzednie pokolenia budowały drogi, szkoły i szpitale, tak my stoimy przed zadaniem zbudowania publicznych dróg cyfrowych – otwartych, dostępnych i bezpiecznych dla wszystkich. Wymaga to zmiany myślenia: od konsumenta usług staniemy się ich współtwórcami i strażnikami. Ale nagroda jest ogromna: Internet służący społeczeństwu, a nie tylko garstce korporacji.

Bibliografia

1. Germany: dPhoenix on the road to failure? – Free Software Foundation Europe (2023).
2. France builds a government community for open source (Les Blue Hats) – Open Source Observatory, European Commission (2018).
3. X-Road: The Backbone of Estonia’s Interoperable Digital State – e-Estonia (platforma X-Road, 2021).
4. Nav: We build our software in the open – NAV (Norwegian Labour and Welfare Administration), GitHub README (dostęp 2026).
5. France jacks into the Matrix for state messaging – and pays too – The Register (Richard Speed, 30.10.2025).
6. More than two million users have flocked to Mastodon since Elon Musk took over Twitter – The Verge (J. Peters, 20.12.2022).
7. Munich Is Ditching Linux For Purely Political Reasons – It’s FOSS (A. Prakash, 11.01.2023).
8. Public Money? Public Code! – Free Software Foundation Europe (kampania, publiccode.eu).