W ostatnich dniach pojawiła się ciekawa informacja. Grupa czeskich aktywistów, w trakcie hackatonu, stworzyli prototyp elektronicznego systemu sprzedaży winiet. O samym projekcie możecie poczytać tutaj. W dużym skrócie z bodajże 18 elementów specyfikacji w czasie imprezy zaimplementowano 16, a te, których nie zaimplementowano to elementy powiązane z dostępem do informacji niejawnych. I można by w tym miejscu krzyknąć heap heap hura i podskakiwać z radości. W końcu „nasi” pokazali tym państwowym darmozjadom, że można lepiej wydać 400 mln koron. Można do tego dołożyć jeszcze, że dokopano Asseco, co jest rzeczą godną pochwały. Tyle, że nie do końca…

Rodzaje projektów i co z tego podziału wynika

Inżynieria oprogramowania jest dość ciekawą działką w kontekście relacji państwo-oprogramowanie, ale jeszcze ciekawszą działką jest światek starupowo-korporacyjny. Jedną z zasad w tym świecie jest ta, która mówi, że oprogramowania nie powinno się pisać, a kupować.

Kupuj, nie pisz

Nie mówi tylko o jakie oprogramowanie chodzi. Państwo może spokojnie kupować oprogramowanie użytkowe. Wręcz powinno, bo ciężko mi sobie wyobrazić, by ktoś chciał rozwijać swój OS albo pakiet biurowy. Nawet Korea Północna nie stworzyła swojego państwowego OSa od zera, a jedynie zbudowała własne distro Debiana.

Ale przecież, można wziąć darmowego Linuxa?

Można. Można też wziąć Libre Office. Tyle tylko, że później takiego darmowego Linuxa trzeba utrzymywać.

To się biurwy nauczą!

Tak. Nauczą się dokładnie w tym samym momencie, gdy ty nauczysz się ich pracy. Coś za coś. Szeroko rozumiana branżunia ma niestety problem z postrzeganiem pracy z komputerem. Dla nas wszystko jest proste i można to szybko ogarnąć. Nawet skomplikowane koncepcje „same wchodzą”. Mamy wprawę w modelowaniu procesów i tłumaczeniu ich na programy. To jednak za mało, bo nie mamy głębokiej wiedzy, która idzie wraz z tymi procesami. Szczególnie jeżeli procesy te dotyczą np. procedury administracyjnej. Podsumowując, niech biurwy potrafią sprawnie biurwować, a nie klepać skrypty w bashu.

Kupujesz sprzęt i wsparcie

W idealnym przypadku państwo powinno kupować sprzęt oraz wsparcie do oprogramowania o otwartym kodzie. Do tego dochodzą szkolenia, które powinny jednak być specyficznie zaplanowane. Szkolenia powinny być realizowane wewnątrz organizacji przez osoby zatrudnione w tej organizacji. Niektóre z tych osób powinny szkolić się na zewnątrz (u twórców), a swoją wiedzę przekazywać innym szkoleniowcom. Dzięki temu państwo zachowuje znaczną niezależność od zewnętrznych szkoleń, a jednocześnie może wpływać na program szkolenia, tak by dostosować je do potrzeb pracowników.

Rozszerzaj to co kupiłeś

Drugim podejściem jest zakup oprogramowania, które jest najbliżej wymagań i jego modyfikacja. Część procesów i potrzeb, jakie ma państwo, można ogarnąć za pomocą modyfikacji dostępnego oprogramowania. Wynika to z faktu, że niektóre procesy realizowane przez państwo nie różnią się od typowych procesów biznesowych. Publikowanie dokumentów w BIPie, choć musi spełniać pewne reguły, nie jest niczym innym jak tworzenie treści za pomocą CMSa. Serio. To, co zrobili Czesi, to przecież sklep z winietami postawiony na otwartym CMSie.

Pisz rzeczy specyficzne

Takich rzeczy jest zazwyczaj niewiele. Ich specyficzność nie leży w procesach lub wymaganiach jako takich, ale w sposobie obsługi, czy dodatkowych cechach. Co prawda rejestr PESEL nie odbiega od typowego rejestru kadrowego. Ba można powiedzieć, że jest znacznie prostszy. Jednak jego specyfika leży w informacjach, które przechowuje oraz w sposobie dostępu do nich.
Osobną grupę stanowią procesy objęte klauzulami poufności czy tajności. W ich przypadku to wystarczy, by wyłączyć je z analizy „czy jest coś, co można dostosować”. Przynajmniej na poziomie oficjalnego przetargu.

Urzędy nie powinny pisać oprogramowania

Urzędy, a nie państwo. Dlaczego? Cóż urzędy jako takie mają dwa piony. Pion merytoryczny, który zazwyczaj składał się z kompetentnych ludzi i pion polityczny, który składa się z ludzi „dających twarz” takim, a nie innym decyzjom. Piony te przenikają się w mniejszym bądź większym stopniu. Przy czym w ostatnich 15 latach to raczej pion polityczny wpycha swoich w pion merytoryczny, a nie na odwrót.

Urzędy pisać oprogramowania nie powinny, ponieważ nie mają do tego kompetencji. Byłem, widziałem. Rolą urzędów powinno być specyfikowanie wymagań dla oprogramowania, którego nie będzie się kupować w wersji pudełkowej.

Co może zrobić państwo?

Państwo ma kilka dróg, którymi może realizować swoje potrzeby w zakresie informatyzacji.

Tylko kupować

Państwo może kupować oprogramowanie w ramach jakiejś procedury. Czasami oznacza to, że kupi gotowce w pudełkach (systemy operacyjne, pakiety biurowe). Czasami oznacza to, że kupi zmodyfikowane oprogramowanie otwarte. Czasami rzeczywiście kupi coś napisanego od zera.
Wadą tego rozwiązania jest praktyczne zamknięcie kodu i specyfikacji. Wiele lat walki twórców Janosika z ZUSem o otwarcie specyfikacji systemów ZUS doskonale to ilustruje. To nie jest dobra droga.

Kupować gotowce, rozwijać samodzielnie

Ten model jest w pewnym sensie przeciwieństwem poprzedniego. Zakupy ograniczamy do minimum. Kupujemy tylko to, co nie będzie modyfikowane. Systemy operacyjne, pakiety biurowe, oprogramowanie do obsługi systemu „numerkowego” czy kadrowego. Cała reszta prac jest przeniesiona do odpowiednich ośrodków akademickich. Państwo samodzielnie rozwija potrzebne oprogramowanie w swoich firmach. Tam też są prowadzone prace w zakresie R&D czy badań podstawowych.
Taki model jest możliwy i działał przez wiele lat w USA. Zaletą takiego podejścia jest zabezpieczenie państwa przed problemami dostawców. Całość oprogramowania, które wymaga jakiejś pracy, a nie jedynie instalacji z pudełka, jest własnością państwa. Źródła nie są może powszechnie dostępne, ale też nie muszą. Wadą jest duża bezwładność takiego systemu i koszty. Jeżeli chcemy być na bieżąco, to trzeba inwestować w badania. Te nie są tanie. W dodatku złe decyzje projektowe będą się ciągnąć przez dziesięciolecia.

Kupować gotowce i Otwarta specyfikacja

Poza wspomnianymi już kilkukrotnie pudełkami cała reszta oprogramowania nie jest rozwijana przez państwo. Zamiast tego państwo definiuje, ogłasza i utrzymuje specyfikacje. Utrzymuje też infrastrukturę potrzebną do testowania zgodności oraz certyfikuje producentów w procedurze administracyjnej.
Tu mała uwaga, procedura administracyjna ma to do siebie, że nie bada „racji” stron, a jedynie sprawdza, czy spełnione są wymagania. Spełniasz wymagania, oto twój certyfikat i nie ważne, że napisałeś to w php4.
Zaletą tego modelu jest odpowiednia separacja odpowiedzialności pomiędzy biznes-państwo, a dostawców. Pozwala to też na uniknięcie sytuacji, gdzie dostawca nie chce ujawnić specyfikacji. Ta jest zawsze jawna. Eliminujemy w ten sposób monopolistów.
Oczywiście model ten ma też wady. Oprogramowanie nadal trzeba kupować. Nadal trzeba płacić za jego utrzymanie i rozwój. Pozostaje też problem jakości specyfikacji i jej szczegółowości. Specyfikacje też będą się starzeć z punktu widzenia technologii, co oznacza konieczność ich aktualizacji.

Hackatony nie są rozwiązaniem

Problem to sposób, w jaki państwo powinno zamawiać oprogramowanie. Na hackatonach można stworzyć bardzo dużo bardzo fajnego oprogramowania. Można pokazać, że taka czy inna koncepcja daje ciekawe możliwości albo zmaterializować dość mglisty pomysł. Takie imprezy to świetne miejsce by państwo i specjaliści IT wymieniali się pomysłami, ideami, wskazywali sobie wzajemnie problemy. To w takim miejscu powinna siedzieć fundacja Panoptykon, by móc mówić o problemach ochrony prywatności.
Hackatony jednak nie są miejscami, gdzie stworzy się konkretne rozwiązanie. Po imprezie w Czechach co prawda anulowano kontrakt, a władze chcą wdrażać rezultaty pracy uczestników. Jednak nie wyobrażam sobie, żeby teraz te czterdzieści kilka osób z dnia na dzień rzuciło pracę i ruszyło po kraju, by szkolić użytkowników. Albo, żeby rozdysponowało pomiędzy siebie kilka telefonów i ustaliło grafik dyżurów nocnych i weekndowych, bo system wymaga wsparcia 24/7. I co najważniejsze uczestnicy nie zrobią tego za darmo.
Media podając kwotę przetargu, rzucają konkretną liczbę. Nigdy nie starają się rozbić jej na poszczególne pozycje. Przemilczają też, ile trwa utrzymanie, czy cena obejmuje szkolenia i wdrożenie użytkowników. To wszystko kosztuje co najmniej tyle samo co „czyste programowanie”.

I o ile programowanie na hackatonie jest dobrą zabawą, to nikt nie będzie w tej formie utrzymywać oprogramowania.