Google hat die erste Beta von Android 17 QPR1 (Quarterly Platform Release) für Pixel-Geräte veröffentlicht. Die Vorabversion mit der Bildnummer CP31.260403.005.A1 kann auf dem Pixel 6 und neueren Modellen des Herstellers ausprobiert werden. Die fertige Version erscheint voraussichtlich im September als sogenannter „Pixel Drop“ für Googles Pixel-Geräte.

Android 17 QPR1 Beta laut Google stabil

Während das große Update auf Android 17 weitgehend fertig ist – es hat bereits im März Plattformstabilität erreicht, sodass Entwickler ihre Apps auf die neuen Schnittstellen auslegen können – arbeitet das Entwickler-Team bei Google am ersten QPR-Release auf Basis der neuen Android-Version.

Damit ist Google in diesem Jahr schneller als im vergangenen: Die erste QPR1-Beta von Android 16 erschien erst Ende Mai 2025. Das dürfte aber damit zu tun haben, dass Google zuerst die größeren Designänderungen, die mit Material 3 Expressive einhergingen, im Zuge der Android Show im Mai erklären wollte. In diesem Jahr gibt es mit Android 17 nicht schon wieder ein großes optisches Update.

QPR-Versionen enthalten in der Regel neue Funktionen und Erweiterungen bestehender Features. Die erste Beta von Android 17 QPR1 scheint indes keine Neuerungen an Bord zu haben. Stattdessen enthält das Update in erster Linie Fehlerkorrekturen. Zudem sagt Google, dass diese Version über keine neuen Schnittstellen verfüge – diese werden nur halbjährlich ausgeliefert, wie das Unternehmen bereits im Jahr 2024 mitteilte. Neue Schnittstellen sind zum einen im Major Release (etwa Android 16 und 17) und zum anderen in der QPR2 enthalten, die in der Regel im Dezember veröffentlicht wird. Dabei seien die Schnittstellenänderungen der QPR2 „weitgehend additiv und so konzipiert, dass zusätzliche App-Tests auf ein Minimum reduziert werden“ könnten, sagt Google.

Der Hersteller erklärt ferner, dass „diese Builds für den allgemeinen Gebrauch geeignet“ seien. Bei den Entwicklervorschauen und Betaversionen für noch nicht veröffentlichte Hauptversionen sei das nicht der Fall.

Bugfixes

Das Update behebt Google zufolge einige bekannte Probleme. So behebt die neue Version einen Fehler im Standarddruckdienst, „der bei niedrigem Tintenstand auftrat und verhinderte, dass Nutzer Druckaufträge abschließen konnten“ (Problem #487545419). Weiter fixt Google in der QPR1 Beta 1 einen Fehler in der Terminal-App, bei der ein ANR-Fehler („App antwortet nicht“) ausgelöst wurde, ‚der dazu führt, dass die App und das Gerät nicht mehr reagieren’“ (Problem #497465940).

Weiter adressiert das Update ein Problem, „bei dem die unkontrollierbare Hardware-Audioverarbeitung auf dem Sprachkommunikationspfad zu Verzerrungen und Phasenauslöschung in VoIP-Anwendungen führte“ (Problem #494843726). Außerdem löst die Aktualisierung einen Fehler, der bei der direkten Audioausgabe auftritt. Es kam vor, dass auf Geräten, die AIDL-Audio-HAL verwenden, die Audioausgabe nicht geöffnet wurde, wenn Audiostreams länger als fünf Sekunden wiedergegeben wurden (Problem #372064012), so Google.

Warten auf Android 17

Google macht darauf aufmerksam, dass Beta-Nutzer, die die bald erscheinende stabile Version von Android 17 auf ihrem Pixel-Gerät installieren wollen, die angebotene QPR-Beta nicht installieren sollen. Wer die stabile Android-17-Version erhalten möchte, müsse sich zudem vom Betaprogramm abmelden und auf das finale Update warten, auf diesem Wege blieben alle Daten auf dem Gerät erhalten.

Falls man sich nach der Installation der Beta 1 oder zukünftigen Updates aus dem Betaprogramm abmeldet, „werden alle Benutzerdaten auf dem Gerät gemäß den üblichen Programmrichtlinien gelöscht“, erklärt das Unternehmen weiter.

(afl)

In seinem Vortrag „KI-zentrierte Softwaredokumentation: Einblicke in die Praxis von KI-Startups“ auf der Online-Konferenz betterCode() ArchDoc 2025 hat Ingo Eichhorst Konzepte für die automatisierte Dokumentation von Architekturprojekten vorgestellt. Dabei zeigt er praxisnahe Beispiele aus seinen Arbeitsbereichen in KI-Start-ups.

Die von ihm vorgestellten Ansätze reichen von der automatisierten Qualitätssicherung durch simulierte Interaktionen von Entwicklern bis hin zu sich selbst dokumentierenden Systemen. Dabei können moderne Dokumentationssysteme nicht nur Wissen festhalten, sondern auch die Resilienz des gesamten Softwaresystems erhöhen.

Sein Ansatz startet bei der Spezifikation eines Projekts, die nicht nur die zu erfüllenden Aufgaben der Software beschreibt, sondern auch weitere benötigte Daten aus dem Kontext mitliefert wie Architekturvorgaben, Domänenmodell oder Unternehmensspezifika: „Gib dem Modell die Informationen, die du selbst bräuchtest, um die Aufgabe zu erfüllen“, lautet das Motto des Redners. Die Spezifikation wird zur Single Source of Truth, und Entwicklerinnen und Entwickler arbeiten in Folge nur mit dieser.

Die konkrete Ausgestaltung des Codes und der zugehörigen Dokumentation obliegt hingegen dem LLM. Konkrete Hilfsmittel für die KI können dabei etwa eine Repo-Map und ein arc42-Template sein. Auch durch Korrekturschleifen erforderliche Änderungen finden nur in der Spezifikation statt. Die Entscheidungen für diese Anpassung der Architektur ergeben dabei mehr oder weniger fertige Architecture Decision Records.

Grafiken und Storytelling

Für die konkrete Ausgestaltung der Dokumentation ergeben sich mithilfe von KI viele Möglichkeiten: Das LLM übernimmt eine zielgruppengerechte Lesersicht, schreibt lesefreundliche, einfach zugängliche Geschichten zum Projekt und reduziert so die kognitive Belastung. Auch die zugehörigen Grafiken lassen sich automatisiert zum Beispiel aus JSON-Angaben erzeugen.

Sogar eine Bewertung der Dokumentation kann durch KI selbst erfolgen, zum Beispiel durch Digital Twins von Menschen. Das LLM korrigiert dann auf Wunsch automatisiert seine Arbeit. Am Schluss des Vortrags stellt Eichhorst ein Projekt vor, in dem die KI eine komplette Doku überarbeitet hat. Dabei lässt sich ein Wildwuchs aus verzweigten, über viele Webseiten verteilten Angaben systematisch zusammenführen.

(who)

Wer heute Software entwickelt und dafür Geld verlangt, muss sich rechtfertigen. Wer sie verschenkt, gilt als moralisch überlegen. Diese Haltung hat ein Strukturproblem geschaffen, das die gesamte Branche betrifft.

Open Source hat in den vergangenen Jahrzehnten die Softwareentwicklung grundlegend verändert, und zwar überwiegend zum Besseren. Quelloffene Projekte haben Wissen demokratisiert, Zusammenarbeit über Unternehmensgrenzen hinweg ermöglicht und Innovationszyklen beschleunigt. Doch hinter der Erfolgsgeschichte verbirgt sich ein Mechanismus, den erstaunlich wenige hinterfragen: Open Source ist längst nicht mehr nur ein Modell der Zusammenarbeit. Es ist zu einem strategischen Instrument geworden, das vor allem denjenigen nutzt, die es am wenigsten nötig haben.

Wenn kostenlos zur Währung wird

Es gibt einen Satz, den vermutlich jede Entwicklerin und jeder Entwickler schon einmal gehört hat:

„Warum soll ich dafür bezahlen, wenn es das auch als Open Source gibt?“

Die Frage klingt pragmatisch, beinahe vernünftig. Doch sie offenbart ein Denkmuster, das sich über Jahre eingeschliffen hat und das weitreichende Konsequenzen hat.

Open Source hat dazu beigetragen, dass wir den Wert von Softwarearbeit systematisch herabgesetzt haben. Nicht den Wert der Ausführung, wohlgemerkt, denn Entwicklerinnen und Entwickler werden nach wie vor gut bezahlt, wenn sie in Anstellung arbeiten. Sondern den Wert der Gedankenleistung, die in ein Softwareprodukt fließt: das Durchdenken einer Architektur, das Entwerfen einer API, das Lösen eines komplexen fachlichen Problems. All das verschenken wir, weil es als selbstverständlich gilt, dass Software im Quellcode frei verfügbar sein sollte.

Was dabei verloren geht, ist das Bewusstsein dafür, dass Softwareentwicklung nicht nur Handwerk ist, sondern auch geistige Schöpfung. Wenn ein Autor ein Buch schreibt, erwartet niemand, dass er es kostenlos verteilt. Wenn eine Architektin ein Gebäude entwirft, käme niemand auf die Idee, den Entwurf als Open Source zu veröffentlichen. Doch bei Software hat sich die Erwartung etabliert, dass alles, was nicht hinter einer Bezahlschranke steht, auch nichts kosten darf. Und wer dennoch Geld verlangt, steht unter Rechtfertigungsdruck.

Das ist eine bemerkenswerte Entwicklung. Innerhalb weniger Jahrzehnte haben wir uns daran gewöhnt, dass die intellektuelle Leistung hinter Software keinen monetären Wert hat, solange sie in Form von Quellcode vorliegt. Wir haben kostenlos zur Normalität erklärt und Bezahlen zur Ausnahme. Dabei übersehen wir, dass hinter jeder Bibliothek, jedem Framework und jedem Tool Hunderte oder Tausende Stunden stecken, in denen jemand nachgedacht, entworfen, verworfen und neu gebaut hat. Diese Stunden haben einen Wert. Doch das vorherrschende Narrativ der Branche erzählt uns, dass dieser Wert erst dann legitim ist, wenn jemand anderes darauf einen Service baut und diesen verkauft.

Das Spiel der Großen

Wer verstehen will, warum Open Source heute so funktioniert, wie es funktioniert, muss den Blick auf diejenigen richten, die am meisten davon profitieren. Und das sind nicht die einzelnen Entwicklerinnen und Entwickler, die ihre Wochenenden in ein Projekt investieren. Es sind die großen Technologiekonzerne.

Nehmen wir PostgreSQL als Beispiel. PostgreSQL gilt als Vorzeigeprojekt der Open-Source-Welt: stabil, leistungsfähig, kostenlos. Was viele nicht wissen oder bewusst ausblenden: Ein erheblicher Teil der Entwicklung wird von Unternehmen wie Microsoft, Google und Amazon finanziert. Die Entwicklerinnen und Entwickler, die den Kern von PostgreSQL vorantreiben, sind zu großen Teilen bei genau diesen Konzernen angestellt.

Auf den ersten Blick wirkt das wie Altruismus. Microsoft investiert in eine Datenbank, die dem eigenen Produkt (dem SQL Server) Konkurrenz macht. Warum sollte ein Konzern das tun? Die Antwort ist ernüchternd schlicht: Weil sich die Rechnung trotzdem lohnt. Jede PostgreSQL-Instanz, die auf Azure läuft, bringt Microsoft Umsatz. Es spielt keine Rolle, ob der SQL Server dabei Marktanteile verliert, solange die Cloud-Plattform gewinnt. Die Investition in Open Source ist keine Spende. Sie ist eine strategische Entscheidung mit kalkulierbarem Return.

Dieses Muster wiederholt sich in der gesamten Branche. Kubernetes wird maßgeblich unter anderem von Google und Microsoft vorangetrieben. Linux wird von allen großen Cloudanbietern unterstützt, weil es die Grundlage ihrer Infrastruktur bildet. Chromium ist Open Source, doch Google kontrolliert die Richtung. Überall dort, wo Konzerne Open-Source-Projekte finanzieren, geschieht das nicht aus Idealismus. Es geschieht, weil es ihr Geschäftsmodell stützt.

Und es geht noch weiter. Viele der großen Open-Source-Projekte werden über Foundations organisiert, die den Anschein von Neutralität und Gemeinschaftlichkeit erwecken. Die Cloud Native Computing Foundation, die Linux Foundation, die Apache Software Foundation: Sie alle werden in erheblichem Maße von denselben Konzernen getragen, die von den Projekten profitieren. Die Foundation-Struktur verleiht dem Ganzen Legitimität und schafft den Eindruck, hier arbeite eine unabhängige Community am Gemeinwohl. Im Hintergrund sind es aber oft dieselben Geldgeber, die auch die strategische Ausrichtung beeinflussen.

Es wäre naiv, das als Zufall abzutun. Die Konzerne haben erkannt, dass Open Source ein hervorragendes Mittel ist, um Märkte zu gestalten, ohne die damit verbundenen Kosten vollständig selbst tragen zu müssen. Die Community liefert Code, Dokumentation, Bug-Reports und Evangelismus. Die Konzerne liefern Infrastruktur, Hosting und Managed-Services. Wer dabei das bessere Geschäft macht, muss man nicht lange überlegen.

Die doppelte Mauer für kleine Anbieter

Was bedeutet das für diejenigen, die Software nicht verschenken können oder wollen? Für kleine Unternehmen, die mit einem kommerziellen Produkt am Markt bestehen müssen?

Sie stehen vor einer doppelten Herausforderung. Auf der einen Seite konkurrieren sie mit den Großen, die über nahezu unbegrenzte Ressourcen verfügen: Marketing-Budgets, Vertriebsstrukturen, Bekanntheit. Das war schon immer schwierig. Doch Open Source hat eine zweite Barriere geschaffen, die mindestens ebenso wirksam ist.

Denn kleine Anbieter konkurrieren nicht nur mit den Konzernen selbst. Sie konkurrieren auch mit den Open-Source-Alternativen, die von eben diesen Konzernen finanziert werden. Wer eine kommerzielle Datenbank anbietet, kämpft nicht nur gegen Oracle und Microsoft. Er kämpft auch gegen PostgreSQL und gegen die Erwartungshaltung, dass eine Datenbank nichts kosten darf, weil es ja eine kostenlose Alternative gibt.

Open Source wird auf diese Weise zum Burggraben der großen Konzerne. Nicht, weil die Konzerne die Open-Source-Projekte direkt kontrollieren, sondern weil sie über die Finanzierung ein Ökosystem geschaffen haben, in dem kommerzielle Alternativen es schwer haben, überhaupt wahrgenommen zu werden. Der Markt wird von zwei Seiten eingeengt: von oben durch die Konzerne mit ihren Managed-Services, von unten durch die kostenlosen Alternativen, die oft von denselben Konzernen mitfinanziert werden.

Wer als kleines Unternehmen in diesem Umfeld ein kommerzielles Softwareprodukt anbietet, muss nicht nur technisch überzeugen. Er muss zunächst einmal erklären, warum das eigene Produkt überhaupt etwas kosten darf. Diese Erklärungspflicht existiert in kaum einer anderen Branche in dieser Form. Niemand fragt einen Handwerker, warum sein Angebot nicht kostenlos ist. Niemand erwartet von einer Steuerberaterin, dass sie ihre Arbeit verschenkt, weil es irgendwo eine kostenlose Vorlage gibt. Doch bei Software ist diese Frage so tief verankert, dass sie oft nicht einmal bewusst gestellt wird. Sie schwingt einfach mit, in jedem Evaluierungsprozess, in jeder Kaufentscheidung, in jedem Vergleich.

Das Ergebnis ist ein Markt, der Innovation dort bremst, wo sie am meisten gebraucht würde. Kleine, spezialisierte Anbieter, die spezifische Probleme besser lösen könnten als generische Open-Source-Werkzeuge, schaffen es oft gar nicht erst in die engere Auswahl. Nicht, weil ihre Produkte schlechter sind, sondern weil sie gegen eine Erwartungshaltung antreten, die von den Großen systematisch kultiviert wird.

Besonders perfide ist dabei die Dynamik, die sich aus dem Zusammenspiel ergibt. Die Konzerne finanzieren Open-Source-Projekte, die den Markt für kommerzielle Alternativen austrocknen. Gleichzeitig bauen sie auf denselben Open-Source-Projekten Managed-Services auf, die sie gewinnbringend verkaufen. Der kleine Anbieter zahlt also doppelt: Er verliert potenzielle Kundinnen und Kunden an die kostenlose Alternative und an den Managed-Service des Konzerns, der auf eben dieser Alternative basiert.

Die blinden Flecken der Community

An dieser Stelle wird es unbequem. Denn die Konzerne können dieses Spiel nur spielen, weil die Community es mitträgt. Und zwar nicht aus böser Absicht, sondern aus einer Mischung aus Idealismus und Kurzsichtigkeit.

In der Entwickler-Community hat sich über Jahrzehnte eine Überzeugung verfestigt, die selten hinterfragt wird: Open Source ist gut. Kommerziell ist verdächtig. Wer Software verschenkt, handelt im Sinne der Gemeinschaft. Wer Geld dafür verlangt, hat erklärungsbedürftige Motive.

Diese Haltung ist verständlich. Sie wurzelt in einer Zeit, in der Software tatsächlich überteuert war, in der Lizenzmodelle undurchsichtig waren und Vendor-Lock-in die Regel. Open Source war die Antwort auf reale Probleme, und es hat viele dieser Probleme gelöst. Doch die reflexhafte Verteidigung von Open Source als moralisch überlegenes Modell ignoriert, wie sich die Rahmenbedingungen verändert haben.

Heute ist Open Source kein Gegenmodell mehr zu den großen Konzernen. Es ist ein integraler Bestandteil ihrer Strategie. Und wer in der Community weiterhin jedes Open-Source-Projekt verteidigt, ohne zu fragen, wer dahintersteht und wer davon profitiert, macht sich zum Werkzeug genau jener Interessen, die man eigentlich kritisch sehen sollte.

Das zeigt sich besonders deutlich im Umgang mit Maintainerinnen und Maintainern, die an ihren Projekten zerbrechen. Die Burnout-Rate unter Open-Source-Maintainern ist erschreckend hoch. Menschen investieren Jahre ihrer Freizeit in Projekte, die von Millionen genutzt werden, und erhalten dafür bestenfalls Anerkennung, schlimmstenfalls Beschwerden über zu langsame Bugfixes. Die Community reagiert darauf mit Mitleid und dem Verweis auf Sponsoring-Modelle, die in der Praxis kaum funktionieren. Was sie nicht tut: die grundlegende Frage stellen, ob es richtig ist, dass diese Arbeit überhaupt kostenlos erwartet wird.

Denn genau das ist der blinde Fleck. Die Community verteidigt ein System, das den Wert von Arbeit nach dem Lizenzmodell bemisst, nicht nach der Qualität oder dem Nutzen. Ein Projekt ist gut, weil es Open Source ist. Nicht, weil es ein Problem besser löst als die Alternativen. Diese Umkehrung der Bewertungskriterien schadet nicht nur den Maintainern. Sie schadet der gesamten Softwarebranche, weil sie Innovation dort bremst, wo sie am dringendsten gebraucht wird: bei kleinen, spezialisierten Anbietern, die es sich nicht leisten können, ihre Arbeit zu verschenken.

Und es gibt noch einen weiteren Aspekt, der selten ausgesprochen wird: Viele Nutzerinnen und Nutzer wählen Open Source nicht aus Überzeugung, sondern schlicht, weil es kostenlos ist. Die moralische Überhöhung dient als bequeme Rechtfertigung für eine Entscheidung, die im Kern ökonomisch motiviert ist. Das wäre an sich nicht verwerflich. Doch es wird problematisch, wenn dieselben Menschen andere dafür kritisieren, dass sie für ihre Software Geld verlangen. Es entsteht eine Kultur, in der kostenlos als ethisch gilt und das Verlangen einer Bezahlung als gierig, und in der diese Zuschreibungen kaum noch hinterfragt werden.

Wer etwa als Unternehmen eine Technologieentscheidung trifft und sich für ein Open-Source-Produkt entscheidet, tut das selten aus ideologischer Überzeugung. Die Budgetfreigabe für ein kostenloses Tool ist schlicht einfacher als für ein kommerzielles. Dass die versteckten Kosten in Form von Einarbeitung, Anpassung und fehlendem Support oft höher liegen als ein Lizenzpreis, wird in der Kalkulation gerne übersehen. Open Source gewinnt die Evaluierung nicht, weil es besser ist, sondern weil es den geringeren Erklärungsbedarf hat.

Weder zurück noch weiter so

Ich möchte nicht missverstanden werden. Dieser Blogpost ist kein Plädoyer gegen Open Source. Ich möchte nicht zurück in eine Zeit, in der ein C-Compiler mehrere tausend Mark kostete und eine Textverarbeitung ein Luxusgut war. Open Source hat Barrieren abgebaut, Wissen zugänglich gemacht und die Art, wie wir Software entwickeln, grundlegend verbessert. Das ist eine Leistung, die man nicht kleinreden sollte.

Aber ebenso wenig sollte man die Augen davor verschließen, was aus Open Source geworden ist. Es ist heute nicht mehr nur ein Modell der Zusammenarbeit und des Teilens. Es ist ein strategisches Werkzeug in den Händen von Konzernen, die es nutzen, um ihre Marktposition zu sichern und den Wettbewerb einzuschränken. Und es ist ein System, das die Arbeit derjenigen entwertet, die es am Leben halten.

Das Problem ist nicht Open Source selbst. Das Problem sind die Strukturen, die sich um Open Source herum gebildet haben. Es sind die Konzerne, die Open-Source-Projekte instrumentalisieren, ohne dafür die Verantwortung zu übernehmen, die mit einer solchen Abhängigkeit einhergeht. Und es ist eine Community, die dieses Spiel unreflektiert mitspielt, weil die Alternative bedeuten würde, liebgewonnene Überzeugungen infrage zu stellen.

Was es braucht, ist ein differenzierterer Blick. Ein Verständnis dafür, dass Open Source und kommerziell keine moralischen Kategorien sind, sondern Lizenzmodelle. Dass die Frage nicht lautet, ob Software etwas kosten darf, sondern wer davon profitiert, wenn sie es nicht tut. Und dass die reflexhafte Verteidigung von „kostenlos“ oft genau denen in die Hände spielt, deren Marktmacht man eigentlich einschränken wollte.

Open Source ist nicht das Problem. Aber wer so tut, als wäre es die Lösung für alles, hat das eigentliche Problem noch nicht erkannt.

(rme)