Mikä on Laravel: mitä PHP- ja Laravel-valinta merkitsee järjestelmän tilaajalle

Tarjouksen rivit ”PHP 8.4, Laravel 13” eivät ole tekninen yksityiskohta: nämä kaksi riviä määräävät, kuinka kauan järjestelmä saa tietoturvakorjauksia, mitä siinä maksaa lisäksi ja miten kallis luovutus toiselle kehittäjälle on.

Tarjous saapuu perjantai-iltapäivällä, ja sen teknisessä osassa on kaksi riviä, joita kukaan ei lue ääneen kokouksessa: ”PHP 8.4” ja ”Laravel 13”. Hinta on ymmärrettävä, aikataulu on ymmärrettävä, ja nämä kaksi riviä näyttävät toimittajan sisäiseltä keittiöltä — suunnilleen yhtä tärkeiltä kuin se, millä poralla seinään porataan reikä, ja siksi ne yleensä ohitetaan teknisenä yksityiskohtana, josta vastaa joku muu. Allekirjoitus tulee kuitenkin koko asiakirjan alle, ja juuri nämä kaksi riviä määräävät, kuinka kauan järjestelmä ylipäätään saa tietoturvakorjauksia, mitä siinä laskutetaan kuukausittain kehityshinnan päälle ja miten kallis sen luovutus jollekulle muulle on kolmen vuoden päästä.

Tämä artikkeli ei ole siitä, onko PHP hyvä kieli ja onko Laravel hyvä ohjelmistokehys, koska siihen kehittäjät vastaavat keskenään eikä ostaja saa siitä keskustelusta mitään käytännön hyötyä. Kyse on neljästä asiasta, jotka ostaja voi tarkistaa itse ilman teknistä osaamista: tukikalenterista, lisenssistä, työmarkkinasta ja luovutuksen ehdoista. Kaikki neljä ovat julkisia, kolme niistä on joko päivämääriä tai rahasummia, neljäs on se, mitä markkinasta voi ja mitä ei voi tietää, eikä yksikään riipu siitä, miten vakuuttavasti tarjous on kirjoitettu — siksi ne kannattaa tarkistaa juuri sinä viikkona, jona hinnasta voi vielä puhua.

Mikä on Laravel, mikä on PHP, ja miksi ne eivät ole yksi valinta

PHP on ohjelmointikieli, jolla järjestelmän palvelinpuoli on kirjoitettu — se osa, joka pyörii toimittajalla tai webhotellissasi ja jota käyttäjä ei koskaan näe. Laravel taas on ohjelmistokehys, eli PHP-kielellä jo kirjoitettu koodipohja, joka ratkaisee sen, mikä toistuu lähes jokaisessa hankkeessa: käyttäjien kirjautumisen, tietokantakyselyt, jonot, tiedostojen tallennuksen, sähköpostin lähettämisen. Tarjouksessa ne seisovat rinnakkain kuin yhtenä valintana, mutta ne ovat kaksi erillistä tuotetta, joita ylläpitää kaksi eri tiimiä kahdella eri tukikalenterilla, ja juuri siksi ne kannattaa lukea erikseen.

Kuinka yleinen kieli on, osoittautuu vaikeammaksi sanoa kuin odottaisi. W3Techs, joka skannaa säännöllisesti yli kahtakymmentä miljoonaa sivustoa, kirjoittaa tämän vuoden elokuussa, että PHP:tä käyttää 70,2 % kaikista sivustoista, joiden palvelinpuolen ohjelmointikielen tämä työkalu tuntee. Viimeinen ehto on se, joka yleensä katoaa, kun luku kirjoitetaan esitykseen: kyse ei ole 70 prosentista kaikista maailman sivustoista, vaan 70 prosentista niistä, jotka tämä nimenomainen työkalu ylipäätään pystyy tunnistamaan, ja osan tunnistuksesta se itse kuvaa päätellyksi epäsuorasti — jos sivu on WordPress, se on PHP.

Ostajalle hyödyllisempi on toinen luku samalta sivulta. Niistä sivustoista, joille W3Techs määrittää myös PHP-version, 63,3 % pyörii kahdeksannella, 28,7 % seitsemännellä ja 7,9 % yhä viidennellä, vaikka seitsemäs versio menetti jopa tietoturvakorjaukset jo neljä vuotta sitten. Se tarkoittaa, että noin kolmannes mitattavasta PHP-internetistä toimii tänään koodilla, johon kukaan ei enää tee korjauksia, eikä se ole tapahtunut siksi, että kieli olisi huono tai että joku olisi tehnyt virheen kehityksessä. Se on tapahtunut siksi, ettei kukaan ole tilannut ja maksanut versionvaihtoa, ja juuri tämä on se riskin osa, jonka ostaja voi sekä nähdä että hallita.

PHP:n tukikalenteri on ensimmäinen asiakirja, joka kannattaa avata

PHP:n kehittäjäryhmän sääntö on lyhyt ja julkinen: jokainen versiohaara saa täyden tuen kaksi vuotta ensimmäisestä vakaasta julkaisusta, sen jälkeen vielä kaksi vuotta vain tietoturvakorjauksia, ja neljän vuoden jälkeen sen elinkaari päättyy (EOL) eikä sitä ylläpidetä enää lainkaan. Tässä säännössä on yksi yksityiskohta, jonka kertomukset lähes aina katkaisevat: taulukon todelliset päättymispäivät on sovitettu vuoden viimeiseen päivään, ei marraskuisen julkaisun vuosipäivään, siksi ”kaksi vuotta julkaisusta” ja se, mikä lukee php.netin taulukossa, eroavat kuukaudella tai kahdella.

Käytännössä se tarkoittaa seuraavaa. Versio 8.2 on tällä hetkellä vain tietoturvakorjausten tilassa, ja sen tuki päättyy jo tämän vuoden lopussa, eli noin neljän kuukauden päästä. Versio 8.3 menetti täyden tuen viime vuoden lopussa ja saa tietoturvakorjauksia vuoden 2027 loppuun, eli vielä noin kuusitoista kuukautta. Versio 8.4 työskentelee täydessä tuessa tämän vuoden loppuun ja pysyy sen jälkeen vielä kaksi vuotta vain tietoturvakorjausten tilassa, kun taas uusin 8.5, joka ilmestyi viime vuoden marraskuussa, saa täyden tuen vielä koko ensi vuoden ja tietoturvakorjauksia vuoden 2029 loppuun.

Version 8.1 tuki päättyi viime vuoden viimeisenä päivänä, ja juuri tämä tapaus ansaitsee huomion, jos sinulla on jo järjestelmä, ei tarjous. Jos toimittaja kirjoitti sen kolme vuotta sitten 8.1:lle eikä kukaan ole sen jälkeen muuttanut mitään, se pyörii tänään haaralla, jolle tietoturvakorjauksia ei enää tule, eikä siitä varoita palvelin, selain eikä järjestelmä itse. Sivu avautuu täsmälleen kuten eilen, asiakkaat eivät huomaa mitään, ja ainoa paikka, jossa sen voi nähdä, on tämä sama julkinen taulukko, jonka avaaminen vie vähemmän aikaa kuin tarjouksen kansilehden lukeminen.

Laravelin kalenteri on lyhyempi kuin PHP:n kalenteri

Laravel muotoilee politiikkansa vielä lyhyemmin: virhekorjauksia kahdeksantoista kuukautta, tietoturvakorjauksia kaksi vuotta, ja uusi pääversio joka vuosi noin ensimmäisellä neljänneksellä. Pitkän tuen julkaisua, jota alalla kutsutaan LTS:ksi, ei tänään enää ole — vanhoissa versioissa sellainen todella oli, mutta tämän vuoden taulukossa sellaista saraketta ei ole lainkaan, siksi tarjous, jossa lukee ”LTS Laravel”, kuvaa jotain, jota tällä hetkellä kukaan ei myy. Se on lyhyempi lupaus kuin monet ostajat odottavat ohjelmistokehykseltä, jonka päälle järjestelmä rakennetaan seuraaviksi viideksi vuodeksi.

Lukuina, Laravelin oman dokumentaation mukaan, järjestys on tämä. Laravel 13 ilmestyi tämän vuoden maaliskuussa, saa virhekorjauksia ensi vuoden kolmanteen neljännekseen ja tietoturvakorjauksia 17. maaliskuuta 2028 asti. Laravel 12:n virhekorjausikkuna sulkeutui tämän vuoden elokuun puolivälissä, eli seitsemäntoista päivää ennen näiden rivien kirjoittamista, ja sen tietoturvakorjaukset päättyvät ensi vuoden helmikuussa. Laravel 11:n tietoturvatuki päättyi tämän vuoden keväällä, joten järjestelmä, joka tänään pyörii versiolla 11, pyörii jo ilman korjauksia, vaikka miltä se ulospäin näyttäisi.

Huomaa, että Laravel 13:n virhekorjausten päättyminen on merkitty vuosineljänneksenä, ei tarkkana päivänä. Se on Laravelin oman muotoilun epätarkkuus, eikä se ole ongelma niin kauan kuin se kirjoitetaan uudestaan täsmälleen niin kuin siellä lukee; ongelma alkaa sillä hetkellä, kun toimittaja tai ostaja pyöristää sen tiettyyn päivään ja suunnittelee sitten budjetin luvun mukaan, jota lähteessä ei ole. Toinen raja, joka pitää tietää ennen version valintaa: Laravel 13 vaatii vähintään PHP 8.3:n, joten järjestelmää versiossa 13 ei voi jättää 8.2:lle silloinkaan, jos 8.2 itse saisi tietoturvakorjauksia vielä jonkin aikaa.

Mitä molemmat kalenterit yhdessä merkitsevät tänään tilattavalle järjestelmälle

Jos järjestelmä luovutetaan Laravel 13:lla yhdessä PHP 8.4:n tai 8.5:n kanssa, ensimmäinen päivämäärä, jolloin jonkin on pakko liikahtaa, on maaliskuu 2028, jolloin Laravelin tietoturvakorjaukset päättyvät, ja se on noin kahdeksantoista ja puoli kuukautta tästä päivästä. PHP ei ole tässä yhdistelmässä rajoite, koska molemmat nämä haarat saavat tietoturvakorjauksia pidempään kuin kehys, siksi ensimmäisenä vanhenee Laravel, ei kieli. Se on myös ainoa rehellinen tapa vastata kysymykseen ”kuinka kauan tämä järjestelmä kestää ilman lisäsijoitusta” — ei tunteella, vaan kahdesta julkisesta päivämäärästä aikaisemmalla.

Jos sama järjestelmä luovutetaan Laravel 13:lla mutta PHP 8.3:lla, järjestys kääntyy ja ensimmäinen määräaika tulee noin kuudessatoista kuukaudessa, jolloin tämän PHP-haaran tietoturvakorjaukset päättyvät. Jos toimittaja kirjoittaa Laravel 12:lle, joka olemassa olevalle hankkeelle on yhä täysin tavallinen valinta, tietoturvakorjaukset päättyvät ensi vuoden helmikuussa, ja uuden järjestelmän elämä alkaa kuudella kuukaudella ensimmäiseen pakolliseen versionvaihtoon. Ero ensimmäisen ja kolmannen vaihtoehdon välillä on vuosi, jonka voi vielä neuvotella yhdessä keskustelussa ennen sopimusta ja jota allekirjoituksen jälkeen ei enää saa rahalla.

Kaksi virhettä tässä laskelmassa on niin yleisiä, että ne kannattaa nimetä erikseen. Ensimmäinen on sekoittaa täysi tuki tietoturvatukeen, siksi kun kuulet, että ”PHP 8.4:n tuki päättyy vuoden lopussa”, kannattaa kysyä, kumpaa kahdesta ikkunasta tarkoitetaan: tavallisten virheiden korjaus päättyy, mutta tietoturvakorjauksia tulee vielä kaksi vuotta. Toinen on uskoa Laravelin omaa lausetta, että siirtymä uuteen pääversioon kestäisi yleensä päivän tai vähemmän; se on kehittäjien muotoilema tavoite, ei mitattu keskiarvo, eikä sitä voi kirjoittaa sopimukseen määräajaksi.

Lisenssi maksaa nollan, ja se on totta vain kielestä ja kehyksestä

Laravelin ohjelmistokehys jaetaan MIT-lisenssillä, joka on yksi yksinkertaisimmista avoin lähdekoodi -lisensseistä ja sallii koodin käyttämisen, muuttamisen ja edelleen myymisen, kunhan tekijänoikeusilmoitus säilytetään. PHP:n kanssa on hieman monimutkaisempaa, ja tämä monimutkaisuus on juuri nyt ajankohtainen, koska lisenssi vaihtuu: versiot 8.5:een asti ilmestyvät PHP-lisenssin 3.01-versiolla, mutta 8.6:sta alkaen siirrytään neljänteen versioon, jota php.net itse kuvaa ”Modified BSD” -lisenssiksi ja joka käytännössä vastaa BSD-3-Clausea. Missään näistä vaihtoehdoista maksua ei ole säädetty.

Se tarkoittaa, että itse kielestä ja itse kehyksestä yritys ei maksa käyttäjästä, prosessoriytimestä eikä vuodesta, eikä tämä nolla ole kampanja, joka joskus päättyy. Vertailuksi käy malli, jota Microsoft SQL Server käyttää: siellä lisensoidaan joko ytimien mukaan tai palvelimen mukaan yhdessä asiakaskäyttöoikeuksien kanssa, Standard-julkaisu on rajattu pienempään neljästä suoritinkannasta tai kahdestakymmenestäneljästä ytimestä, maksuton Express-julkaisu yhteen suoritinkantaan tai neljään ytimeen. Tarkkoja summia emme tähän kirjoita, koska hinnasto muuttuu ja se pitää lukea Microsoftilta; ostajalle vertailtavissa on malli, ei luku — toinen tuote laskuttaa rautamäärän mukaan, toinen ei laskuta lainkaan.

Hankinnassa sillä on kaksi seurausta, jotka kannattaa kirjoittaa heti. Ensimmäinen on miellyttävä: ei lisenssiauditointia, ei vuotuista uudelleenlaskentaa käyttäjistä, jotka vuoden mittaan ovat kasvaneet, eikä tilannetta, jossa ohjelmistotoimittaja tulee kolmen vuoden päästä laskulla ylitetystä rajasta. Toinen on se, joka yleensä unohdetaan: avoin lähdekoodi poistaa riippuvuuden kehyksen omistajasta, mutta ei poista riippuvuutta ylipäätään. Riippuvuus siirtyy muihin paikkoihin — toimistoon, joka yksin tietää, miten hanke on koottu, maksullisiin tuotteisiin, jotka seisovat koodin rinnalla, abandoned packageen, jonka ylläpitäjät ovat lopettaneet, ja pääversioon, jonka tuki on päättynyt. Nämä neljä paikkaa ostajan on tarkistettava, koska lisenssirivi ei niistä kerro mitään.

Missä Laravel silti alkaa maksaa: tuotteet, jotka eivät ole kehys

Sama tiimi, joka ylläpitää Laravelia, myy myös useita tuotteita, ja tarjouksessa ne saattavat seistä samalla rivillä kehyksen kanssa kuin sen osa. Laravel erottaa nämä kaksi asiaa itse sivustollaan: paketit — Laravel Horizon, Telescope, Pulse, Scout, Sanctum, Octane ja muut — ovat MIT-lisensoituja ja maksuttomia, tuotteet taas ovat Cloud, Forge, Nightwatch, Vapor ja Nova, ja niistä maksetaan joka kuukausi tai joka vuosi. Envoyeria myydään yhä erikseen. Mikään näistä tuotteista ei ole tarpeen, jotta Laravel-järjestelmä toimisi, ja juuri siksi niiden läsnäolo tarjouksessa on valinta, ei välttämättömyys.

Hinnat näyttivät tämän vuoden elokuussa tältä. Forge, jolla hallitaan palvelimia, maksaa 12, 19 tai 39 Yhdysvaltain dollaria kuukaudessa suunnitelman mukaan. Nova, joka on hallintapaneeli, maksaa 99 dollaria kerran yhdestä hankkeesta vuoden päivityksineen ja 79 dollaria vuodessa päivitysten jatkamisesta, mutta rajoittamaton lisenssi maksaa vastaavasti 299 ja 249 dollaria, ja se kattaa omat projektisi, ei asiakkaidesi projekteja. Nightwatch, joka kerää järjestelmän tapahtumat, alkaa maksuttomasta suunnitelmasta ja nousee 20, 60 ja 300 dollariin kuukaudessa, lisäksi lisämaksu mukaan luetun rajan ylittävistä tapahtumista. Laravel Cloud alkaa 5 dollarista kuukaudessa, kulutus päälle, ja Envoyer maksaa 10–50 dollaria kuukaudessa.

Ostajan kysymys ei ole, ovatko nämä tuotteet hyviä, koska yleensä ne ovat hyviä ja säästävät kehittäjältä useita päiviä kuukaudessa. Kysymys on, mitkä niistä sisältyvät nimettyyn hintaan, minkä tilin päälle ne on rekisteröity ja mitä niille tapahtuu, jos vaihdat toimittajaa kahden vuoden päästä. Tilaus, joka seisoo toimiston tilillä eikä näy sopimuksessa, on juuri se riippuvuus, jota MIT-lisenssi ei poista, koska MIT puhuu koodista, ei tilistä, jossa se sijoitetaan ja jota valvotaan.

Mitä tapahtuu, jos kehittäjä katoaa

”Koodin voi ottaa haltuun kuka tahansa Laravel-kehittäjä” on lause, joka on juridisesti tosi ja käytännössä vajaa, ja olemme kirjoittaneet sen itsekin. MIT-lisenssi todella antaa toisen yrityksen työskennellä tällä koodilla kysymättä lupaa meiltä eikä Laravelin tiimiltä. Onko uusi kehittäjä hyödyksi jo ensimmäisellä viikolla, päättävät neljä aivan muuta asiaa, ja kaikki neljä voi tarkistaa ennen kuin sopimus ylipäätään on allekirjoitettu.

Ensimmäinen on pääversio. Luovutus Laravel 11:stä uudelle tiimille ei ole luovutus vaan versionvaihtohanke, koska tietoturvatuki on siellä jo päättynyt ja ensimmäinen työ ei ole uutta toiminnallisuutta vaan myöhässä oleva vaihto tuettuun julkaisuun. Toinen on etäisyys kehyksen käytännöistä: Laravelin dokumentaatio olettaa tietyn kansioiden ja luokkien asettelun, ja mitä kauemmas hanke siitä on lähtenyt, sitä kalliimpi tutustuminen on. Lukua tässä ei ole eikä missään lähteessä sellaista ole, on vain suunta; sen sijaan ostaja voi aivan konkreettisesti kysyä, mitä hankkeessa on kirjoitettu oletusta vastaan ja mikä tarve sen vaati.

Kolmas on riippuvuudet, eli vieraat paketit, joihin järjestelmä tukeutuu. Composer, joka Laravelin maailmassa niitä hallitsee, säilyttää tiedoston tarkkoine versioineen, ja se on arvokas juuri siksi, että uusi kehittäjä voi asentaa täsmälleen saman minkä edellinen näki, ei sitä mikä tänään on uusinta. Mitä tämä tiedosto ei takaa, on kaksi asiaa: että paketti on yhä ladattavissa, ja ettei siitä ole sen jälkeen löydetty haavoittuvuutta. Komento composer audit näyttää molemmat yhdellä kutsulla, ja se on lyhin kysymyksen muoto, jonka vieraasta koodipohjasta ylipäätään voi esittää.

Neljäs on abandoned package, ja tässä sanat harhauttavat. Packagist, Composerin julkinen luettelo, merkitsee, että ylläpitäjät ovat pysähtyneet, mutta se ei tarkoita, että paketti katoaisi tai lakkaisi toimimasta: swiftmailer jaetaan yhä, sillä on 449 miljoonaa rekisteröityä asennusta, viimeisin julkaisu on vuodelta 2021, ja samalla sillä on kolme tunnettua haavoittuvuutta. Tämän sivuston omassa koodipohjassa, joka on Laravel 13 yhdessä Filament-hallintapaneelin kanssa, on 109 tuotantopakettia, eikä yksikään ole abandoned package — se on meidän lukumme meidän hankkeestamme, ei alan keskiarvo, koska julkaistua alan keskiarvoa ei ole missään.

Kuinka suuri työmarkkina on, ja miksi tarkkaa lukua ei kukaan sano

Kysymykseen, onko Suomesta helppo löytää ihminen, joka ottaa järjestelmän haltuun, rehellinen vastaus on, ettei PHP- tai Laravel-kehittäjistä Suomessa ole julkista tilastoa. On epäsuoria tietoja, ja ne ovat arvokkaita täsmälleen niin tarkasti kuin ne kuvataan. JetBrainsin viime vuoden PHP-kyselyssä 1 720 ihmisestä, joille PHP on pääkieli, 64 % työskentelee Laravelilla, 25 % WordPressillä ja 23 % Symfonyllä; kenttätyö tehtiin keväällä, kysely on vinoutunut JetBrainsin työkalujen käyttäjien suuntaan, minkä yritys myöntää itse, ja suurimmat vastaajaryhmät tulevat Japanista, Yhdysvalloista, Venäjältä, Kiinasta ja Ranskasta, ei Baltiasta.

Euroopan tasolla Eurostat kertoo tämän vuoden toukokuussa, että viime vuonna Euroopan unionissa työskenteli 10,45 miljoonaa tieto- ja viestintätekniikan asiantuntijaa, mikä on 5,0 % kaikista työllisistä ja 2,6 % enemmän kuin vuotta aiemmin. Suomesta saman lähteen varhaisemmassa koonnissa on toinen luku, joka ostajalle on kokonaiskasvua hyödyllisempi: vuonna 2023 Suomen yrityksistä 11,78 % etsi tai yritti palkata tällaisia asiantuntijoita, ja niistä suomalaisista yrityksistä, jotka etsivät, 43,73 % ei saanut paikkaa täytettyä.

Nämä luvut koskevat alan asiantuntijoita kokonaisuutena, ei PHP:tä, eikä niitä saa kirjoittaa uudestaan väitteeksi Laravelin työmarkkinasta Suomessa — ei meidän, eikä toimittajan, joka siteeraa niitä tarjouksessasi. Olemme itse kirjoittaneet palvelusivullamme, että haltuunottajia on helppo löytää; tätä artikkelia valmistellessa emme löytäneet lähdettä tälle väitteelle, siksi emme toista sitä tässä. Ostajan käytännön järjestys on silti toinen: ei uskoa markkinan kokoon, vaan saada koodipohja sellaiseksi, johon uusi ihminen astuu halvalla riippumatta siitä, kuinka monta sellaista ihmistä on.

Mihin me itse vedämme rajan tarjouksessa

Olemme kirjoittaneet Laravelia vuodesta 2013, jolloin sen neljäs versio ilmestyi, ja se tarkoittaa käytännössä, että olemme useaan kertaan kulkeneet juuri sen läpi, josta tämä artikkeli varoittaa — pääversion vaihdon, joka ei ole yhden päivän työ eikä onnistu muiden tehtävien välissä. Laravel-kehityksen sivullamme on hinta ja aikataulut, ja se on erillinen keskustelu; tässä artikkelissa on vain se, minkä tarjouksesta voi tarkistaa riippumatta siitä, kuka sen on kirjoittanut ja miten hyvin se on kirjoitettu.

Mitä emme väitä, on se, että kuka tahansa kehittäjä ottaisi minkä tahansa koodipohjan yhtä helposti haltuun, koska edellinen jakso sanoo päinvastaista. Mitä väitämme, on konkreettisempaa ja tarkistettavampaa: repositorio on asiakkaan ensimmäisestä päivästä, siinä on sekä riippuvuustiedosto, dokumentaatio että julkaisukonfiguraatio, ja luovutushetkellä versio on se, joka sillä hetkellä vielä saa tietoturvakorjauksia. Jos sinusta tuntuu, että valinta on itse asiassa valmiin tuotteen ja räätälöidyn järjestelmän välillä, se on toinen keskustelu, jonka olemme kirjoittaneet erikseen, ja jos kysymys koskee juuri verkkokauppaa, WooCommercen ja Laravelin vertailu vastaa tarkemmin kuin tämä artikkeli.

Käytännössä luovutuspakettiin kuuluu repositorio koko historioineen, riippuvuustiedosto tarkkoine versioineen, README käynnistysvaiheineen, julkaisukonfiguraatio ja pääsy kaikkiin tileihin, joissa järjestelmä toimii. Se on se, minkä voi luvata ja tarkistaa. Mitä luvata ei voi, on markkina: kuinka monta ihmistä Suomessa ottaa tämän työn ja millä hinnalla, ei ole meidän käsissämme eikä missään julkisessa tilastossa, siksi emme vastaa tähän kysymykseen vakuuttavalla luvulla. Ainoa, mikä tässä todella toimii ostajan hyväksi, on se, että koodipohja on tavallinen, versio on tuettu ja dokumentaatio on kirjoitettu silloin, ei siirretty luovutusviikolle.

Mitä kysyä ennen kuin allekirjoitat

Ensimmäinen kysymys koskee päivämääriä: mikä Laravelin pääversio ja mikä PHP-haara on järjestelmässä juuri luovutuspäivänä, ja milloin niiden tietoturvakorjaukset päättyvät. Vastaus on kaksi päivämäärää, molemmat voi tarkistaa kahdelta julkiselta sivulta viidessä minuutissa, ja ne pitää kirjoittaa joko sopimukseen tai ainakin kirjeenvaihtoon. Jos toimittaja nimeää version, jonka tuki päättyy ennen takuuaikaa, se ei ole kiellettyä ja on joskus jopa perusteltua, mutta silloin sen pitää olla molempien tiedossa, ja hinnassa pitää olla selvää, kuka maksaa siirtymän.

Toinen kysymys koskee tilauksia: mitkä maksulliset tuotteet — Forge, Cloud, Nova, Nightwatch, Vapor tai Envoyer — järjestelmän toimintaan tarvitaan, mitä ne yhteensä maksavat kuukaudessa ja minkä tilin päällä ne seisovat. Kolmas koskee repositoriota: mistä päivästä se on sinun, onko siinä riippuvuustiedosto ja onko automaattiseen tarkistukseen sisällytetty composer audit -komento. Neljäs on rahakysymys, joka yleensä lykätään myöhemmäksi ja löydetään sitten yllätyksenä budjetista: kuka maksaa pääversion vaihdon puolentoista vuoden päästä ja sisältyykö se ylläpitosopimukseen vai onko se uusi tilaus.

Mikään näistä neljästä kysymyksestä ei vaadi, että ymmärrät koodia, eikä yhtäkään niistä pidä ottaa epäluottamuksena toimittajaa kohtaan. Kaikki koskevat sitä, mitä tapahtuu sen jälkeen, kun hanke on valmis ja lasku maksettu, ja hyvä toimittaja vastaa niihin heti, koska tuntee nämä päivämäärät ulkoa. Jos vastaus johonkin niistä vie viikon tai muuttuu selitykseksi, miksi kysymys ei ole tärkeä, se on jo vastaus.

Nämä neljä kysymystä eivät korvaa teknistä arviota eivätkä vastaa siihen, onko tarjottu arkkitehtuuri hyvä, mutta ne poistavat suurimman osan epämiellyttävistä yllätyksistä, jotka yleensä saapuvat toisena tai kolmantena vuonna, kun alkuperäinen innostus on loppunut ja järjestelmä vain toimii. Jos sinulla on tarjous kädessä etkä ole varma, mitä siinä kirjoitetut versiot merkitsevät aikatauluillesi ja budjetillesi, kirjoita meille — vastauksen näihin neljään kysymykseen voi valmistella avaamatta koodia.