© lightfieldstudios / 123RF.com

Progress Software, die Firma hinter Chef, empört Admins und Nutzer seit anderthalb Jahren, denn wer die Software von Chef beziehen und kommerziell nutzen will, braucht seitdem eine separate Lizenz dafür. Cinc tritt als freie Chef-Distribution mit kompletter Kompatibilität und damit als echte Alternative an.

Die meisten Administratoren verfallen nicht gerade in Euphorie, wenn sie sich mit den Details von Softwarelizenzen befassen müssen. Wer sich vorrangig im Open-Source-Umfeld bewegt, ist anderes gewohnt: Hier hat sich in den vergangenen Jahren die Apache-Lizenz durchgesetzt, ihr zur Seite steht noch immer die gute alte GNU Public License (GPL), bevorzugt in der Version 2. Zudem ist es in der FL/OSS-Welt üblich, die kompilierte Form von Programmen unter derselben Lizenz zu verteilen wie den originären Quelltext. Die überwältigende Mehrheit der Open-Source-Projekte geht jedenfalls so vor.

Eine bemerkenswerte Ausnahme von dieser Regel bildet Chef, das sich als einer der ersten Automatisierer vor Jahren einen Namen machte. Hierzulande erreichte es allerdings nie die Verbreitung von Puppet oder dem wesentlich weniger komplexen Ansible. Eine treue Fangemeinde hat Chef aber auch in diesem Teil der Welt, und in der hängt seit Mitte 2019 der Haussegen gewaltig schief: Wer die fertigen Pakete von Chef nutzen möchte, braucht dafür nun eine kommerzielle Lizenz, die vorher nicht notwendig war.

Doch wie man es in der Open-Source-Welt kennt, dauerte es nicht lange, bis sich eine freie Alternative gründete: Cinc tritt mit dem Versprechen an, vollständig kompatibel zu Chef zu sein und dabei weiter unter einer freien Lizenz zu stehen. Dieser Artikel erklärt zunächst, welche Auswirkungen die Änderung des Chef-Lizenzmodells für Admins eigentlich mit sich brachten und wie Cinc sich als Alternative in Stellung bringt.

Wie es (oft) funktioniert

Der Tag, an dem die Welt manches Chef-nutzenden Admins ins Wanken geriet, war der 2. April 2019. An diesem Tag wurden umfangreiche Änderungen der Chef-Lizenzen wirksam (Abbildung 1), die sich unmittelbar auch auf jene Chef-Nutzer auswirkten, die Chef ganz normal wie jede andere FL/OSS-Software genutzt hatten.

Abbildung 1: Keine guten Nachrichten für Chef-Nutzer: Nach einer Lizenzänderung darf man die kompilierten Pakete von Chef kommerziell faktisch nicht mehr kostenfrei nutzen.

Zwar ist es rechtlich nicht vorgeschrieben und faktisch auch nicht notwendig, das Kompilat einer freien Software kostenlos abzugeben, doch hat sich in der FL/OSS-Welt ein gewisses Standardprozedere etabliert, die eigene Software unter die Leute zu bringen. Das geht so: Anbieter wie Docker oder Projekte wie PostgreSQL haben großes Interesse daran, die eigene Nutzerschaft mit gut funktionierenden Versionen ihrer Software zu versorgen. In der Vergangenheit geschah das meist über Pakete: Docker etwa bietet bis heute die Community Edition seiner Container-Umgebung an, die auf allen gängigen Linux-Distributionen funktioniert.

Der Systemverwalter kann die vom Anbieter feilgebotenen Pakete denkbar leicht nutzen: Dazu aktiviert er in der Paketverwaltung seiner Systeme die entsprechenden Repositories des Herstellers, aus denen er im nächsten Schritt die dort verfügbaren Pakete herunterlädt. In der modernen und hippen Welt von Docker & Co. kommen heute für dieselbe Aufgabe oft Container zum Einsatz, die die Hersteller statt Paketen anbieten. Das Prinzip bleibt im Kern aber dasselbe.

Dieses Prinzip hat für die Anbieter durchaus Vorteile: Sie nutzen die frei verfügbaren Pakete der eigenen Software regelmäßig als Basis für kommerzielle Erweiterungen. Vor allem hat der Hersteller auf diese Weise aber eine gewisse Kontrolle darüber, welche Version des eigenen Produkts bei den Anwendern zum Einsatz kommt. Es würde sowohl das Leisten von Support als auch das Finden von Fehlern erschweren, würde jeder Systemverwalter mit selbst kompilierten Binaries hantieren. Obendrein stellen Anbieter von Software auf diese Weise sicher, dass die von den Anwendern genutzten Pakete bestimmten Qualitätsstandards entsprechen und nicht uralt sind. Chef und die dahinterstehende Firma Progress Software hielten sich eine ganze Weile an eben dieses Prinzip – einschließlich proprietärer Tools, deren Quelltext öffentlich nicht verfügbar war.

Gut gemeint, schlecht gemacht

Die im April 2019 in Kraft getretenen Änderungen der Lizenzierung von Chef hatten zwei wesentliche Ziele. Das erste war hehr und nobel: Der Anbieter wollte sich von seinen Closed-Source-Komponenten befreien und stellte alle proprietären Werkzeuge aus dem eigenen Stall unter eine freie Lizenz – zumindest im Quelltext. Genau hier liegt der Hase im Pfeffer: Zeitgleich mit der Änderung der Lizenz des Quelltexts diverser Tools führte Progress Software ein EULA ein, ein End User License Agreement. Es gelte, so stellte der Hersteller klar, ganz ausdrücklich nicht für die Quellen der Software, sondern für die vom Anbieter zur Verfügung gestellten binären Pakete. Wer also bis dahin sein Chef bereits selbst kompilierte, war von den Änderungen praktisch nicht betroffen.

Die Anzahl der Admins, auf die das zutrifft, dürfte verschwindend gering sein. Deutlich größer ist zweifelsohne die Zahl der Systemverwalter, denen Progress Software durch den Lizenzwechsel lästige Knüppel zwischen die Beine warf. Diese Klientel versuchte der Hersteller indes zu beschwichtigen: Das neue EULA gelte nicht für alle Chef-Komponenten; die zentralen Tools einer Chef-Installation seien auch künftig wie gehabt in binärer Form und unter freier Lizenz verfügbar.

Wer Chef bisher kommerziell einsetzte – und kommerziell bedeutet in den Augen des Herstellers in einem Szenario, das auf die Erzielung von Gewinn ausgelegt ist, der nutzte dafür freilich die binären Pakete des Anbieters.

Lizenz-Trickle-down

Aus heutiger Sicht dürfen Chef-Nutzende diese Ankündigung mit Fug und Recht als Lippenbekenntnis bezeichnen. Denn während zentrale Werkzeuge wie die Chef Workstation, der Infra Client oder der Infra Server zunächst tatsächlich unter ihren gewohnten Lizenzen auch in binärer Form verfügbar blieben, zog der Hersteller in späteren Versionen die Zügel an und schrieb auch hier das neue EULA zwingend vor. Heute steht keine einzige der zentralen Chef-Komponenten mehr in binärer Form unter einer freien Lizenz.

Admins, deren ganze Automation auf Chef fußt, stehen damit vor einem Dilemma: Die genutzten Chef-Pakete wurden nach und nach unbrauchbar, wenn man keine Chef-Lizenz kaufen und sich nicht des Bruchs der Lizenz schuldig machen wollte. Denn das neue EULA erlaubt die Nutzung der Pakete ohne kommerzielle Vereinbarung mit Progress eben nur für experimentelle oder persönliche Zwecke. Gut möglich auch, dass mancher Admin von der Lizenzänderung gar nichts mitbekommen hat und Chef heute illegal nutzt.

Schwierige Begründung

Als Begründung für die Lizenzänderungen führte der Hersteller seinerzeit übrigens ins Feld, man wolle das Lizenzmodell der Software insgesamt vereinheitlichen und den besten Support für Kunden bieten, die Chef kommerziell nutzen. Einen fragwürdigen Vergleich lieferte Progress ebenfalls gleich mit: Im Grunde sei das neue Geschäftsmodell ja auch nichts anderes als jenes, das Red Hat und Suse bei ihren Distributionen für das Enterprise-Segment zum Einsatz bringen. Auch dort sei der größte Teil der Software Open Source, doch für die kommerzielle Nutzung müssten Anwender zahlen.

Dieser Vergleich lässt freilich außer Acht, dass Anwendern in Form von CentOS spätestens seit 2004 eine binärkompatible Distribution als Alternative zu Red Hat zur Verfügung steht, die über viele Jahre hinweg sogar direkt durch das Unternehmen gepflegt wurde. Wer ein Red-Hat-Setup sein Eigen nennt, konnte insofern mit relativ wenigen Handgriffen auf CentOS umsteigen – von dieser Option haben mehr als genug Admins ausgiebigen Gebrauch gemacht. Wie wichtig CentOS am Markt ist, stellte sich heraus, als Red Hat der Distribution den Garaus machen wollte: Binnen weniger Stunden gründeten sich in Form von Rocky Linux und AlmaLinux zwei Projekte, die weiterhin eine vollständig zu RHEL kompatible Distribution anbieten wollen.

Für Chef-Administratoren stellt sich die Situation anders dar: Sie haben meist vor einigen Jahren eine Entscheidung für ein Werkzeug zur Automation getroffen und seither in vielen Fällen ein komplexes Tooling auf Basis dieser Lösung entwickelt. Die Lizenzänderung setzte ihnen quasi die Pistole auf die Brust: entweder zahlen oder eine andere Automationslösung nutzen. Deren Einführung indes würde, wie jeder mit Sachverstand weiß, viel Geld verschlingen, vor allem aber extrem viel Aufwand produzieren – in einer Zeit, in der Firmen ohnehin bereits verzweifelt Personal suchen.

Die Trademark-Keule

Damit das schöne neue Lizenzsystem auch ja nicht durch Störfeuer von der Seite in Gefahr gerät, hat Chef sich zeitgleich mit den neuen Lizenzen auch noch eine nagelneue Trademark-Keule zugelegt (Abbildung 2). Die setzt der Anbieter rabiat ein: Chef darf in binärer Form seither nur noch heißen, was unmittelbar von Chef und mithin von Progress Software kommt. Die Begründungen dafür sind so vorhersehbar wie halbseiden: Man wolle “die Marke nicht verwässern” und “sicherstellen, dass Admins die höchste Qualität der Software erhalten, wenn sie Binaries installieren, die Chef im Namen tragen”.

Abbildung 2: Damit die Community nicht auf aus Chef-Sicht dumme Gedanken kommt, packte der Hersteller parallel zur Lizenz-Keule auch gleich noch die Copyright-Keule aus.

Das bedeutet ganz konkret: Distributoren, die Chef aus den Quellen selbst übersetzen, also quasi eine eigene Chef-Distribution bauen, dürfen die entsprechenden Pakete nicht mehr unter dem Label Chef vertreiben. Zudem müssen Drittanbieter darauf achten, dass kompilierte Chef-Pakete sich mit den offiziellen Paketen nicht die Pfade im Dateisystem teilen. Wer also eine eigene Chef-Distribution auf Basis freier Quellen starten möchte, muss den Pfad etwa in »/opt/Irgendwas« ändern, weil die offiziellen Pakete »/opt/chef« bereits in Beschlag nehmen. Ruby-Modulen der offiziellen Chef-Pakete erlaubt der Anbieter in seiner ganzen Gnade, ihre Namen zu behalten. Wer allerdings von Chef auf eine andere Chef-Distribution ausweichen will, hat schon wegen der anderen Pfade im Dateisystem erhebliche Migrationsarbeiten zu leisten.

Debian macht kurzen Prozess

Mit ein wenig zeitlichem Verzug reagierten die ersten Distributoren auf die verwirrenden Anflüge des Chef-Herstellers. Bei Debian GNU/Linux etwa flogen sämtliche Chef-Pakete samt und sonders aus der Distribution; ein kleiner Hinweis in den Release Notes ist alles, was von Chef in Debian übrig blieb. Das war kaum anders zu erwarten, denn mit störrischen Herstellern hat man beim Debian-Projekt genug Erfahrung. Unvergessen etwa ist bis heute Iceweasel, das Firefox-Pendant, das man bei Debian pflegte, weil Firefox das Verteilen des Browsers unter der geschützten Bezeichnung Firefox verbieten wollte (Abbildung 3).

Abbildung 3: Der Chef-Lizenzwechsel ruft Erinnerungen an den Webbrowser Firefox wach, der bei Debian GNU/Linux lange Iceweasel heißen musste, weil man sich um Markenrechte zankte.

Chef bewerten die Debian-Entwickler offensichtlich als nicht wichtig genug, um eine eigene Variante bereitzustellen. Damit stehen Debian-Anwender, die bisher Chef aus der Distribution nutzten, seit Debian GNU/Linux 11 im Regen. Man darf wohl davon ausgehen, dass andere Distributionen dem Beispiel von Debian GNU/Linux mittel- und langfristig folgen werden: Die Kombination aus neuer Chef-Lizenz und der offensichtlich angewandten Trademark-Strategie lässt ihnen praktisch keine Wahl.

Alternativen

Welche Möglichkeiten haben nun aber Chef-Nutzer, denen ihr Automatisierer auf die beschriebene Weise quasi abhanden gekommen ist? Mancher mag sich im ersten Moment dazu verleitet fühlen, selbst zum Compiler zu greifen. Wo kein Kläger, da kein Richter – und ob die eigens kompilierten Pakete als Pfad »/opt/chef/« nutzen oder etwas anderes, kann Progress Software egal sein, solange man die Binaries nicht weiterverteilt. Diese Variante erscheint aber nur auf den ersten Blick attraktiv. Jeder, der schon einmal Pakete egal welcher Art für eine Linux-Distribution gepflegt hat, weiß: Will man qualitativ hochwertige Pakete bauen, verursacht das einen wiederkehrenden Aufwand beträchtlichen Ausmaßes, den viele Unternehmen vermutlich gar nicht leisten können.

An dieser Stelle kommt nun Cinc ins Spiel. Cinc steht als Abkürzung für Cinc is not Chef und bezeichnet sich selbst scherzhaft als “Free-as-in-Beer Distribution of Chef”. Das “Free as in Beer” ist in der FL/OSS-Community ein stehender Begriff: Der damalige FSF-Chef Richard Stallman nutzte den Begriff regelmäßig, um das englische Wort “free” passend zu übersetzen. Das kann bekanntlich sowohl frei als auch kostenlos bedeuten, wobei letzterer Aspekt bei freier Software gerade nicht im Fokus steht.

So oder so: Cinc will sich als eine binärkompatible Chef-Distribution am Markt etablieren, ohne dass Admins Kosten entstehen und ohne dass irgendwer Stress mit Progress Software bekommt. Um dieses Ziel zu erreichen, gehen die Macher hinter dem Projekt in Phasen vor und nehmen sich die unterschiedlichen Komponenten von Chef Stück für Stück vor.

Woraus Chef besteht

Es erfordert einen kleinen Exkurs in die Struktur von Chef, um genauer nachvollziehen zu können, wie weit Cinc dabei bisher gekommen ist. Wer sich mit dem Portfolio des Anbieters beschäftigt, bekommt es mit einer Vielzahl an Komponenten zu tun: Chef Automate, Chef Infra, Chef Workstation, Chef Inspec – da ist es leicht, den Überblick zu verlieren. Welches Werkzeug zeichnet im Chef-Zirkus also wofür genau verantwortlich?

Zunächst tut der Admin gut daran, das Hauptaugenmerk auf Chef Infra zu legen. Darin steckt der Nachfolger jener Komponente, die früher einfach nur Chef hieß (Abbildung 4). Bevor Automation auch Faktoren wie Continuous Integration und Continuous Delivery umfasste, hieß der Vorgänger des heutigen Chef Infra einfach Chef. Darin enthalten waren der Chef-Server einerseits sowie der Client auf der anderen Seite. Im Gespann mit sogenannten Cookbooks waren diese Komponenten völlig ausreichend, um selbst großen Flotten mit Chef automatisiert eine komplette Konfiguration zu verpassen. Traditionell folgt Chef einem Server-Client-Schema, obgleich sich lokale Änderungen auf einzelnen Systemen ebenfalls mittels der Chef-Komponenten einspielen lassen.

Abbildung 4: Chef Infra besteht aus dem Server, dem Client sowie der Workstation. Hinzu gesellt sich der Compliance-Tester Inspec mit dem CI/CD-Werkzeug Habitat. Quelle: Chef

Chef Infra umfasst drei Subkomponenten. Der Server ist das Herz einer Automationsumgebung auf Basis von Chef. In ihm liegen zentral alle Konfigurationsparameter für alle Server der Umgebung. Hier liegen auch die Cookbooks bereit, die die Zielsysteme mit einer spezifischen Konfiguration versehen. Mittels einer zentralen API lässt der Chef-Server sich abfragen; er enthält zudem die Policy-Komponente, die Berechtigungen und Abläufe in Chef mit einem Rechteschema versieht. Zu guter Letzt ist Chef Server mittels des Supermarket an ein Verzeichnis angebunden, aus dem heraus sich weitere Cookbooks oder andere Komponenten nachinstallieren lassen.

Dem Chef-Server gegenüber steht der Chef Infra Client. Er läuft als Agent auf jedem einzelnen System und empfängt dort die vom Chef Server für den jeweiligen Host ermittelten Befehle, um sie lokal auszuführen. Quasi eine Art Bindeglied zwischen Administrator und Chef Infra bildet die Chef Workstation, die selbst Bestandteil der Lösung ist. Hier finden sich die bekannten Werkzeuge wie Knife, mittels derer der Admin die passende Konfiguration pro Host im Chef Infra Server hinterlegt.

Was Cinc tut

Soviel sei vorweg bereits gesagt: Derzeit kann Cinc mit den eigenen Tools noch nicht das komplette Toolset von Chef Infra abdecken. Zu Redaktionsschluss Anfang Januar hatten die Cinc-Entwickler eigene Versionen von Chef Infra Client sowie eine Vorserienversion von Chef Infra Workstation im Portfolio. Im Hintergrund liefen die Arbeiten an einem Cinc-Pendant zu Chef Infra Server auf Hochtouren, sodass sich bald eine vollständige Kompatibilität zum “echten” Chef ergeben sollte.

Dabei darf man nicht vergessen, dass das Bauen einer Chef-Community-Distribution, die den offiziellen Segen von Progress Software hat, alles andere als trivial und angenehm ist. Faktisch fangen die Cinc-Leute bei jeder Komponente bei null an. Zunächst geht es darum, Pakete mit angepassten Pfaden zu bauen, die sich nicht mehr mit den offiziellen Chef-Paketen ins Gehege kommen. Danach muss die Bezeichnung “Chef” überall dort verschwinden, wo sie dem Endanwender gegenüber insinuieren könnte, es handele sich um ein offizielles Produkt von Progress Software.

Einmal mehr bietet sich der Vergleich mit Iceweasel bei Debian an: Der Aufwand, den das Projekt seinerzeit in das Debranding von Firefox investieren musste, war erheblich – vor allem vor dem Hintergrund, dass er über viele Jahre mit jeder neuen Version wieder anfiel. Ein ähnliches Schicksal blüht den Cinc-Machern. Die bestehen übrigens, wer wollte es ihnen auch verübeln, vehement darauf, mit Progress Software in keiner wie auch immer gearteten Weise verbandelt zu sein.

Ausdrücklich erwähnt sei an dieser Stelle nochmals, dass Cinc, so weit es rechtlich zulässig ist, so kompatibel wie möglich zu Chef sein möchte. Für eine bestimmte Chef-Version konzipierte Cookbooks etwa sollen dem Willen der Entwickler nach auch mit derselben Version von Cinc funktionieren. Grenzen sind der Kompatibilität freilich an Stellen wie Dateisystempfaden gesetzt, eben weil sich die erzwungenermaßen von denen von Chef unterscheiden müssen. Ein Drop-in-Replacement kann Cinc insofern nicht werden.

Cincs Inspec funktioniert gut

Die wohl am weitesten fortgeschrittene Komponente im Cinc-Portfolio ist das Gegenstück zu Chef Inspec (Abbildung 5), also zu einer Komponente, die anfangs gar nicht zu Chef gehörte und die Progress Software zugekauft hat. Inspec war im Linux-Magazin bereits Thema [1].

Abbildung 5: Inspec verfügt über eine deklarative Skriptsprache, in der Admins Bedingungen definieren – sind die auf dem System nicht gegeben, schlägt das Werkzeug Alarm.

Das Tool steht an der Seite von Chef Infra. Während Letzteres die Konfiguration der Systeme übernimmt, kümmert sich Inspec hauptsächlich um die Überwachung. Über eine eigene, deklarative Skriptsprache hinterlegt der Administrator pro System Compliance-Regeln, deren Einhaltung Inspec dann automatisch überprüft. Soll etwa die Datei »/etc/passwd« einen bestimmten Eintrag nicht enthalten, legt der Systemverwalter das per Konfiguration fest und ruft auf dem jeweiligen System hinterher Inspec auf. Findet Inspec den Eintrag in der »passwd«, schlägt es Alarm.

Weil auch Inspec als Markenname geschützt ist, trägt die Komponente bei Cinc den Namen Auditor. Wie ein schneller Test mit vorhandenen Definitionen für Host-Compliance ergab, arbeitet Cinc Auditor in der Tat vollständig kompatibel zu Inspec. Im Versuch glichen sich beim Aufruf von Chef Inspec und Cinc Auditor Ein- wie Ausgabe wie ein Ei dem anderen. Gelingt es den Cinc-Leuten mit derselben Zuverlässigkeit, auch die anderen Teile von Chef in die eigene Distribution zu packen, gibt es für Admins keinen Grund, Cinc nicht anstelle von Chef in Betracht zu ziehen (Abbildung 6).

Abbildung 6: Cinc Auditor, das Gegenstück zu Inspec (hier im Bild), funktioniert bereits gut und ist produktiv einsetzbar.

Chefs Distributions-Guidelines

Es ist übrigens keineswegs so, als sei den Chef-Machern nicht selbst der Gedanke gekommen, es mit dem Lizenzwechsel etwas zu wild getrieben zu haben. In einer eigenen FAQ [2] hält das Unternehmen einerseits fest, dass der Chef-Code aktuell keine Checks enthält, die den Workload vor Ort automatisch klassifizieren, um Lizenzverstöße zu ahnden. Man begründet das damit, dass man um die eigene Verantwortung für jene Setups wisse, in denen Chef als Mission-critical-Komponente zum Einsatz kommt und die selbst von Relevanz etwa für den Betrieb wichtiger Infrastruktur sind. Solche Checks seien auch absehbar nicht geplant, heißt es weiter. Ob man auf solche Versprechen des Herstellers noch etwas gibt, ist freilich eine Frage der persönlichen Einstellung.

Andererseits nimmt der Hersteller im selben Dokument die Option eines Forks oder einer externen Distribution durchaus vorweg. Man wäre aber nicht Chef, würde man nicht auch dieses Pferd zu reiten versuchen. Vorsorglich hat Chef deshalb eine Distribution Guideline vorgestellt, an die Distributoren sich halten sollen. Verantwortlich für die Inhalte von Distributionen und Forks seien deren jeweilige Macher, so der Hersteller.

Explizit lehnt Progress Software es im selben Dokument auch ab, externen Distributoren aus der Community Schützenhilfe beim Bauen zu geben. Die Feststellung, ob eine Chef-Distribution mit der Distributorenrichtlinie sowie den Trademark-Vorgaben kompatibel sei, könne man mangels Ressourcen für externe Projekte nicht treffen, heißt es seitens Progress Software. Im Klartext: Ob Distributoren wie Cinc richtig stehen, merken sie spätestens dann, wenn sie Post von Chefs Anwälten erhalten.

Fazit

Cinc erweist sich als rettender Anker für verzweifelte Admins, die nicht wegen eines Lizenzverstoßes in Schwierigkeiten geraten wollen. Zwar ist der Umstieg von einer älteren Chef-Version auf eine aktuelles Cinc-Release mit ein paar Hürden verbunden, was vor allem Pfade zu Dateien im Dateisystem betrifft. Frei nach dem Motto “lieber ein Ende mit Schrecken als ein Schrecken ohne Ende” ist das aber deutlich weniger aufwendig als die Pflege eigener Pakete und mithin akzeptabel.

Deutlich weniger akzeptabel ist der Stunt von Progress Software, der Admins zwingt, zu diesen Notfallmaßnahmen zu greifen. Freilich steht es jedem Softwarehersteller frei, sein Geschäftsmodell zu bestimmen und im Lauf der Zeit zu verändern. Wenn das aber dazu führt, dass im Grunde die technische Basis von Setups wegfällt, verursacht das einen heftigen Vertrauensbruch zwischen Anbieter und Nutzer.

Auch hier schlägt Cinc die Brücke, und das könnte für Chef zu einem bösen Erwachen führen. Wenn es den Cinc-Machern nämlich gelingt, die Qualität ihres Produkts hoch zu halten, könnte die Distribution Nutzer von Chef abziehen. Das hätte der Anbieter dann allerdings allein sich selbst zuzuschreiben. (jcb)