|
18.09.2026 10:27 Uhr |
Alexander Lichter arbeitet als Developer Relations Engineer bei VoidZero, der Firma des Vue- und Vite-Erfinders Evan You. Im Interview mit Timo Zander spricht er über gescheiterte Geschäftsmodelle, die Akquisition durch Cloudflare und die Pläne für die Zukunft.
Auf der Vue.js Amsterdam 2025 hat Evan das dann auch in einem seiner Talks angekündigt. Nach etwas Papierkram war ich offiziell Teil von VoidZero. Damals bestand das Team aus rund zwölf Leuten. Alle waren supertalentiert und motiviert und haben eigenständig an ihren Projekten gearbeitet. Es gab keine Anweisungen von oben, jeder wusste genau, was er zu tun hatte, und das ist auch heute noch so. Alle, die Open-Source-Projekte betreuen, sind dort die Experten und pflegen ihre Roadmaps. Klar, man spricht sich untereinander ab und sucht nach Synergien. Abseits davon ist jeder in seiner eigenen Welt, und es ist faszinierend, so viel Talent auf einem Fleck zu sehen.
Für mich war es genauso: Ich weiß, wie Developer Relations funktioniert und wie ich Social Media bespielen muss – und dann macht man einfach.
Agentische KI bringt eine neue Dynamik in die Webentwicklung. Erfahre am 22. Oktober 2026 auf der Online-Konferenz enterJS Agentic, wie du mit Agentic AI moderne JavaScript-/TypeScript-Projekte entwickelst, wie du Kosten vs. Performance abwägst und wobei dir KI wirklich weiterhilft. Frühbuchertickets sind im Online-Ticketshop erhältlich.
Ich persönlich habe meine Rolle immer als Brücke zwischen zwei Welten gesehen: Einerseits geht es darum, den normalen Webentwickler für die Entwicklungen unseres Teams zu begeistern. Andererseits muss man verstehen, wie die Entwickler unser Tooling nutzen, wo die Probleme liegen, und dieses Feedback ins Team zurücktragen.
Mir war es immer wichtig, den Prozess Ende-zu-Ende zu begleiten. Wenn jemand ein Problem hatte, habe ich mir das zunächst angeschaut, um herauszufinden: Ist es ein bekanntes Problem? Ist es eine Kleinigkeit, die ich vielleicht sogar selbst fixen kann? Oder arbeitet bereits jemand im Team daran? Das Tolle ist, dass ich anschließend direkt zum Nutzer zurückgehen kann: „Probier mal bitte folgende Alpha-Version aus. Behebt das dein Problem?“ So bekommen wir schnell Feedback.
In meiner Stelle geht es also nicht nur um Content- und Community-Arbeit, sondern auch darum, zu zeigen, dass wir auf Probleme reagieren und diese ernst nehmen. Das machen natürlich unsere Engineers genauso, aber je mehr Arbeit ich ihnen abnehmen kann, ohne sie aus ihrem Flow zu reißen, desto besser.
Gerade bei Developer Tooling ist das aus meiner Sicht auch die beste Auslegung der Developer-Relations-Rolle. Man sollte auf jeden Fall ein guter Engineer sein, denn abseits von Social Media und Content Creation, was einfacher zu lernen ist, muss man eben auch die Sicht der Entwickler verstehen.
Wir wollten Vite+ auch selbst haben, denn wir wussten, dass wir damit echte Probleme beheben: den riesigen Aufwand beim Erstellen jedes neuen Projektes und die große Heterogenität im Tooling, wenn man in verschiedenen Codebasen gleichzeitig arbeitet. Um damit Geld zu verdienen, haben wir zunächst viele Gespräche mit Unternehmen geführt. Dabei sind einige Dinge aufgekommen, die der Kommerzialisierung von Vite+ Steine in den Weg gelegt haben.
Das größte Problem war KI, denn Vite+ sollte in seinen Kernbestandteilen immer quelloffen sein. Was hindert also eine Firma daran, einen Agenten auf unsere Open-Source-Projekte anzusetzen und die Funktionen von Vite+ selbst intern nachzubauen? Vor dem letzten Herbst, bevor die Modelle so gut geworden sind, war das noch nicht so eine große Sorge.
Das zweite Problem – damit hatten wir auch schon eingangs gerechnet – ist, dass Unternehmen sehr ungern für Dev Tooling bezahlen. Produktivitäts- und Zeitgewinne sind dort schwierig zu bemessen. Verglichen mit einer Deployment-Plattform, bei der sich klar sagen lässt, wie viel schneller man dadurch deployen kann, ist das weniger greifbar – gerade für Personen, die nicht so technisch involviert sind. Gleichzeitig wollten wir keine große B2B-Enterprise-Sales-Pipeline aufbauen und dafür Leute einstellen. Unsere Philosophie war eigentlich immer, alles so Self-Service-basiert wie möglich zu machen.
Außerdem gab es immer den Konflikt, welche Features Open Source werden sollen und was Vite+-exklusiv sein soll. Wir hatten intern häufig lange Diskussionen über Features, die besonders spannend für Unternehmen sind, aber trotzdem auch einfach Teil von Vite oder Rolldown hätten sein können.
Das Endergebnis der Reise war, dass wir uns eingestanden haben, dass dieser Weg der Finanzierung trotz unserer Versuche nicht wirklich funktioniert. Deshalb haben wir Vite+ im März 2026 Open Source veröffentlicht.
Das macht für uns auch die Vision, dass Vite+ ein De-facto-Standard für JavaScript-Tooling werden kann, deutlich realistischer. Nach der Vorstellung gab es besonders viel Kritik daran, dass Kommerzialisierung und Standardisierung schwierig zu vereinbaren sind, was definitiv stimmt. Jetzt haben wir nur das Problem, dass der Name Vite+ suggeriert, dass es ein Kaufprodukt sei und dass man zwingend Vite zur Nutzung brauche. Dabei kann man es genauso für seine Node.js-CLI oder eine Next.js-Anwendung ganz ohne Vite nutzen.
Gebaut haben wir alles auf Cloudflare-Primitives wie Workers for Platforms, damit wir möglichst wenig selbst bauen mussten. Da stellt sich natürlich die Frage: Was ist der Vorteil, wenn Cloudflare selbst schon viele Features hat?
Void hat die gesamte Infrastruktur auf Code-Ebene komplett wegabstrahiert. Wenn du eine Datenbank brauchst, nutzt du dafür einfach das Void SDK, und die Plattform setzt die Infrastruktur automatisch auf. Du brauchst außerdem keinen Cloudflare-Account, alles läuft über Void. Zusätzlich gibt es direkte Integrationen in diverse Frameworks, aber der Fokus lag trotzdem klar immer auf Vite als gemeinsamem Nenner.
Alles war extrem auf Developer Experience fokussiert. VoidZero achtet bei allen Toolings immer auf die zwei großen Themen Performance und Developer Experience, das heißt, wir sind Experten in diesen Dingen. Viele andere Plattformen versuchen genau das auch, einige wie Vercel schaffen es sogar sehr gut. Unser Ziel war es daher, eine sogar noch bessere DX als bei Vercel zu schaffen – mit der Besonderheit, dass das auch im lokalen Dev-Modus einfach mit allen konfigurierten Primitives funktioniert.
Bei NuxtHub brauchte man beispielsweise immer sowohl einen Cloudflare- als auch einen NuxtHub-Account, was für Reibung gesorgt hat. Daher war für uns klar, dass wir alles über einen einzigen Void-Account abwickeln. Zudem wollten wir Void frameworkagnostisch bauen und uns auf Vite fokussieren, statt auf einzelne Ausprägungen. Das macht es auch einfacher, bestehende Vite-basierte Anwendungen auf Void zu überführen.
Void hat dank seines SDK sogar die Möglichkeit, Features wie serverseitiges Rendering völlig ohne Framework zu nutzen und der eigenen Anwendung eine Art Insel-Architektur zu verpassen. Wir haben also von „Ich hoste nur meine statische Anwendung auf Void“ bis hin zu „Mein gesamter Applikationscode basiert auf Void-Features“ eine große Bandbreite an Möglichkeiten, die fließend ineinander übergehen.
Bei NuxtHub war es dagegen ein stärkeres Opt-in, das man bewusst wählen musste.
Als ich es das erste Mal ausprobiert habe, gab es natürlich noch einige Dinge, die etwas fummelig waren, so wie es bei frühen Versionen eben meist ist. Aber bei Dingen, die ich nutze und gern mag, ist es meine Natur, auch dort beizutragen. Also habe ich direkt losgelegt.
Zum Beispiel habe ich gemerkt, dass das Handling von Umgebungsvariablen nicht so toll war. Ich wollte eine Lösung, die frameworkübergreifend ist, auch mit Secrets gut klarkommt und sowohl lokal als auch im Deployment funktioniert. Eine andere Sache, an der ich mitgearbeitet habe, war die Einführung der Cloudflare-E-Mail-Primitives, also sowohl Versand als auch Empfang von E-Mails, basierend auf dem Cloudflare-E-Mail-Routing-Feature.
Schlussendlich haben wir nur eine Wrangler-Config generiert, die dann alle Features korrekt konfiguriert. Aber das so zu gestalten, dass die Developer Experience gut ist, war eine echte Herausforderung. Alle Erfahrungen, die wir gesammelt haben und bei denen Dinge komplex oder unintuitiv waren, können wir jetzt mitnehmen und zu einem gewissen Maß bei Cloudflare selbst einbringen. Das Cloudflare-Team hatte sich unsere Features ja auch im Detail angesehen und war begeistert.
Die Annäherung hat aber nicht Jahre gedauert. Schon während wir Void gebaut haben, haben wir es regelmäßig Leuten gezeigt, auch dem Workers-for-Platforms-Team, um zu kommunizieren, welchen Problemen wir dort begegnet sind.
Vite zum Beispiel verfolgt seit jeher ein Multi-Stakeholder-Prinzip. Das Team besteht aus unterschiedlichsten Leuten, die bei verschiedenen Tech-Unternehmen arbeiten oder komplett unabhängig als Freelancer tätig sind. Zusätzlich werden dem Team von Netlify, Vercel und Cloudflare Entwickler zur Seite gestellt, die die jeweilige Unternehmensperspektive repräsentieren. Dieser heterogene Mix sorgt dafür, dass Vite auch weiterhin plattformagnostisch bleiben kann.
Ich persönlich bin bisher sehr glücklich mit Cloudflare. Zum einen beweist Cloudflare durch seinen mit einer Million US-Dollar dotierten Beitrag zum Ecosystem Fund, der Contributors außerhalb von VoidZero und Cloudflare finanziert, wie ernst es dem Unternehmen mit Open Source ist. So eine Finanzierung erlaubt es einigen Open-Source-Maintainern, sich vielleicht sogar dediziert einen Tag dafür freizunehmen, statt die gesamte Arbeit neben ihrem Hauptjob machen zu müssen. Das ist auch eine Möglichkeit, die riesige Leistung der Beteiligten anzuerkennen.
Zudem müssen wir dank Cloudflare jetzt nicht länger darüber nachdenken, wie wir VoidZero nachhaltig finanzieren, sondern können einfach an den Projekten bauen, die wir lieben, was super für das gesamte Ökosystem ist. Cloudflare ist ein etabliertes Unternehmen, das selbst nicht mehr von Venture Capital abhängig ist.
Bei solchen Akquisitionen malen sich Anwender schnell Horrorszenarien aus, zum Beispiel „Was passiert, wenn das Funding ausläuft?“ oder Rugpulls wie bei Redis, wo auf einmal die Lizenz geändert wurde. Mit Cloudflare denke ich persönlich – und meinem Vernehmen nach auch die Community –, dass so etwas am unwahrscheinlichsten beziehungsweise ausgeschlossen ist. Gerade bei einem Projekt wie Vite geht dies de facto auch gar nicht. Aber auch bei anderen Projekten im Stack – Vitest, Rolldown und so weiter – haben wir Outside Contributors, die mit Cloudflare nichts zu tun haben. Daher bin ich sehr zuversichtlich.
Cloudflare wird sich als guter Open-Source-Software-Steward auszeichnen, indem es seine Projekte langfristig offen weiterentwickelt, die Community einbindet und so effektiv dem gesamten Ökosystem hilft.
Ich kannte dank meiner bisherigen DevRel-Tätigkeiten und von Konferenzen schon einige Entwickler bei Cloudflare, mit denen ich viel gesprochen habe und die auch viel Positives erzählt haben.
Als Marke bleibt VoidZero aber bestehen. Die Personen im Ökosystem kennen den Namen und verbinden gewisse Dinge damit. Da wäre es jetzt Quatsch, alles in Cloudflare umzubenennen.
Dank Cloudflare haben wir aber jetzt viel mehr Input dazu, wie unsere Tools genutzt werden, besonders weil Cloudflare viele kleine Projekte hat und nicht die eine Mega-Codebasis. Das erlaubt uns auch, bei Vite+ Dinge zu testen, wie etwa Standardisierung innerhalb eines großen Unternehmens mit zig Projekten. Es ist spannend zu sehen, wie Leute, die echte Dev-Tool-Nerds sind, mit unseren Tools interagieren, verglichen mit jenen, die JavaScript eher leidenschaftslos schreiben. Wir lernen viel darüber, wie wir die Ergonomie der Tools verbessern können und welche Probleme eher in größeren Unternehmen als in kleineren Projekten auftreten.
Natürlich waren wir auch vorher oft im Austausch mit großen Unternehmen, aber wenn man so hautnah involviert ist, ist die Zusammenarbeit viel einfacher. Es ist leichter, Leute einfach mal anzuschreiben, besonders weil man die Reproduktion bei Problemen komplett sehen kann. Bei GitHub Issues sind diese sonst meistens beschnitten, um alle Firmeninterna zu entfernen, sodass es wirklich schwierig ist, zu verstehen, wie diese spezifische Konstellation zustande kam.
Auch können wir Cloudflare-intern Toolmigrationen erproben, zum Beispiel eine Migration von ESLint auf Oxlint innerhalb eines Teams. So sehen wir, wie die Entwickler reagieren, wo Probleme auftreten oder wo der Migration Guide vielleicht Lücken hat. Das hat echte Vorteile für alle: Die Teams sind happy, weil ihr Tooling schneller läuft, und wenn die Build-Zeit zum Beispiel eine Minute kürzer ist und man mehrere Tausend Pull Requests am Tag hat, schlägt sich das auch auf die Kosten nieder.
Abseits davon gibt es einige Wege, die wir gerade erkunden, zu denen ich aber erst zu gegebener Zeit etwas erzählen kann.
Abseits davon ist Evan You seit vielen Jahren eine Größe in der Entwicklerwelt. Hätte er einfach nur für sich und sein Team eine Stelle in einem Unternehmen finden wollen, wäre dies deutlich einfacher gegangen. Auch war Evan selbst seit Jahren nicht mehr im Angestelltenverhältnis, sondern hat als unabhängiger Open-Source-Entwickler gelebt.
Unser erklärtes Ziel ist es seit jeher, eine Unified Toolchain für JavaScript zu bauen, die auch überleben sollte, wenn es VoidZero nicht mehr gibt. Wir haben also immer einen großen Fokus auf unsere Vision und das Beste für das Ökosystem gelegt, nicht auf unseren eigenen Vorteil.
Andere Ökosysteme wie Rust und Go haben ihr Tooling direkt mit eingebaut, und in JavaScript haben wir so viel Wildwuchs, dass es Material für Witze ist. Genau das wollen wir eben verändern, auch wenn wir nicht die Ersten sind, die das versuchen. Doch scheinen wir bislang die Ersten zu sein, die eine Chance haben, nicht nur die Tools erfolgreich zu bauen, sondern auch dafür zu sorgen, dass sie entsprechend angenommen werden.
Es gibt aber auch noch unzählige Dinge innerhalb von Vite+ zu erledigen, denn JavaScript-Projekte sind stark unterschiedlich. Zum Beispiel fehlt es Oxlint immer noch an Template-Linting für Svelte, Vue, Astro und Co.
Wir sprechen mit Leuten aus dem TC39-Komitee, mit Node-Entwicklern oder mit Kolleginnen und Kollegen bei Cloudflare über Themen, die sie bewegen, und darüber, was wir einbauen sollten. Langweilig wird uns definitiv nicht.
Natürlich bekommen wir viele PRs in verschiedensten Qualitätsstufen. Das variiert stark nach Projekt, je nach dessen Komplexität und wie viel Kontext man benötigt, um dort sinnvoll beizutragen. Es ermöglicht aber auch viele coole Dinge. Oft bekommen wir Issues ohne eine Reproduktion, weil der Autor sagt, dass es in einem privaten Firmenprojekt aufgetreten ist. Gerade das ist ein super Use Case: Mithilfe eines LLM kann man den Fehler extrahieren und daraus eine veröffentlichbare Version machen.
Code ist heutzutage günstig zu produzieren. Es ist daher umso wichtiger, gute Issues mit einer Reproduction zu erstellen. Token zu verbrennen, um aus dem Issue einen PR zu bauen, der das Problem fixt, können wir genauso selbst. Die Leute können sich diesen Aufwand also sparen und ihn lieber in eine perfekte Fehlerbeschreibung investieren.
Pull Requests sind toll, wenn Leute tiefer eingestiegen sind und das Gefühl haben, dass sie genug Kontext haben, um den Code wirklich zu verstehen und zu beurteilen. Auch kleine Sachen wie Docs-Anpassungen sind super hilfreich, dafür braucht es kein Issue.
Aber wenn Entwickler PRs wie „Ich habe hier mal eben vollen CSS-Support in Oxlint eingebaut“ mit 15.000 Zeilen erstellen und sich dann beschweren, dass wir das verständlicherweise nicht mergen, ist das einfach frustrierend für uns. Wir können das überhaupt nicht maintainen. Gerade weil Code günstig ist, muss die Architektur umso sauberer und klarer sein.
Wir freuen uns immer über neue Mitwirkende, aber besonders bei größeren Änderungen sollte der erste Schritt immer sein, dass man darüber spricht.
Oxlint ist vergleichsweise einfach für den Einstieg, da haben wir auch viele markierte „Good First Issues“. Bei Vite sind wir durch die Größe und den Impact meist etwas vorsichtiger bei Änderungen. Bei Vite+ hingegen gibt es noch viel zu tun, da sind wir noch in einer früheren Phase.
Aus meiner Sicht ist der beste Weg ohnehin: Ich nutze etwas, merke, dass irgendetwas nicht gut funktioniert oder schlecht dokumentiert ist, und dann springe ich hinein. Sich nur wegen des Contributens ein Projekt auszusuchen, funktioniert meiner Erfahrung nach eher selten.
(mai)