Freie KI-Nachbauten: Wer pflegt den Code?

Am 30.09.2026 hat ein Team von vier Leuten PhotoCraft veröffentlicht, einen freien Nachbau von Photoshop, gebaut mit Coding-Agenten. Zwei Wochen später, am 15.10., zählt das Repository rund 61.800 Sterne, über 10.600 Forks und 310 Beitragende. In der Woche vom 08. bis 14.10. wurden 1.725 Pull Requests gemergt, im Schnitt also rund zehn pro Stunde, Tag und Nacht.

Den Fall selbst haben wir im ersten Teil dieser Serie beschrieben. Dort stand auch ein Versprechen, das wir jetzt prüfen: Der Code ist frei, also kann jeder übernehmen, wenn das Team aufhört oder eine Richtung einschlägt, die den Nutzern nicht passt. Mit Agenten werde ein Fork für wenige Leute tragbar.

Zwei Wochen sind kurz für ein Urteil, aber lang genug, um zu sehen, wie so ein Projekt tatsächlich läuft. Dieser Teil fragt deshalb: Was passiert mit Open Source, wenn kommerzielle Suiten freie Alternativen bekommen, die wenige Leute mit Agenten bauen? Wer schreibt den Code, wer entscheidet darüber, und wer kann ihn übernehmen?

Viele liefern, einer entscheidet

Die 310 Beitragenden sind echt, 137 davon haben genau einen Commit. Brandon Thomas aus dem ArtCraft-Team, auf GitHub echelon, kommt auf 270 von 2.371 Commits, also gut elf Prozent. Von den 2.166 gemergten Pull Requests stammen 183 von ihm. Den Großteil der Commits liefern inzwischen andere.

Die Entscheidung, was davon in den Hauptzweig kommt, ist dagegen nicht verteilt. Wir haben eine Stichprobe von 100 Pull Requests ausgewertet, die zwischen dem 08. und 14.10. gemergt wurden. 99 davon hat dasselbe Konto gemergt: echelon. Seit dem 14.10. mergt ein zweites Konto mit: In einer Stichprobe von 40 Merges seitdem stehen 27 von echelon und 12 vom zweiten Konto.

Hunderte Leute schreiben also Code, und ein bis zwei Personen nehmen ihn an. Bei 1.725 Merges in einer Woche ist klar, dass dabei nicht jede Zeile von Menschen gelesen wird. Wie genau die Prüfung läuft, ob ein Agent vorsortiert oder die automatischen Tests das meiste tragen, beschreibt das Projekt nicht öffentlich. Die geteilten Regeln, auf die die AGENTS.md verweist, liegen in einem Repository namens craftrules, das nicht öffentlich ist. Wer beitragen will, soll bei einem Maintainer nachfragen.

Was öffentlich ist, zeigt eine Arbeitsweise, die auf Agenten zugeschnitten ist. Die Beitragsregeln verlangen Tests für jede Änderung, kein unsafe und kein panic! außerhalb von Tests, vorher-nachher-Screenshots bei Oberflächenänderungen. Die AGENTS.md regelt, wie mehrere Agenten parallel arbeiten, ohne sich gegenseitig die Build-Verzeichnisse zu zerschießen. Von der Einreichung bis zum Merge vergeht im Mittel etwa ein halber Tag.

Die Menge erzeugt eigene Probleme. Zwei Konten reichen für denselben Fehler fast gleichzeitig zwei fast gleiche Lösungen ein, eine wird als Duplikat geschlossen. 102 Issues tragen inzwischen das Label duplicate, 150 offene Issues haben noch gar kein Label. Die eigene Roadmap vom 13.10. sagt offen, wo PhotoCraft steht: Alpha, nach eigener Schätzung zu etwa 45 Prozent "ready for real work", 22 von 25 Leistungsvorgaben verfehlt, von PhotoCraft geschriebene PSD-Dateien öffnet Photoshop noch nicht zuverlässig.

Forken geht, mithalten nicht

Wenn viele beitragen und wenige entscheiden, wird das Fork-Argument wichtig. Es besagt: Wer mit der Richtung nicht einverstanden ist, nimmt den Code und macht selbst weiter.

Nach zwei Wochen sind die Daten eindeutig. Von über 10.600 Forks hat keiner mehr als neun Sterne. Fast alle dienen offenbar nur als Ablage, aus der jemand einen Pull Request ans Original schickt. Der einzige Fork mit erkennbar eigener Richtung heißt lanczarus und beschreibt sich als PhotoCraft "with stripped telemetry and ai". Er hat einen eigenen Commit und liegt nach acht Tagen 2.077 Commits hinter dem Original.

Das Argument bleibt richtig, es greift nur später als gedacht. Forken ist mit Agenten leichter geworden, aber gegen ein Original, das rund 250 Commits am Tag bekommt, läuft kein kleiner Fork an. Interessant wird die Fork-Frage erst, wenn das Tempo des Originals sinkt, das Team aufhört oder eine Entscheidung trifft, die viele nicht mittragen. Dann ist der Code da, samt Tests, Roadmap und Agenten-Anleitung. Das ist mehr, als ein Fork früher in der Hand hatte, und bei einer geschlossenen Suite gibt es diese Option gar nicht.

Praktisch bedeutet das: Wer heute eine freie Alternative einsetzt, setzt auf das Originalprojekt und seine ein bis zwei Leute, die mergen. Der offene Code ist eine Versicherung für später.

Was die Flut mit anderen Projekten macht

PhotoCraft hat sich entschieden, Beiträge von Agenten ausdrücklich anzunehmen. Andere Projekte haben in diesem Jahr den umgekehrten Weg gewählt, weil sie mit der Menge nicht mehr fertig wurden.

Das Geoinformationssystem QGIS hat am 07.10.2026 eine neue Fassung seiner KI-Richtlinie aufgenommen. Sie lässt keinen Spielraum: "No LLM, AI or agent assisted code contributions are allowed in the https://github.com/qgis/qgis repository." Wer dabei erwischt wird, muss mit der Rücknahme seines Codes rechnen. Das Terminalprogramm Ghostty schließt Pull Requests von Erstbeitragenden automatisch, solange niemand aus dem Projekt für sie bürgt. Der curl-Maintainer Daniel Stenberg hat das Bug-Bounty-Programm Ende Januar beendet. Früher waren laut Stenberg mehr als 15 Prozent der Meldungen echte Lücken, seit 2025 sind es unter 5 Prozent. Er nennt als einen Grund "the mind-numbing AI slop". GitHub hat im Juni eine Obergrenze für offene Pull Requests von Leuten ohne Schreibrecht eingeführt.

Wie viel davon bei Sicherheitsmeldungen ankommt, haben wir in der News zum OSS Scanner von Anthropic beschrieben. Was passiert, wenn ein Projekt unter dieser Last aufgibt, steht in Wenn ein OSS-Projekt mit offener Lücke stirbt.

Das Totalverbot ist trotzdem die Ausnahme. Eine Auswertung von 281 KI-Richtlinien populärer Open-Source-Projekte vom September 2026 kommt auf 83,3 Prozent, die KI beim Programmieren erlauben oder sogar fördern. Zwei Drittel verlangen aber, dass ein Mensch maßgeblich beteiligt ist, knapp die Hälfte will offengelegt haben, wo KI im Spiel war.

Zwischen QGIS und PhotoCraft liegen also zwei Antworten auf dieselbe Frage. QGIS schützt die Aufmerksamkeit seiner Maintainer, indem es die Menge begrenzt. PhotoCraft nimmt die Menge an und setzt auf Tempo und automatische Prüfung. Welche Antwort trägt, zeigt sich erst, wenn die Aufmerksamkeit für PhotoCraft nachlässt und die eine Person, die mergt, krank wird oder keine Lust mehr hat.

Geht das auch mit offenen Modellen?

Im ersten Teil stand eine offene Frage: Hängt so ein Nachbau am jeweils stärksten Modell eines Herstellers? Dann wäre die Freiheit des Codes nur die halbe Freiheit, weil die Werkzeuge, die ihn pflegen, jemand anderem gehören.

Das Projekt selbst bindet sich nicht. Die AGENTS.md nennt keinen Hersteller und kein Modell. Die Praxis sieht anders aus: Die Roadmap rechnet den Aufwand bis zur Beta in "Opus 5.5 agent wall-clock hours", 1.100 bis 1.800 Stunden. Rund die Hälfte der jüngsten Commits trägt den Vermerk, dass Claude Opus 5.5 mitgeschrieben hat.

Ob offene Modelle dasselbe leisten, lässt sich derzeit nicht belegen, weder in die eine noch in die andere Richtung. Der Benchmark MirrorCode von Epoch AI misst genau diese Aufgabe: ganze Programme nachbauen, ohne den Originalcode zu sehen, über Tage. Auf der Rangliste stehen Stand 15.10. neun Modelle, alle von Anthropic, OpenAI und Google. Offene Modelle wurden dort nicht getestet.

Was es gibt, ist ein allgemeiner Vergleich. Epoch AI sieht die besten offenen Modelle seit Januar 2026 im Schnitt vier Monate hinter den besten geschlossenen. Das ist wenig. Es betrifft aber die allgemeine Leistungsfähigkeit, nicht lange Agentenläufe über Tage.

Und es gibt einen Erfahrungsbericht, der zur Vorsicht mahnt. Der Entwickler des Compiler-Ports ts-rust hat nach eigener Angabe mit zwei OpenAI-Modellen über Monate Tokens im Wert von über 400.000 Dollar verbraucht und ist bei etwa 84 Prozent Kompatibilität stehen geblieben. Mit Claude Opus 5.5 hat er von vorne angefangen, hatte nach zehn Stunden eine lauffähige erste Fassung und nach zwei Wochen und rund 24.000 Dollar laut README volle Kompatibilität in allen getesteten Projekten. Ein Vergleichstest ist das nicht, nur ein einzelner Bericht. Er zeigt aber, dass bei Vorhaben dieser Größe die Wahl des Modells einen Unterschied von Monaten machen kann, auch zwischen zwei geschlossenen.

Damit bekommt die Fork-Frage einen Haken. Wer PhotoCraft in einem Jahr übernehmen will, braucht nicht nur den Code, sondern auch Zugang zu einem Modell, das mit ihm umgehen kann. Heute ist das ein kommerzielles. Ob es in einem Jahr auch ein offenes ist, ist eine der Fragen, die wir in dieser Serie weiter beobachten.

Wenn der bezahlte Teil nachbaubar wird

Die Craft-Reihe richtet sich gegen geschlossene Software. Für viele Open-Source-Firmen ist eine andere Frage dringender: Was passiert, wenn auch ihr bezahlter Teil nachbaubar wird? Viele finanzieren den freien Kern über Zusatzprodukte, Komponenten oder gehostete Dienste. Dieses Modell heißt Open Core.

Der bekannteste Fall des Jahres ist Tailwind. Adam Wathan, Gründer von Tailwind Labs, schrieb im Januar in einer Diskussion auf GitHub, der Verkehr auf der Dokumentation sei seit Anfang 2023 um etwa 40 Prozent gesunken, obwohl Tailwind beliebter sei denn je. Die Dokumentation sei der einzige Weg, auf dem Leute die kommerziellen Produkte entdecken, der Umsatz sei "down close to 80%". 75 Prozent des Entwicklerteams hätten ihre Stellen verloren. Hier ist kein Nachbau das Problem, sondern ein Kanal: Wer sich Tailwind-Code von einem Agenten schreiben lässt, besucht die Dokumentation nicht mehr.

Den Nachbau selbst hat Cloudflare im Februar vorgeführt. Laut Cloudflare hat ein einzelner Entwickler mit einem KI-Modell als vinext die Programmierschnittstelle von Next.js nachgebaut, in weniger als einer Woche, für rund 1.100 Dollar an Tokens und mit 94 Prozent der API. Der Schlüssel war die Testsuite von Next.js. Sie lieferte, wie Cloudflare schreibt, "a specification we could verify against mechanically". Der Pragmatic Engineer ordnete das ein: Gute Tests machen Neuschreibungen leichter, und er erwartet, dass Firmen Zusatzdienste künftig eher als geschlossenen Code führen.

Zwei weitere Fälle zeigen, wohin das führen kann. Die Python-Bibliothek chardet wurde mit Claude neu geschrieben und von LGPL auf MIT umlizenziert, später auf 0BSD. Der ursprüngliche Autor bestritt das Recht dazu, der Streit im Issue-Tracker endete ohne gerichtliche Klärung. Und der Terminplaner Cal.com hat im April seine kommerzielle Version geschlossen, mit einer abgespeckten Community-Version unter MIT. Als Grund nannte das Unternehmen allerdings nicht das Nachbauen, sondern dass KI das Finden von Sicherheitslücken in offenem Code erleichtert.

Für Open Source heißt das: Was sich mechanisch prüfen lässt, lässt sich nachbauen. Was ein Projekt schützt, sind zunehmend Dinge, die nicht im Code stehen, etwa die Testsuite, der Betrieb, der Support und das Vertrauen der Nutzer.

Und im DACH-Raum?

Freie Alternativen zu Microsoft Office sind hier kein Gedankenspiel. Schleswig-Holstein setzt nach eigenen Angaben auf "nahezu 80 Prozent aller Arbeitsplätze, außerhalb der Steuerverwaltung" LibreOffice ein und hat damit mehr als 15 Millionen Euro an Lizenzen gespart. Rund 20 Prozent der Arbeitsplätze brauchen wegen Fachverfahren in Teilbereichen weiter Microsoft Office. Die Bundesverwaltung hatte im April laut Bundesregierung 8.756 Lizenzen für die Verwaltungssuite openDesk, davon 8.475 im Produktivbetrieb, aber "noch keine exklusive Nutzung von openDesk als Ersatz für proprietäre Lösungen".

Beide Beispiele zeigen, woran ein Umstieg hängt: an Support, an Fachverfahren, an Schulung und an jemandem, der für den Betrieb geradesteht. Beim Umstieg der Staatskanzlei auf Linux übernehmen laut Land die Dienstleister Dataport und Gonicus den Support. Eine Alpha-Software, deren eigene Roadmap von 45 Prozent Einsatzreife spricht, erfüllt diese Voraussetzungen nicht, egal wie schnell sie wächst.

Dazu kommt ein Punkt, der für Souveränitätsdebatten unbequem ist. Die Craft-Programme sind frei, aber mit einem Modell eines US-Anbieters gebaut und gepflegt. Wer aus einem US-Abo aussteigen will, tauscht im ungünstigen Fall eine Abhängigkeit vom Softwareanbieter gegen eine Abhängigkeit vom Modellanbieter der Maintainer. Für den Nutzer ist der Code trotzdem freier als vorher. Für die Frage, wer die Pflege in der Hand hat, ändert sich weniger, als es aussieht.

Woran ihr eine freie KI-Alternative messt

Ob ihr PhotoCraft, eine der anderen Craft-Apps oder den nächsten Nachbau ausprobiert, diese Fragen sagen mehr als die Zahl der Sterne:

• Wer mergt? Schaut in die letzten gemergten Pull Requests. Steht dort immer derselbe Name, hängt das Projekt an einer Person, egal wie viele beitragen.
• Sind die Regeln öffentlich? Verweisen AGENTS.md oder Beitragsregeln auf nicht öffentliche Dokumente, könnt ihr nicht nachvollziehen, wonach geprüft wird.
• Was sagt die Roadmap über Reife? PhotoCraft nennt seine Schwächen selbst. Das ist ein gutes Zeichen, und die Zahlen sind ernst zu nehmen.
• Gibt es einen Meldeweg für Sicherheitslücken? Die SECURITY.md von PhotoCraft dokumentiert am 15.10. keinen privaten Kanal.
• An welchem Modell hängt die Pflege? Steht in der Planung ein bestimmtes Modell, ist das die Abhängigkeit, die ihr mit einkauft.
• Wer übernimmt den Betrieb? Für den Einsatz im Team braucht ihr jemanden, der Updates einspielt, Fehler meldet und notfalls selbst behebt. Das kann intern sein oder ein Dienstleister, aber es muss jemand sein.

Kurz gesagt

PhotoCraft zeigt nach zwei Wochen zweierlei. Agenten machen es leicht, zu einem freien Projekt beizutragen, und Hunderte tun es. Die Entscheidung, was davon gilt, liegt aber bei einer oder zwei Personen, und ein Fork kann gegen dieses Tempo nicht mithalten. Der offene Code ist eine echte Versicherung für den Fall, dass das Team aufhört. Ob jemand sie einlösen kann, hängt auch davon ab, ob er Zugang zu einem Modell hat, das so gut ist wie das der Maintainer. Wer eine KI-gebaute Alternative einsetzt, sollte deshalb weniger auf die Sterne schauen und mehr darauf, wer mergt, wer betreibt und womit gebaut wird.