Der Linux-Desktop im Unternehmen folgt einem Fahrplan, an dem Sie nicht mitschreiben
Unternehmen setzen auf Linux, um die Kontrolle zu behalten. Doch die Oberfläche, mit der jede Mitarbeiterin und jeder Mitarbeiter täglich arbeitet, folgt einer Design-Vision vorgelagerter Entwickler, gegen die kein Kunde ein Vetorecht hat, und die aktuelle Richtung erinnert stark an ein Tablet.
Fragen Sie eine IT-Leiterin oder einen IT-Leiter, warum die Flotte auf Linux läuft, und binnen einer Minute fällt das Wort „Kontrolle“. Keine erzwungenen Redesigns. Eine Oberfläche, die sich an die eigenen Anforderungen anpassen lässt. Hier kommt der unbequeme Teil: Bei der modernen Linux-Desktop-Umgebung im Unternehmen ist ausgerechnet die Ebene, mit der jede Mitarbeiterin und jeder Mitarbeiter den ganzen Tag arbeitet, diejenige, über die die Organisation am wenigsten bestimmt. Die Oberfläche wird von einem vorgelagerten Design-Projekt festgelegt, nach dessen eigenem Zeitplan, und kein Beschaffungsvertrag der Welt gewährt Ihnen ein Vetorecht darüber.
Das wäre eine tragbare Abstraktion, wäre die Richtung des Projekts unspektakulär. Ist sie nicht. GNOME, die Desktop-Umgebung, die die meisten kommerziellen Linux-Distributionen standardmäßig mitliefern, arbeitet seit Jahren auf eine touch-first, opinionated Vereinfachung hin, und sagt das öffentlich. Die Entwickler von GNOME Shell haben ein finanziertes Projekt beschrieben, das GNOME Shell auf Smartphones bringen soll, aufbauend auf der Gesten- und Touch-Navigation, die bereits auf dem Desktop ausgeliefert wird. Legt man diese Richtung neben iPadOS, ist die Familienähnlichkeit unübersehbar. Ebenso öffentlich ist die andere Hälfte des Bildes, das Theming: Dutzende GNOME-App-Entwickler unterzeichneten einen offenen Brief, in dem sie Distributionen auffordern, ihre Apps nicht mehr mit Drittanbieter-Themes zu versehen, mit der Begründung, dass eine Änderung des Erscheinungsbilds ohne Einbindung der App-Entwickler die App beschädigt. Durch beides zieht sich derselbe Instinkt: Theming, tiefgehende Anpassbarkeit und die administrativen Stellschrauben, die Linux-Desktops zu etwas Eigenem machten, gelten als Probleme, die wegdesignt gehören, nicht als Funktionen, die es zu erhalten gilt.
Lesen Sie das noch einmal langsam. Die Konfigurierbarkeit, die die Wahl von Open Source auf der Oberflächenebene rechtfertigte, ist genau das, was der eigene Fahrplan der Oberfläche gerade herauskonstruiert.
Wer kontrolliert eigentlich den Linux-Desktop im Unternehmen?
Folgen Sie dem Mechanismus. Ein Distributionsanbieter paketiert eine Desktop-Umgebung. Die Desktop-Umgebung folgt ihrer eigenen Design-Führung. Diese Führung ist den Zielen des Projekts und ihrem eigenen Bild der idealen Nutzerin oder des idealen Nutzers verpflichtet, nicht Ihrem Rollout-Plan. Kommerzielle Distributionen können Versionen fixieren und eigene Patches pflegen, das verzögert die Zukunft um einen Support-Zyklus oder zwei. Sie lenken sie selten um. Bis eine Design-Vision Ihr Standard-Image erreicht, sind alle relevanten Entscheidungen bereits mehrere Ebenen weiter oben gefallen, von Leuten, die Ihre Organisation nicht kennen und dazu auch nicht verpflichtet sind.
Die Anreize erklären die Richtung. Vorgelagerte Design-Teams werden für Kohärenz belohnt: eine Erfahrung, die sie pflegen und verteidigen können. Jedes Theme, jeder Erweiterungspunkt, jeder Einstellungsschalter ist Angriffsfläche, die sie unterstützen müssen, und eine Variable, für die sie nicht gestalten können. Aus dieser Anreizstruktur heraus betrachtet, wirkt der Abbau von Anpassbarkeit wie Hygiene. Aber das jahrzehntelange Nutzungsmuster Ihrer Flotte ist nicht deren Klientel, und kein Maß an gutem Willen ändert etwas daran, wessen Problem die Lücke am Ende wird.
Erweiterungen wirken wie das Sicherheitsventil, und für eine einzelne Enthusiastin oder einen einzelnen Enthusiasten sind sie das auch. Auf Flottenebene sind sie technische Schuld: Alles, was außerhalb der Design-Vision angeflanscht wird, lebt von deren Nachsicht, und jedes Upstream-Release darf es brechen. Wer das eigene Standard-Desktop-Image auf dieser Grundlage aufbaut, baut auf der Duldung eines anderen.
Ist das Kopieren einer fremden Bedienoberfläche rechtlich riskant?
Wenn das Ziel wie Cupertino aussieht, könnte Cupertino dagegen vorgehen? Die Rechtsgeschichte spricht dagegen. Apple versuchte Anfang der 1990er-Jahre, sich „Look and Feel“ gerichtlich zu sichern, und erreichte damit weitgehend das Gegenteil. In Apple Computer, Inc. v. Microsoft Corp., einem 1994 vom Ninth Circuit entschiedenen Fall, scheiterte Apples Vorwurf, Windows verletze das Look and Feel der Mac-Oberfläche, fast vollständig: Das Gericht befand, die strittigen Oberflächenelemente seien entweder durch eine frühere Lizenz gedeckt oder urheberrechtlich gar nicht schützbar. Jahrzehnte später gilt dieser Vergleich noch immer. Ein Oberflächen-Paradigma lässt sich vollständig imitieren, und das Risiko ist reputativ, nicht juristisch.
Das ist hier aus einem kalten strukturellen Grund relevant. Wäre Imitation haftungsbewehrt, gäbe es eine Bremse gegen die Konvergenz auf die Designsprache eines einzelnen Unternehmens. Gibt es nicht. Die einzigen Kräfte, die ein Desktop-Projekt davon abhalten, zur Coverversion zu werden, sind Geschmack und Community-Druck, und Community-Druck hat gegen ein entschlossenes Design-Team mit Commit-Zugriff eine schlechte Bilanz.
Was kostet ein Redesign, zu dem Sie nicht Nein sagen können?
Jetzt zum Preis. Das sind Budgetkategorien, keine gemessenen Werte, denn jede Flotte ist anders, aber die Kategorien selbst sind hartnäckig vorhersehbar: Schulungsbedarf über alle Arbeitsplätze hinweg, sobald sich das Paradigma verschiebt; die Neubewertung jedes Barrierefreiheits-Workflows, der auf die aktuellen Bedienelemente abgestimmt ist; Dokumentation, Screenshots, Onboarding-Material und Support-Skripte, die still und leise ungültig werden; und darunter die nicht bezifferte Produktivitätssteuer von Tausenden Menschen, die sich neu orientieren müssen. Unternehmen erkennen dieses Kostenprofil wieder, denn es entspricht genau dem, wonach ein erzwungenes Redesign eines proprietären Anbieters aussieht. Der Unterschied, für den man bezahlt hat, war offenbar die Kontrolle über den Quellcode, nicht die Kontrolle über den Fahrplan.
Ja, man kann forken. Sagen Sie diesen Satz jemandem, der einen Fork einer Desktop-Umgebung gepflegt hat, und beobachten Sie die Reaktion. Der Beleg ist leicht nachzuprüfen: Als GNOME 3 im Jahr 2011 das Bedienkonzept von GNOME 2 verwarf, entstand aus dem Widerstand MATE, die Fortführung von GNOME 2, sowie Cinnamon, das Linux Mint aus GNOME-Komponenten zusammensetzte. Beide überleben nur, weil Maintainer seit weit über einem Jahrzehnt dauerhaft Personal und eine mit wachsendem Abstand zum Upstream-Projekt zunehmende Sicherheitslast tragen. Das Recht zu forken ist real. Als Kontrollmechanismus für ein Unternehmen ist es ungefähr so praktikabel wie das Recht, sich seine eigene Autobahn zu bauen.
Wie geht man mit einer Abhängigkeit um, die man nicht steuern kann?
Nennen Sie die Sache zuerst beim Namen. Die Oberflächenebene Ihrer Flotte ist eine Lieferkettenabhängigkeit mit eigenem Willen und gehört auf dasselbe Risikoregister wie jede proprietäre Plattform, die Sie vor einer Verpflichtung prüfen würden. Das ist im Kern, was wir meinen, wenn wir sagen, dass technische Strategie die Disziplin ist, genau die Abhängigkeiten zu bepreisen, die man nicht kontrolliert, und dieselbe Logik gilt für jede Plattform-Entscheidung, bei der der Fahrplan außerhalb der eigenen Mauern liegt.
Wählen Sie dann Ihre Haltung bewusst. Das Fixieren von Long-Support-Releases kauft Jahre, keine Ergebnisse: Das Redesign kommt trotzdem, mit Zinsen. Upstream zu finanzieren und mitzuwirken kauft Einfluss, der es wert ist, aber immer noch keine Kontrolle. Der Wechsel zu einer Desktop-Umgebung mit einer zur eigenen Organisation passenderen Governance ist eine echte Option mit echten Wechselkosten. Und wer bleibt, sollte das Change-Management jetzt budgetieren, zum Zeitpunkt des Refresh, solange es ein Budgetposten ist und kein Notfall.
Keine dieser Optionen stellt das Vetorecht wieder her, denn dieses Vetorecht gab es nie. Open Source gibt Ihnen den Quellcode. Das Lenkrad hat es nie versprochen.
Häufige Fragen
Baut GNOME Theming und Anpassbarkeit wirklich ab?
Die in der langfristigen Design-Arbeit signalisierte Richtung bevorzugt opinionated Standardeinstellungen gegenüber Drittanbieter-Theming und tiefer Konfigurierbarkeit, und zahlreiche eigene App-Entwickler haben Distributionen öffentlich aufgefordert, Drittanbieter-Themes nicht mehr anzuwenden. Betrachten Sie das als Fahrplan-Risiko, nicht als vollzogene Tatsache: Prüfen Sie vor Flotten-Entscheidungen das Verhalten des aktuellen Release, planen Sie aber eher mit schrumpfender als mit wachsender Konfigurierbarkeit.
Kann ein Unternehmen ein ungewolltes Redesign einer Desktop-Umgebung verhindern?
Nein. Sie können es verzögern, indem Sie Long-Support-Distributionsversionen fixieren, es beeinflussen, indem Sie Upstream finanzieren oder mitwirken, oder ihm ausweichen, indem Sie zu einer anders regierten Desktop-Umgebung wechseln. Was Sie nicht können, ist ein Veto einlegen, deshalb besteht der realistische Schritt darin, Schulung und Change-Management einzuplanen, bevor es so weit ist.
Ist es rechtlich zulässig, wenn eine Linux-Oberfläche iPadOS nachahmt?
Grundsätzlich ja. In Apple Computer, Inc. v. Microsoft Corp. (1994), einem Urheberrechtsurteil zum Look and Feel, befand der Ninth Circuit, dass sich allgemeine Oberflächenkonzepte kaum schützen lassen, sodass das Risiko für einen Nachahmer reputativ statt juristisch ist. Für einsetzende Organisationen bedeutet das in der Praxis: Nichts Strukturelles verhindert die Annäherung der Oberflächen.
Verwandte Artikel
- Epic gegen Google: Die App-Katalog-Klausel, die Google seinen Rivalen den Burggraben schenkt
- Speicherpreise haben gedreht: Verhandeln Sie den Liefervertrag neu, bevor der nächste Refresh ansteht
- Wie KI schlechte Chefs noch schlimmer macht: Die Ja-Sager-Maschine im Chefbüro
- Digital Business
Verfasst von einer KI-Redaktionspersona des proprietären Redaktionssystems von Abyshire und von unserem Team geprüft.