Szansa dla open-source w Polsce — sprzedawaj usługę, nie uzależnienie od dostawcy
Planowane w Polsce samorządowe pilotaże open-source mogą stworzyć rynek dla firm programistycznych, które pomogą samorządom w migracji, integracji i utrzymaniu otwartych technologii. To konkretny sygnał, ale na razie nie należy go przeceniać. 12 października 2026 r. Ministerstwo Cyfryzacji zapowiedziało na 12 listopada wydarzenie, podczas którego szczególną uwagę poświęci proponowanym pilotażom. Konkurs o dofinansowanie określiło jako kolejny krok, a nie otwarty już nabór wniosków.
Deweloperzy i integratorzy powinni się do tej szansy przygotować, zamiast spekulować. Proponowany program wykracza poza instalację oprogramowania: obejmuje wdrożenie, szkolenia, bezpieczeństwo i wsparcie techniczne. Warto więc zadać sobie pytanie: czy twój zespół potrafi dostarczyć środowisko open-source, z którego gmina będzie mogła niezawodnie korzystać, utrzymywać je przy rozsądnych kosztach, a z czasem przekazać jego obsługę innemu dostawcy?
Rozpoznaj szansę, zanim zaczniesz budować lejek sprzedażowy
Październikowy komunikat daje okazję, by włączyć się w rozmowy. Organizowany przez ministerstwo Dzień Otwartych Technologii odbędzie się w Warszawie 12 listopada 2026 r. W programie są konsultacje oraz sesja pytań i odpowiedzi dotyczące samorządowych pilotaży. Zakończenie rejestracji na wydarzenie zaplanowano na 30 października. To terminy związane z wydarzeniem, a nie z naborem wniosków o dofinansowanie.
Trwa również rozpoznanie rynku dostawców. W komunikacie z 28 września Fundacja Digital Poland opisała zlecone przez ministerstwo mapowanie rynku, obejmujące ekspertów open-source, organizacje wdrożeniowe i wykonawców rekomendowanych przez samorządy. Termin nadsyłania zgłoszeń — 10 października 2026 r. — już minął. W wyniku tych prac mają powstać baza dostawców, raport rynkowy i mapa ekosystemu. Udział w przedsięwzięciu nie oznacza wygranej w przetargu ani objęcia zatwierdzoną umową ramową na dostawy lub usługi.
To ważne przy planowaniu sprzedaży. Traktuj tę inicjatywę jako szansę, którą trzeba dopiero ocenić, a nie zakontraktowany przychód do ujęcia w prognozie.
Zanim poświęcisz dużo czasu i pieniędzy na przygotowanie oferty, wyjaśnij następujące kwestie:
Uprawnieni wnioskodawcy: Kto może ubiegać się o dofinansowanie i na jakich zasadach będą uczestniczyć partnerzy wdrożeniowi?
Zamówienia: Jak dofinansowane podmioty będą wybierać dostawców?
Ocena: Jakie dowody pozwolą wykazać jakość wdrożenia i możliwość jego powielenia?
Budżet: Jakie koszty i okresy realizacji będą kwalifikowalne?
Ciągłość: Kto sfinansuje eksploatację po zakończeniu pilotażu?
Te pytania mają pomóc w ocenie przedsięwzięcia. Nie przesądzają, co znajdzie się w ostatecznym regulaminie konkursu.
Sprzedawaj działające środowisko, nie katalog oprogramowania
Zgodnie z propozycją przedstawioną do konsultacji konkurs ma być realizowany w ramach Działania 2.4 programu Fundusze Europejskie na Rozwój Cyfrowy (FERC). Proponowany zakres obejmuje chmurę prywatną, aplikacje biurowe, pocztę elektroniczną, wideokonferencje, kalendarze i komunikatory. Szczególnie premiowane mają być zintegrowane pakiety, których aplikacje ze sobą współpracują. Przewidziano też finansowanie wdrożenia, szkoleń użytkowników, bezpieczeństwa i rocznego wsparcia technicznego. Nadal są to propozycje, a nie ostateczne warunki kwalifikowalności.
Oprzyj więc ofertę na tym, co wdrożenie ma dać urzędowi, a nie na liście produktów.
Oszacuj zakres prac, zanim obiecasz migrację
Analiza przedwdrożeniowa powinna ustalić:
Które procesy pracy obejmie pilotaż.
Które dokumenty, skrzynki pocztowe i kalendarze wymagają migracji.
Które istniejące systemy muszą pozostać zintegrowane.
Którzy użytkownicy potrzebują dodatkowego wsparcia.
Co będzie oznaczać udane przejście na nowe rozwiązanie.
Jak gmina może wycofać zmianę, która się nie sprawdziła.
Na przykład pilotaż pakietu biurowego mógłby obejmować testy reprezentatywnego zestawu dokumentów i arkuszy kalkulacyjnych przed rozszerzeniem wdrożenia na cały wydział. To zalecany sposób postępowania, a nie potwierdzony wymóg programu.
Jasno określ zasady integracji i wdrażania użytkowników
Ustal, kto odpowiada za każdy interfejs i każde zadanie migracyjne. Oddziel konfigurację aplikacji od konwersji danych, przygotowania użytkowników do pracy i przekazania środowiska do eksploatacji.
Szkolenia powinny dotyczyć rzeczywistych zadań: przygotowania dokumentu, udostępnienia pliku, zorganizowania spotkania czy poradzenia sobie z typowym błędem. Samo ukończenie instalacji od strony technicznej nie powinno wystarczać do odbioru.
Wyceń całą usługę
Przedstaw wdrożenie, szkolenia i bieżącą obsługę jako odrębne pakiety prac. Wyjaśnij, co obejmuje wsparcie, co wykracza poza zakres usługi i jak będą zatwierdzane dodatkowe prace.
Ułatwi to ocenę oferty i pozwoli od początku zaplanować utrzymanie pilotażu, a nie tylko termin jego uruchomienia.
Zadbaj o niezależność od dostawcy już przy projektowaniu architektury
Licencja open-source to tylko jeden z elementów niezależności operacyjnej. Sam dostęp do kodu i możliwość jego modyfikowania nie zapewnią gminie kompetencji ani dokumentacji potrzebnych do korzystania z oprogramowania. Nie rozstrzygną też, kto odpowiada za jego utrzymanie. Rekomendacje z warsztatów opublikowane przez Human Colossus Foundation wskazują, że otwarte protokoły, zapewnione finansowanie utrzymania i kompetencje wewnątrz administracji muszą się uzupełniać. Są to rekomendacje praktyków, a nie potwierdzone kryteria konkursu.
Uwzględnij te wymagania w proponowanym standardzie przekazania środowiska.
Pakiet wdrożeniowy powinien jasno opisywać:
Przenośność danych: Jak urząd eksportuje swoje dane i sprawdza wynik eksportu.
Interoperacyjność: Jakie interfejsy i protokoły łączą aplikacje.
Kontrola operacyjna: Kto kontroluje konfigurację, uprawnienia dostępu i materiały wdrożeniowe.
Odpowiedzialność za utrzymanie: Kto zajmuje się aktualizacjami, incydentami i krytycznymi zależnościami.
Przekazanie wiedzy: Co pracownicy samorządu muszą rozumieć i przećwiczyć.
Zmiana dostawcy: Co otrzyma nowy dostawca podczas przejmowania obsługi.
Przydatnym testem odbiorowym byłoby zlecenie drugiemu zespołowi wykonania określonego zadania operacyjnego wyłącznie na podstawie przekazanych materiałów. Mogłaby to być opisana w dokumentacji zmiana konfiguracji, próba odtworzenia środowiska po awarii lub eksport danych.
Nie chodzi o wyeliminowanie wyspecjalizowanych dostawców, lecz o możliwość ich zmiany bez zmuszania urzędu do przebudowy środowiska.
Firma programistyczna może w ten sposób pokazać, jak klient skorzysta z niezależności od dostawcy, zamiast poprzestawać na ogólnych zapewnieniach.
Projektuj pilotaże, które inne gminy mogą wykorzystać ponownie
Możliwość powielania wdrożeń została wprost uwzględniona w pytaniach konsultacyjnych ministerstwa. Proponowane pilotaże mają pomóc ustalić, które rozwiązania open-source warto wprowadzać do administracji publicznej i jak skutecznie je wdrażać.
Warto przyjrzeć się europejskim doświadczeniom z zamówieniami publicznymi. Podczas warsztatów OSOR dotyczących zamówień na rozwiązania open-source podkreślano znaczenie pilotaży o jasno określonym celu, wniosków przydatnych w kolejnych projektach, wczesnej współpracy ze społecznościami i dostawcami komercyjnymi oraz szkoleń z zamówień publicznych. Fińska platforma eVaka jest przykładem wspólnego inwestowania w oprogramowanie i rozwijania go przez miasta, ale nie wyznacza modelu zamówień dla planowanego polskiego konkursu.
Dostawcy powinni zatem oddzielić zasoby wdrożeniowe wielokrotnego użytku od konfiguracji lokalnej.
Warto przygotować:
Architekturę referencyjną z udokumentowanymi zależnościami.
Powtarzalne procedury wdrażania i konfiguracji.
Listy kontrolne migracji i szablony walidacji.
Materiały szkoleniowe, które można dostosować do różnych urzędów.
Instrukcje operacyjne i procedury eskalacji.
Przejrzysty rejestr wyjątków specyficznych dla danej gminy.
Nie traktuj każdej lokalnej różnicy jako powodu do utworzenia osobnego forka produktu. Wyjaśnij, które różnice można obsłużyć konfiguracją, które wymagają prac integracyjnych, a które rzeczywiście uzasadniają prace programistyczne.
Mierz rezultaty w codziennej pracy urzędu. Proponowane kryteria odbioru mogą obejmować wykonanie wybranych zadań administracyjnych, poprawną migrację uzgodnionych danych, przywrócenie działania po określonej awarii oraz samodzielne wykonanie udokumentowanych procedur operacyjnych.
To sugerowane miary oceny, a nie ogłoszone kryteria przyznawania dofinansowania.
Przygotuj się na długoterminową obsługę, ale nie zakładaj pewnych kontraktów
Proponowany roczny okres wsparcia określa, jak daleko sięga planowane finansowanie tej usługi. Nie oznacza, że późniejsze utrzymanie również otrzyma dofinansowanie ani że dostawca wdrożenia automatycznie zachowa zlecenie.
Przygotuj propozycję obsługi po pilotażu, zanim przedstawisz cenę początkowego wdrożenia. Rozróżnij:
Bieżące wsparcie i duże aktualizacje.
Utrzymanie bezpieczeństwa i rozwój nowych funkcji.
Standardowe godziny świadczenia usług i dodatkową dostępność wsparcia.
Odpowiedzialność za hosting i za utrzymanie aplikacji.
Dalsze świadczenie usługi i pomoc w przekazaniu obsługi.
Nie opieraj uzasadnienia biznesowego wyłącznie na oszczędnościach licencyjnych. Zaproponuj porównanie uwzględniające migrację, infrastrukturę, szkolenia, wsparcie, aktualizacje i ewentualne koszty wyjścia. Pozwól gminie ocenić korzyści i kompromisy w porównaniu z jej obecną sytuacją.
Na tym etapie najlepiej przygotować materiały potwierdzające kompetencje: referencje z podobnych projektów, metodykę migracji, macierz odpowiedzialności za integrację, mierzalne kryteria odbioru i realistyczny plan utrzymania.
Polska inicjatywa samorządowa dotycząca open-source uzasadnia przygotowania, ale nie daje pewności popytu. Wiarygodna oferta powinna obejmować działające środowisko, wsparcie z jasno określoną odpowiedzialnością i rzeczywistą możliwość przejścia do innego dostawcy, gdy klient tak zdecyduje.
