Vad är Laravel: vad valet betyder när du beställer ett system

Raderna ”PHP 8.4, Laravel 13” i offerten är ingen teknisk detalj: de avgör hur länge systemet får säkerhetsuppdateringar, vad som kostar extra och hur dyr överlämningen till en annan utvecklare blir.

Offerten kommer en fredagseftermiddag, och i den tekniska delen står två rader som ingen läser högt på mötet: ”PHP 8.4” och ”Laravel 13”. Priset och tidsplanen är begripliga, och raderna ser ut som intern detalj hos leverantören — ungefär lika viktiga som vilken borrmaskin som ska borra hålet i väggen, och därför brukar man hoppa över dem som en teknisk detalj som någon annan ansvarar för. Underskriften hamnar ändå under hela dokumentet, och just de två raderna avgör hur länge systemet får säkerhetsuppdateringar, vad som ger en månadsfaktura utöver utvecklingspriset och hur dyr överlämningen till någon annan blir om tre år.

Den här artikeln handlar inte om huruvida PHP är ett bra språk och Laravel ett bra ramverk, för den frågan avgör utvecklarna mellan sig och köparen har inget praktiskt utbyte av den diskussionen. Den handlar om fyra saker som köparen kan kontrollera själv och utan tekniska kunskaper: stödkalendern, licensen, arbetsmarknaden och villkoren för överlämning. Alla fyra är offentliga, tre av dem är antingen datum eller penningsummor, den fjärde är det man kan och inte kan veta om marknaden, och ingen av dem beror på hur övertygande offerten är skriven — därför lönar det sig att kontrollera dem just den vecka då priset fortfarande går att prata om.

Vad är Laravel, vad är PHP och varför det inte är ett enda val

PHP är det programmeringsspråk som systemets serversida är skriven i — den del som körs hos leverantören eller din hostingleverantör och som användaren aldrig ser. Laravel är i sin tur ett PHP-ramverk, det vill säga en kodbas som redan är skriven i PHP och som löser det som upprepas i nästan varje projekt: användarinloggning, databasfrågor, köer, fillagring, e-postsändning. I offerten står de bredvid varandra som ett enda val, men de är två skilda produkter som underhålls av två olika team med två olika stödkalendrar, och just därför är de värda att läsas var för sig.

Hur utbrett språket är visar sig vara svårare att säga än man väntar sig. W3Techs, som regelbundet skannar mer än tjugo miljoner webbplatser, skriver i augusti i år att PHP används av 70,2 % av alla webbplatser vars serversidespråk det här verktyget känner till. Det sista villkoret är det som vanligtvis försvinner när siffran skrivs om i en presentation: det handlar inte om 70 % av världens alla webbplatser, utan om 70 % av dem som just det här verktyget över huvud taget kan känna igen, och en del av igenkänningen beskriver verktyget självt som indirekt härledd — om sidan är WordPress, då är den PHP.

För köparen är en annan siffra från samma sida mer användbar. Bland webbplatser där W3Techs också slår fast PHP-versionen körs 63,3 % på den åttonde, 28,7 % på den sjunde och 7,9 % fortfarande på den femte, trots att den sjunde versionen förlorade även säkerhetsuppdateringarna för fyra år sedan. Det betyder att ungefär en tredjedel av den mätbara PHP-delen av internet i dag körs på kod som ingen längre släpper säkerhetsuppdateringar till, och det har inte skett för att språket skulle vara dåligt eller för att någon skulle ha gjort ett utvecklingsfel. Det har skett för att ingen har beställt och betalat ett versionsbyte, och det är just den delen av risken som köparen både kan se och styra.

PHP-stödkalendern är det första dokumentet värt att öppna

PHP-gruppens regel är kort och offentlig: varje versionsgren får fullt stöd i två år från den första stabila utgåvan, därefter ytterligare två år med endast kritiska säkerhetsfixar, och efter fyra år underhålls den inte alls — end of life i php.net:s egen tabell. I den regeln finns en detalj som återberättelser nästan alltid klipper bort: de verkliga slutdatumen i tabellen är anpassade till årets sista dag, inte till utgåvans årsdag i november, så ”två år från släppet” och det som står i tabellen på php.net skiljer sig med en månad eller två.

I praktiken betyder det följande. Version 8.2 ligger just nu i fönstret med endast säkerhetsfixar, och stödet tar slut redan vid årets slut, alltså om ungefär fyra månader. Version 8.3 förlorade det fulla stödet vid slutet av förra året och får säkerhetsuppdateringar till slutet av 2027, alltså i ungefär sexton månader till. Version 8.4 stannar i fullt stöd året ut och ligger därefter ytterligare två år i fönstret med endast säkerhetsfixar, medan den senaste 8.5, som kom i november förra året, får fullt stöd hela nästa år och säkerhetsuppdateringar till slutet av 2029.

Stödet för version 8.1 tog slut på förra årets sista dag, och just det fallet är värt uppmärksamhet om du redan har ett system, inte en offert. Om leverantören för tre år sedan skrev det på 8.1 och ingen har rört något sedan dess, då kör det i dag på en gren som inte längre får säkerhetsuppdateringar, och varken servern, webbläsaren eller systemet självt varnar för det. Sidan öppnas precis som i går, kunderna märker ingenting, och det enda stället där man kan se det är just den här offentliga tabellen, som tar kortare tid att öppna än att läsa offertens titelsida.

Laravel-kalendern är kortare än PHP-kalendern

Laravel formulerar sin policy ännu kortare: felrättningar i arton månader, säkerhetsuppdateringar i två år, och en ny huvudversion varje år ungefär under första kvartalet. En utgåva med långtidsstöd, som branschen kallar LTS, finns inte längre i dag — i de äldre versionerna fanns en sådan verkligen, men i årets tabell saknas den kolumnen helt, så en offert som skriver ”LTS Laravel” beskriver något som just nu inte säljs. Det är ett kortare löfte än många köpare väntar sig av ett ramverk som systemet ska byggas på de kommande fem åren.

I siffror, enligt Laravels egen dokumentation, ser ordningen ut så här. Laravel 13 kom i mars i år, får felrättningar till nästa års tredje kvartal och säkerhetsuppdateringar till den 17 mars 2028. Fönstret för felrättningar i Laravel 12 stängdes i mitten av augusti i år, det vill säga sjutton dagar innan de här raderna skrevs, och dess säkerhetsuppdateringar tar slut i februari nästa år. Säkerhetsstödet för Laravel 11 tog slut i våras, så ett system som i dag körs på den elfte versionen körs redan utan säkerhetsuppdateringar, hur bra det än ser ut utifrån.

Lägg märke till att slutet för felrättningar i Laravel 13 anges som ett kvartal, inte som ett visst datum. Det är en oprecis formulering från Laravel själva, och den är inget problem så länge man skriver av den precis som den står; problemet börjar i det ögonblick leverantören eller köparen rundar av den till en viss dag och sedan planerar budgeten efter en siffra som inte finns i källan. Ytterligare en gräns att känna till innan versionen väljs: Laravel 13 kräver minst PHP 8.3, så ett system på den trettonde versionen kan inte lämnas kvar på 8.2 ens om 8.2 själv en tid till skulle få säkerhetsuppdateringar.

Vad de två kalendrarna tillsammans betyder för systemet du beställer i dag

Om systemet vid överlämningen körs på Laravel 13 tillsammans med PHP 8.4 eller 8.5 är det första datumet då något måste göras mars 2028, när Laravels säkerhetsuppdateringar tar slut, och det är ungefär arton och en halv månad från i dag. PHP är i den kombinationen inte begränsningen, eftersom båda de grenarna får säkerhetsuppdateringar längre än ramverket, så det som åldras först är Laravel, inte språket. Det är också det enda ärliga sättet att svara på frågan ”hur länge står det här systemet utan ytterligare investering” — inte med en känsla, utan med det tidigaste av två offentliga datum.

Om samma system vid överlämningen körs på Laravel 13 men PHP 8.3 vänds ordningen och den första fristen infaller om ungefär sexton månader, när den här PHP-grenens säkerhetsuppdateringar tar slut. Om leverantören skriver på Laravel 12, som för ett befintligt projekt fortfarande är ett helt normalt val, tar säkerhetsuppdateringarna slut i februari nästa år, och ett nytt systems liv börjar med sex månader till det första obligatoriska versionsbytet. Skillnaden mellan det första och det tredje alternativet är ett år, som går att vinna i ett enda samtal före avtalet, och som inte går att köpa efter underskriften.

Två fel i den här räkningen är så vanliga att de är värda att nämna var för sig. Det första är att blanda ihop fullt stöd med säkerhetsstödet, så när du hör att ”stödet för PHP 8.4 tar slut vid årsskiftet” lönar det sig att fråga vilket av de två fönstren som avses: den vanliga felrättningen tar slut, men säkerhetsuppdateringarna kommer i ytterligare två år. Det andra är att tro på Laravels egen mening att övergången till en ny huvudversion vanligtvis skulle ta en dag eller mindre; det är ett mål formulerat av utvecklarna, inte ett uppmätt medelvärde, och det går inte att skriva in som tidsfrist i avtalet.

Licensen kostar noll, och det stämmer bara för språket och ramverket

Laravel-ramverket sprids med MIT-licens, som är en av de enklaste öppen källkod-licenserna och tillåter att koden används, ändras och säljs vidare, bara upphovsrättsnotisen behålls. Med PHP är det lite mer komplicerat, och den komplikationen är aktuell just nu, eftersom licensen byts: versionerna till och med 8.5 kommer med PHP-licensens version 3.01, men från och med 8.6 går de över till den fjärde versionen, som php.net själv beskriver som en ”Modified BSD”-licens och som i praktiken sammanfaller med BSD-3-Clause. I inget av fallen tas någon avgift ut.

Det betyder att företaget för själva språket och själva ramverket inte betalar vare sig per användare, per processorkärna eller per år, och den nollan är ingen kampanj som någon gång tar slut. Som jämförelse duger modellen som Microsoft SQL Server använder: där licensieras antingen per kärna eller per server tillsammans med klientåtkomstlicenser (CAL), Standard-utgåvan är begränsad till det lägre av fyra processorsocklar eller tjugofyra kärnor, och den avgiftsfria Express-utgåvan till en sockel eller fyra kärnor. Exakta belopp skriver vi inte här, för prislistan ändras och den ska läsas hos Microsoft; för köparen är det modellen som är jämförbar, inte siffran — den ena produkten räknar på mängden maskinvara, den andra räknar inte alls.

Vid köpet har det två följder som är värda att skriva upp med en gång. Den första är behaglig: ingen licensrevision, ingen årlig omräkning för användare som har blivit fler under året, och ingen situation där mjukvaruleverantören efter tre år kommer med en faktura för en överskriden gräns. Den andra är den som brukar glömmas: öppen källkod tar bort beroendet av ramverkets ägare, men tar inte bort beroende över huvud taget. Beroendet flyttar till andra ställen — till byrån som ensam vet hur projektet är hopfogat, till betalprodukterna som står bredvid koden, till en abandoned package, ett paket vars underhållare har stannat, och till en huvudversion där stödet har tagit slut. De fyra ställena är dem köparen måste kontrollera, för licensraden säger ingenting om dem.

Där Laravel ändå börjar kosta: produkter som inte är ramverket

Samma team som underhåller Laravel säljer också flera produkter, och i offerten brukar de stå på samma rad som ramverket, som om de vore en del av det. Laravel skiljer självt de två sakerna på sin webbplats: paketen — Horizon, Telescope, Pulse, Scout, Sanctum, Octane och andra — är MIT-licensierade och gratis, medan produkterna är Cloud, Forge, Nightwatch, Vapor och Nova, och de kostar pengar varje månad eller varje år. Envoyer säljs fortfarande separat. Ingen av de här produkterna behövs för att ett Laravel-system ska fungera, och just därför är deras närvaro i offerten ett val, inte en nödvändighet.

Priserna i augusti i år såg ut så här. Forge, som man hanterar servrar med, kostar 12, 19 eller 39 amerikanska dollar i månaden beroende på plan. Nova, som är en administrationspanel, kostar 99 dollar en gång för ett projekt tillsammans med ett års uppdateringar och 79 dollar om året för att fortsätta få uppdateringar, medan den obegränsade licensen kostar 299 respektive 249 dollar, och den täcker dessutom dina egna projekt, inte dina kunders projekt. Nightwatch, som samlar in systemhändelser, börjar med en avgiftsfri plan och klättrar till 20, 60 och 300 dollar i månaden, plus ett tillägg för händelser över den ingående gränsen. Laravel Cloud börjar på 5 dollar i månaden plus förbrukning, och Envoyer kostar från 10 till 50 dollar i månaden.

Frågan för köparen är inte om de här produkterna är bra, för vanligtvis är de bra och sparar utvecklaren flera dagar i månaden. Frågan är vilka av dem som ingår i det namngivna priset, på vilket konto de är registrerade och vad som händer med dem om du byter leverantör om två år. Ett abonnemang som står på byråns konto och inte nämns i avtalet är precis det beroende som MIT-licensen inte tar bort, för MIT talar om koden, inte om kontot där den läggs upp och övervakas.

Vad som händer om utvecklaren försvinner

”Koden kan tas över av vilken Laravel-utvecklare som helst” är en mening som är juridiskt sann och praktiskt ofullständig, och vi har skrivit den själva också. MIT-licensen tillåter verkligen ett annat företag att arbeta med den här koden utan att be om tillstånd vare sig av oss eller av Laravel-teamet. Om den nya utvecklaren är till nytta redan den första veckan avgörs av fyra helt andra saker, och alla fyra kan kontrolleras innan avtalet över huvud taget är underskrivet.

Den första är huvudversionen. En överlämning från Laravel 11 till ett nytt team är ingen överlämning utan ett versionsbytesprojekt, för säkerhetsstödet där har redan tagit slut och det första arbetet blir inte ny funktionalitet utan det försenade versionsbytet fram till en utgåva som fortfarande får stöd. Den andra är avståndet från ramverkets konvention: Laravels dokumentation utgår från en viss mapp- och klasslayout, och ju längre projektet har avvikit från den, desto dyrare blir inkörningen. Någon siffra finns inte här och inte i någon källa, det finns bara en riktning; däremot kan köparen helt konkret fråga vad i projektet som är skrivet i strid med den konventionen och vilket behov som krävde det.

Den tredje är Composer-beroendena, det vill säga de främmande paket systemet litar på. Composer, som i Laravel-världen hanterar dem, sparar en fil med exakta versioner, och den är värdefull just därför att en ny utvecklare kan installera exakt samma sak som den föregående såg, inte det som i dag är nyast. Vad den här filen inte garanterar är två saker: att paketet fortfarande går att ladda ner, och att det inte har hittats någon sårbarhet i det sedan dess. Kommandot composer audit visar båda i ett anrop, och det är den kortaste frågan man över huvud taget kan ställa om en främmande kodbas.

Den fjärde är en abandoned package, och här vilseleder orden. Packagist, Composers offentliga katalog, markerar att underhållarna har stannat, men det betyder inte att paketet försvinner eller slutar fungera: swiftmailer delas fortfarande ut, det har 449 miljoner registrerade installationer, den senaste utgåvan är från 2021, och samtidigt har det tre kända sårbarheter. I vår egen kodbas för den här webbplatsen, som är Laravel 13 tillsammans med Filament-administrationspanelen, finns 109 produktionspaket och ingen abandoned package — det är vår siffra för vårt projekt, inte ett branschmedel, för något publicerat branschmedel finns ingenstans.

Hur stor arbetsmarknaden är, och varför ingen kan ge en exakt siffra

På frågan om det i Sverige är lätt att hitta någon som tar över systemet är det ärliga svaret att det inte finns någon offentlig statistik om PHP- eller Laravel-utvecklare i Sverige. Det finns indirekta data, och de är värdefulla precis så långt de beskrivs exakt. I JetBrains PHP-undersökning förra året, bland 1 720 personer för vilka PHP är huvudspråk, arbetar 64 % med Laravel, 25 % med WordPress och 23 % med Symfony; fältarbetet skedde på våren, undersökningen är snedvriden till förmån för användare av JetBrains verktyg, vilket företaget själv medger, och de största svarsgrupperna kommer från Japan, USA, Ryssland, Kina och Frankrike, inte från Baltikum.

På europeisk nivå rapporterar Eurostat i maj i år att det förra året arbetade 10,45 miljoner specialister inom informations- och kommunikationsteknik i Europeiska unionen, vilket är 5,0 % av alla sysselsatta och 2,6 % fler än året innan. För Sverige finns i samma källas tidigare sammanställning en annan siffra, som för köparen är mer användbar än den samlade tillväxten: 2023 sökte eller försökte 10,14 % av de svenska företagen anställa sådana specialister, och 53,03 % av de svenska företag som sökte inte kunde tillsätta tjänsten.

De här siffrorna gäller branschens specialister som helhet, inte PHP, och de får inte skrivas om som ett påstående om Laravel-arbetsmarknaden i Sverige — varken av oss eller av en leverantör som citerar dem i din offert. Vi har själva skrivit på vår tjänstesida att det är lätt att hitta utvecklare som tar över arbetet; när vi tog fram den här artikeln hittade vi ingen källa för det påståendet, så här upprepar vi det inte. För köparen är den praktiska ordningen ändå en annan: inte att tro på marknadens storlek, utan att se till att kodbasen är en där en ny person kan komma in till låg kostnad oavsett hur många sådana personer det finns.

Var vi själva drar gränsen i offerten

Vi har skrivit på Laravel sedan 2013, när den fjärde versionen kom, och det betyder i praktiken att vi flera gånger har gått igenom just det den här artikeln varnar för — bytet av huvudversion, som inte är ett dagsverke och som inte går att göra mellan andra uppgifter. På vår sida om Laravel-utveckling finns pris och tider, och det är ett separat samtal; i den här artikeln finns bara det som kan kontrolleras i en offert oavsett vem som har skrivit den och hur bra den är skriven.

Vad vi inte påstår är att vilken utvecklare som helst tar över vilken kodbas som helst lika lätt, för föregående avsnitt säger motsatsen. Vad vi påstår är mer konkret och mer kontrollerbart: kodförrådet är kundens från första dagen, i det finns både beroendefilen, dokumentationen och distributionskonfigurationen, och vid överlämningen är versionen den som just då fortfarande får säkerhetsuppdateringar. Om du tycker att valet egentligen står mellan en färdig produkt och ett skräddarsytt system är det en annan diskussion, som vi har skrivit separat, och om frågan just gäller en webbutik svarar jämförelsen mellan WooCommerce och Laravel mer precist än den här artikeln.

I praktiken ingår i överlämningspaketet kodförrådet med hela historiken, beroendefilen med exakta versioner, en README med startstegen, distributionskonfigurationen och åtkomst till alla konton där systemet körs. Det är det som går att lova och kontrollera. Vad som inte går att lova är marknaden: hur många personer i Sverige som tar det här arbetet och till vilket pris ligger inte i våra händer och inte i någon offentlig statistik, så vi svarar inte på den frågan med en övertygande siffra. Det enda som här verkligen gynnar köparen är att kodbasen är konventionell, versionen har stöd och dokumentationen är skriven då, inte uppskjuten till överlämningsveckan.

Vad du ska fråga innan du skriver under

Den första frågan gäller datumen: vilken Laravel-huvudversion och vilken PHP-gren som kommer att ligga i systemet just på överlämningsdagen, och när deras säkerhetsuppdateringar tar slut. Svaret är två datum, båda kan kontrolleras på två offentliga sidor på fem minuter, och de ska skrivas in antingen i avtalet eller åtminstone i korrespondensen. Om leverantören namnger en version vars stöd tar slut tidigare än garantitiden är det inte förbjudet och ibland till och med motiverat, men då ska båda parter veta det, och i priset ska det vara begripligt vem som betalar för övergången.

Den andra frågan gäller abonnemangen: vilka betalprodukter — Forge, Cloud, Nova, Nightwatch, Vapor eller Envoyer — som systemet behöver för att köras, vad de tillsammans kostar i månaden och på vilket konto de står. Den tredje gäller kodförrådet: från vilken dag det är ditt, om beroendefilen finns i det och om den automatiska kontrollen omfattar kommandot composer audit. Den fjärde är en pengafråga som vanligtvis skjuts upp och sedan dyker upp som en överraskning i budgeten: vem som betalar för bytet av huvudversion om ett och ett halvt år, och om det ingår i avtalet om drift och förvaltning eller blir en ny beställning.

Ingen av de fyra frågorna kräver att du förstår koden, och ingen av dem ska läsas som misstro mot leverantören. Alla handlar om det som händer efter att projektet är klart och fakturan betald, och en bra leverantör svarar på dem genast, för leverantören kan datumen utantill. Om svaret på någon av dem tar en vecka eller förvandlas till en förklaring av varför frågan inte är viktig, då är det redan ett svar.

De här fyra frågorna ersätter inte en teknisk bedömning och svarar inte på om den föreslagna arkitekturen är bra, men de tar bort merparten av de obehagliga överraskningar som vanligtvis kommer det andra eller tredje året, när den ursprungliga entusiasmen har tagit slut och systemet helt enkelt körs. Om du har en offert i handen och inte är säker på vad versionerna som står där betyder för dina tider och din budget, skriv till oss — ett svar på de fyra frågorna kan tas fram utan att koden öppnas.