Co to jest Laravel: co ten wybór znaczy dla firmy zamawiającej system

Zapisane w ofercie „PHP 8.4, Laravel 13” nie jest szczegółem technicznym: te dwa wiersze rozstrzygają, jak długo system będzie dostawał poprawki zabezpieczeń, co będzie w nim kosztowało dodatkowo i ile będzie kosztowało przekazanie innemu programiście.

Oferta przychodzi w piątkowe popołudnie, a w części technicznej stoją dwa wiersze, których na spotkaniu nikt nie czyta na głos: „PHP 8.4” i „Laravel 13”. Cena jest zrozumiała, termin jest zrozumiały, i te dwa wiersze wyglądają jak wewnętrzna kuchnia dostawcy, mniej więcej tak samo ważne jak to, jakim wiertłem wywierci się otwór w ścianie, i dlatego zwykle pomija się je jako szczegół techniczny, za który odpowiada ktoś inny. Podpis stoi jednak pod całym dokumentem, a właśnie te dwa wiersze rozstrzygają, jak długo system w ogóle będzie dostawał poprawki zabezpieczeń, kto wystawi w nim comiesięczny rachunek ponad cenę prac i ile za trzy lata będzie kosztowało przekazanie go komu innemu.

Ten artykuł nie jest o tym, czy PHP jest dobrym językiem i czy Laravel jest dobrym frameworkiem, bo na to pytanie programiści odpowiadają między sobą, a zamawiającemu z tej rozmowy nie wynika żaden praktyczny pożytek. Jest o czterech rzeczach, które zamawiający może sprawdzić sam i bez wiedzy technicznej: kalendarz wsparcia, licencję, rynek pracy i warunki przekazania. Wszystkie cztery są publiczne, trzy z nich to albo daty, albo kwoty, czwarta jest tym, co o rynku da się i czego nie da się wiedzieć, i żadna nie zależy od tego, jak przekonująco napisano ofertę — dlatego warto je sprawdzić właśnie w tym tygodniu, w którym o cenie jeszcze można rozmawiać.

Co to jest Laravel, co to jest PHP i dlaczego to nie jeden wybór

PHP jest językiem programowania, w którym napisana jest serwerowa część systemu — ta część, która działa u dostawcy albo u Państwa operatora hostingu i której użytkownik nigdy nie widzi. Laravel z kolei to framework, to znaczy baza kodu już napisana w PHP, która rozwiązuje to, co powtarza się niemal w każdym projekcie: logowanie użytkowników, zapytania do bazy danych, kolejki, przechowywanie plików, wysyłkę poczty. W ofercie stoją obok siebie jak jeden wybór, ale są to dwa osobne produkty, które utrzymują dwa różne zespoły z dwoma różnymi kalendarzami wsparcia, i właśnie dlatego warto je przeczytać osobno.

Jak rozpowszechniony jest język, okazuje się trudniej powiedzieć, niż by się spodziewano. W3Techs, który regularnie skanuje ponad dwadzieścia milionów stron internetowych, w sierpniu tego roku pisze, że PHP używa 70,2% wszystkich witryn, których język programowania po stronie serwera to narzędzie zna. Ten ostatni warunek zwykle znika, gdy liczbę przepisuje się do prezentacji: nie chodzi o 70% wszystkich witryn świata, tylko o 70% tych, które to konkretne narzędzie w ogóle potrafi rozpoznać, przy czym część rozpoznań samo opisuje jako wyprowadzoną pośrednio — jeśli witryna jest na WordPressie, to jest PHP.

Zamawiającemu bardziej przydaje się inna liczba z tej samej strony. Wśród witryn, dla których W3Techs ustala także wersję PHP, 63,3% działa na ósmej, 28,7% na siódmej i 7,9% wciąż na piątej, choć siódma wersja straciła nawet poprawki zabezpieczeń już cztery lata temu. To znaczy, że około jednej trzeciej mierzalnego internetu opartego na PHP pracuje dziś na kodzie, do którego nikt już nie robi poprawek, i stało się tak nie dlatego, że język byłby zły albo że ktoś popełnił błąd przy pracach. Stało się tak dlatego, że nikt nie zamówił i nie opłacił zmiany wersji, i to jest właśnie ta część ryzyka, którą zamawiający może zarówno zobaczyć, jak i nią zarządzać.

Kalendarz wsparcia PHP to pierwszy dokument, który warto otworzyć

Zasada grupy deweloperów PHP jest krótka i publiczna: każda gałąź wersji dostaje pełne wsparcie przez dwa lata od pierwszego stabilnego wydania, potem jeszcze dwa lata wyłącznie krytycznych poprawek zabezpieczeń, a po czterech latach nie jest już utrzymywana wcale. W tej zasadzie jest jeden szczegół, który przy powtarzaniu prawie zawsze się ucina: rzeczywiste daty końca w tabeli są dostosowane do ostatniego dnia roku, a nie do rocznicy wydania w listopadzie, dlatego „dwa lata od premiery” i to, co stoi w tabeli php.net, różni się o miesiąc albo dwa.

W praktyce znaczy to, co następuje. Wersja 8.2 jest obecnie wyłącznie w trybie poprawek zabezpieczeń, a jej wsparcie kończy się już z końcem tego roku, czyli za około cztery miesiące. Wersja 8.3 pełne wsparcie straciła z końcem zeszłego roku i poprawki zabezpieczeń dostanie do końca 2027 roku, czyli jeszcze około szesnastu miesięcy. Wersja 8.4 w pełnym wsparciu dociągnie ten rok do końca i potem jeszcze dwa lata zostanie w trybie poprawek zabezpieczeń, natomiast najnowsza 8.5, która ukazała się w listopadzie zeszłego roku, pełne wsparcie dostaje jeszcze przez cały przyszły rok, a poprawki zabezpieczeń do końca 2029 roku.

Wsparcie wersji 8.1 skończyło się ostatniego dnia zeszłego roku, i właśnie ten przypadek zasługuje na uwagę, jeśli mają już Państwo system, a nie ofertę. Jeśli dostawca trzy lata temu napisał go na 8.1 i od tamtej pory nikt nic nie zmienił, to dziś działa na gałęzi, do której poprawki zabezpieczeń już nie przychodzą, i nie ostrzega o tym ani serwer, ani przeglądarka, ani sam system. Witryna otwiera się dokładnie tak samo jak wczoraj, klienci nic nie zauważają, a jedyne miejsce, w którym da się to zobaczyć, jest ta sama publiczna tabela, której otwarcie zajmuje mniej czasu niż przeczytanie strony tytułowej oferty.

Kalendarz Laravela jest krótszy niż kalendarz PHP

Laravel swoją politykę formułuje jeszcze krócej: poprawki błędów przez osiemnaście miesięcy, poprawki zabezpieczeń przez dwa lata i nowa wersja główna co roku mniej więcej w pierwszym kwartale. Wydania ze wsparciem długoterminowym, które w branży nazywa się LTS, dziś już nie ma — w starych wersjach naprawdę było, ale w tegorocznej tabeli takiej kolumny nie ma wcale, dlatego oferta, w której stoi „LTS Laravel”, opisuje coś, czego obecnie nikt nie sprzedaje. To krótsza obietnica, niż wielu zamawiających oczekuje od frameworka, na którym system ma stać przez następne pięć lat.

W liczbach, według samej dokumentacji Laravela, porządek jest taki. Laravel 13 ukazał się w marcu tego roku, poprawki błędów dostanie do trzeciego kwartału przyszłego roku, a poprawki zabezpieczeń — do 17 marca 2028 roku. Okno poprawek błędów Laravela 12 zamknęło się w połowie sierpnia tego roku, to jest siedemnaście dni przed napisaniem tych wierszy, a jego poprawki zabezpieczeń skończą się w lutym przyszłego roku. Wsparcie zabezpieczeń Laravela 11 skończyło się wiosną tego roku, więc system, który dziś działa na wersji jedenastej, już działa bez poprawek, niezależnie od tego, jak dobrze wygląda z zewnątrz.

Proszę zwrócić uwagę na to, że koniec poprawek błędów Laravela 13 podany jest jako kwartał, a nie jako konkretna data. To nieprecyzyjność samego sformułowania Laravela i nie jest problemem, dopóki przepisuje się je dokładnie tak, jak tam stoi; problem zaczyna się w chwili, gdy dostawca albo zamawiający zaokrągla to do konkretnego dnia i potem planuje budżet według liczby, której w źródle nie ma. Jeszcze jedna granica, którą trzeba znać, zanim wybierze się wersję: Laravel 13 wymaga co najmniej PHP 8.3, więc systemu na wersji trzynastej nie da się zostawić na 8.2 nawet wtedy, gdy sama 8.2 jeszcze przez jakiś czas dostawałaby poprawki zabezpieczeń.

Co oba kalendarze razem znaczą dla systemu zamawianego dziś

Jeśli system jest przekazywany na Laravelu 13 razem z PHP 8.4 albo 8.5, to pierwsza data, w której coś musi się ruszyć, to marzec 2028 roku, gdy kończą się poprawki zabezpieczeń Laravela, i jest to około osiemnastu i pół miesiąca od dziś. PHP w tym zestawieniu nie jest ograniczeniem, bo obie te gałęzie dostają poprawki zabezpieczeń dłużej niż framework, dlatego pierwsze, co się starzeje, jest Laravel, a nie język. To jest też jedyny uczciwy sposób, żeby odpowiedzieć na pytanie „jak długo ten system przetrwa bez dodatkowego nakładu” — nie odczuciem, tylko wcześniejszą z dwóch publicznych dat.

Jeśli ten sam system jest przekazywany na Laravelu 13, ale na PHP 8.3, kolejność odwraca się i pierwszy termin przypada za około szesnaście miesięcy, gdy kończą się poprawki zabezpieczeń tej gałęzi PHP. Jeśli dostawca pisze na Laravelu 12, co przy istniejącym projekcie wciąż jest całkowicie normalnym wyborem, to poprawki zabezpieczeń kończą się w lutym przyszłego roku, a życie nowego systemu zaczyna się od sześciu miesięcy do pierwszej obowiązkowej zmiany wersji. Różnica między pierwszym a trzecim wariantem to rok, który da się zyskać w jednej rozmowie przed umową, i którego po podpisie już kupić nie można.

Dwa błędy w tym rachunku są tak rozpowszechnione, że warto je nazwać osobno. Pierwszy to pomylenie pełnego wsparcia ze wsparciem zabezpieczeń, dlatego słysząc, że „wsparcie PHP 8.4 kończy się z końcem roku”, warto zapytać, które z dwóch okien jest w tym zdaniu: kończy się poprawianie zwykłych błędów, ale poprawki zabezpieczeń przychodzą jeszcze dwa lata. Drugi to zawierzenie zdaniu samego Laravela, że przejście na nową wersję główną zwykle zajmuje dzień albo mniej; to cel sformułowany przez deweloperów, nie zmierzona średnia, i w umowie nie da się go zapisać jako terminu.

Licencja kosztuje zero, i to prawda tylko o języku i frameworku

Framework Laravel jest rozpowszechniany na licencji MIT, jednej z najprostszych licencji open source, która pozwala używać kodu, zmieniać go i sprzedawać dalej, żądając jedynie zachowania informacji o prawach autorskich. Przy PHP jest nieco bardziej złożone, i ta złożoność jest aktualna właśnie teraz, bo licencja się zmienia: wersje do 8.5 włącznie wychodzą z redakcją 3.01 licencji PHP, a od 8.6 przechodzą na czwartą redakcję, którą php.net sam opisuje jako licencję „Modified BSD” i która w praktyce pokrywa się z BSD-3-Clause. W żadnym z tych wariantów opłaty nie przewidziano.

To znaczy, że za sam język i sam framework firma nie płaci ani za użytkownika, ani za rdzeń procesora, ani za rok, i to zero nie jest promocją, która kiedyś się skończy. Do porównania nadaje się model, którego używa Microsoft SQL Server: tam licencjonuje się albo według rdzeni, albo według serwera razem z licencjami dostępu klienta, wydanie Standard jest ograniczone do mniejszej z liczb: czterech gniazd procesora albo dwudziestu czterech rdzeni, a bezpłatne wydanie Express — do jednego gniazda albo czterech rdzeni. Dokładnych kwot tutaj nie zapisujemy, bo cennik się zmienia i trzeba go czytać u Microsoftu; dla zamawiającego porównywalny jest model, nie liczba — jeden produkt liczy według ilości sprzętu, drugi nie liczy wcale.

W zamówieniu ma to dwie konsekwencje, które warto zapisać od razu. Pierwsza jest przyjemna: nie ma audytu licencji, nie ma corocznego przeliczenia za użytkowników, których przez rok przybyło, i nie ma sytuacji, w której dostawca oprogramowania po trzech latach przychodzi z rachunkiem za przekroczony limit. Druga jest ta, o której się zwykle zapomina: otwarty kod źródłowy zdejmuje zależność od właściciela frameworka, ale nie zdejmuje zależności w ogóle. Zależność przechodzi w inne miejsca — na agencję, która jako jedyna wie, jak projekt jest złożony, na płatne produkty, które stoją obok kodu, na abandoned package, którego nikt już nie utrzymuje, i na wersję główną, której wsparcie się skończyło. Te cztery miejsca są tymi, które zamawiający musi sprawdzić, bo wiersz licencji nic o nich nie mówi.

Gdzie Laravel jednak zaczyna kosztować: produkty, które nie są frameworkiem

Ten sam zespół, który utrzymuje Laravel, sprzedaje też kilka produktów, i w ofercie bywają w jednym wierszu z frameworkiem, jakby były jego częścią. Laravel na swojej witrynie te dwie rzeczy rozdziela sam: pakiety — Laravel Horizon, Telescope, Pulse, Scout, Sanctum, Octane i inne — są na licencji MIT i bez opłat, natomiast produkty to Cloud, Forge, Nightwatch, Vapor i Nova, i kosztują pieniądze co miesiąc albo co rok. Envoyer nadal jest sprzedawany osobno. Żaden z tych produktów nie jest potrzebny, żeby system na Laravelu działał, i właśnie dlatego ich obecność w ofercie jest wyborem, a nie koniecznością.

Ceny w sierpniu tego roku wyglądały tak. Forge, którym zarządza się serwerami, kosztuje 12, 19 albo 39 dolarów amerykańskich miesięcznie w zależności od planu. Nova, która jest panelem administracyjnym, kosztuje 99 dolarów jednorazowo za jeden projekt razem z rocznymi aktualizacjami i 79 dolarów rocznie za kontynuację aktualizacji, a licencja nieograniczona kosztuje odpowiednio 299 i 249 dolarów, przy czym obejmuje Państwa własne projekty, nie projekty Państwa klientów. Nightwatch, który zbiera zdarzenia systemu, zaczyna się od planu bezpłatnego i dochodzi do 20, 60 i 300 dolarów miesięcznie, z dopłatą za zdarzenia powyżej wliczonego limitu. Laravel Cloud zaczyna się od 5 dolarów miesięcznie plus zużycie, a Envoyer kosztuje od 10 do 50 dolarów miesięcznie.

Pytanie do zamawiającego nie brzmi, czy te produkty są dobre, bo zwykle są dobre i oszczędzają deweloperowi kilka dni w miesiącu. Pytanie brzmi, które z nich są wliczone w podaną cenę, na którym koncie są zarejestrowane i co się z nimi dzieje, jeśli za dwa lata zmienią Państwo dostawcę. Abonament, który stoi na koncie agencji i w umowie nie jest wspomniany, jest właśnie tą zależnością, której licencja MIT nie zdejmuje, bo MIT mówi o kodzie, nie o koncie, na którym ten kod jest wdrażany i nadzorowany.

Co się dzieje, gdy programista znika

„Kod może przejąć dowolny programista Laravela” to zdanie, które jest prawnie prawdziwe i praktycznie niepełne, i my sami je też pisaliśmy. Licencja MIT naprawdę pozwala innej firmie pracować z tym kodem, nie prosząc o zgodę ani nas, ani zespołu Laravela. Czy nowy programista będzie użyteczny już w pierwszym tygodniu, rozstrzygają cztery zupełnie inne rzeczy, i wszystkie cztery da się sprawdzić, zanim umowa w ogóle zostanie podpisana.

Pierwsza jest wersja główna. Przekazanie z Laravela 11 nowemu zespołowi nie jest przekazaniem, tylko projektem zmiany wersji, bo wsparcie zabezpieczeń tam już się skończyło i pierwszą pracą nie będzie nowa funkcjonalność, tylko zaległe przejście do wspieranego wydania. Druga jest odległość od konwencji frameworka: dokumentacja Laravela zakłada określony układ katalogów i klas, i im dalej projekt od tego odszedł, tym droższe jest zapoznanie się. Liczby tutaj nie ma i w żadnym źródle jej nie ma, jest tylko kierunek; natomiast zamawiający może całkiem konkretnie zapytać, co w projekcie jest napisane wbrew domyślnemu układowi i jaka potrzeba tego wymagała.

Trzecia to zależności, to znaczy obce pakiety, na których system polega. Composer, który w świecie Laravela nimi zarządza, trzyma plik z dokładnymi wersjami, i jest cenny właśnie dlatego, że nowy programista może zainstalować dokładnie to samo, co widział poprzedni, a nie to, co dziś jest najnowsze. Ten plik nie gwarantuje dwóch rzeczy: że pakiet nadal będzie dostępny do pobrania, i że od tamtej pory nie znaleziono w nim podatności. Polecenie composer audit pokazuje obie w jednym wywołaniu, i to jest najkrótsza forma pytania, jaką w ogóle da się zadać o obcą bazę kodu.

Czwarta jest abandoned package — pakiet, którego opiekunowie przestali utrzymywać — i tu słowa mylą. Packagist, publiczny katalog Composera, oznacza, że opiekunowie stanęli, ale to nie znaczy, że pakiet znika albo przestaje działać: swiftmailer nadal jest dostępny do instalacji, ma 449 milionów zarejestrowanych instalacji, ostatnie wydanie pochodzi z 2021 roku, i jednocześnie ma trzy znane podatności. W naszej własnej bazie kodu tej witryny, która jest Laravel 13 razem z panelem administracyjnym Filament, jest 109 pakietów produkcyjnych i żadnego abandoned package — to jest nasza liczba o naszym projekcie, nie średnia branżowa, bo opublikowanej średniej branżowej nie ma nigdzie.

Jak duży jest rynek pracy i dlaczego dokładnej liczby nikt nie poda

Na pytanie, czy w Polsce łatwo znaleźć człowieka, który system przejmie, uczciwa odpowiedź brzmi, że publicznej statystyki o programistach PHP albo Laravela w Polsce nie ma. Są dane pośrednie, i są warte dokładnie tyle, jak precyzyjnie się je opisze. W zeszłorocznej ankiecie PHP JetBrains wśród 1720 osób, dla których PHP jest głównym językiem, 64% pracuje z Laravelem, 25% z WordPressem i 23% z Symfony; praca w terenie odbyła się wiosną, ankieta jest przesunięta na korzyść użytkowników narzędzi JetBrains, co firma sama przyznaje, a największe grupy respondentów pochodzą z Japonii, USA, Rosji, Chin i Francji, nie z krajów bałtyckich.

Na poziomie europejskim Eurostat w maju tego roku podaje, że w zeszłym roku w Unii Europejskiej pracowało 10,45 miliona specjalistów technologii informacyjnych i komunikacyjnych, co stanowi 5,0% wszystkich zatrudnionych i o 2,6% więcej niż rok wcześniej. We wcześniejszym zestawieniu tego samego źródła jest inna liczba dotycząca Polski, bardziej przydatna zamawiającemu niż ogólny wzrost: w 2023 roku 5,64% polskich firm szukało albo próbowało zatrudnić takich specjalistów, natomiast wśród tych polskich firm, które szukały, 32,25% nie zdołało zapełnić wakatu.

Te liczby dotyczą specjalistów branży ogółem, nie PHP, i nie wolno ich przepisać jako twierdzenia o rynku pracy Laravela w Polsce — ani nam, ani dostawcy, który je cytuje w Państwa ofercie. Sami na stronie usługi napisaliśmy, że programistów, którzy przejmą pracę, łatwo znaleźć; przygotowując ten artykuł, źródła dla tego twierdzenia nie znaleźliśmy, więc tutaj go nie powtarzamy. Dla zamawiającego praktyczna kolejność i tak jest inna: nie wierzyć w wielkość rynku, tylko doprowadzić do tego, żeby baza kodu była taka, w którą nowy człowiek wchodzi tanio niezależnie od tego, ilu takich ludzi jest.

Gdzie sami stawiamy granicę w ofercie

Laravela piszemy od 2013 roku, gdy ukazała się jego czwarta wersja, i to w praktyce znaczy, że kilka razy przeszliśmy dokładnie przez to, przed czym ten artykuł ostrzega — zmianę wersji głównej, która nie jest pracą jednego dnia i której nie da się zrobić między innymi zadaniami. Na naszej stronie tworzenia systemów w Laravelu jest cena i terminy, i to jest osobna rozmowa; w tym artykule jest tylko to, co w ofercie da się sprawdzić niezależnie od tego, kto ją napisał i jak dobrze jest napisana.

Nie twierdzimy, że dowolny programista przejmuje dowolną bazę kodu jednakowo łatwo, bo poprzednia część mówi przeciwnie. Twierdzimy coś konkretniejszego i sprawdzalnego: repozytorium jest klienta od pierwszego dnia, jest w nim i plik zależności, i dokumentacja, i konfiguracja wdrożenia, a w chwili przekazania wersja jest tą, która wówczas jeszcze dostaje poprawki zabezpieczeń. Jeśli wydaje się Państwu, że wybór naprawdę jest między gotowym produktem a systemem na zamówienie, to jest inna rozmowa, którą napisaliśmy osobno, a jeśli pytanie dotyczy właśnie sklepu internetowego, to porównanie WooCommerce’a i Laravela odpowiada precyzyjniej niż ten artykuł.

W praktyce w komplecie przekazania jest repozytorium z całą historią, plik zależności z dokładnymi wersjami, README z krokami uruchomienia, konfiguracja wdrożenia i dostępy do wszystkich kont, na których system działa. To jest to, co da się obiecać i sprawdzić. Rynku obiecać nie można: ilu ludzi w Polsce weźmie tę pracę i za jaką cenę, nie jest w naszych rękach i nie ma w żadnej publicznej statystyce, dlatego na to pytanie nie odpowiadamy przekonującą liczbą. Jedyną rzeczą, która tutaj naprawdę działa na korzyść zamawiającego, jest to, że baza kodu jest zwyczajna, wersja jest wspierana i dokumentacja jest napisana wówczas, a nie odłożona na tydzień przekazania.

Co zapytać, zanim podpiszą Państwo

Pierwsze pytanie dotyczy dat: która wersja główna Laravela i która gałąź PHP będą w systemie właśnie w dniu przekazania, i kiedy kończą się ich poprawki zabezpieczeń. Odpowiedzią są dwie daty, obie da się sprawdzić na dwóch publicznych stronach w pięć minut, i trzeba je zapisać albo w umowie, albo przynajmniej w korespondencji. Jeśli dostawca nazywa wersję, której wsparcie kończy się wcześniej niż okres gwarancji, to nie jest zabronione i czasem jest nawet uzasadnione, ale wtedy muszą o tym wiedzieć obie strony, i w cenie musi być zrozumiałe, kto zapłaci za przejście.

Drugie pytanie dotyczy abonamentów: które płatne produkty — Forge, Cloud, Nova, Nightwatch, Vapor albo Envoyer — są potrzebne do działania systemu, ile kosztują łącznie miesięcznie i na którym koncie stoją. Trzecie dotyczy repozytorium: od którego dnia jest Państwa, czy jest w nim plik zależności i czy w automatycznym sprawdzeniu jest polecenie composer audit. Czwarte jest pytaniem o pieniądze, które zwykle odkłada się na później, a potem ze zdziwieniem znajduje w budżecie: kto zapłaci za zmianę wersji głównej po półtora roku i czy mieści się to w umowie opieki, czy będzie nowym zamówieniem.

Żadne z tych czterech pytań nie wymaga, żeby Państwo rozumieli kod, i żadnego nie należy odbierać jako braku zaufania do dostawcy. Wszystkie dotyczą tego, co się stanie potem, gdy projekt będzie skończony i rachunek opłacony, a dobry dostawca odpowiada na nie od razu, bo sam te daty zna na pamięć. Jeśli odpowiedź na któreś z nich zajmuje tydzień albo zamienia się w wyjaśnienie, dlaczego pytanie nie jest ważne, to już jest odpowiedź.

Te cztery pytania nie zastępują oceny technicznej i nie odpowiadają na to, czy proponowana architektura jest dobra, ale likwidują większą część nieprzyjemnych niespodzianek, które zwykle przychodzą w drugim albo trzecim roku, gdy początkowy entuzjazm się skończył, a system po prostu działa. Jeśli mają Państwo ofertę w ręku i nie są Państwo pewni, co zapisane w niej wersje znaczą dla Państwa terminów i budżetu, proszę do nas napisać — odpowiedź na te cztery pytania da się przygotować, nie otwierając kodu.