PHP ja Laravel: mida see valik tähendab ettevõttele, kes süsteemi tellib

Pakkumises kirjas „PHP 8.4, Laravel 13“ ei ole tehniline detail: need kaks rida määravad, kui kaua süsteem saab turvapaiku, mis selles iga kuu juurde maksab ja kui kallis on üleandmine teisele arendajale.

Pakkumine jõuab reede pärastlõunal ja selle tehnilises osas on kaks rida, mida koosolekul keegi valjusti ette ei loe: „PHP 8.4“ ja „Laravel 13“. Hind on arusaadav, tähtaeg on arusaadav, ja need kaks rida paistavad tarnija sisemise köögina — umbes sama tähtsad kui see, millise puuriga seina auk tehakse. Seepärast jäetakse need tavaliselt vahele kui tehniline detail, mille eest vastutab keegi teine. Allkiri tuleb ometi kogu dokumendi alla, ja just need kaks rida määravad, kui kaua süsteem üldse turvapaiku saab, mis toob sinna igakuise arve arendushinna kõrvale ja kui kallis on kolme aasta pärast selle üleandmine kellelegi teisele.

See artikkel ei räägi sellest, kas PHP on hea keel ja kas Laravel on hea raamistik, sest sellele küsimusele vastavad arendajad omavahel ja ostjal ei ole sellest vestlusest mingit praktilist kasu. Jutt on neljast asjast, mida ostja saab ise ja ilma tehniliste teadmisteta kontrollida: tugikalendrist, litsentsist, tööjõuturust ja üleandmise tingimustest. Kõik neli on avalikud, kolm neist on kas kuupäevad või rahasummad, neljas on see, mida turu kohta saab ja ei saa teada, ja ükski neist ei sõltu sellest, kui veenvalt pakkumine on kirjutatud — seepärast tasub need kontrollida just sel nädalal, mil hinna üle veel rääkida saab.

Mis on keel, mis on raamistik, ja miks see ei ole üks valik

PHP on programmeerimiskeel, milles on kirjutatud süsteemi serveripool — see osa, mis töötab tarnija või teie majutaja juures ja mida kasutaja kunagi ei näe. Laravel on omakorda raamistik, see tähendab PHP keeles juba kirjutatud koodibaas, mis lahendab selle, mis kordub peaaegu igas projektis: kasutajate sisselogimise, andmebaasipäringud, järjekorrad, failide hoidmise, e-kirjade saatmise. Pakkumises seisavad nad kõrvuti nagu üks valik, tegelikult on need kaks eraldi toodet, mida hoiavad kaks erinevat meeskonda kahe erineva tugikalendriga, ja just seepärast tasub need eraldi läbi lugeda.

Kui levinud keel on, on oodatust raskem öelda. W3Techs, mis skaneerib regulaarselt enam kui kakskümmend miljonit veebisaiti, kirjutab tänavuse aasta augustis, et PHP-d kasutab 70,2 % kõigist saitidest, mille serveripoolset programmeerimiskeelt see tööriist teab. Viimane tingimus on see, mis tavaliselt kaob, kui arvu esitlusele ümber kirjutatakse: jutt ei ole 70 % kõigist maailma saitidest, vaid 70 % neist, mida see konkreetne tööriist üldse ära tunneb, ja osa äratundmisest kirjeldab ta ise kui kaudselt järeldatut — kui leht on WordPress, siis on see PHP.

Ostjale on kasulikum teine arv samalt lehelt. Saitide seas, millel W3Techs määrab ka PHP versiooni, töötab 63,3 % kaheksandal, 28,7 % seitsmendal ja 7,9 % endiselt viiendal, kuigi seitsmes versioon kaotas isegi turvapaigad juba neli aastat tagasi. See tähendab, et umbes kolmandik mõõdetavast PHP internetist töötab täna koodil, millele keegi enam paiku ei tee, ja see ei ole juhtunud sellepärast, et keel oleks halb või et keegi oleks arenduses vea teinud. See on juhtunud sellepärast, et keegi ei ole versioonivahetust tellinud ega kinni maksnud, ja just see on riski osa, mida ostja saab nii näha kui ka juhtida.

PHP tugikalender on esimene dokument, mis tasub avada

PHP arendajate rühma reegel on lühike ja avalik: iga versiooniharu saab täielikku tuge kaks aastat esimesest stabiilsest väljalaskest, seejärel veel kaks aastat ainult kriitilisi turvapaiku (security-only support), ja nelja aasta pärast ei hoita seda enam üldse. Selles reeglis on üks detail, mille ümberjutustused peaaegu alati maha lõikavad: tegelikud lõpukuupäevad tabelis on joondatud aasta viimasele päevale, mitte väljalaske aastapäevale novembris, seega „kaks aastat ilmumisest“ ja see, mis seisab php.neti tabelis, erinevad kuu või kahe võrra.

Praktikas tähendab see järgmist. Versioon 8.2 on praegu ainult security-only support staadiumis ja tema tugi lõpeb juba tänavuse aasta lõpus, seega umbes nelja kuu pärast. Versioon 8.3 kaotas täieliku toe möödunud aasta lõpus ja saab turvapaiku kuni 2027. aasta lõpuni, seega veel umbes kuusteist kuud. Versioon 8.4 töötab täieliku toega selle aasta lõpuni ja jääb seejärel veel kaheks aastaks security-only support staadiumisse, uusim 8.5, mis ilmus möödunud aasta novembris, saab täielikku tuge kogu järgmise aasta ja turvapaiku kuni 2029. aasta lõpuni.

Versiooni 8.1 tugi lõppes möödunud aasta viimasel päeval (end of life), ja just see juhtum väärib tähelepanu, kui teie süsteem on juba olemas, mitte pakkumine. Kui tarnija kirjutas selle kolm aastat tagasi 8.1 peale ja keegi pole sellest ajast midagi muutnud, töötab see täna harul, kuhu turvapaigad enam ei tule, ja sellest ei hoiata ei server, ei brauser ega süsteem ise. Leht avaneb täpselt nagu eile, kliendid ei märka midagi, ja ainus koht, kus seda näha saab, on seesama avalik tabel, mille avamine võtab vähem aega kui pakkumise tiitellehe lugemine.

Laraveli kalender on lühem kui PHP kalender

Laravel sõnastab oma poliitika veel lühemalt: veaparandused kaheksateist kuud, turvapaigad kaks aastat, ja uus põhiversioon igal aastal umbes esimeses kvartalis. Pikaajalise toe väljalaset, mida valdkonnas nimetatakse LTS-iks, täna enam ei ole — vanades versioonides see tõesti oli, tänavuse aasta tabelis seda veergu aga üldse ei ole, seega pakkumine, milles seisab „LTS Laravel“, kirjeldab midagi, mida praegu keegi ei müü. See on lühem lubadus, kui paljud ostjad ootavad raamistikult, mille peale ehitatakse süsteem järgmiseks viieks aastaks.

Arvudes, Laraveli enda dokumentatsiooni järgi, on järjekord selline. Laravel 13 ilmus tänavuse aasta märtsis, veaparandusi saab ta kuni järgmise aasta kolmanda kvartalini, turvapaiku kuni 2028. aasta 17. märtsini. Laravel 12 veaparanduste aken sulgus tänavuse aasta augusti keskel, see tähendab seitseteist päeva enne nende ridade kirjutamist, ja tema turvapaigad lõpevad järgmise aasta veebruaris. Laravel 11 turvapaigad lõppesid tänavuse aasta kevadel, seega süsteem, mis täna töötab üheteistkümnendal versioonil, töötab juba ilma paikadeta, ükskõik kui hästi ta väljast paistab.

Pange tähele, et Laravel 13 veaparanduste lõpp on märgitud kvartalina, mitte konkreetse kuupäevana. See on Laraveli enda sõnastuse ebatäpsus, ja see ei ole probleem, kuni see kirjutatakse ümber täpselt nii, nagu seal seisab; probleem algab hetkel, kui tarnija või ostja ümardab selle konkreetsele päevale ja planeerib seejärel eelarvet arvu järgi, mida allikas ei sisalda. Veel üks piir, mida tasub teada enne versiooni valimist: Laravel 13 nõuab vähemalt PHP 8.3, seega süsteemi kolmeteistkümnendal versioonil ei saa jätta 8.2 peale isegi siis, kui 8.2 ise saaks veel mõnda aega turvapaiku.

Mida tähendavad mõlemad kalendrid koos süsteemile, mille te täna tellite

Kui süsteem antakse üle Laravel 13 peal koos PHP 8.4 või 8.5-ga, on esimene kuupäev, mil miski kohustuslikult liikuma peab, 2028. aasta märts, mil lõpevad Laraveli turvapaigad, ja see on tänasest umbes kaheksateist ja pool kuud. PHP ei ole selles kombinatsioonis piirang, sest mõlemad harud saavad turvapaiku kauem kui raamistik, seega vananeb esimesena Laravel, mitte keel. See on ka ainus aus viis vastata küsimusele „kui kaua see süsteem ilma lisainvesteeringuta vastu peab“ — mitte tundega, vaid kahest avalikust kuupäevast varasemaga.

Kui sama süsteem antakse üle Laravel 13 peal, aga PHP 8.3-ga, pöördub järjekord ümber ja esimene tähtaeg saabub umbes kuueteistkümne kuuga, mil lõpevad selle PHP-haru turvapaigad. Kui tarnija kirjutab Laravel 12 peale, mis olemasoleva projekti jaoks on endiselt täiesti tavaline valik, lõpevad turvapaigad järgmise aasta veebruaris ja uue süsteemi elu algab kuue kuuga esimese kohustusliku versioonivahetuseni. Vahe esimese ja kolmanda variandi vahel on aasta, mille saab teenida ühes vestluses enne lepingut ja mida pärast allkirja enam osta ei saa.

Kaks viga selles arvestuses on nii levinud, et need tasub eraldi nimetada. Esimene on segi ajada täielikku tuge security-only support aknaga, seega kuuldes, et „PHP 8.4 tugi lõpeb aasta lõpus“, tasub küsida, kumb kahest aknast on mõeldud: tavaliste vigade parandamine lõpeb, turvapaigad tulevad veel kaks aastat. Teine on uskuda Laraveli enda lauset, et üleminek uuele põhiversioonile võtvat tavaliselt päeva või vähem; see on arendajate sõnastatud eesmärk, mitte mõõdetud keskmine, ja lepingusse seda tähtajana kirjutada ei saa.

Litsents maksab nulli, ja see on tõsi ainult keele ja raamistiku kohta

Laraveli raamistikku levitatakse MIT-litsentsiga, mis on üks lihtsamaid avatud lähtekoodi litsentse ja lubab koodi kasutada, muuta ja edasi müüa, nõudes vaid autoriõiguse teate säilitamist. PHP-ga on natuke keerulisem, ja see keerukus on just praegu aktuaalne, sest litsents muutub: versioonid kuni 8.5 kaasa arvatud ilmuvad PHP-litsentsi redaktsiooniga 3.01, alates 8.6 minnakse üle neljandale redaktsioonile, mida php.net ise kirjeldab kui „Modified BSD“ litsentsi ja mis praktikas ühtib BSD-3-Clause'iga. Kummaski variandis ei ole tasu ette nähtud.

See tähendab, et keele enda ja raamistiku enda eest ei maksa ettevõte ei kasutaja, ei protsessorituuma ega aasta eest, ja see null ei ole kampaania, mis kunagi lõpeb. Võrdluseks sobib mudel, mida kasutab Microsoft SQL Server: seal litsentsitakse kas tuumade järgi või serveri järgi koos kliendipääsulitsentsidega, Standard-väljaanne on piiratud väiksemaga neljast protsessoripesast või kahekümne neljast tuumast, tasuta Express-väljaanne ühe pesa või nelja tuumaga. Täpseid summasid me siia ei kirjuta, sest hinnakiri muutub ja seda tuleb lugeda Microsofti juures; ostjale on võrreldav mudel, mitte arv — üks toode arvestab raua mahu järgi, teine ei arvesta üldse.

Tellimisel on sellel kaks tagajärge, mis tasub kohe kirja panna. Esimene on meeldiv: ei ole litsentsiauditit, ei ole aastast ümberarvestust kasutajate eest, keda aasta jooksul juurde on tulnud, ega olukorda, milles tarkvara tarnija tuleb kolme aasta pärast arvega ületatud limiidi eest. Teine on see, mis kipub ununema: avatud lähtekood võtab ära sõltuvuse raamistiku omanikust, aga ei võta ära sõltuvust üldse. Sõltuvus liigub mujale — agentuuri, kes ainsana teab, kuidas projekt on kokku pandud, tasulistele toodetele, mis seisavad koodi kõrval, abandoned package'ile, mida keegi enam ei hoia, ja põhiversioonile, mille tugi on lõppenud. Need neli kohta on need, mida ostja peab kontrollima, sest litsentsirida nende kohta midagi ei ütle.

Kus Laravel siiski maksma hakkab: tooted, mis ei ole raamistik

Sama meeskond, kes Laraveli üleval hoiab, müüb ka mitut toodet, ja pakkumises kipuvad need seisma ühel real raamistikuga, otsekui oleksid selle osa. Laravel eraldab need kaks asja oma veebilehel ise: paketid — Horizon, Telescope, Pulse, Scout, Sanctum, Octane ja teised — on MIT-litsentsiga ja tasuta, tooted on Cloud, Forge, Nightwatch, Vapor ja Nova, ja need maksavad raha iga kuu või iga aasta. Envoyer müüakse endiselt eraldi. Ükski neist toodetest ei ole vajalik, et Laraveli süsteem töötaks, ja just seepärast on nende olemasolu pakkumises valik, mitte paratamatus.

Hinnad tänavuse aasta augustis nägid välja nii. Forge, millega hallatakse servereid, maksab plaani järgi 12, 19 või 39 USA dollarit kuus. Nova, mis on halduspaneel, maksab 99 dollarit ühekordselt ühe projekti eest koos aasta uuendustega ja 79 dollarit aastas uuenduste jätkamise eest, piiramatu litsents maksab vastavalt 299 ja 249 dollarit, ja see katab teie enda projektid, mitte teie klientide omad. Nightwatch, mis kogub süsteemi sündmusi, algab tasuta plaanist ja tõuseb 20, 60 ja 300 dollarini kuus, pluss lisatasu sündmuste eest üle sisalduva limiidi. Laravel Cloud algab 5 dollarist kuus pluss tarbimine, ja Envoyer maksab 10 kuni 50 dollarit kuus.

Küsimus ostjale ei ole, kas need tooted on head, sest tavaliselt on nad head ja säästavad arendajale mitu päeva kuus. Küsimus on, millised neist on nimetatud hinna sees, millise konto peal nad on registreeritud ja mis nendega juhtub, kui te kahe aasta pärast tarnijat vahetate. Tellimus, mis seisab agentuuri kontol ja lepingus mainimata, on täpselt see sõltuvus, mida MIT-litsents ära ei võta, sest MIT räägib koodist, mitte kontost, milles seda majutatakse ja jälgitakse.

Mis juhtub, kui arendaja kaob

„Koodi saab üle võtta ükskõik milline Laraveli arendaja“ on lause, mis on juriidiliselt tõene ja praktiliselt puudulik, ja me oleme seda ka ise kirjutanud. MIT-litsents tõesti lubab teisel ettevõttel selle koodiga töötada, küsimata luba ei meilt ega Laraveli meeskonnalt. Kas uus arendaja on kasulik juba esimesel nädalal, otsustavad neli hoopis teist asja, ja kõiki nelja saab kontrollida enne, kui leping üldse allkirjastatud on.

Esimene on põhiversioon. Üleandmine Laravel 11 pealt uuele meeskonnale ei ole üleandmine, vaid versioonivahetuse projekt, sest turvapaiku seal enam ei tule ja esimene töö ei ole uus funktsionaalsus, vaid mahajäänud üleminek toetatud väljalaskele. Teine on kaugus raamistiku tavast: Laraveli dokumentatsioon eeldab kindlat kaustade ja klasside paigutust, ja mida kaugemale projekt sellest on läinud, seda kallim on sisseelamine. Arvu siin ei ole ja üheski allikas seda ei ole, on ainult suund; ostja saab aga päris konkreetselt küsida, mida on projektis tehtud teisiti kui vaikimisi ette nähtud ja milline vajadus seda nõudis.

Kolmas on sõltuvused, see tähendab võõrad paketid, millele süsteem toetub. Composer, mis neid Laraveli maailmas haldab, hoiab faili täpsete versioonidega, ja see on väärtuslik just sellepärast, et uus arendaja saab paigaldada täpselt sama, mida nägi eelmine, mitte seda, mis täna on uusim. Mida see fail ei garanteeri, on kaks asja: et pakett on endiselt allalaadimiseks saadaval, ja et selles ei ole sellest ajast leitud turvanõrkust. Käsk composer audit näitab mõlemat ühe käivitamisega, ja see on lühim küsimuse vorm, mida võõra koodibaasi kohta üldse esitada saab.

Neljas on abandoned package, ja siin sõnad eksitavad. Packagist, Composeri avalik kataloog, märgib, et hooldajad on peatunud, see ei tähenda aga, et pakett kaob või lakkab töötamast: swiftmailer väljastatakse endiselt, tal on 449 miljonit registreeritud paigaldust, viimane väljalase on 2021. aastast, ja samal ajal on tal kolm teadaolevat turvanõrkust. Meie enda selle saidi koodibaasis, mis on Laravel 13 koos Filamenti halduspaneeliga, on 109 toodangupaketti ja ühtegi abandoned package'it — see on meie arv meie projekti kohta, mitte valdkonna keskmine, sest avaldatud valdkonna keskmist ei ole kuskil.

Kui suur on tööjõuturg ja miks täpset arvu keegi ei ütle

Küsimusele, kas Eestis on kerge leida inimest, kes süsteemi üle võtab, on aus vastus, et avalikku statistikat PHP või Laraveli arendajate kohta Eestis ei ole. On kaudseid andmeid, ja need on väärt täpselt nii palju, kui täpselt neid kirjeldatakse. JetBrainsi möödunud aasta PHP küsitluses töötab 1720 inimese seas, kellele PHP on peamine keel, 64 % Laraveliga, 25 % WordPressiga ja 23 % Symfonyga; välitöö toimus kevadel, küsitlus on kallutatud JetBrainsi tööriistade kasutajate kasuks, mida ettevõte ise tunnistab, ja suurimad vastajate rühmad tulevad Jaapanist, USAst, Venemaalt, Hiinast ja Prantsusmaalt, mitte Baltikumist.

Euroopa tasandil teatab Eurostat tänavuse aasta mais, et möödunud aastal töötas Euroopa Liidus 10,45 miljonit info- ja kommunikatsioonitehnoloogia spetsialisti, mis on 5,0 % kõigist hõivatutest ja 2,6 % rohkem kui aasta varem. Eesti kohta on sama allika varasemas koondis teine arv, mis on ostjale kasulikum kui üldine kasv: 2023. aastal otsis või üritas palgata selliseid spetsialiste 7,71 % Eesti ettevõtetest, ja nende Eesti ettevõtete seas, kes otsisid, ei suutnud 54,02 % vaba kohta täita.

Need arvud on valdkonna spetsialistide kohta tervikuna, mitte PHP kohta, ja neid ei tohi ümber kirjutada väiteks Laraveli tööjõuturu kohta Eestis — ei meil ega tarnijal, kes neid teie pakkumises tsiteerib. Me ise oleme oma teenuselehel kirjutanud, et arendajaid, kes töö üle võtavad, on kerge leida; seda artiklit valmistades me sellele väitele allikat ei leidnud, seega siin me seda ei korda. Ostja praktiline järjekord on niikuinii teine: mitte uskuda turu suurust, vaid saavutada, et koodibaas oleks selline, millesse uus inimene tuleb odavalt, sõltumata sellest, kui palju selliseid inimesi on.

Kus me ise pakkumises piiri tõmbame

Me kirjutame Laraveli peale alates 2013. aastast, mil ilmus selle neljas versioon, ja see tähendab praktikas, et oleme mitu korda läbi käinud just selle, mille eest see artikkel hoiatab — põhiversiooni vahetuse, mis ei ole ühe päeva töö ja mida ei saa teha muude ülesannete vahel. Meie Laraveli süsteemide arenduse lehel on hind ja tähtajad, ja see on eraldi jutt; selles artiklis on ainult see, mida pakkumises saab kontrollida sõltumata sellest, kes selle on kirjutanud ja kui hästi see on kirjutatud.

Mida me ei väida, on see, et ükskõik milline arendaja võtab ükskõik millise koodibaasi üle üheviisi kergelt, sest eelmine jaotis ütleb vastupidist. Mida me väidame, on konkreetsem ja kontrollitavam: repositoorium on kliendi oma esimesest päevast, selles on nii sõltuvuste fail, dokumentatsioon kui ka paigalduse konfiguratsioon, ja üleandmise hetkel on versioon see, mis sel hetkel veel turvapaiku saab. Kui teile tundub, et valik on tegelikult valmistoodangu ja eritellimussüsteemi vahel, siis on see teine jutt, mille oleme kirjutanud eraldi, ja kui küsimus on just e-poe kohta, vastab WooCommerce'i ja Laraveli võrdlus täpsemalt kui see artikkel.

Praktilisse üleandmiskomplekti kuulub repositoorium kogu ajalooga, sõltuvuste fail täpsete versioonidega, README käivitussammudega, paigalduse konfiguratsioon ja ligipääsud kõigile kontodele, milles süsteem töötab. See on see, mida saab lubada ja kontrollida. Mida lubada ei saa, on turg: kui palju inimesi Eestis selle töö ette võtab ja mis hinnaga, ei ole meie kätes ega üheski avalikus statistikas, seega me seda küsimust veenva arvuga ei vasta. Ainus, mis siin ostja kasuks päriselt töötab, on see, et koodibaas on tavaline, versioon on toetatud ja dokumentatsioon on kirjutatud sel hetkel, mitte lükatud üleandmise nädalasse.

Mida küsida enne, kui allkirjastate

Esimene küsimus on kuupäevade kohta: milline Laraveli põhiversioon ja milline PHP-haru on süsteemis just üleandmise päeval, ja millal lõpevad nende turvapaigad. Vastus on kaks kuupäeva, mõlemat saab kontrollida kahel avalikul lehel viie minutiga, ja need tuleb kirjutada kas lepingusse või vähemalt kirjavahetusse. Kui tarnija nimetab versiooni, mille tugi lõpeb varem kui garantii tähtaeg, ei ole see keelatud ja mõnikord on see isegi põhjendatud, aga siis peavad seda teadma mõlemad pooled, ja hinnas peab olema selge, kes ülemineku eest maksab.

Teine küsimus on tellimuste kohta: milliseid tasulisi tooteid — Forge, Cloud, Nova, Nightwatch, Vapor või Envoyer — on süsteemi tööks vaja, kui palju need kokku kuus maksavad ja millise konto peal nad seisavad. Kolmas on repositooriumi kohta: millisest päevast see on teie oma, kas selles on sõltuvuste fail ja kas automaatsesse kontrolli on lisatud käsk composer audit. Neljas on raha küsimus, mida tavaliselt lükatakse hilisemaks ja leitakse siis eelarvest üllatusena: kes maksab põhiversiooni vahetuse eest pooleteise aasta pärast ja kas see mahub hoolduslepingusse või on uus tellimus.

Ükski neist neljast küsimusest ei nõua, et te koodist aru saaksite, ja ühtegi neist ei ole tarvis võtta usaldamatusena tarnija vastu. Kõik neli on sellest, mis juhtub pärast seda, kui projekt on valmis ja arve makstud, ja hea tarnija vastab neile kohe, sest ta teab neid kuupäevi peast. Kui vastus mõnele neist võtab nädala või muutub seletuseks, miks küsimus ei ole tähtis, on see juba vastus.

Need neli küsimust ei asenda tehnilist hindamist ega vasta sellele, kas pakutud arhitektuur on hea, aga need võtavad ära suurema osa ebameeldivatest üllatustest, mis tavaliselt saabuvad teisel või kolmandal aastal, kui algne entusiasm on otsas ja süsteem lihtsalt töötab. Kui teil on pakkumine käes ja te ei ole kindel, mida selles kirjas versioonid teie tähtaegadele ja eelarvele tähendavad, kirjutage meile — vastuse neile neljale küsimusele saab ette valmistada, koodi avamata.