PhotoCraft und der Preis kostenloser Software im KI-Zeitalter
Eine unabhängige Photoshop-Neuimplementierung wirft eine größere Frage auf: Wenn KI die Softwareentwicklung erleichtert, wer bezahlt dann für Zuverlässigkeit, Wartung und den nächsten Durchbruch?
Originalillustration der Redaktion von Telli.sh. Dies ist eine konzeptionelle Grafik, kein PhotoCraft-Screenshot und keine gemessene Wirtschaftsprognose.
Eine vertraute Kreativanwendung, öffentlich neu entwickelt und ohne Abonnement verfügbar: Bei dieser Vorstellung fällt es schwer, nicht begeistert zu sein. Für Studierende, gelegentliche Kreative und Menschen, denen professionelle Werkzeuge zu teuer sind, kann kostenloser Zugang den Unterschied ausmachen zwischen einer Idee und ihrer tatsächlichen Umsetzung. Doch die Begeisterung ist erst der Anfang der Geschichte. Wenn KI die Kosten für die Nachbildung von Software deutlich senkt, müssen wir auch fragen, wer die Fähigkeiten weiterentwickelt, deren Nachbildung sich lohnt.
PhotoCraft macht diese Frage ungewöhnlich konkret. Berichte über die ArtCraft-Projekte beschreiben einen KI-gestützten Versuch, etablierte Kreativwerkzeuge neu zu entwickeln, darunter einen Photoshop-ähnlichen Editor. Bedeutsam ist nicht einfach, dass eine weitere Alternative auf einer Downloadseite auftaucht. Es geht um die Möglichkeit, dass der Weg von der Beobachtung eines nützlichen Arbeitsablaufs bis zu einer brauchbaren Implementierung kürzer wird. Diese Möglichkeit verdient Aufmerksamkeit, ohne aus einem ambitionierten Projekt in einer frühen Phase einen fertigen professionellen Ersatz zu machen. Phoronix, 7. Oktober 2026
PhotoCraft bildet vertraute Bearbeitungsabläufe nach
PhotoCraft ist ein unabhängiges Projekt, keine Veröffentlichung von Adobe. Das Repository nennt Ebenen, Masken, Einstellungsebenen, editierbare Schrift, Vektoren sowie PSD- und PSB-Workflows. Laut der Paritätseinschätzung des Projekts vom 10. Oktober 2026 befindet es sich noch in der Alpha-Phase: Die Maintainer schätzen die Einsatzreife für professionelle Arbeit auf etwa 45 Prozent und halten den PSD-Austausch mit Photoshop noch nicht für zuverlässig genug für eine Beta. Das sind eigene Messungen und Einschätzungen des Projekts, keine unabhängige Bewertung. PhotoCraft-Repository, Paritätseinschätzung, 10. Oktober 2026
„Eine Open-Source-Version von Photoshop“ ist eine bequeme Kurzform, kann aber wichtige Unterschiede verwischen. Verhalten nachzubilden ist etwas anderes, als Adobes Originalquellcode zu veröffentlichen. Die Beschreibung eines Entwicklers über einen Clean-Room-Prozess ist keine unabhängige Prüfung dieses Prozesses. Und eine vertraute Oberfläche belegt keine Kompatibilität mit jedem Dokument, Plug-in, jeder Schrift oder professionellen Produktionspipeline. Für diesen Artikel haben wir weder die Herkunft der Implementierung geprüft noch die Anwendung installiert oder unabhängig getestet.
Der Quellcode wird unter MIT- oder Apache-2.0-Bedingungen angeboten; Hinweise, gebündelte Assets und Marken erfordern jedoch jeweils eine eigene Prüfung. Eine freizügige Code-Lizenz ist keine Erlaubnis, jede mit einem Repository verbundene Marke oder jedes Kunstwerk weiterzuverwenden. Wer eine Weiterverbreitung erwägt, sollte die tatsächlichen Lizenz- und Attributionsdateien konsultieren und „kostenlos“ nicht als pauschale Freigabe verstehen. Dieser Artikel klärt nicht den rechtlichen Status von Reverse Engineering in irgendeiner Gerichtsbarkeit. Lizenz und Credits, Attributionsdatei
Kompatibilität ist ein Arbeitsablauf, keine Anzahl von Menüpunkten
Funktionsbreite ist nur ein Teil der Kompatibilität. In seiner Einschätzung vom 10. Oktober berichtet das Projekt, dass 133 von 256 PSD-Referenzdateien aus Photoshop die aktuelle Prüfung der Dateitreue bestanden. Außerdem nennt es offene Lücken bei Leistung, Stabilität, Interaktion und Unterstützung des Ökosystems. Das sind nützliche Hinweise auf laufende Tests, aber keine unabhängigen Bewertungen jedes Workflows. Paritätseinschätzung von PhotoCraft
Stellen wir uns vor, eine Designerin testet eine Alternative anhand eines einfachen Posters. Es lässt sich öffnen, eine Textebene bleibt bearbeitbar und der Export sieht korrekt aus. Das ist ein bedeutsamer Fortschritt. Nun erhält dieselbe Designerin ein Kundendokument mit ungewöhnlichen Farbprofilen, verknüpften Assets, Plug-in-Effekten und sorgfältig abgestimmter Typografie. Die zweite Aufgabe stellt eine andere Frage: Bleiben die über Jahre entstandenen Erwartungen beim Austausch zwischen Personen, Rechnern und Versionen erhalten?
Eine vernünftige Bewertung beginnt daher mit Dateikopien und einem eng begrenzten Arbeitsablauf. Lässt sich ein importiertes Dokument bearbeiten, speichern, in der ursprünglichen Anwendung erneut öffnen und an eine Kollegin weitergeben, ohne dass sich etwas Unerwartetes ändert? Erholt sich die Anwendung nach einem Absturz? Werden nicht unterstützte Vorgänge erklärt, bevor Informationen verloren gehen? Eine eindrucksvolle Demo belegt, dass eine Demonstration funktioniert hat; sie belegt nicht, dass all diese Anforderungen erfüllt sind.
Diese Unterscheidung ist kein Argument gegen das Projekt. Sie trennt die Anerkennung einer Leistung davon, in ihrem Namen ein Versprechen abzugeben. Frühe Alternativen brauchen Raum zur Verbesserung, und Nutzer brauchen genügend Informationen, um zu entscheiden, wann Experimente angemessen sind. Keiner Seite wäre damit geholfen, diese Beziehung durch das Wort „fertig“ zu ersetzen.
Kostenloser Zugang eröffnet echte Möglichkeiten
Das stärkste Argument für Open Source beginnt bei den Menschen, die zuvor nicht teilnehmen konnten. Ein wiederkehrendes Abonnement kann für ein Studio angemessen, für jemanden mit einem Schulprojekt, einem Vereinsnewsletter oder gelegentlichen Illustrationen aber schwer zu stemmen sein. Ein zugänglicher Editor ermöglicht es solchen Nutzern, zu üben, Fehler zu machen und Fähigkeiten zu entwickeln, ohne jeden Lernmonat in eine finanzielle Entscheidung zu verwandeln. Das zählt auch dann, wenn das Werkzeug anfangs nur einen Bruchteil professioneller Anforderungen abdeckt.
Verfügbarer Quellcode schafft eine weitere Art des Zugangs. Eine lokale Gemeinschaft kann die Sprachunterstützung verbessern. Eine Fachkraft für Barrierefreiheit kann eine Interaktion untersuchen, die Nutzer ausschließt. Eine Institution kann eine nützliche Version bewahren, statt vollständig von der kommerziellen Roadmap eines Anbieters abhängig zu sein. Das sind mögliche Vorteile einer offenen Codebasis, keine automatischen Errungenschaften eines bestimmten Projekts. Wirklichkeit werden sie erst, wenn jemand die Arbeit übernimmt und das Projekt sie annehmen und pflegen kann.
Wettbewerb verändert auch die Fragen, die etablierte Anbieter beantworten müssen. Wenn eine Alternative Alltagsaufgaben gut bewältigt, können Kunden klarer nachfragen, was ein Premiumprodukt zusätzlich bietet: tiefere Funktionen, besseren Support, verlässliche Zusammenarbeit oder ein besonders starkes Ökosystem. Ein Abonnement lässt sich nicht mehr allein mit dem Fehlen von Alternativen rechtfertigen. Es muss den Wert der fortlaufenden Beziehung erklären.
Wir müssen nicht so tun, als wollten alle Nutzer dasselbe Modell. Manche schätzen ein Offline-Werkzeug, das sie dauerhaft behalten können. Andere möchten verwaltete Updates und Support. Eine kleine Organisation kann beides kombinieren. Open Source ist auch deshalb wertvoll, weil es die Auswahl erweitert, statt allen eine einzige Theorie darüber aufzuzwingen, wie Software finanziert oder bereitgestellt werden sollte.
Eine günstigere Nachbildung macht Innovation nicht kostenlos
Meine Sorge ist nicht, dass Nutzer nützliche Software kostenlos bekommen können. Das ist ein Vorteil, den es zu schützen gilt. Die Sorge betrifft vielmehr den Unterschied zwischen der Nachbildung eines bestehenden Arbeitsablaufs und der Entdeckung des nächsten wertvollen Arbeitsablaufs. Eine Nachbildung kann von einem Produkt lernen, das bereits viele schwierige Designprobleme gelöst hat. Trotzdem muss jemand neue Probleme erkennen, unsichere Wetten eingehen und die Kosten gescheiterter Experimente tragen.
Dasselbe gilt nach der ersten Veröffentlichung. Die Kompatibilität mit einem sich verändernden Betriebssystem zu erhalten, ist keine einmalige Aufgabe. Ebenso wenig sind die Untersuchung eines seltenen Datenverlusts, der Umgang mit einer verwundbaren Abhängigkeit oder die Prüfung eines ungewöhnlichen Importformats einmalige Aufgaben. KI kann dabei helfen, aber die Verantwortung verschwindet dadurch nicht. Jemand muss entscheiden, was korrekt ist, es überprüfen und Verantwortung übernehmen, wenn eine Korrektur ein weiteres Problem verursacht.
Ein Ökosystem kann gesund wirken und zugleich von einer kleinen Menge unsichtbarer Arbeit abhängen. Nutzer sehen neue Funktionen, nicht unbedingt den erschöpften Maintainer, der Hunderte Meldungen sortiert. Eine Organisation kann sich gern auf kostenlosen Code verlassen, ohne je dessen Pflege zu finanzieren. Wenn günstigere Nachbildung Einnahmen verringert, ohne die Wartung auf andere Weise zu finanzieren, könnte es mehr verfügbare Anwendungen, aber weniger zuverlässige geben.
Das ist ein Risiko, keine Vorhersage, dass Open Source Innovation zwangsläufig zerstört. Offene Projekte können Unternehmen hervorbringen, Fördermittel erhalten, Sponsoren gewinnen und die Entwicklung über Organisationen hinweg teilen. Auch kommerzielle Projekte können Wartung vernachlässigen oder Nutzer an schlechten Service binden. Entscheidend ist nicht, welches Etikett Tugend garantiert. Entscheidend ist, ob das Finanzierungsmodell die Arbeit belohnt, die Nutzer langfristig brauchen.
Wofür sollten Nutzer zahlen, wenn Code im Überfluss verfügbar ist?
Originales redaktionelles Modell. Die drei Verantwortungsbereiche können bei einem Team oder mehreren liegen; durch das Generieren von Code ist keiner automatisch abgedeckt.
Eine Antwort besteht darin, den Zugang zu einer Funktion von den Garantien rundherum zu trennen. Ein kostenloser lokaler Editor kann erheblichen Nutzen bieten. Eine unterstützte Distribution könnte für signierte Releases, getestete Upgrades und Hilfe bei schwierigen Dateien Geld verlangen. Ein kollaborativer Dienst könnte Speicher, Berechtigungen, Synchronisierung und Wiederherstellung berechnen. Das sind Beispiele möglicher Geschäftsmodelle, keine von uns bestätigten derzeitigen Angebote von PhotoCraft.
Die Infrastrukturschicht finde ich besonders wichtig. Eine Funktion kann für sich genommen beeindruckend und als Teil der täglichen Arbeit trotzdem fragil sein. Zuverlässiger Dienst erfordert Backups, die sich tatsächlich wiederherstellen lassen, klare Zugriffsregeln, sichtbare Fehler und einen Notfallplan. Wenn mehrere Personen von denselben Informationen abhängen, können die Kosten eines nicht verfügbaren oder inkonsistenten Systems den Preis der Funktion selbst übersteigen.
„Infrastruktur“ sollte jedoch keine vage Ausrede für ein weiteres Abonnement werden. Ein Anbieter sollte erklären können, was er betreibt, was bei einem Ausfall geschieht und wie Kunden den Dienst verlassen können. Speicher ohne Exportmöglichkeit kann zur Falle werden. Ein Backup-Versprechen ohne Wiederherstellungsverfahren ist unvollständig. Vertrauen entsteht durch konkrete Zusagen und wiederholte Leistung, nicht dadurch, dass man Open-Source-Code das Wort „verwaltet“ voranstellt.
Dienstleistung und Eigentum können nebeneinander bestehen. Nutzer können Dateien in Standardformaten und lokale Kopien behalten und zugleich für zuverlässige Zusammenarbeit zahlen. Unternehmen können Verbesserungen upstream beitragen und Einnahmen durch den Betrieb der Software erzielen. Die gesündeste Lösung könnte den Quellcode verfügbar und den Dienst optional machen, wobei Wechselkosten aus echtem Komfort entstehen statt aus vorenthaltenem Zugriff auf die eigene Arbeit.
Persönliche Software könnte praktikabler werden
Wenn Implementierung günstiger wird, lohnt es sich, kleinere Probleme zu lösen. Eine Fotografin könnte eine Oberfläche wünschen, die auf eine wiederkehrende Exportaufgabe zugeschnitten ist statt auf eine universelle Werkzeugpalette. Eine Lehrkraft braucht vielleicht eine Prüfoberfläche für eine bestimmte Klasse. Eine Forschungsgruppe bevorzugt womöglich einen Arbeitsablauf, der einen bestimmten Validierungsschritt sichtbar hält. Das sind plausible Richtungen, keine Behauptung, ein persönlicher Agent könne bereits jede Anwendung sicher bauen.
Bisher wurde eine so eng gefasste Anforderung oft zu einer Tabelle, einem Makro oder einem Kompromiss innerhalb eines größeren Produkts. KI-gestützte Entwicklung könnte es erleichtern, aus solchen Kompromissen zweckgebundene Oberflächen zu machen. Damit würde sich die Rolle der Anpassung verändern. Statt aus Einstellungen auszuwählen, die jemand vorausgesehen hat, könnte ein Nutzer einen Arbeitsablauf beschreiben und dabei helfen, ein kleines Softwarestück darum herum zu gestalten.
Die Schwierigkeit besteht darin, die Eigenschaften zu bewahren, die gemeinsam genutzte Software nützlich machen. Eine persönliche Änderung kann mit künftigen Updates inkompatibel werden. Ein generierter Helfer könnte den Normalfall abdecken, aber Löschen oder Wiederherstellung falsch behandeln. Ein Arbeitsablauf, der seinem Urheber einleuchtet, könnte für eine Kollegin unverständlich sein. Personalisierung braucht deshalb Grenzen, Dokumentation und rückgängig machbare Änderungen, nicht nur eine begeisterte Generierungsschleife.
Auch die Verteilung von Fachwissen ist zu bedenken. Ein technisch versierter Nutzer kann eine Änderung prüfen; eine andere Person kann vielleicht nicht erkennen, ob es sich um eine harmlose Oberflächenänderung oder um ein Programm handelt, das Dateien liest oder Daten an anderer Stellehin sendet. Wenn persönliche Software verbreiteter wird, werden verständliche Berechtigungsmodelle wichtiger, nicht unwichtiger. Einfachere Erstellung darf nicht unbemerkt sämtliche Wartungs- und Sicherheitslast auf die Person abwälzen, die das Werkzeug angefordert hat.
Claude Code Mods gibt einen kleinen Einblick in diese Richtung
Claude Code Mods ist ein konkretes Beispiel dafür, wie ein Werkzeug zu einer anpassbaren Umgebung werden kann. Die Dokumentation von Anthropic beschreibt JavaScript- oder TypeScript-Handler, die Oberflächenelemente und Verhalten innerhalb von Claude Code verändern können. Das geht über die Bitte hinaus, das Modell möge in einem anderen Ton antworten: Kleine Codebausteine können Teile der Arbeitsumgebung neu gestalten. Offizielle Mods-Übersicht, geprüft am 12. Oktober 2026
Dieselbe Dokumentation warnt, dass Mods nicht in einer Sandbox laufen und mit den Berechtigungen des Nutzers ausgeführt werden. Das macht das Beispiel in zweierlei Hinsicht nützlich. Es weist auf zunehmend persönliche Software hin und zeigt, warum persönliche Software trotzdem eine vertrauenswürdige Grundlage braucht. Eine praktische Anpassung ist nicht automatisch sicher, nur weil eine KI beim Schreiben geholfen hat.
Für mich ist PhotoCraft weniger als Urteil über einen etablierten Anbieter interessant, sondern vielmehr als Frage nach der nächsten Softwareökonomie. Open Source kann leistungsfähige Funktionen mehr Menschen zugänglich machen. Gleichzeitig bleiben Investitionen in Entdeckung, Wartung und zuverlässigen Betrieb notwendig. Wenn KI es leichter macht, Oberflächen nachzubauen und anzupassen, erwarte ich persönlichere Software, während die gemeinsame Infrastruktur darunter wichtiger wird. Claude Code Mods gewährt einen bescheidenen, aber aufschlussreichen Blick auf diese Zukunft: Das Werkzeug kann sich an seinen Nutzer anpassen, doch jemand muss den Boden darunter zuverlässig machen.
Eine überprüfbare Dokumentation Ihrer KI-Recherche führen
Für Leser, die eigene Recherche-Notizen sammeln möchten, ist Telli.sh ein optionaler Ort, um Material und daraus abgeleitete Zusammenfassungen zu organisieren. Einen Notizbereich erstellen.