In Blogposts und auf der Mailingliste diskutiert die (Open) Suse-Community seit der Open Suse Conference in Thessaloniki verstärkt über die Ziele und Strategie des Projektes. Vor allem die vielen Softwarequellen vom Open Build Service über Factory bis zuTest- und Developer-Repositories möchten die Beteiligten umstrukturieren. Dabei steht auch eine andere Planung für die Distribution Open Suse auf der Liste. Sie soll wieder näher an die Enterprise-Variante rücken und professioneller werden.
Während Red Hat und Fedora, aber auch Debian und Ubuntu eine scheinbar klare Rollenverteilung besitzen, hat die Suse-Community in den letzten Monaten zunehmend Unklarheiten bei Ihrer Zielgruppe ausgemacht. Fedora etwa sieht sich als reine Entwickler-Distribution und verzichtet recht deutlich auf Neueinsteiger, RHEL liefert das darauf aufbauende Enterprise-Linux für Profis. Ubuntu adressiert die Einsteiger, Debian die Linuxer, denen die Freiheit und Unabhängigkeit von Unternehmenslogik wichtig ist. SLES hat seinen Vorsprung am Markt unter anderem im HPC-Umfeld und bei Cloud- und Cluster-Kunden, aber auch, wenn es darum geht, auch fremde Distributionen oder Betriebssysteme zu pflegen.
Open Suse dagegen hat sich da nicht so klar festgelegt, und das haben mittlerweile auch die Mitglieder der Community erkannt. Sowohl aus der Firma Suse (siehe die Keynote von Ralf Flaxa auf der OSC 2013 in Thessaloniki) als auch aus der Open-Suse-Gemeinschaft drängen derzeit mehr und mehr Fragen nach oben, was denn der typische Suse-Anwender sei und wie die verschiedenen Software-Quellen und -Repositories zu interpretieren seien. Im Vergleich zu anderen Distributionen steht das Chamäleon nämlich recht heterogen da. Vom Kernel-Entwickler über den Linux-Desktop-User bis zu Windows-Admins, die “mal schnell was mit Yast, per Mausklick administrieren wollen” reicht die Zielgruppe. Und die können (müssen?) aus einer Vielzahl von Quellen auswählen: Tumbleweed ist die Rolling Release, Factory das Testbett für Mutige, dazu gibt es aber auch noch mit Developer-Repositories einzelner Projekte und dem Open Suse Build Service gleich eine ganze Handvoll verschiedener Softwarequellen für ambitionierte User. Und bald soll mit Evergreen auch noch Long-Term-Enterprise-Support für einst veraltete Open-Suse-Distributionen kommen, ebenfalls über eigene Repositories.
Factory: Suse Pakete für erfahrene Anwender.
Open Suse ist das Testbett für SLES
Klar ist, dass Open Suse das Testbett ist, aus dem die Firma Suse das Suse Linux Enterprise baut. Doch erwächst hier mittlerweile eine Lücke, meint nicht nur Community-Manager Jos Poortvliet in seinem Blog. Während Suse eindeutig auf Unternehmenskunden abziele, sei die Anwenderlandschaft von Open Suse sehr weit gefasst, was eine Spezialisierung erschwere. Poortvliet schreibt, man wolle gleichzeitig Open Governance stärken, also Open Suse mehr Freiheiten lassen, als auch die Lücke füllen, damit aus der freien Distribution mehr Input für SLES erwachsen könne.
Open-Suse-Community-Manager Jos Poortvliet bei seiner Keynote in Thessaloniki.
Das bedeutet Poortvliet zu Folge (Hier ein Video von ihm aus Thessaloniki) auch, dass die Firma Suse mehr Entwickler für Open Suse abstellen wird, auch mit dem Hintergedanken, Open Suse mehr im professionellen Bereich zu etablieren. Das bringt einige Änderungen mit sich, die die Community gerade hier diskutiert. So überdenkt man die derzeitigen achtmonatigen Releasezyklen, die “aus einer Zeit stammen, als es weder Tumbleweed noch OBS noch Evergreen gab”, und möchte sie zugunsten langfristigerer Planung mit höheren QA-Ansprüchen und -Aufwänden umstrukturieren. Außerdem solle sich die Community, schreibt deren Manager, überlegen, worauf man sich konzentrieren wolle. Open Suse sei bekannt dafür, “alles einigermaßen gut zu machen, aber nichts perfekt”. Dank dem OBS gelinge das recht gut, dennoch gäbe es Verbesserungspotenzial, schreibt Poortvliet.
Ausgehend von den Wünschen, mehr automatisiertes Testen einzuführen, mehr Menschen zu beteiligen und Tumbleweed, Devel und Factory in Einklang zu bringen, geht es letztendlich vor allem darum, wie sich die Factory besser in Suses Distributionslandschaft integrieren ließe. Wolle man höhere Qualität, längere Release Cycles und eine klarere Zielgruppe erreichen, dann könne man beispielsweise die bestehende Infrastruktur in Komponenten aufteilen, etwa “eine Core Selection plus Open Build Service”, oder aber das Ganze in konzentrische Ringe aufteilen.
Ein Ring, sie zu knechten?
Diese Idee hat die Community bereits länger diskutiert, dabei würde ein Ring 0 beispielsweise alles beinhalten, was für Bootstrap und Compiler notwendig sei, Ring 1 dann “alles hinauf bis zu X”. Der wird alle zwei Jahre released und drei Jahre maintained. Ring 2 enthält die Desktops und ihre Frameworks und wird zwei Jahre gepflegt, Ring 3 bringt Applikationen und Development Tools – direkt aus dem OBS, mehr oder weniger als Rolling Release wie bei Tumbleweed.
Der oben genannte “Core” könnte dann aus Ring 0 und 1 bestehen, auf Enterprise-Level getestet und gehärtet sein, und zusammen mit einem Basis-Desktop plus Libre Office und Firefox eine Open-Suse-Release ergeben. “Den Rest holt sich der Anwender einfach aus dem Open Suse Build Service”, schreibt Poortvliet. So eine Release wird naturgemäß deutlich kleiner, kann aber auch deutlich näher an der Enterprise-Version liegen.
Die Frage, wofür sich die Community entscheidet, meint Poortvliet, sei aber nicht, was technisch möglich sei, sondern “Was ist unser Ziel? Wo wollen wir hin? Wen wollen wir als typischen Open-Suse-User adressieren?”. Über dieser Frage brüten die an Open Suse Mitwirkenden schon länger, eine schnelle Lösung scheint nicht in Sicht – doch beschäftigt diese Frage die grüne Community zunehmend.
