DrWindows
Redaktion
Kommentar zum Kommentar: Ein bezahltes Chromium löst das Problem nicht
von Kevin Kozuszek
Am vergangenen Dienstag hatte Martin in einem Kommentar zum aktuellen Antitrust-Verfahren gegen Google in den USA und zu einem möglichen Verkauf von Chrome Stellung genommen. Während ich mit dem wesentlichen Teil der Analyse, was die Dominanz von Chrome und dessen Nachteiligkeit für den Wettbewerb betrifft, durchaus einverstanden bin, sieht das bei den Lösungsvorschlägen gänzlich anders aus. Vor allem ein Punkt ist extrem problematisch.
Mir geht es dabei nicht um die bessere Verzahnung mit anderen Bezahlmodellen. Mozilla ist bereits ein Beispiel dafür, wo Dienste wie Pocket, Firefox Relay oder Mozilla VPN entweder direkt oder über Addons besser mit Firefox als Browser zusammenspielen sollen. Wenn man aber meint, das Problem würde gelöst, wenn man die anderen Chromium-Nutzer zur Kasse bittet und daraus ein rein kommerzielles und geschlossenes Projekt zu machen, dann zeugt das eher von einer gewissen Naivität, Blauäugigkeit und einem fehlenden Bewusstsein dafür, was das konkret in der Folgenabschätzung bedeuten würde. Die Folgen wären nämlich extrem.
Das Grundproblem
Chromium ist für sich genommen erstmal keine Engine, sondern eine Plattform, deren kollektive Zusammenarbeit mittlerweile auch verstärkt unter dem Dach der Linux Foundation organisiert wird. Weitaus wichtiger ist aber seine Rolle als Industriestandard, der er mittlerweile geworden ist und dessen Rolle weit über die Browserwelt hinaus geht. Viele Apps am Desktop oder den mobilen Plattformen basieren entweder direkt (über Electron, dem CEF oder React Native) oder indirekt (über Qt mit der QtWebEngine, .NET mit WebView2 etc.) zumindest teilweise darauf. Für JavaScript-Frameworks ist es über Node.js die Referenz.
Betrachtet man nur klassische Apps, ist völlig klar, dass gerade die kleineren Entwickler die höheren Kosten wie bei materiellen Gütern entlang der gesamten Wertschöpfungskette bis zum Endnutzer durchreichen müssen, während die Megakonzerne wie Microsoft sowas vielleicht noch querfinanzieren würden. Ein Mittelständler kann sich diese finanziellen Einbußen schlicht nicht leisten, und selbst bei den großen Kalibern wäre nicht sicher, dass sie zahlen. Das beste Beispiel ist die Android-Entwicklung: Eine direkte Folge aus dem Rechtsstreit zwischen Google und Oracle war letztlich, dass fortan das OpenJDK zur Grundlage wurde und die von JetBrains entwickelte Programmiersprache Kotlin statt Java zur bevorzugten Wahl erklärt worden ist.
Dramatischer wird es dann, wenn man die wichtige Rolle von JavaScript innerhalb des Internets als Ökosystem betrachtet. Hier bietet der Kommentar auf die möglichen Auswirkungen keine Lösung an, wer letztlich die Kosten zahlen soll, die an Chromium gehen müssten. Sämtliche Seitenbetreiber? Die Hoster, die die Kosten dann auf die Seitenbetreiber umlegen? Die Internetprovider, die dafür die Kosten für die Endkunden erhöhen? Was ist eigentlich mit Gemeinnützigkeit oder der öffentlichen Verwaltung? Gähnende Leere, was diese Folgenabschätzung betrifft, und dabei sind wir noch nicht zum Kern dessen vorgestoßen, wie Open Source-Projekte im Regelfall reagieren würden.
Don’t pay, just fork!
In erster Linie ist Open Source zwar ein Entwicklungsmodell, im allgemeinen Verständnis ist damit aber auch ein Wertekanon und andere Charakteristika verbunden. Wenn sich bei einem bestimmten Projekt eine Entwicklung abzeichnet, die diesem Selbstverständnis zuwider laufen, dann wird es nicht mehr lange dauern, bis ein Fork quasi schon beschlossene Sache ist. Beispiele aus der Vergangenheit finden sich im Großen wie im Kleinen tonnenweise, deswegen möchte ich nur exemplarisch einige Beispiele aufzählen:
Dass es anders ausgeht, ist tatsächlich sehr selten und konnte dann meistens auch nur unter großen Anstrengungen verhindert werden. Wo es gut ausgegangen ist, waren die Verhandlungen zwischen dem KDE e.V. und der Qt Company, als diese im Hinblick auf das kommende Qt 6.0 Pläne zur Einschränkung der LTS-Versionen im FOSS-Umfeld ankündigte. Auch Facebook bekam 2017 nochmal die Kurve, als es zunächst die BSD-Lizenz bei React Native mit einer Zusatzklausel versehen hat, ehe man zusammen mit React selbst zur MIT-Lizenz gewechselt ist.
Grundsätzlich muss man festhalten, dass das FOSS-Umfeld eiserne Prinzipien und ein klares Selbstverständnis hat, wo man sich nicht erpressen lassen und in aller Regel auch einen neuen Status Quo nicht akzeptieren würde. Das ist einfach so. Wendet man das auf Chromium an, ist es viel wahrscheinlicher, dass ein neuer Fork unter der Federführung von Microsoft, Opera und Vivaldi, die allesamt dank Trident, EdgeHTML und Presto auch schon Erfahrung in der Entwicklung von Browser-Plattformen inkl. ihrer Engines haben, entsteht und dieser dann unter dem Dach der Linux Foundation betrieben wird, wo schon Strukturen aufgebaut werden. Chromium wäre vielleicht tot, aber grundsätzlich geht es weiter wie bisher.
Was sonst?
Mit einer geschlossenen Bezahlversion von Chromium würde man keine Probleme lösen und, selbst wenn man es durchziehen würde, dafür viele andere Probleme an anderen Stellen maximal öffnen. Gleichzeitig gehört es zur bitteren Wahrheit auch dazu, dass wir es uns nicht leisten können, einerseits Chromium als heutigen Industriestandard und andererseits besonders Gecko (aber auch WebKit2) wegen der Webstandards und ihrer Entwicklung zu verlieren. Die Lösungen für die Gesamtproblematik müsste also kreativer ausfallen:
Schlusswort
Mir liegt es fern, Martin bei seinem Kommentar wirklich in die Parade zu fahren oder irgendwelche Vorwürfe zu machen. Dennoch ist eine mögliche Lösung nur dann eine Lösung, wenn man die Folgen einer Maßnahme richtig abschätzen kann und dabei nicht alles noch viel schlimmer wird. Mit der Analyse aus dem vorherigen Kommentar kann ich in vielen Punkten durchaus zustimmen, aber die Idee eine Bezahlversion von Chromium, deren Quellcode auch noch geschlossen würde, geht einfach an der Realität vorbei und der entstehende Schaden würde die Maßnahme nicht im Ansatz mehr rechtfertigen.
Schreibt eure Gedanken dazu gerne in die Kommentare.
Der Beitrag Kommentar zum Kommentar: Ein bezahltes Chromium löst das Problem nicht erschien zuerst auf Dr. Windows.
Hinweis: Der Artikel wird möglicherweise nicht vollständig angezeigt, eingebettete Medien sind in dieser Vorschau beispielsweise nicht zu sehen.
Artikel im Blog lesen
von Kevin Kozuszek
Am vergangenen Dienstag hatte Martin in einem Kommentar zum aktuellen Antitrust-Verfahren gegen Google in den USA und zu einem möglichen Verkauf von Chrome Stellung genommen. Während ich mit dem wesentlichen Teil der Analyse, was die Dominanz von Chrome und dessen Nachteiligkeit für den Wettbewerb betrifft, durchaus einverstanden bin, sieht das bei den Lösungsvorschlägen gänzlich anders aus. Vor allem ein Punkt ist extrem problematisch.
Mir geht es dabei nicht um die bessere Verzahnung mit anderen Bezahlmodellen. Mozilla ist bereits ein Beispiel dafür, wo Dienste wie Pocket, Firefox Relay oder Mozilla VPN entweder direkt oder über Addons besser mit Firefox als Browser zusammenspielen sollen. Wenn man aber meint, das Problem würde gelöst, wenn man die anderen Chromium-Nutzer zur Kasse bittet und daraus ein rein kommerzielles und geschlossenes Projekt zu machen, dann zeugt das eher von einer gewissen Naivität, Blauäugigkeit und einem fehlenden Bewusstsein dafür, was das konkret in der Folgenabschätzung bedeuten würde. Die Folgen wären nämlich extrem.
Das Grundproblem
Chromium ist für sich genommen erstmal keine Engine, sondern eine Plattform, deren kollektive Zusammenarbeit mittlerweile auch verstärkt unter dem Dach der Linux Foundation organisiert wird. Weitaus wichtiger ist aber seine Rolle als Industriestandard, der er mittlerweile geworden ist und dessen Rolle weit über die Browserwelt hinaus geht. Viele Apps am Desktop oder den mobilen Plattformen basieren entweder direkt (über Electron, dem CEF oder React Native) oder indirekt (über Qt mit der QtWebEngine, .NET mit WebView2 etc.) zumindest teilweise darauf. Für JavaScript-Frameworks ist es über Node.js die Referenz.
Betrachtet man nur klassische Apps, ist völlig klar, dass gerade die kleineren Entwickler die höheren Kosten wie bei materiellen Gütern entlang der gesamten Wertschöpfungskette bis zum Endnutzer durchreichen müssen, während die Megakonzerne wie Microsoft sowas vielleicht noch querfinanzieren würden. Ein Mittelständler kann sich diese finanziellen Einbußen schlicht nicht leisten, und selbst bei den großen Kalibern wäre nicht sicher, dass sie zahlen. Das beste Beispiel ist die Android-Entwicklung: Eine direkte Folge aus dem Rechtsstreit zwischen Google und Oracle war letztlich, dass fortan das OpenJDK zur Grundlage wurde und die von JetBrains entwickelte Programmiersprache Kotlin statt Java zur bevorzugten Wahl erklärt worden ist.
Dramatischer wird es dann, wenn man die wichtige Rolle von JavaScript innerhalb des Internets als Ökosystem betrachtet. Hier bietet der Kommentar auf die möglichen Auswirkungen keine Lösung an, wer letztlich die Kosten zahlen soll, die an Chromium gehen müssten. Sämtliche Seitenbetreiber? Die Hoster, die die Kosten dann auf die Seitenbetreiber umlegen? Die Internetprovider, die dafür die Kosten für die Endkunden erhöhen? Was ist eigentlich mit Gemeinnützigkeit oder der öffentlichen Verwaltung? Gähnende Leere, was diese Folgenabschätzung betrifft, und dabei sind wir noch nicht zum Kern dessen vorgestoßen, wie Open Source-Projekte im Regelfall reagieren würden.
Don’t pay, just fork!
In erster Linie ist Open Source zwar ein Entwicklungsmodell, im allgemeinen Verständnis ist damit aber auch ein Wertekanon und andere Charakteristika verbunden. Wenn sich bei einem bestimmten Projekt eine Entwicklung abzeichnet, die diesem Selbstverständnis zuwider laufen, dann wird es nicht mehr lange dauern, bis ein Fork quasi schon beschlossene Sache ist. Beispiele aus der Vergangenheit finden sich im Großen wie im Kleinen tonnenweise, deswegen möchte ich nur exemplarisch einige Beispiele aufzählen:
- Wie Audacity durch die Muse Group übernommen wurde, bildeten sich sehr schnell erste Forks wie Tenacity heraus. Die Folgen waren hier gering, beide Projekte sind weiterhin in Entwicklung.
- Gerade Mozilla ist bei der Firefox-Entwicklung durch sowas gebeutelt. Die größte Sprengkraft hatte seinerseits die Abspaltung von Pale Moon und Basilisk, als mit Goanna ein Fork der Gecko-Engine entstand und spätestens nach dem Quantum-Update im Jahr 2017 der endgültige Split vollzogen wurde. Auch sonst hat das Ökosystem bei den Derivaten gelitten. SeaMonkey kommt nicht mehr wirklich in Fahrt, von den einstigen Abspaltungen auf Gecko-Basis wie Cyberfox oder Waterfox sind nur noch wenige übrig.
- Eines der bekanntesten Beispiele ist LibreOffice. Der Konflikt mit Oracle bei OpenOffice führte mittelfristig zur Gründung der The Document Foundation und dem bekannten Fork, während das Original mittlerweile bei der Apache Software Foundation vor sich hin gammelt.
- Canonical war im späteren Verlauf immer wieder ein Spannungsfeld von Linux, wenn Ideen wie der Displayserver Mir, der Unity-Desktop oder das Snap-Paketformat aufkamen. Meistens haben sich Konkurrenzformate wie Wayland und Flatpaks durchgesetzt, einige Distributionen wie Linux Mint sind aber noch vorsichtiger und haben zur Sicherheit auch einen Debian-Ableger aufgelegt.
- Bei den Linux-Desktops hatte Gnome 3 seinerzeit eine enorme Sprengkraft und hat die Entwicklung anderer GTK-basierter Desktops wie Mate, Cinnamon oder – im späteren Verlauf wegen libadwaita – auch Budgie befördert. Aber auch KDE Plasma ist von solchen Erscheinungen nicht verschont geblieben, wie die Entwicklung von Trinity beweist.
- Zwei Beispiele aus dem kommerziellen Unternehmensumfeld sind Elasticsearch und Redis. Beide sind letztlich Subjekt von Lizenzänderungen geworden, um mehr Geld mit der Entwicklung zu verdienen. Bei Elasticsearch mündete das 2021 in Amazons Fork OpenSearch, bei Redis ist im vergangenen Jahr der Fork Valkey entstanden. Die Projekte unterstehen mittlerweile der Linux Foundation.
- Auch bei den Cloudanbietern kam es zur Trennung zwischen OwnCloud und NextCloud, wobei letzterer heute als bevorzugter Repräsentant auch in der öffentlichen Verwaltung verwendet wird.
Dass es anders ausgeht, ist tatsächlich sehr selten und konnte dann meistens auch nur unter großen Anstrengungen verhindert werden. Wo es gut ausgegangen ist, waren die Verhandlungen zwischen dem KDE e.V. und der Qt Company, als diese im Hinblick auf das kommende Qt 6.0 Pläne zur Einschränkung der LTS-Versionen im FOSS-Umfeld ankündigte. Auch Facebook bekam 2017 nochmal die Kurve, als es zunächst die BSD-Lizenz bei React Native mit einer Zusatzklausel versehen hat, ehe man zusammen mit React selbst zur MIT-Lizenz gewechselt ist.
Grundsätzlich muss man festhalten, dass das FOSS-Umfeld eiserne Prinzipien und ein klares Selbstverständnis hat, wo man sich nicht erpressen lassen und in aller Regel auch einen neuen Status Quo nicht akzeptieren würde. Das ist einfach so. Wendet man das auf Chromium an, ist es viel wahrscheinlicher, dass ein neuer Fork unter der Federführung von Microsoft, Opera und Vivaldi, die allesamt dank Trident, EdgeHTML und Presto auch schon Erfahrung in der Entwicklung von Browser-Plattformen inkl. ihrer Engines haben, entsteht und dieser dann unter dem Dach der Linux Foundation betrieben wird, wo schon Strukturen aufgebaut werden. Chromium wäre vielleicht tot, aber grundsätzlich geht es weiter wie bisher.
Was sonst?
Mit einer geschlossenen Bezahlversion von Chromium würde man keine Probleme lösen und, selbst wenn man es durchziehen würde, dafür viele andere Probleme an anderen Stellen maximal öffnen. Gleichzeitig gehört es zur bitteren Wahrheit auch dazu, dass wir es uns nicht leisten können, einerseits Chromium als heutigen Industriestandard und andererseits besonders Gecko (aber auch WebKit2) wegen der Webstandards und ihrer Entwicklung zu verlieren. Die Lösungen für die Gesamtproblematik müsste also kreativer ausfallen:
- Ein sinnvoller Beitrag wäre es, wenn Chromium und seine Entwicklung unter die Leitung einer unabhängigen Organisation gestellt werden, die nur an der Standardisierung selbst ein Interesse hat. Solche Beispiele werden mit dem W3C, der IETF oder auch ECMA International bei JavaScript schon lange erfolgreich praktiziert. Die Rolle der Koordinationsgruppe bei der Linux Foundation müsste geklärt werden.
- Zumindest in dem begrenzten Maße, wie das heute noch möglich ist, muss der Wettbewerb zwischen den Rendering-Engines wieder in Schwung kommen, damit auch die Entwicklung der Webstandards wieder besser funktioniert. Kurzfristig wäre das vor allem machbar, indem man Apple dazu verpflichtet, WebKit2 sowie Safari als stärksten Browser auf allen relevanten Plattformen (wieder) verfügbar zu machen. Gerade unter Android und Windows ist das aktuell nicht der Fall. Nur wenn Chromium, Firefox und Safari (und damit Blink, Gecko und WebKit2) auf allen Plattformen die gleichen Wettbewerbsbedingungen vorfinden, können auch die besten Lösungen entstehen. Kleinere Engines wie Dillo oder Goanna machen dabei den Kohl allerdings nicht fett.
- Sinnvoll wäre es speziell für die Europäer zudem, wenn sie ihr eigenes Ökosystem endlich wieder entwickeln und entsprechend schützen. Selbst wenn man nur die technische Basis betrachtet, die bereits verfügbar ist, haben wir mit Vertretern wie Opera (wenn auch mit gewissem China-Einfluss), Vivaldi, Waterfox, dem Mullvad Browser oder dem Ecosia Browser bereits brauchbare Alternativen. Strategische Investitionen wären zusätzlich sinnvoll, worunter zum Beispiel Servo fallen könnte, die ebenfalls mittlerweile unter dem Dach der Linux Foundation hausiert.
Schlusswort
Mir liegt es fern, Martin bei seinem Kommentar wirklich in die Parade zu fahren oder irgendwelche Vorwürfe zu machen. Dennoch ist eine mögliche Lösung nur dann eine Lösung, wenn man die Folgen einer Maßnahme richtig abschätzen kann und dabei nicht alles noch viel schlimmer wird. Mit der Analyse aus dem vorherigen Kommentar kann ich in vielen Punkten durchaus zustimmen, aber die Idee eine Bezahlversion von Chromium, deren Quellcode auch noch geschlossen würde, geht einfach an der Realität vorbei und der entstehende Schaden würde die Maßnahme nicht im Ansatz mehr rechtfertigen.
Schreibt eure Gedanken dazu gerne in die Kommentare.
Der Beitrag Kommentar zum Kommentar: Ein bezahltes Chromium löst das Problem nicht erschien zuerst auf Dr. Windows.
Hinweis: Der Artikel wird möglicherweise nicht vollständig angezeigt, eingebettete Medien sind in dieser Vorschau beispielsweise nicht zu sehen.
Artikel im Blog lesen
Zuletzt bearbeitet von einem Moderator:
