System76 verweigert sich Upstream

  Ralf Hersel   Lesezeit: 5 Minuten  🗪 7 Kommentare

Es gibt einige Beispiel dafür, wie sich GNU/Linux-Projekte selbst ins Abseits schiessen.

system76 verweigert sich upstream

In der Vergangenheit finden sich einige Beispiele dafür, wie sich 'übermotivierte' Projekte vom Community-Geist verabschiedet haben. Da wäre zum Beispiel die Firma Canonical, die sich mit vielen Ideen (TV, Smartphone, MIR, Unity, Snap-Paketen) vom Rest der freien Gesellschaft abheben wollte, letztendlich aber damit gescheitert ist. Oder Tuxedo-Computers, die mit TUXEDO-OS (einem Ubuntu-Derivat) einen eigenen Weg beschritten sind.

Eine ähnliche Richtung schlägt nun auch der Geräte- und Distro-Hersteller System76 ein. Wir berichteten darüber, dass die Firma demnächst GNOME links liegen lässt, um einen eigenen Desktop (COSMIC) zu entwickeln. In den letzten Tagen hat sich das Verhältnis zwischen System76 und dem GNOME-Team weiter abgekühlt, was sich in einem Blog-Post des GNOME-Designers Chris Davis manifestiert.

Als Einleitung schreibt er:

In letzter Zeit gab es einige hitzige Diskussionen über die Zukunft von GNOME. Dies hat dazu geführt, dass eine Menge Angst, Unsicherheit und Zweifel über GNOME verbreitet wurden, sowie Angriffe und Feindseligkeit gegenüber GNOME als Ganzes und gegenüber einzelnen Mitwirkenden. Dies begann grösstenteils aufgrund der Äusserungen von Mitarbeitern der Firma System76.

Einer der Streitpunkte ist der Linux Vendor Firmware Service (LVFS). In den Jahren 2017 und 2018 kommunizierte Richard Hughes, dass man für Firmware Updates LVFS einsetzen wolle. Dann kündigte System76 plötzlich seine eigene Infrastruktur und Software für Firmware-Updates an.

Weiter ging es mit der Behandlung von Patches. Im Jahr 2019 teilte Sebastien Bacher von Canonical einen Beitrag über den Umgang mit Fehlerbehebungen gegenüber Upstream durch System76. Dieses Verhalten betraf sowohl Ubuntu als auch GNOME. System76 hat Fehler, die für Pop!_OS relevant waren, behoben, jedoch nicht an Upstream geliefert:

"Später fingen sie an, die Upstream (Ubuntu, GNOME, ...) Bug Tracker zu kommentieren und weisen die Benutzer darauf hin, dass das Problem in Pop!_OS behoben wurde, und werben damit, dass sie sich um die Benutzer kümmern und das Problem bei sich behoben haben. Sie sollten zwar stolz auf die Arbeit sein, die sie für Ihre Benutzer leisten, aber ich denke, sie gehen hier den falschen Weg. An Korrekturen zu arbeiten und sie früh in das Produkt einzubauen ist eine Sache, diese Korrekturen nicht in an Upstream zu geben, um sich besser vermarkten zu können, ist ein riskantes Spiel", so Sebastien Bacher.

Dann kam System76 mit dem GNOME-Shell Tiling. Ende 2019 begann System76 mit der Arbeit an einer Erweiterung, die ein i3-ähnliches Tiling in GNOME ermöglichte. Als ein Upstream-Designer die Zusammenarbeit beim Tiling anbot, weigerte sich Jeremy Soller, leitender Ingenieur bei System76, mit ihm zu arbeiten. Der wirklich problematische Teil ist, dass System76 in den letzten Jahren immer wieder behauptet hat, dass Upstream nicht an Tiling interessiert sei, was laut Michael Murphy (GNOME) eine Falschaussage ist.

Kurz nachdem GNOME 40 bekannt gegeben hatten, überraschte Jeremy Soller mit der Aussage, dass System76 dem neuen Design der GNOME-Shell nicht zugestimmt habe. Er behauptete auch, dass das Feedback der Designerin nicht berücksichtigt wurde. Laut dem GNOME-Team ist das nicht der Fall. Tatsache sei, dass System76 für etwa ein Jahr des dreijährigen Entwurfsprozesses eine Designerin hinzugezogen hat. Die Designerin nahm an Design-Calls und Diskussionen mit dem Design-Team teil, und ihre Rolle konzentrierte sich auf die UX-Forschung selbst. Während des Designprozesses gab es nie Mockups oder konkrete Vorschläge von System76. Das einzige Mal, dass System76 einen Vorschlag gemacht habe, war ganz am Ende des Entwurfsprozesses bei einem Treffen des Entwurfsteams mit Interessengruppen. Dort stellten sie COSMIC vor und bekamen nicht das gewünschte Feedback.

Das Verhalten des Unternehmens wiederholte das ursprüngliche Muster. Als sich System76 mit seinem Entwurf nicht durchsetzen konnte, begann es, Fehlinformationen zu verbreiten. Dieser spezielle Fall von Fehlinformation war sehr schädlich für den Ruf von GNOME.

Die neueste Eskalation zwischen GNOME und System76 betrifft das Thema 'Gtk Themes und libadwaita'. Als Hintergrund-Information empfehle ich dieses Video von 'The Linux Experiment'. Die umfangreichen Details dazu erfahrt ihr im letzten Kapitel der Quelle.

Fazit

System76 gesellt sich zu den Projekten (Firmen), die Mühe mit der Balance zwischen eigenem Erfolgsbegehren und der Community-Zusammenarbeit haben. Exklusion und eigene Suppen kochen, haben in der Geschichte freier Software noch nie zum Erfolg geführt. Zusammenarbeit unter den Projekten und Upstream-Delivery sind bessere Rezepte um am gemeinsamen Ziel zu arbeiten. Die Firma System76 muss sich fragen lassen, ob ihr Verhalten nicht nur ein Lippenbekenntnis zu freier Software und der Community ist.

Quelle: https://blogs.gnome.org/christopherdavis/2021/11/10/system76-how-not-to-collaborate/

Tags

System76, GNOME, Upstream, COSMIC, GNOME-Team, Ubuntu, Tiling

dodobird
Geschrieben von dodobird am 11. November 2021 um 12:03

Gibt auch noch eine andere Sicht eines Beteiligten: https://joshuastrobl.com/2021/09/14/building-an-alternative-ecosystem/ Der Vorwurf ist, dass es bei Gnome niemanden interessiert, wenn Input kommt. Stattdessen wird dann von Gnome-Leuten ad hominem argumentiert. So ein Projekt kann man nur fallen lassen, das ist sektenartiges Getue.

BSB
Geschrieben von BSB am 11. November 2021 um 12:36

Es ist richtig und wichtig das Narrativ aus der RedHat-GNOME-Bubble nachzuplappern! Schon Unity ist nur deshalb entstanden, weil sich GNOME geweigert hat ein bisschen Flexibilität bzgl. der Desktops zu zeigen. Das Snap-Format ist älter als Flatpak, hat den GNOME-Entwicklern aber nicht geschmeckt. Und die ruppige Absage, das man gefälligst die GNOME-Anwendungen nicht themen soll, war ebenfalls ein Offenbarungseid. Das man mit solchen Menschen nicht arbeiten will - das verstehe ich gut.

GNOME bzw. RedHat dominiert die Linux-Welt und drückt damit letztlich seine Interessen durch (ein weiteres Beispiel: systemd anstatt das gut vorangeschrittene Upstart). Das ist kein bisschen weniger communityunfreundlich als Canonical. Der große Unterschied ist bloß: GNOME bzw. RedHat dominieren das Narrativ - wir sind die Guten, die anderen sind blöd und wollen nicht mit uns zusammenarbeiten.

Lioh
Geschrieben von Lioh am 11. November 2021 um 13:23

Canonical hat sich bei der Integration des libappindicators extrem mühsam verhalten und sie wollten primär ihr eigenes Ding durchdrücken. Wenn man zu einem Projekt beitragen möchte, das wie GNOME schon lange Bestand hat, sollte man sich mit der Ausrichtung des Projektes identifizieren können. Ihnen ging es darum Komponenten aus dem Projekt für ihr eigenes Ding zu nutzen, da frage ich mich wer da egoistischer ist.

Snap ist gefailed, weil sie von Anfang an auf einen proprietären Store gesetzt haben. So kann kein offenes Ökosystem entstehen.

Du bist übrigens der erste der upstart gut findet. Ich empfand es als wenig durchdacht und schlecht umgesetzt, so wie die meisten.

Und natürlich ist Red Hat auch nicht unschuldig, da sie oftmals die "wir können es halt einfach besser" Attitüde an den Tag legen. Leider haben sie rein technisch damit zumeist recht.

Tobias
Geschrieben von Tobias am 11. November 2021 um 14:51

Ich finde auch, das upstart das beste zu dem Zeitpunkt war als es raus kam. Es hat den Start im Vergleich zu den älteren Init-Skripten stark beschleunigt . Aber systemd ist halt einfach noch besser.

Snap-Format ist älter als Flatpak aber halt mit closed Appstore.

Unity fand ich auch besser als GNOME 3.0 bis ~3.12. aber es war wohl zu teuer es weiter zu pflegen und GNOME wurde halt auch besser.

Als Entwickler von Anwendungen kann ich es auch verstehen, das diese bitte nicht mit Themes verändert werden. Da bekomme ich dann Bugreports nur weil jemand ein kaputtes Theme benutzt.

Und ja es stimmt auch, das Gnome/GTK und RedHat keine Engel sind.

Das man erfolgreich mit Gnome zusammenarbeiten kann zeigt aber ja z.B. Purism. Man muss es halt nur wollen.

Insgesamt frage ich mich, warum ein Hardware Hersteller überhaupt eine eigene Distribution braucht. Einfach eine der Fertigen Distributionen nehmen, egal ob Debian, Ubuntu, RedHat, .... Dann ein eigenes Repository mit den Treibern und fertig.

Andanan
Geschrieben von Andanan am 11. November 2021 um 21:57

Die wollen halt ein Nutzererlebnis wie aus einem Guss. Ich kann das schon nachvollziehen, das ist ja auch der Grund warum viele Menschen das Apple-Ökosystem so mögen. Allerdings steht dieses "aus einem Guss"-sein meiner Meinung nach einer offnen Community im Weg. So etwas kann eben nur zentral gesteuert werden.

kamome
Geschrieben von kamome am 11. November 2021 um 13:09

Danke dafür – die Seite der Medaille wäre sonst vermutlich zunächst an mir vorbeigegangen!

systemV
Geschrieben von systemV am 11. November 2021 um 14:47

Zitat: "In den Jahren 2017 und 2018 kommunizierte Richard Hughes von System76, dass man für Firmware Updates LVFS einsetzen wolle" .. ein Richard Hughes von System76 ist meines Wissens noch nie in Erscheinung getreten. Der Richard Hughes, der LVFS initiiert (und zum Erfolg geführt) hat, ist aber bei RedHat/IBM fest angestellt, war oder ist Entwickler im GNOME-Projekt, bei Fedora usw. Dann wäre die betreffende Anekdote verwirrend.