In vielen Softwareteams läuft die Entwicklung wie geschmiert. Entwicklerinnen und Entwickler sammeln Anforderungen, setzen Features um, schließen Sprints ab und liefern Releases aus. Es wird gebaut, getestet, deployt, immer und immer wieder. Und doch bleibt häufig ein diffuses Gefühl zurück. Warum diese Arbeit, warum der ganze Code? Selbst wenn man mit KI-Unterstützung noch schneller mehr Code erzeugen kann, heißt das noch lange nicht, dass am Ende viel Wert entsteht.

Darin liegt das Problem, das viele Produktteams haben: Der Fokus liegt auf Output. Die Teams setzen mehr und mehr Features um und messen den Fortschritt anhand der erledigten Arbeit. Produkte sammeln immer mehr Funktionalität an und wachsen kontinuierlich. Viele Produktverantwortliche glauben, dass das nötig ist, um sich vom Wettbewerb zu differenzieren und bestehenden Nutzerinnen und Nutzern ständig etwas Neues zu bieten. Dabei ist nicht immer „mehr“ die Lösung, sondern manchmal sogar ein Problem. Je mehr Features das Produkt umfasst, umso mehr Arbeit muss in Bugfixing und Wartung fließen. Und genau hier setzt der Gedanke an, sich mehr auf Outcome statt Output zu konzentrieren.

Output ist nicht gleich Wert

Wo liegt der Unterschied zwischen Output und Outcome? Output beschreibt, was produziert wird. Outcome ist das, was das Produzierte bewirkt. Jede Funktion, jede neue Dokumentation, jeder neue Test ist erst einmal nur Output. Je mehr ein Team davon liefert, desto „produktiver“ ist es. Dabei bleibt zunächst unklar, was sich durch den erzeugten Output verändert. Was wird sich für Nutzerinnen und Nutzer ändern?

Zum Beispiel hat ein Onlineshop mit häufig wiederkehrenden Einkäufen (etwa für den Wocheneinkauf oder die Bestellung bei der Lieblingspizzeria) eine Funktion, die User beim Einkauf daran erinnern soll, dass sie ein oft gekauftes Produkt diesmal vergessen haben (zum Beispiel „Du nimmst normalerweise Pizzabrötchen dazu. Hast du sie vielleicht vergessen?“). Das Feature für diese Erinnerung ist erst einmal nur der Output. Wenn Kundinnen und Kunden das Feature aber nutzen und es dafür sorgt, dass sie mehr einkaufen, ist das der Outcome. In anderen Kontexten kann das dann auch eine schnellere Einarbeitung, glücklichere Kunden oder Ähnliches bedeuten. Outcome ist aber am Ende immer die Antwort auf die Frage, was sich durch den Output verbessern soll.

Das Konzept von Outcome und Output bei einem komplexen Produkt lässt sich gut am Beispiel des Essens für eine Feierlichkeit verdeutlichen. Jedes einzelne Gericht, jeder Dip, jede Soße und jede Beilage ist Output. Misst man den Erfolg der eigenen Arbeit an Output, so geht es in erster Linie darum, dass möglichst viel Essen auf dem Tisch steht. Geht es aber um Outcome, dann sind die Freude beim Essen, das Lächeln der Gäste und das Genießen des Essens von Bedeutung. Man geht demnach anders an die Arbeit, wenn man sich andere Fragen stellt. Braucht es möglichst viel Essen oder geht es darum, die Personen kulinarisch zufrieden zu stellen? Geht es um schlichte Sättigung oder um Begeisterung beim Essen? Bezogen auf Software: Nutzerinnen und Nutzer freuen sich nicht über zusätzliche Features an sich. Vielmehr freuen sie sich darüber, wenn sie ein Problem einfacher lösen, eine Arbeit schneller durchführen oder eine Funktion leichter bedienen können.

Output-Orientierung lässt sich in vielen Produktteams beobachten. Sie streben dann oft danach, die Arbeitszeit von Entwicklerinnen und Entwicklern maximal auszulasten. Eine hohe Anzahl an Arbeitsergebnissen erzeugt das Gefühl von Produktivität. Langfristig führt das aber nicht nur zu Produkten mit begrenzter Wirkung, sondern auch zu Frustration im Team. Gerade Developer erleben häufig, dass sie technisch anspruchsvolle Lösungen umsetzen, ohne zu wissen, ob diese überhaupt sinnvoll sind.

Outcome ist auch Entwickleraufgabe

Jetzt kann man es sich relativ einfach machen. Die Entscheidung, was gebaut wird, liegt häufig beim Produktmanagement oder der Konzeption. Als Entwicklerin oder Entwickler muss man „nur noch“ die Anforderungen umsetzen beziehungsweise in Code konvertieren. Dieses Übersetzen setzt jedoch einiges an Expertise voraus, denn gute Software zu bauen ist alles andere als trivial. Aber sich auf die Umsetzung von Features zurückzuziehen, entbindet Entwickler nicht von der Verantwortung, sich um die eigene Wirksamkeit zu kümmern. Sich nur als Umsetzende zu sehen, ist zu kurz gedacht, denn gerade Entwicklerinnen und Entwickler sitzen an zentraler Stelle. Sie übersetzen Ideen in Realität, treffen dabei aber wichtige Architekturentscheidungen und kennen die technischen Möglichkeiten und Grenzen am besten. Wenn sie in diesem Prozess Fragen zum angestrebten Outcome stellen, hilft Ihr Wissen dabei, gute Lösungen zu finden, statt nur Anforderungen umzusetzen.

Der stärkste Hebel sind die richtigen Fragen

Developer müssen aber nun keine neuen Rollen übernehmen. Häufig hilft es schon, an den richtigen Punkten die richtigen Fragen zu stellen (siehe Textkasten). Insbesondere in Terminen, in denen es um Anforderungen geht, entstehen oft wertvolle Diskussionen und somit auch Gelegenheiten, den Grund (den gewünschten Outcome) eines Features zu erfragen und durch das Gespräch gegebenenfalls den Fokus der Entwicklung zu verschieben. Warum soll das jeweilige Feature gebaut werden? Warum benötigen die User das Feature? Woran erkennt man hinterher, dass es sich gelohnt hat, das Feature zu entwickeln?

Natürlich ist es für diejenigen, die die Anforderungen stellen, einfacher, direkt eine bestimmte Funktion zu bestellen. Aber es ist überraschend, wie oft sich auch diese Menschen noch nicht so richtig Gedanken dazu gemacht haben, warum die Welt dieses Feature benötigt und welche Wirkung es eigentlich genau erzielen soll.

Sicherlich sollte jemand aus dem Produktmanagement oder anderen Bereichen die obigen Fragen beantworten können, aber zwei wichtige Aspekte darf man dabei nicht vergessen. Zum einen arbeiten auch dort nur Menschen. Vielleicht finden sie die Idee für das Feature einfach spannend oder haben einfach Lust darauf, es im Produkt zu sehen. Welche Wirkung es bei den Usern auslöst, wurde vielleicht nicht bedacht. Zum anderen passiert es jeder und jedem hin und wieder einmal, dass man sich sehr in einer Lösungsidee verfängt und aus den Augen verliert, dass die gleiche Wirkung auch auf einem anderen Weg erreichbar wäre.

Entwicklerinnen und Entwickler haben als vollwertige Teammitglieder auch die Aufgabe, dafür zu sorgen, die richtigen Dinge zu tun. Manche Teammitglieder wollen aber nicht als Widerstand empfunden werden. Vor allem wer noch nicht viel Arbeitserfahrung hat, stellt mitunter die eigene Perspektive hinten an und geht davon aus, dass der Rest schon wissen wird, warum es sinnvoll ist, das Feature zu bauen. Aber Fragen bremsen nicht, sie schärfen. Sie helfen Teams, bewusster Entscheidungen zu treffen.

Outcome in der täglichen Arbeit verankern

Eine verstärkte Outcome-Orientierung darf aber nicht vom Engagement einzelner Teammitglieder abhängen. Sie muss vielmehr Teil der Arbeitsroutine werden, und auch dazu gibt es wirksame Hebel. Einige Produktteams nutzen beispielsweise eine Definition of Ready (DoR), die beschreibt, welche Eigenschaften erfüllt sein müssen, damit eine Anforderung umgesetzt werden kann. Eine DoR kann dann unter anderem aufführen, dass bestimmte Fragen zum angestrebten Outcome beantwortet sein müssen. Zu diesen Fragen gehören beispielsweise die im Textkasten genannten. Durch die Einbindung solcher Fragen in die DoR müssen einzelne Entwicklerinnen und Entwickler nicht mehr jedes Mal nachfragen und gefühlt stören, sondern ein Team verpflichtet sich als Ganzes dazu, die Fragen abzuarbeiten. Wenn beim Überprüfen der DoR unklar ist, wofür eine Anforderung umgesetzt werden soll oder woran Erfolg erkennbar sein soll, ist es sinnvoll, die Umsetzung zu verschieben und erst einmal das angestrebte Ziel oder die angestrebte Wirkung zu klären.

Die Ergebnisse der Umfrage „State of Rust Survey 2025“ liegen vor: Immer mehr Entwicklerinnen und Entwickler setzen Rust in ihrem Arbeitsumfeld ein, können zunehmend produktiver damit arbeiten und verwenden dafür fast immer das aktuelle, stabile Release. Allerdings ist nur eine knappe Mehrheit der Teilnehmer mit dem Tempo zufrieden, mit dem sich Rust weiterentwickelt. Befürchtungen gibt es auch dahingehend, dass Rust zu komplex wird, Developer wie Maintainer zu wenig Unterstützung erhalten und sich die Programmiersprache im Unternehmensumfeld nicht durchsetzen kann.

Produktives Arbeiten am liebsten mit dem stabilen Release

Mehr als die Hälfte der Befragten meint, dass es sich mit Rust produktiv arbeiten lässt (56,8 Prozent). Damit setzt sich ein Trend fort, denn bei der Vorjahresumfrage stimmten noch 53,5 Prozent dieser Aussage zu, während es im Jahr 2023 nur 47 Prozent waren. Leicht gestiegen, auf 55,1 Prozent, ist auch der Anteil der Entwicklerinnen und Entwickler, die Rust täglich einsetzen. Unter den am häufigsten genannten Alltagsproblemen stehen dabei langsames Kompilieren (27,3 Prozent) und hoher Speicherbedarf für Zielverzeichnisse (22,2 Prozent) an vorderster Stelle.

Mit 89,2 Prozent setzt die große Mehrheit der Rust-Developer auf das aktuelle stabile Release. Sorge vor einem Upgrade hat dabei fast niemand, denn 97,1 Prozent stimmen der Aussage zu, dass der Wechsel auf eine neue stabile Compiler-Version sehr einfach ist und höchstens geringe Code-Anpassungen erfordert.

Vorsichtiger ist man bei Nightly-Upgrades, denn 56,9 Prozent erwarten hier Probleme wie Compiler-Fehler. Warum man diese trotzdem nutzt, beantworten knapp 31 Prozent damit, dass sie ein bestimmtes Feature nutzen wollen, das noch nicht in der stabilen Version zur Verfügung steht. Die Nightly-Version wird auch eingesetzt, weil ein bestimmtes Tool sie erfordert (10,8 Prozent) oder weil eine Crate-Abhängigkeit besteht (8,5 Prozent).

Hauptsorgen: Hohe Komplexität und mangelnder Support

Knapp 60 Prozent sind mit dem Tempo zufrieden, mit dem sich Rust weiterentwickelt. Einem Viertel geht es indes zu langsam und 41,6 Prozent meinen sogar, dass Rust zu komplex wird. Die ausbleibende Unterstützung für Developer und Maintainer sehen 38,4 Prozent als Problem an, ein Punkt, der gegenüber dem Vorjahr (35,4 Prozent) sogar in der Umfrage gestiegen ist. Hier spiegelt sich offensichtlich eine allgemeine Überforderung, die viele Projektverantwortliche bemängeln, oft neuerdings auch im Zusammenhang mit zunehmendem AI-Slop.

Den Spitzenplatz unter den Zukunftssorgen nimmt aber die Befürchtung ein, dass Rust in der Technologiebranche zu wenig Einsatz findet (42,1 Prozent). Die Umfrage macht allerdings auch einen gegenläufigen Trend sichtbar. Im Unternehmensumfeld wird Rust häufiger für den produktiven Einsatz herangezogen (48,8 Prozent), ein klares Plus gegenüber den Jahren 2023 und 2022, in denen noch 45,5 Prozent beziehungsweise 38,7 Prozent der Befragten diese Beobachtung gemacht haben. Zudem gibt ein Viertel der Teilnehmer an, dass ihr Unternehmen Rust-Developer einstellen will. Vergangenes Jahr waren es 22 Prozent und 2021 noch 19,6 Prozent.

Beliebteste Stable-Features und eine Wunschliste

Unter den Stable-Features, die in den letzten 12 Monaten dazugekommen sind, verwenden Entwicklerinnen und Entwickler Let Chains (71,4 Prozent) und Async Closures (55,5 Prozent) am häufigsten. Auf dem dritten Platz landet Trait Upcasting mit 28,1 Prozent. Im Gegensatz dazu werden Features wie Naked Functions, Strict Provenance API und diagnostic::do_not_recommend kaum benötigt.

Für das nächste stabile Release wünschen sich die Teilnehmer, dass noch nicht implementierte oder den Nightly-Versionen vorbehaltene Features wie Generic Const Expressions, Const Trait Methods, Stable ABI und Portable SIMD Aufnahme finden.

VS-Code-Nutzung sinkt

Die beliebteste Entwicklungsumgebung für Rust bleibt Visual Studio Code, allerdings mit weiter sinkendem Anteil. Im Jahr 2022 war es für 61,7 Prozent der Entwicklerinnen und Entwickler der Editor der Wahl, jetzt nur noch für 51,6 Prozent. Bei den genutzten Paketmanagern und Crate-Quellen sind die Sympathien klar verteilt. Rust-Developer verwenden fast ausschließlich Cargo (97,5 Prozent) und beziehen ihre Crates überwiegend von crates.io (96,6 Prozent). Einen großen Anteil machen mittlerweile auch die Git-Repositories aus, die 46,2 Prozent der Teilnehmer nutzen.

Linux ist als Rust-Entwicklungsplattform weiterhin das OS der Wahl (75,2 Prozent). macOS und Windows bringen es zusammen auf einen Anteil von 61,4 Prozent. Ein ähnliches Bild zeigt sich bei den Zielplattformen. Hier liegt Linux mit 88,4 Prozent vorn, gefolgt von Windows mit 43,3 Prozent und macOS mit 30,7 Prozent.

Mehr als 7000 Umfrage-Teilnehmende

Die vom Rust Survey Team durchgeführte Online-Umfrage „State of Rust Survey 2025“ lief 30 Tage lang vom 17. November bis zum 17. Dezember 2025 und war in zehn Sprachen verfügbar. Den kompletten Fragebogen beantworteten 7156 Entwicklerinnen und Entwickler, von denen sich eine Mehrheit von 23,4 Prozent in den USA verortete. Mit 13,4 Prozent folgten Teilnehmer aus Deutschland auf Platz zwei. Frankreich, Großbritannien und China machen mit zusammen etwa 16 Prozent die Plätze drei bis fünf unter sich aus.

Insgesamt unterscheiden sich die Antworten zum großen Teil nur geringfügig von der Umfrage aus dem Jahr 2024, so ihre Urheber. Die gegenüber den Vorjahren leicht gesunkene Beteiligung führt das Survey-Team auf die größere Anzahl von Umfragen zurück, die 2025 über den Rust-Blog lanciert wurden.

Sämtliche Ergebnisse der Umfrage stehen im Rust-Blog bereit. Die Auswertung gibt es auch als 59-seitigen PDF-Report.

(who)

Das OpenWrt-Projekt hat die Version 25.12.0 der Open-Source-Router-Firmware veröffentlicht. Besonders stechen darin die zahlreichen unterstützten Geräte und der Wechsel auf eine neue Paketverwaltung hervor.

In den Release-Notes liefert OpenWrt einen Überblick über die Änderungen. Als wichtigen Punkt vorneweg nennen die Entwickler, dass das Upgrade von OpenWrt 24.10 auf 25.12 in vielen Fällen vom sysupgrade-Werkzeug unterstützt wird, das versucht, die Konfiguration mitzumigrieren. Dennoch sollten Upgrade-Willige zuvor ein Backup ihrer Konfiguration anlegen, raten die OpenWrt-Programmierer. An OpenWrt 25.12.0 haben die Entwickler über ein Jahr lang gearbeitet und kommen auf mehr als 4700 Quellcode-Commits seit Fassung 24.10. Der Codename „Dave’s Guitar“ soll der Erinnerung des im April 2025 verstorbenen Dave Täht dienen.

OpenWrt: Änderungen unter der Haube

Der Paketmanager wechselt vom alten opkg zu apk (Alpine Package Keeper). Wichtigster Grund dafür ist, dass das OpenWrt-opkg nicht mehr unterstützt und apk weiterhin gepflegt wird. Nur wenige Paketnamen haben sich geändert. Ein Cheatsheet soll beim Umsteigen hilfreiche Informationen liefern. Außerdem liefert OpenWrt nun eine webbasierte „attended.sysupgrade“-LuCI-App (ASU) mit. Auf Geräten mit größerem Flash-Speicher installiert OpenWrt außerdem das Kommandozeilen-Tool „owut“ (OpenWrt Upgrade Tool) standardmäßig mit. ASU soll auf neue OpenWrt-Versionen aktualisieren und Firmware-Images automatisch mit allen derzeit installierten Paketen zusammenbauen können. Dabei erhält es die Systemkonfiguration und erlaubt die Integration zusätzlicher installierter Pakete direkt in das SquashFS-Dateisystem. Das soll Upgrades deutlich vereinfachen: Mit nur wenigen Klicks in LuCI und nach kurzer Wartezeit steht ein angepasstes Firmware-Abbild bereit, das ohne weitere manuelle Eingriffe installiert wird.

Außerdem speichert OpenWrt in einem RAM-basierten Dateisystem den Befehlsverlauf der Shell. Der steht damit auch nach neuen Logins bereit. Das erspart unnötige Schreibzugriffe auf den Flash-Speicher, der nur eine begrenzte Zahl an Schreibzyklen verkraftet. Das lässt sich jedoch umstellen, sodass auch persistente Speicherung auf dem Flash-Speicher möglich ist. Das erhöht jedoch die Schreibzyklen und wirkt sich auf die Flash-Lebensdauer aus, warnen die Entwickler.

Hard- und Software-Unterstützung

Hardwareseitig gibt es mehr Unterstützung für Realtek-Ziele, dort insbesondere mehr Switch-SoCs mit 10-GBit-Support. Das qualcommax-Ziel unterstützt zwei weitere SoCs. Neu dabei ist ein siflower-Build-Target und neue Sub-Targets für Allwinner-F1C100/200s-SoCs. Ebenfalls neu dabei ist der Microchip LAN969x-Switch-Chipsatz. Insgesamt kommt OpenWrt nun auf mehr als 2200 unterstützte Geräte. Seit OpenWrt 24.10 sind 180 neu dazugekommen.

Die Software ist ebenfalls aktueller: Der Linux-Kernel 6.12.71 kommt für alle Build-Targets zum Einsatz, außerdem sind die Stände von glibc 2.41, gcc 14.3.0, binutils 2.44 dabei. Als zentrale Komponenten sind nun die Fassungen busybox 1.37.0, dropbear 2025.89 und dnsmasq 2.91 Bestandteil von OpenWrt. OpenWrt 24.10 erreicht mit dem Release von OpenWrt 25.12.0 in sechs Monaten das Support-Ende, also gibt es dafür nach September 2026 keine Sicherheitsupdates mehr. Nutzer sollten daher die Zeit nutzen und zeitnah auf die neue Version aktualisieren.

Ende Oktober musste das OpenWrt-Projekt Sicherheitslücken schließen. Die haben Angreifern etwa das Einschleusen und Ausführen von Schadcode oder das Ausweiten ihrer Rechte im System ermöglicht.

(dmk)