Hva er Laravel for bedriften som bestiller et system

«PHP 8.4, Laravel 13» i tilbudet er ikke en teknisk detalj: de to linjene avgjør hvor lenge sikkerhetsoppdateringer kommer, hva som koster ekstra, og hvor dyr overleveringen blir.

Tilbudet kommer fredag ettermiddag, og i den tekniske delen står det to linjer ingen leser høyt i møtet: «PHP 8.4» og «Laravel 13». Prisen er forståelig, fristen er forståelig, og de to linjene ser ut som leverandørens interne kjøkken — omtrent like viktig som hvilken bor som lager hullet i veggen, og derfor blir de vanligvis hoppet over som en teknisk detalj noen andre har ansvaret for. Underskriften står likevel under hele dokumentet, og det er nettopp disse to linjene som avgjør hvor lenge systemet i det hele tatt får sikkerhetsoppdateringer, hva som vil sende en månedlig faktura oppå utviklingsprisen, og hvor dyr overleveringen til noen andre blir etter tre år.

Denne artikkelen handler ikke om hvorvidt PHP er et godt språk og om Laravel er et godt rammeverk, for det spørsmålet svarer utviklerne på seg imellom, og kjøperen har ingen praktisk nytte av den samtalen. Den handler om fire ting kjøperen kan sjekke selv og uten teknisk kunnskap: støttekalenderen, lisensen, arbeidsmarkedet og vilkårene for overlevering. Alle fire er offentlige, tre av dem er enten datoer eller pengebeløp, den fjerde er det man kan og ikke kan vite om markedet, og ingen av dem avhenger av hvor overbevisende tilbudet er skrevet — derfor er de verdt å sjekke akkurat den uken det fortsatt går an å snakke om prisen.

Hva er Laravel, hva er språket, og hvorfor det ikke er ett valg

PHP er programmeringsspråket som systemets serverside er skrevet i — den delen som kjører hos leverandøren eller på webhotellet ditt, og som brukeren aldri ser. Laravel er et PHP-rammeverk, det vil si en kodebase som allerede er skrevet i PHP og som løser det som går igjen i nesten hvert prosjekt: innlogging, databasespørringer, køer, fillagring, utsending av e-post. I tilbudet står de ved siden av hverandre som ett valg, men de er to separate produkter, vedlikeholdt av to ulike team med to ulike støttekalendere, og nettopp derfor er de verdt å lese hver for seg.

Hvor utbredt språket er, viser seg å være vanskeligere å si enn man venter. W3Techs, som jevnlig skanner mer enn tjue millioner nettsteder, skriver i august i år at PHP brukes av 70,2 % av alle nettsteder der dette verktøyet kjenner serverside-språket. Det siste vilkåret er det som vanligvis forsvinner når tallet skrives om i en presentasjon: det er ikke snakk om 70 % av alle nettsteder i verden, men om 70 % av dem dette konkrete verktøyet i det hele tatt klarer å kjenne igjen, og en del av gjenkjenningen beskriver det selv som utledet indirekte — hvis siden er WordPress, er den PHP.

For kjøperen er et annet tall fra den samme siden mer nyttig. Blant nettstedene der W3Techs også fastslår PHP-versjonen, kjører 63,3 % på den åttende, 28,7 % på den sjuende og 7,9 % fortsatt på den femte, selv om den sjuende versjonen mistet til og med sikkerhetsoppdateringene for fire år siden. Det betyr at omtrent en tredel av det målbare PHP-internettet i dag kjører på kode ingen lenger lager fikser til, og det har ikke skjedd fordi språket er dårlig, eller fordi noen gjorde en feil i utviklingen. Det har skjedd fordi ingen har bestilt og betalt et versjonsbytte, og dette er nettopp den delen av risikoen kjøperen både kan se og styre.

PHP-støttekalenderen er det første dokumentet som er verdt å åpne

Regelen til PHP-utviklergruppen er kort og offentlig: hver versjonsgren får full støtte i to år fra den første stabile utgivelsen, deretter ytterligere to år med kun sikkerhetsfikser, og etter fire år er den end of life og vedlikeholdes ikke lenger i det hele tatt. I den regelen ligger én detalj som gjenfortellingene nesten alltid kutter: de faktiske sluttdatoene i tabellen er lagt til årets siste dag, ikke til årsdagen for utgivelsen i november, derfor skiller «to år fra lansering» og det som står i tabellen på php.net seg med en måned eller to.

I praksis betyr det dette. Versjon 8.2 er nå inne i fasen med kun sikkerhetsfikser, og støtten tar slutt allerede ved utgangen av dette året, altså om omtrent fire måneder. Versjon 8.3 mistet den fulle støtten ved utgangen av fjoråret og får sikkerhetsoppdateringer til utgangen av 2027, altså omtrent seksten måneder til. Versjon 8.4 blir værende i full støtte ut dette året og går deretter over i to år med kun sikkerhetsfikser, mens den nyeste 8.5, som kom i november i fjor, får full støtte gjennom hele neste år og sikkerhetsoppdateringer til utgangen av 2029.

Støtten til versjon 8.1 tok slutt (end of life) siste dag i fjor, og akkurat dette tilfellet er verdt oppmerksomhet hvis du allerede har et system, og ikke et tilbud. Hvis leverandøren skrev det på 8.1 for tre år siden og ingen har rørt noe siden, kjører det i dag på en gren der sikkerhetsoppdateringene ikke lenger kommer, og verken serveren, nettleseren eller selve systemet varsler om det. Siden åpner seg akkurat som i går, kundene merker ingenting, og det eneste stedet du kan se det, er den samme offentlige tabellen, som tar kortere tid å åpne enn å lese forsiden av tilbudet.

Laravel-kalenderen er kortere enn PHP-kalenderen

Laravel formulerer politikken sin enda kortere: feilrettinger i atten måneder, sikkerhetsoppdateringer i to år, og en ny hovedversjon hvert år omtrent i første kvartal. Et utgivelsesløp med langtidsstøtte, som bransjen kaller LTS, finnes ikke lenger i dag — i de gamle versjonene fantes det virkelig, men i årets tabell er det ingen slik kolonne i det hele tatt, derfor beskriver et tilbud der det står «LTS Laravel», noe ingen selger akkurat nå. Det er et kortere løfte enn mange kjøpere venter seg av rammeverket et system skal bygges på i de neste fem årene.

I tall, etter Laravel-dokumentasjonen selv, er rekkefølgen slik. Laravel 13 kom i mars i år, får feilrettinger til tredje kvartal neste år, og sikkerhetsoppdateringer til 17. mars 2028. Vinduet for feilrettinger i Laravel 12 stengte midt i august i år, det vil si sytten dager før disse linjene ble skrevet, og sikkerhetsoppdateringene der tar slutt i februar neste år. Sikkerhetsstøtten til Laravel 11 tok slutt i vår, så et system som i dag kjører på den ellevte versjonen, kjører allerede uten fikser, uansett hvor pent det ser ut utenfra.

Legg merke til at slutten på feilrettingene for Laravel 13 er oppgitt som et kvartal, ikke som en konkret dato. Det er en unøyaktighet i Laravels egen formulering, og det er ikke et problem så lenge den gjengis nøyaktig slik den står; problemet begynner i det øyeblikket leverandøren eller kjøperen runder den av til en bestemt dag og deretter planlegger budsjettet etter et tall kilden ikke har. Enda en grense som må være kjent før versjonen velges: Laravel 13 krever minst PHP 8.3, så et system på den trettende versjonen kan ikke bli stående på 8.2, selv om 8.2 i en periode fortsatt ville fått sikkerhetsoppdateringer.

Hva de to kalenderene sammen betyr for systemet du bestiller i dag

Hvis systemet leveres på Laravel 13 sammen med PHP 8.4 eller 8.5, er mars 2028 den første datoen da noe nødvendigvis må flyttes, når Laravel-sikkerhetsoppdateringene tar slutt, og det er omtrent atten og en halv måned fra i dag. PHP er ikke begrensningen i denne kombinasjonen, fordi begge disse grenene får sikkerhetsoppdateringer lenger enn rammeverket, så det som eldes først, er Laravel, ikke språket. Det er også den eneste ærlige måten å svare på spørsmålet «hvor lenge står dette systemet uten ytterligere investering» — ikke med en følelse, men med den tidligste av to offentlige datoer.

Hvis det samme systemet leveres på Laravel 13, men PHP 8.3, snur rekkefølgen, og den første fristen kommer om omtrent seksten måneder, når sikkerhetsoppdateringene til denne PHP-grenen tar slutt. Hvis leverandøren leverer på Laravel 12, som for et eksisterende prosjekt fortsatt er et helt normalt valg, tar sikkerhetsoppdateringene slutt i februar neste år, og det nye systemets liv begynner med seks måneder til det første obligatoriske versjonsbyttet. Forskjellen mellom det første og det tredje alternativet er et år du kan tjene i én samtale før avtalen, og som du ikke lenger kan kjøpe etter signaturen.

To feil i dette regnestykket er så vanlige at de er verdt å navngi for seg. Den første er å blande full støtte med sikkerhetsstøtte, så når du hører at «støtten til PHP 8.4 tar slutt ved årets slutt», er det verdt å spørre hvilket av de to vinduene som er ment: den vanlige feilrettingen tar slutt, men sikkerhetsoppdateringene kommer i ytterligere to år. Den andre er å tro på Laravels egen setning om at overgangen til en ny hovedversjon vanligvis tar en dag eller mindre; det er et mål utviklerne selv har formulert, ikke et målt gjennomsnitt, og det kan ikke skrives inn i avtalen som en frist.

Lisensen koster null, og det er bare sant for språket og rammeverket

Laravel-rammeverket distribueres under MIT-lisens, som er en av de enkleste lisensene for åpen kildekode og lar koden brukes, endres og selges videre, mot at opphavsrettserklæringen blir stående. Med PHP er det litt mer innviklet, og innviklingen er aktuell akkurat nå, fordi lisensen skifter: versjoner til og med 8.5 kommer med versjon 3.01 av PHP-lisensen, mens den fra 8.6 går over til den fjerde versjonen, som php.net selv beskriver som en «Modified BSD»-lisens og som i praksis faller sammen med BSD-3-Clause. I ingen av disse variantene er det lagt opp til betaling.

Det betyr at bedriften for selve språket og selve rammeverket ikke betaler verken per bruker, per prosessorkjerne eller per år, og denne nullen er ingen kampanje som en gang tar slutt. Til sammenligning duger modellen Microsoft SQL Server bruker: der lisensieres det enten etter kjerner, eller etter server sammen med klienttilgangslisenser, Standard-utgaven er begrenset til det minste av fire prosessorsokler eller tjuefire kjerner, mens den gratis Express-utgaven er begrenset til én sokkel eller fire kjerner. Nøyaktige beløp skriver vi ikke her, fordi prislisten endrer seg og må leses hos Microsoft; for kjøperen er det modellen som er sammenlignbar, ikke tallet — det ene produktet regner etter mengden maskinvare, det andre regner ikke i det hele tatt.

Når du kjøper, har dette to følger som er verdt å skrive ned med en gang. Den første er behagelig: ingen lisensrevisjon, ingen årlig etterberegning for brukere som har kommet til i løpet av året, og ingen situasjon der programvareleverandøren etter tre år kommer med en faktura for en overskredet grense. Den andre er den som pleier å glemmes: åpen kildekode tar bort avhengigheten av eieren av rammeverket, men tar ikke bort avhengighet i det hele tatt. Avhengigheten flytter seg til andre steder — til byrået som alene vet hvordan prosjektet er satt sammen, til betalte produkter som står ved siden av koden, til en abandoned package som ingen lenger vedlikeholder, og til en hovedversjon der støtten har tatt slutt. Det er disse fire stedene kjøperen må sjekke, fordi lisenslinjen ikke sier noe om dem.

Der Laravel likevel begynner å koste: produkter som ikke er rammeverket

Det samme teamet som vedlikeholder Laravel, selger også flere produkter, og i tilbudet pleier de å stå på én linje med rammeverket, som om de var en del av det. Laravel skiller selv disse to tingene på nettstedet sitt: pakkene — Horizon, Telescope, Pulse, Scout, Sanctum, Octane og andre — er MIT-lisensierte og gratis, mens produktene er Cloud, Forge, Nightwatch, Vapor og Nova, og de koster penger hver måned eller hvert år. Envoyer selges fortsatt separat. Ingen av disse produktene trengs for at et Laravel-system skal virke, og nettopp derfor er tilstedeværelsen deres i tilbudet et valg, ikke en nødvendighet.

Prisene i august i år så slik ut. Forge, som brukes til å styre servere, koster 12, 19 eller 39 amerikanske dollar i måneden avhengig av planen. Nova, som er et administrasjonspanel, koster 99 dollar én gang for ett prosjekt sammen med oppdateringer i et år og 79 dollar i året for å fortsette å få oppdateringer, mens den ubegrensede lisensen koster henholdsvis 299 og 249 dollar, og den dekker dine egne prosjekter, ikke prosjektene til kundene dine. Nightwatch, som samler inn systemhendelser, starter med en gratisplan og stiger til 20, 60 og 300 dollar i måneden, pluss et tillegg for hendelser over den inkluderte grensen. Laravel Cloud starter på 5 dollar i måneden pluss forbruk, og Envoyer koster fra 10 til 50 dollar i måneden.

Spørsmålet til kjøperen er ikke om disse produktene er gode, for det er de vanligvis, og de sparer utvikleren flere dager i måneden. Spørsmålet er hvilke av dem som ligger inne i den oppgitte prisen, hvilken konto de er registrert på, og hva som skjer med dem hvis du bytter leverandør om to år. Et abonnement som står på byråets konto og ikke er nevnt i avtalen, er nøyaktig den avhengigheten MIT-lisensen ikke tar bort, fordi MIT snakker om koden, ikke om kontoen der den blir plassert og overvåket.

Hva som skjer hvis utvikleren forsvinner

«Koden kan overtas av hvilken som helst Laravel-utvikler» er en setning som er juridisk sann og praktisk ufullstendig, og vi har skrevet den selv også. MIT-lisensen lar virkelig et annet selskap arbeide med denne koden, uten å be om tillatelse verken fra oss eller fra Laravel-teamet. Om den nye utvikleren er til nytte allerede den første uken, avgjøres av fire helt andre ting, og alle fire kan sjekkes før avtalen i det hele tatt er signert.

Den første er hovedversjonen. Å overlevere fra Laravel 11 til et nytt team er ikke en overlevering, men et versjonsbytteprosjekt, fordi sikkerhetsstøtten der allerede har tatt slutt og den første jobben ikke blir ny funksjonalitet, men det forsinkede versjonsbyttet fram til en støttet utgivelse. Den andre er avstanden fra rammeverkets konvensjoner: Laravel-dokumentasjonen tar et bestemt oppsett av mapper og klasser for gitt, og jo lenger prosjektet har beveget seg bort fra det, jo dyrere blir det å bli kjent. Noe tall finnes ikke her og ikke i noen kilde, det finnes bare en retning; derimot kan kjøperen helt konkret spørre hva i prosjektet er skrevet mot standarden, og hvilket behov som krevde det.

Den tredje er avhengighetene, altså de fremmede pakkene systemet stoler på. Composer, som styrer dem i Laravel-verdenen, lagrer en fil med de nøyaktige versjonene, og den er verdifull nettopp fordi en ny utvikler kan installere nøyaktig det samme den forrige så, og ikke det som er nyest i dag. Det denne filen ikke garanterer, er to ting: at pakken fortsatt ligger til nedlasting, og at det ikke er funnet en sårbarhet i den siden den gang. Kommandoen composer audit viser begge i ett kall, og det er den korteste spørsmålsformen du i det hele tatt kan stille om en fremmed kodebase.

Den fjerde er en abandoned package, og her villeder ordene. Packagist, Composers offentlige katalog, merker at vedlikeholderne har stanset, men det betyr ikke at pakken forsvinner eller slutter å virke: swiftmailer blir fortsatt servert, den har 449 millioner registrerte installasjoner, siste utgivelse er fra 2021, og samtidig har den tre kjente sårbarheter. I kodebasen til dette nettstedet, som er vårt eget og som kjører Laravel 13 sammen med Filament-administrasjonspanelet, er det 109 produksjonspakker og ikke en eneste abandoned package — det er vårt tall for vårt prosjekt, ikke et bransjegjennomsnitt, fordi et publisert bransjegjennomsnitt ikke finnes noe sted.

Hvor stort arbeidsmarkedet er, og hvorfor ingen kan gi et nøyaktig tall

På spørsmålet om det i Latvia er lett å finne et menneske som overtar systemet, er det ærlige svaret at det ikke finnes offentlig statistikk over PHP- eller Laravel-utviklere i Latvia. Det finnes indirekte data, og de er verdifulle nøyaktig så langt de beskrives presist. I JetBrains’ PHP-undersøkelse i fjor, blant 1 720 personer som har PHP som hovedspråk, jobber 64 % med Laravel, 25 % med WordPress og 23 % med Symfony; feltarbeidet skjedde om våren, undersøkelsen er skjev i retning av dem som bruker JetBrains-verktøy, noe selskapet selv innrømmer, og de største gruppene av svar kommer fra Japan, USA, Russland, Kina og Frankrike, ikke fra Baltikum.

På europeisk nivå rapporterer Eurostat i mai i år at det i fjor arbeidet 10,45 millioner spesialister innen informasjons- og kommunikasjonsteknologi i Den europeiske union, som er 5,0 % av alle sysselsatte og 2,6 % mer enn året før. For Latvia står det i en tidligere sammenstilling fra den samme kilden et annet tall, som for kjøperen er mer nyttig enn den samlede veksten: i 2023 søkte eller forsøkte bare 4,48 % av latviske foretak å ansette slike spesialister, og det var det laveste tallet i hele Unionen, mens 57,5 % av de europeiske foretakene som søkte, ikke klarte å fylle stillingen.

Disse tallene handler om bransjespesialister samlet, ikke om PHP, og de må ikke skrives om til et utsagn om Laravel-arbeidsmarkedet i Latvia — verken av oss, eller av leverandøren som siterer dem i tilbudet ditt. Vi har selv skrevet på tjenestesiden at det er lett å finne utviklere som overtar arbeidet; da vi forberedte denne artikkelen, fant vi ingen kilde for den påstanden, derfor gjentar vi den ikke her. For kjøperen er den praktiske rekkefølgen likevel en annen: ikke å tro på markedets størrelse, men å sørge for at kodebasen er en der et nytt menneske kommer inn billig, uavhengig av hvor mange slike mennesker det er.

Hvor vi selv trekker grensen i tilbudet

Vi har skrevet Laravel siden 2013, da den fjerde versjonen kom, og det betyr i praksis at vi flere ganger har gått gjennom akkurat det denne artikkelen advarer mot — bytte av hovedversjon, som ikke er en dags jobb og som ikke kan gjøres mellom andre oppgaver. På siden vår om utvikling av Laravel-systemer står pris og frister, og det er en samtale for seg; i denne artikkelen står bare det som kan sjekkes i et tilbud, uavhengig av hvem som har skrevet det og hvor godt det er skrevet.

Det vi ikke påstår, er at hvilken som helst utvikler overtar hvilken som helst kodebase like lett, for avsnittet foran sier det motsatte. Det vi påstår, er mer konkret og mer etterprøvbart: repositoriet er kundens fra første dag, i det ligger både avhengighetsfilen, dokumentasjonen og driftsoppsettet, og i overleveringsøyeblikket er versjonen den som da fortsatt får sikkerhetsoppdateringer. Hvis du synes valget egentlig står mellom et ferdig produkt og et bestilt system, er det en annen samtale, som vi har skrevet for seg, og hvis spørsmålet nettopp gjelder en nettbutikk, svarer sammenligningen av WooCommerce og Laravel mer presist enn denne artikkelen.

I praksis inngår det i overleveringssettet et repositorium med hele historikken, en avhengighetsfil med nøyaktige versjoner, en README med stegene for å starte, driftsoppsett og tilgang til alle kontoene systemet kjører i. Det er det som kan loves og sjekkes. Det som ikke kan loves, er markedet: hvor mange mennesker i Latvia som tar denne jobben, og til hvilken pris, ligger ikke i våre hender og ikke i noen offentlig statistikk, derfor svarer vi ikke på dette spørsmålet med et overbevisende tall. Det eneste som her virkelig arbeider til kjøperens fordel, er at kodebasen er ordinær, at versjonen er støttet, og at dokumentasjonen er skrevet da, ikke utsatt til overleveringsuken.

Hva du bør spørre om før du signerer

Det første spørsmålet gjelder datoene: hvilken Laravel-hovedversjon og hvilken PHP-gren som skal stå i systemet nøyaktig på overleveringsdagen, og når sikkerhetsoppdateringene deres tar slutt. Svaret er to datoer, begge kan sjekkes på to offentlige sider på fem minutter, og de skal skrives inn enten i avtalen, eller i det minste i korrespondansen. Hvis leverandøren navngir en versjon der støtten tar slutt tidligere enn garantitiden, er det ikke forbudt og av og til til og med begrunnet, men da må begge parter vite det, og i prisen må det være klart hvem som betaler for overgangen.

Det andre spørsmålet gjelder abonnementene: hvilke betalte produkter — Forge, Cloud, Nova, Nightwatch, Vapor eller Envoyer — som trengs for at systemet skal virke, hva de til sammen koster i måneden, og hvilken konto de står på. Det tredje gjelder repositoriet: fra hvilken dag det er ditt, om avhengighetsfilen ligger der, og om den automatiske sjekken inkluderer kommandoen composer audit. Det fjerde er et pengespørsmål som vanligvis utsettes og deretter dukker opp som en overraskelse i budsjettet: hvem som betaler for byttet av hovedversjon om halvannet år, og om det ligger i vedlikeholdsavtalen eller blir en ny bestilling.

Ingen av disse fire spørsmålene krever at du forstår koden, og ingen av dem skal tas som mistillit til leverandøren. Alle handler om det som skjer etter at prosjektet er ferdig og fakturaen betalt, og en god leverandør svarer på dem med en gang, fordi de kan disse datoene utenat. Hvis svaret på ett av dem tar en uke, eller blir til en forklaring på hvorfor spørsmålet ikke er viktig, er det allerede et svar.

Disse fire spørsmålene erstatter ikke en teknisk vurdering og svarer ikke på om den foreslåtte arkitekturen er god, men de fjerner det meste av de ubehagelige overraskelsene som vanligvis kommer i det andre eller tredje året, når den opprinnelige entusiasmen er slutt og systemet rett og slett virker. Hvis du har et tilbud i hånden og ikke er sikker på hva versjonene som står der, betyr for fristene og budsjettet ditt, skriv til oss — et svar på disse fire spørsmålene kan forberedes uten at koden åpnes.