Interview: Die Zukunft von Vite & Co. beim neuen Eigentümer Cloudflare

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.

Alexander Lichter ist Developer Relations Engineer bei VoidZero, Mitglied des Nuxt.js-Teams, Web-Engineering-Berater und Open-Source-Enthusiast. Er erstellt technologieorientierte Videoinhalte, spricht auf Konferenzen und leitet Workshops, um Entwickler zu unterstützen und das Web-Ökosystem voranzubringen.

Das Interview führte Timo Zander, Software Engineer bei Barra Technologies und freier Autor. Er schreibt über Web Engineering, Developer Tooling und die Technologien, die die Zukunft des Webs prägen.

Timo Zander: Du bist im März 2025 zu VoidZero gestoßen, knapp ein halbes Jahr nach der öffentlichen Bekanntgabe der Firmengründung. Wie kam es dazu – und wie sah das Unternehmen zu diesem Zeitpunkt aus?

Alexander Lichter: Ich habe kurz nach der Gründung im Herbst 2024 mit Evan You ein Interview auf meinem YouTube-Kanal geführt und rückblickend war das wie eine Art Jobinterview für mich. Einige Monate später hat Evan mich angesprochen, ob ich mir vorstellen könnte, Developer Relations für VoidZero zu machen, nachdem ich das ja auch schon für Vue und Nuxt getan hatte. Das war für mich ein Angebot, das ich schlecht ablehnen konnte: eine Firma rund um Developer Tooling, auf die die ganze Community zumindest ein Auge wirft, und bei der ich die Zukunft des JavaScript-Ökosystems mitgestalten kann. Das ist einfach mega.

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.

Bei der Größe von VoidZero damals ist es aber auch nicht der gängigste Fall, dass es eine dedizierte Developer-Relations-Stelle gibt. Wie siehst du das?

Es ist nicht ganz typisch, aber sobald du etwas im Entwicklerökosystem und für Entwickler baust, brauchst du jemanden, der Tutorials schreibt, Dokumentationen pflegt und Videos produziert. Evan war im Endeffekt der erste Developer Relations Engineer vor mir, aber er sagte selbst, dass er nicht die Zeit habe, täglich alle Feeds zu checken und Content zu produzieren.

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.

Auf der ViteConf 2025 habt ihr Vite+ angekündigt. Die Rust-basierte Toolchain sollte das Tooling in Teilen kommerzialisieren. Innerhalb weniger Monate seid ihr von diesem Plan abgerückt und habt Vite+ stattdessen vollständig Open Source veröffentlicht. Wie liefen diese Monate ab? Welche Vorstellungen haben sich nicht bewahrheitet?

Als VoidZero gegründet wurde, war die Vision, die „Unified Toolchain“ zu haben, und das ist auch nach wie vor unser großes Ziel. Gleichzeitig stellte sich schnell ein zweites Ziel heraus: All die Menschen, die an den Open-Source-Tools arbeiten, sollen irgendwie von ihrer Arbeit leben können. Wir wollten ein faires Modell finden, bei dem individuelle Entwickler das Tooling weiterhin komplett kostenlos in einem großzügigen Free Tier nutzen können, während Unternehmen entsprechend Lizenzkosten zahlen. Ähnlich, wie es viele andere Services machen.

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.

Mit Void habt ihr eure eigene Deployment-Plattform erdacht. Was ist der Elevator Pitch? Was war eure Vision dahinter?

Nachdem sich Vite+ als schwieriges Finanzierungsmodell herausgestellt hatte, haben wir über den Pivot nachgedacht. Über das chinesische Neujahr hatte Evan You dann wieder einen seiner „Evan-Momente“, ähnlich wie bei Vite, und hat sich Void als Plattform ausgedacht.

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.

Das erinnert mich an NuxtHub, den (gescheiterten) Versuch des Nuxt-Teams vor rund zwei Jahren, eine auf Nuxt spezialisierte Deployment-Plattform zu bauen. Habt ihr daraus lernen können?

Die Idee war ähnlich. Nuxt wollte die ganzen Infrastruktur-Primitives für die lokale Entwicklung wegabstrahieren, und ich habe es auch selbst vor einiger Zeit benutzt. Lernen konnten wir daraus definitiv einige Dinge.

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.

Wie lange hat es vom „Aha-Moment“ von Evan You bis zur ersten funktionierenden Version gedauert?

Ein paar Wochen, wenn überhaupt. Im Zeitalter von KI – und damit meine ich nicht einfach alles zu vibe-coden, sondern Agenten sinnvoll zu steuern, also Agentic Engineering – geht so etwas echt fix.

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.

Auf welchem Stack basiert Void – Rust oder TypeScript?

Es ist in TypeScript geschrieben. Das SDK musste ja ohnehin auf TypeScript basieren, und die Plattform selbst haben wir daher auch direkt in derselben Sprache verfasst.

Wann ist Cloudflare auf eure Existenz aufmerksam geworden?

VoidZero war Cloudflare definitiv von früh an ein Begriff, allein schon, weil es Nutzer unserer Tools ist. Cloudflare hat zum Beispiel Oxc für Cloudflare Workflows verwendet, und Vite ist seit Ewigkeiten Teil von Cloudflares Stack. Wann die konkreten Gespräche für eine engere Zusammenarbeit begonnen haben, kann ich aber nicht genau sagen.

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.

Das gesamte Wrangler-Tooling ist sehr kontrovers: einerseits viel gelobt, andererseits scharf kritisiert. Seid ihr dann die Lösung hierfür?

Auch ohne uns tut sich da viel! Die neue Cloudflare CLI bietet neben der ursprünglichen Wrangler CLI viele weitere Features, und die Config lässt sich inzwischen auch experimentell in TypeScript statt nur in JSON/TOML schreiben. Da passiert einiges, und das begeistert mich sehr.

Cloudflares Akquisition von Astro Anfang 2026 hat für viel Kritik gesorgt. Hat euch das bei der Wahl von Cloudflare als Partner zu denken gegeben?

Zunächst muss man in diesen Fällen klar unterscheiden. Sowohl beim Astro-Fall als auch bei der Akquisition von Nuxt durch Vercel werden jeweils die Unternehmen hinter den Frameworks – also die Astro Technology Company beziehungsweise NuxtLabs – übernommen. Die Projekte selbst bleiben Open Source, was naturgemäß einer der riesigen Vorteile von Open Source ist. Und die Projekte bestehen ja nicht lediglich aus den ursprünglichen Entwicklern, sondern auch aus vielen weiteren Beteiligten.

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.

Wie seid ihr in Cloudflare überführt worden?

VoidZero wurde als eigene Einheit mit allen Teammitgliedern vollständig in Cloudflare eingegliedert. Das Schöne ist, dass jeder mit übernommen wurde und dass bei jedem Einzelnen sichergestellt wurde, dass er oder sie glücklich damit ist.

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.

Was hat sich in der täglichen Arbeit seit der Akquisition verändert?

Es gibt natürlich einige Änderungen, wenn man von einem 20-Leute-Start-up in ein Unternehmen mit Tausenden Mitarbeitern wechselt, gerade bei den Prozessen. Ansonsten ist vieles gleich: Wir bauen weiterhin an Open-Source-Projekten.

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.

Was passiert mit Void? Bleibt es ein eigenes Tool oder integriert ihr es?

Was feststeht, ist, dass Void komplett Open Source wird. Das bietet dann auch eine gute Referenz dafür, wie man eine Plattform basierend auf Workers for Platforms baut, etwa für ein internes System.

Abseits davon gibt es einige Wege, die wir gerade erkunden, zu denen ich aber erst zu gegebener Zeit etwas erzählen kann.

In verschiedenen Online-Foren erhoben Nutzer den Vorwurf, dass es sich bei der Übernahme im Kern um einen Acqui-Hire handelt – dass also vor allem das Team und dessen Know-how übernommen werden, statt das Produkt. Was denkst du darüber?

VoidZero wurde definitiv nicht einfach gegründet, nur um Leute anderswo anstellen zu lassen. Unsere aufwendigen Versuche, unsere Produkte zu monetarisieren, der Pivot und all die Gedanken und Zeit, die wir dort investiert haben, zeigen mit Sicherheit eine gewisse Ernsthaftigkeit.

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.

Was ist deine Vision über Vite+ hinaus? Gibt es größere Pain Points, die du beheben möchtest, die noch nicht auf eurer Roadmap stehen?

Ich glaube, das ist etwas, das sich ständig weiterentwickelt. Durch KI ist es aktuell zum Beispiel ein großes Thema, unsere Tools noch besser mit Agenten zu integrieren. Zum Beispiel wollen wir dem Vite-Server ein Logfile geben, das der Agent einfacher auslesen kann als den Terminal-Output.

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.

Wie sehr hat KI euren Alltag verändert? Und was haltet ihr von den unterschiedlichen Ansätzen in Open Source – etwa Zigs striktem KI-Verbot im Vergleich zu Rusts differenzierter Policy, die bestimmte KI-generierte Beiträge unter Auflagen erlaubt?

Wir nutzen natürlich intern selbst viel KI. Für unsere Repositories verfolgen wir eine ähnliche Policy wie Nuxt: Erstens, lass niemals ein LLM für dich sprechen, sondern schreib dein Issue oder deine Pull-Request-Beschreibung selbst. Dann hast du idealerweise auch verstanden, was dein Problem ist. Zweitens versteh den Code, den du produzierst und committest. Nimm dir die Zeit, ihn durchzulesen und zu durchdringen.

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.

Wenn jemand an VoidZero-Projekten mitarbeiten möchte: Welches Projekt würdest du als Einstieg empfehlen?

Das kommt, glaube ich, sehr stark auf die eigene Präferenz an. Oxc ist zum Beispiel super für Rust-Liebhaber. Bei Rolldown ist das Problem eher, dass das Konzept eines Bundlers selbst schon ziemlich komplex ist, unabhängig von der gewählten Programmiersprache. Das ist definitiv eine große Hürde.

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.