Was ist Laravel für Unternehmen, die ein System beauftragen

Was im Angebot als „PHP 8.4, Laravel 13“ steht, ist keine technische Randnotiz: Diese zwei Zeilen legen fest, wie lange das System Sicherheitsupdates erhält, was monatlich extra kostet und wie teuer die Übergabe an einen anderen Entwickler wird.

Das Angebot geht am Freitagnachmittag ein, und in seinem technischen Teil stehen zwei Zeilen, die in der Besprechung niemand laut vorliest: „PHP 8.4“ und „Laravel 13“. Was ist Laravel in diesem Angebot — und was PHP? Der Preis ist verständlich, die Frist ist verständlich, und diese zwei Zeilen wirken wie die interne Küche des Anbieters — ungefähr so wichtig wie die Frage, mit welchem Bohrer das Loch in die Wand kommt, und deshalb werden sie gewöhnlich als technische Randnotiz übergangen, für die jemand anderes zuständig ist. Die Unterschrift steht trotzdem unter dem ganzen Dokument, und genau diese zwei Zeilen legen fest, wie lange das System überhaupt noch Sicherheitsupdates erhält, was darin monatlich zusätzlich zur Entwicklungsrechnung auftaucht und wie teuer in drei Jahren die Übergabe an jemand anderen wird.

Dieser Artikel handelt nicht davon, ob PHP eine gute Sprache und Laravel ein gutes Framework ist, denn auf diese Frage antworten Entwickler unter sich, und dem Auftraggeber nützt dieses Gespräch praktisch nichts. Er handelt von vier Dingen, die der Auftraggeber selbst und ohne technisches Wissen prüfen kann: den Support-Kalender, die Lizenz, den Arbeitsmarkt und die Bedingungen der Übergabe. Alle vier sind öffentlich, drei davon sind Datumsangaben oder Geldbeträge, die vierte ist das, was man über den Markt wissen kann und was nicht, und keine hängt davon ab, wie überzeugend das Angebot geschrieben ist — deshalb lohnt es sich, sie genau in der Woche zu prüfen, in der über den Preis noch gesprochen werden kann.

Was ist das Laravel-Framework, was ist PHP — und warum das keine einzige Wahl ist

PHP ist die Programmiersprache, in der die Serverseite des Systems geschrieben ist — der Teil, der beim Anbieter oder bei Ihrem Hoster läuft und den der Nutzer nie sieht. Laravel wiederum ist ein PHP-Framework, also eine bereits in PHP geschriebene Codebasis, die löst, was sich in fast jedem Projekt wiederholt: Benutzeranmeldung, Datenbankabfragen, Queues, Dateispeicherung, den Versand von E-Mails. Im Angebot stehen sie nebeneinander wie eine einzige Wahl, tatsächlich sind es zwei getrennte Produkte, die zwei verschiedene Teams mit zwei verschiedenen Support-Kalendern pflegen, und genau deshalb lohnt es sich, sie getrennt zu lesen.

Wie verbreitet die Sprache ist, lässt sich schwerer sagen, als man erwartet. W3Techs, das regelmäßig mehr als zwanzig Millionen Websites scannt, schreibt im August dieses Jahres, dass 70,2 % aller Websites, deren serverseitige Programmiersprache dieses Werkzeug kennt, PHP nutzen. Die letzte Bedingung ist das, was gewöhnlich verschwindet, wenn die Zahl in eine Präsentation umgeschrieben wird: Es geht nicht um 70 % aller Websites der Welt, sondern um 70 % derjenigen, die dieses konkrete Werkzeug überhaupt erkennen kann, und einen Teil der Erkennung beschreibt es selbst als indirekt erschlossen — wenn die Seite WordPress ist, dann ist sie PHP.

Für den Auftraggeber nützlicher ist eine andere Zahl von derselben Seite. Unter den Websites, bei denen W3Techs auch die PHP-Version bestimmt, laufen 63,3 % auf der achten, 28,7 % auf der siebten und 7,9 % noch auf der fünften, obwohl die siebte Version schon vor vier Jahren selbst die Sicherheitsupdates verloren hat. Das heißt, etwa ein Drittel des messbaren PHP-Internets läuft heute auf Code, für den niemand mehr Sicherheitsupdates schreibt, und das ist nicht geschehen, weil die Sprache schlecht wäre oder jemand in der Entwicklung einen Fehler gemacht hätte. Es ist geschehen, weil niemand einen Versionswechsel beauftragt und bezahlt hat, und genau das ist der Teil des Risikos, den der Auftraggeber sowohl sehen als auch steuern kann.

Der PHP-Support-Kalender ist das erste Dokument, das sich zu öffnen lohnt

Die Regel der PHP-Entwicklergruppe ist kurz und öffentlich: Jeder Versionszweig erhält zwei Jahre vollen Support ab der ersten stabilen Veröffentlichung, danach noch zwei Jahre nur kritische Sicherheitsfixes, und nach vier Jahren wird er überhaupt nicht mehr gepflegt. In dieser Regel steckt eine Einzelheit, die Nacherzählungen fast immer abschneiden: Die tatsächlichen Enddaten in der Tabelle sind auf den letzten Tag des Jahres ausgerichtet, nicht auf den Jahrestag der Veröffentlichung im November, deshalb unterscheiden sich „zwei Jahre ab Erscheinen“ und das, was in der Tabelle auf php.net steht, um einen oder zwei Monate.

Praktisch heißt das Folgendes. Version 8.2 ist derzeit nur noch im Stadium „nur Sicherheitsfixes“, und ihr Support endet bereits am Ende dieses Jahres, also in etwa vier Monaten. Version 8.3 hat den vollen Support Ende des vergangenen Jahres verloren und erhält Sicherheitsupdates bis Ende 2027, also noch etwa sechzehn Monate. Version 8.4 arbeitet dieses Jahr bis zum Schluss im vollen Support und bleibt danach noch zwei Jahre im Stadium „nur Sicherheitsfixes“, die jüngste 8.5, die im November des vergangenen Jahres erschienen ist, erhält den vollen Support noch das ganze nächste Jahr und Sicherheitsupdates bis Ende 2029.

Der Support von Version 8.1 hat am letzten Tag des vergangenen Jahres End of Life erreicht, und genau dieser Fall verdient Aufmerksamkeit, wenn Sie bereits ein System haben und nicht ein Angebot. Wenn der Anbieter es vor drei Jahren auf 8.1 geschrieben hat und seitdem niemand etwas geändert hat, dann läuft es heute auf einem Zweig, für den keine Sicherheitsupdates mehr kommen, und davor warnt weder der Server noch der Browser noch das System selbst. Die Seite öffnet sich genau wie gestern, die Kunden merken nichts, und der einzige Ort, an dem man es sehen kann, ist eben diese öffentliche Tabelle, deren Öffnen weniger Zeit braucht als das Lesen der Titelseite des Angebots.

Der Laravel-Kalender ist kürzer als der PHP-Kalender

Laravel formuliert seine Politik noch kürzer: Fehlerbehebungen achtzehn Monate, Sicherheitsupdates zwei Jahre, und jedes Jahr etwa im ersten Quartal eine neue Hauptversion (Major). Ein Release mit langfristigem Support, den die Branche LTS nennt, gibt es heute nicht mehr — in den alten Versionen gab es das wirklich, in der Tabelle dieses Jahres fehlt diese Spalte aber vollständig, deshalb beschreibt ein Angebot, in dem „LTS Laravel“ steht, etwas, das derzeit niemand verkauft. Das ist ein kürzeres Versprechen, als viele Auftraggeber von einem Framework erwarten, auf dem das System für die nächsten fünf Jahre gebaut werden soll.

In Zahlen, nach der Laravel-Dokumentation selbst, sieht die Reihenfolge so aus. Laravel 13 ist im März dieses Jahres erschienen, Fehlerbehebungen erhält es bis zum dritten Quartal des nächsten Jahres, Sicherheitsupdates bis zum 17. März 2028. Das Fenster der Fehlerbehebungen von Laravel 12 schloss Mitte August dieses Jahres, das heißt siebzehn Tage bevor diese Zeilen geschrieben wurden, und seine Sicherheitsupdates enden im Februar des nächsten Jahres. Laravel 11 hat im Frühjahr dieses Jahres End of Life erreicht, und ein System, das heute auf der elften Version läuft, läuft damit bereits ohne Sicherheitsupdates, so gut es von außen auch aussehen mag.

Laravel 13 nennt das Ende der Fehlerbehebungen als Quartal, nicht als konkretes Datum. Das ist die Ungenauigkeit von Laravels eigener Formulierung, und sie ist kein Problem, solange man sie genau so abschreibt, wie sie dort steht; das Problem beginnt in dem Moment, in dem Anbieter oder Auftraggeber sie auf einen konkreten Tag runden und danach das Budget nach einer Zahl planen, die in der Quelle nicht vorkommt. Eine weitere Grenze, die man kennen muss, bevor die Version gewählt wird: Laravel 13 verlangt mindestens PHP 8.3, deshalb lässt sich ein System auf der dreizehnten Version nicht auf 8.2 belassen, selbst wenn 8.2 selbst noch eine Weile Sicherheitsupdates erhielte.

Was beide Kalender zusammen für das System bedeuten, das Sie heute beauftragen

Wird das System auf Laravel 13 zusammen mit PHP 8.4 oder 8.5 übergeben, dann ist das erste Datum, an dem sich zwingend etwas bewegen muss, der März 2028, wenn die Laravel-Sicherheitsupdates enden, und das ist etwa achtzehneinhalb Monate von heute. PHP ist in dieser Kombination keine Grenze, weil beide Zweige Sicherheitsupdates länger erhalten als das Framework, deshalb altert zuerst Laravel, nicht die Sprache. Das ist auch die einzige ehrliche Art, die Frage „wie lange steht dieses System ohne zusätzliche Investition“ zu beantworten — nicht mit einem Gefühl, sondern mit dem früheren der zwei öffentlichen Daten.

Wird dasselbe System auf Laravel 13, aber PHP 8.3 übergeben, dann kehrt sich die Reihenfolge um und die erste Frist kommt in etwa sechzehn Monaten, wenn die Sicherheitsupdates dieses PHP-Zweigs enden. Schreibt der Anbieter auf Laravel 12, für ein bestehendes Projekt nach wie vor eine völlig normale Wahl, dann enden die Sicherheitsupdates im Februar des nächsten Jahres, und das Leben des neuen Systems beginnt mit sechs Monaten bis zum ersten verpflichtenden Versionswechsel. Die Differenz zwischen der ersten und der dritten Variante ist ein Jahr, das sich in einem Gespräch vor dem Vertrag verdienen lässt und das man nach der Unterschrift nicht mehr kaufen kann.

Zwei Fehler in dieser Rechnung sind so verbreitet, dass sie sich gesondert zu nennen lohnen. Der erste ist, vollen Support mit dem Stadium „nur Sicherheitsfixes“ zu verwechseln, deshalb lohnt es sich beim Satz „der Support von PHP 8.4 endet am Jahresende“ zu fragen, welches der zwei Fenster gemeint ist: Die Behebung gewöhnlicher Fehler endet, die Sicherheitsupdates kommen noch zwei Jahre. Der zweite ist, Laravels eigenem Satz zu glauben, der Wechsel auf eine neue Hauptversion dauere gewöhnlich einen Tag oder weniger; das ist ein von Entwicklern formuliertes Ziel, kein gemessener Durchschnitt, und als Frist lässt es sich in einen Vertrag nicht schreiben.

Die Lizenz kostet null, und das gilt nur für Sprache und Framework

Das Laravel-Framework wird unter der MIT-Lizenz verbreitet, einer der einfachsten Open-Source-Lizenzen, und sie erlaubt, den Code zu nutzen, zu ändern und weiterzuverkaufen, verlangt aber, den Urheberrechtshinweis zu behalten. Bei PHP ist es etwas komplizierter, und diese Komplikation ist gerade jetzt aktuell, weil die Lizenz wechselt: Versionen bis einschließlich 8.5 erscheinen unter der PHP-Lizenz in der Fassung 3.01, ab 8.6 unter der vierten Fassung, die php.net selbst als „Modified BSD“-Lizenz beschreibt und die praktisch mit BSD-3-Clause zusammenfällt. In keiner dieser Varianten ist eine Gebühr vorgesehen.

Das heißt, für die Sprache selbst und das Framework selbst zahlt das Unternehmen weder pro Nutzer noch pro Prozessorkern noch pro Jahr, und diese Null ist keine Aktion, die irgendwann ausläuft. Zum Vergleich eignet sich das Modell, das Microsoft SQL Server verwendet: Dort wird entweder nach Kernlizenzen oder nach Server zusammen mit Clientzugriffslizenzen (CALs) lizenziert, die Standard-Edition ist auf das kleinere von vier Prozessorsockeln oder vierundzwanzig Kernen begrenzt, die kostenlose Express-Edition auf einen Sockel oder vier Kerne. Genaue Beträge schreiben wir hier nicht, weil die Preisliste sich ändert und man sie bei Microsoft lesen muss; für den Auftraggeber vergleichbar ist das Modell, nicht die Zahl — das eine Produkt rechnet nach der Menge an Hardware, das andere rechnet überhaupt nicht.

Für die Beschaffung hat das zwei Folgen, die sich sofort aufzuschreiben lohnen. Die erste ist angenehm: Es gibt kein Lizenzaudit, keine jährliche Neuberechnung für Nutzer, die im Laufe des Jahres dazugekommen sind, und keine Situation, in der der Softwareanbieter nach drei Jahren mit einer Rechnung für ein überschrittenes Limit kommt. Die zweite ist die, die man zu vergessen pflegt: Open Source hebt die Abhängigkeit vom Eigentümer des Frameworks auf, hebt aber Abhängigkeit als solche nicht auf. Die Abhängigkeit wandert an andere Stellen — zur Agentur, die als einzige weiß, wie das Projekt zusammengebaut ist, zu den kostenpflichtigen Produkten, die neben dem Code stehen, zu einem abandoned package, das niemand mehr pflegt, und zu einer Hauptversion, deren Support geendet hat. Diese vier Stellen sind es, die der Auftraggeber prüfen muss, weil die Lizenzzeile dazu nichts sagt.

Wo Laravel trotzdem Kosten verursacht: Produkte, die nicht das Framework sind

Dasselbe Team, das Laravel pflegt, verkauft auch mehrere Produkte, und im Angebot stehen sie oft in einer Zeile mit dem Framework, als wären sie ein Bestandteil. Laravel trennt diese zwei Dinge auf der eigenen Website selbst: Pakete — Horizon, Telescope, Pulse, Scout, Sanctum, Octane und andere — stehen unter MIT-Lizenz und sind kostenlos, Produkte sind Cloud, Forge, Nightwatch, Vapor und Nova, und die kosten jeden Monat oder jedes Jahr Geld. Envoyer wird nach wie vor gesondert verkauft. Keines dieser Produkte ist nötig, damit ein Laravel-System läuft, und genau deshalb ist ihre Anwesenheit im Angebot eine Wahl, keine Notwendigkeit.

Die Preise sahen im August dieses Jahres so aus. Forge, mit dem man Server verwaltet, kostet 12, 19 oder 39 US-Dollar im Monat, je nach Tarif. Nova, der Administrationsbereich, kostet 99 US-Dollar einmalig für ein Projekt einschließlich der Jahresupdates und 79 US-Dollar im Jahr für die Fortsetzung der Updates, die unbegrenzte Lizenz kostet entsprechend 299 und 249 US-Dollar, und sie deckt Ihre eigenen Projekte, nicht die Projekte Ihrer Kunden. Nightwatch, das Systemereignisse sammelt, beginnt mit einem kostenlosen Tarif und steigt auf 20, 60 und 300 US-Dollar im Monat, zuzüglich eines Aufpreises für Ereignisse über dem enthaltenen Limit. Laravel Cloud beginnt bei 5 US-Dollar im Monat plus Verbrauch, und Envoyer kostet von 10 bis 50 US-Dollar im Monat.

Die Frage an den Auftraggeber ist nicht, ob diese Produkte gut sind, denn in der Regel sind sie gut und sparen dem Entwickler mehrere Tage im Monat. Die Frage ist, welche davon im genannten Preis enthalten sind, auf wessen Konto sie registriert sind und was mit ihnen geschieht, wenn Sie in zwei Jahren den Anbieter wechseln. Ein Abonnement, das auf dem Konto der Agentur steht und im Vertrag nicht erwähnt ist, ist genau die Abhängigkeit, die die MIT-Lizenz nicht aufhebt, weil MIT über den Code spricht, nicht über das Konto, in dem er betrieben und überwacht wird.

Was passiert, wenn der Entwickler verschwindet

„Den Code kann jeder Laravel-Entwickler übernehmen“ ist ein Satz, der juristisch stimmt und praktisch unvollständig ist, und wir haben ihn auch selbst geschrieben. Die MIT-Lizenz erlaubt wirklich einem anderen Unternehmen, mit diesem Code zu arbeiten, ohne uns oder das Laravel-Team um Erlaubnis zu fragen. Ob der neue Entwickler schon in der ersten Woche nützlich ist, entscheiden vier ganz andere Dinge, und alle vier lassen sich prüfen, bevor der Vertrag überhaupt unterschrieben ist.

Das erste ist die Hauptversion. Eine Übergabe von Laravel 11 an ein neues Team ist keine Übergabe, sondern ein Projekt zum Versionswechsel, weil dort bereits End of Life erreicht ist und die erste Arbeit nicht neue Funktionalität sein wird, sondern der versäumte Wechsel auf ein unterstütztes Release. Das zweite ist der Abstand zur Konventionen des Frameworks: Die Laravel-Dokumentation nimmt eine bestimmte Ordner- und Klassenstruktur an, und je weiter das Projekt davon weggegangen ist, desto teurer wird die Einarbeitung. Eine Zahl gibt es hier nicht und in keiner Quelle eine, es gibt nur die Richtung; der Auftraggeber kann aber ganz konkret fragen, was im Projekt gegen die Voreinstellung geschrieben ist und welcher Bedarf das verlangt hat.

Das dritte sind die Abhängigkeiten, also die fremden Pakete, auf die das System sich stützt. Composer, der sie in der Laravel-Welt verwaltet, speichert eine Datei mit den genauen Versionen, und die ist genau deshalb wertvoll, weil ein neuer Entwickler genau dasselbe installieren kann, was der vorherige gesehen hat, nicht das, was heute das neueste ist. Was diese Datei nicht garantiert, sind zwei Dinge: dass das Paket weiterhin zum Download bereitsteht, und dass darin seither keine Sicherheitslücke gefunden wurde. Der Befehl composer audit zeigt beides in einem Aufruf, und das ist die kürzeste Frageform, die man über eine fremde Codebasis überhaupt stellen kann.

Das vierte ist ein abandoned package, und hier führen die Wörter in die Irre. Packagist, der öffentliche Katalog von Composer, markiert, dass die Maintainer aufgehört haben, das heißt aber nicht, dass das Paket verschwindet oder aufhört zu funktionieren: swiftmailer wird weiterhin ausgeliefert, es hat 449 Millionen registrierte Installationen, der letzte Release stammt von 2021, und gleichzeitig hat es drei bekannte Sicherheitslücken. In unserer eigenen Codebasis dieser Website, Laravel 13 zusammen mit dem Filament-Administrationsbereich, sind 109 Produktionspakete und kein einziges abandoned package — das ist unsere Zahl für unser Projekt, kein Branchendurchschnitt, denn einen veröffentlichten Branchendurchschnitt gibt es nirgendwo.

Wie groß der Arbeitsmarkt ist — und warum niemand eine genaue Zahl nennen wird

Auf die Frage, ob man in Deutschland leicht jemanden findet, der das System übernimmt, ist die ehrliche Antwort, dass es keine öffentliche Statistik über PHP- oder Laravel-Entwickler in Deutschland gibt. Es gibt indirekte Daten, und die sind genau so viel wert, wie präzise man sie beschreibt. In der PHP-Umfrage von JetBrains aus dem vergangenen Jahr arbeiten unter 1.720 Menschen, für die PHP die Hauptsprache ist, 64 % mit Laravel, 25 % mit WordPress und 23 % mit Symfony; die Feldarbeit fand im Frühjahr statt, die Umfrage ist zugunsten der Nutzer von JetBrains-Werkzeugen verzerrt, was das Unternehmen selbst einräumt, und die größten Gruppen der Befragten kommen aus Japan, den USA, Russland, China und Frankreich, nicht aus dem Baltikum.

Auf europäischer Ebene berichtet Eurostat im Mai dieses Jahres, dass im vergangenen Jahr in der Europäischen Union 10,45 Millionen Spezialisten der Informations- und Kommunikationstechnik arbeiteten, das sind 5,0 % aller Beschäftigten und 2,6 % mehr als ein Jahr zuvor. Für Deutschland steht in einer früheren Zusammenstellung derselben Quelle eine andere Zahl, die dem Auftraggeber nützlicher ist als das gesamte Wachstum: 2023 suchten oder versuchten 12,03 % der deutschen Unternehmen, solche Spezialisten einzustellen, und unter den deutschen Unternehmen, die suchten, konnten 72,41 % die Stelle nicht besetzen — einer der höchsten Werte in der ganzen Union.

Diese Zahlen betreffen Branchenspezialisten insgesamt, nicht PHP, und man darf sie nicht zu einer Behauptung über den Laravel-Arbeitsmarkt in Deutschland umschreiben — weder wir noch ein Anbieter, der sie in Ihrem Angebot zitiert. Wir selbst haben auf unserer Leistungsseite geschrieben, dass Entwickler, die die Arbeit übernehmen, leicht zu finden sind; bei der Vorbereitung dieses Artikels haben wir für diese Behauptung keine Quelle gefunden, deshalb wiederholen wir sie hier nicht. Die praktische Reihenfolge für den Auftraggeber ist ohnehin eine andere: nicht an die Größe des Marktes zu glauben, sondern zu erreichen, dass die Codebasis eine ist, in die ein neuer Mensch günstig einsteigt, unabhängig davon, wie viele solche Menschen es gibt.

Wo wir selbst im Angebot die Grenze ziehen

Wir schreiben auf Laravel seit 2013, als die vierte Version erschien, und das heißt praktisch, dass wir mehrfach genau durch das gegangen sind, wovor dieser Artikel warnt — den Wechsel der Hauptversion, der keine Arbeit eines Tages ist und den man nicht zwischen anderen Aufgaben erledigen kann. Auf unserer Seite zur Laravel-Entwicklung stehen Preis und Fristen, und das ist ein gesondertes Gespräch; in diesem Artikel steht nur das, was sich in einem Angebot prüfen lässt, unabhängig davon, wer es geschrieben hat und wie gut es geschrieben ist.

Was wir nicht behaupten, ist, dass jeder Entwickler jede Codebasis gleich leicht übernimmt, denn der vorige Abschnitt sagt das Gegenteil. Was wir behaupten, ist konkreter und prüfbarer: Das Repository gehört dem Kunden vom ersten Tag, darin liegen die Datei der Abhängigkeiten, die Dokumentation und die Deployment-Konfiguration, und im Moment der Übergabe ist die Version die, die zu diesem Zeitpunkt noch Sicherheitsupdates erhält. Wenn Sie den Eindruck haben, die Wahl sei in Wahrheit die zwischen einem Standardprodukt und Individualsoftware, dann ist das ein anderes Gespräch, das wir gesondert aufgeschrieben haben, und wenn die Frage genau den Onlineshop betrifft, dann antwortet der Vergleich von WooCommerce und Laravel genauer als dieser Artikel.

Zum praktischen Übergabepaket gehören das Repository mit der gesamten Geschichte, die Datei der Abhängigkeiten mit den genauen Versionen, ein README mit den Startschritten, die Deployment-Konfiguration und der Zugang zu allen Konten, in denen das System läuft. Das ist das, was man versprechen und prüfen kann. Was man nicht versprechen kann, ist der Markt: Wie viele Menschen in Deutschland diese Arbeit übernehmen und zu welchem Preis, liegt nicht in unserer Hand und in keiner öffentlichen Statistik, deshalb beantworten wir diese Frage nicht mit einer überzeugenden Zahl. Das Einzige, was hier wirklich zugunsten des Auftraggebers arbeitet, ist, dass die Codebasis gewöhnlich ist, die Version unterstützt wird und die Dokumentation in diesem Moment geschrieben ist, nicht auf die Woche der Übergabe verschoben.

Was Sie fragen sollten, bevor Sie unterschreiben

Die erste Frage betrifft die Daten: Welche Laravel-Hauptversion und welcher PHP-Zweig am Tag der Übergabe im System sein werden, und wann deren Sicherheitsupdates enden. Die Antwort sind zwei Daten, beide lassen sich auf zwei öffentlichen Seiten in fünf Minuten prüfen, und sie gehören entweder in den Vertrag oder wenigstens in den Schriftwechsel. Nennt der Anbieter eine Version, deren Support früher endet als die Gewährleistungsfrist, ist das nicht verboten und manchmal sogar begründet, aber dann müssen es beide Seiten wissen, und im Preis muss klar sein, wer den Wechsel bezahlt.

Die zweite Frage betrifft die Abonnements: Welche kostenpflichtigen Produkte — Forge, Cloud, Nova, Nightwatch, Vapor oder Envoyer — für den Betrieb des Systems nötig sind, was sie zusammen im Monat kosten und auf wessen Konto sie stehen. Die dritte betrifft das Repository: Ab welchem Tag es Ihres ist, ob die Datei der Abhängigkeiten darin liegt und ob in der automatischen Prüfung der Befehl composer audit enthalten ist. Die vierte ist die Geldfrage, die man gewöhnlich auf später verschiebt und dann überrascht im Budget findet: Wer nach eineinhalb Jahren den Wechsel der Hauptversion bezahlt und ob das in den Wartungsvertrag fällt oder ein neuer Auftrag wird.

Keine dieser vier Fragen verlangt, dass Sie den Code verstehen, und keine ist als Misstrauen gegenüber dem Anbieter zu lesen. Alle vier handeln davon, was geschieht, nachdem das Projekt fertig und die Rechnung bezahlt ist, und ein guter Anbieter antwortet darauf sofort, weil er diese Daten selbst auswendig kennt. Wenn die Antwort auf eine davon eine Woche braucht oder sich in eine Erklärung verwandelt, warum die Frage unwichtig sei, dann ist das bereits die Antwort.

Diese vier Fragen ersetzen nicht die technische Bewertung und beantworten nicht, ob die angebotene Architektur gut ist, aber sie räumen den größten Teil der unangenehmen Überraschungen aus, die gewöhnlich im zweiten oder dritten Jahr eintreffen, wenn die anfängliche Begeisterung vorbei ist und das System einfach läuft. Wenn Sie ein Angebot in der Hand haben und nicht sicher sind, was die darin geschriebenen Versionen für Ihre Fristen und Ihr Budget bedeuten, schreiben Sie uns — eine Antwort auf diese vier Fragen lässt sich vorbereiten, ohne den Code zu öffnen.