Open Source „Der Glaubenskrieg um Linux ist vorbei“

Redakteur: Martina Hafner

Vor einem Jahr wurde der Linux Business Campus Nürnberg gegründet mit dem Ziel, die Metropolregion Nürnberg als europäisches Zentrum für Open-Source zu etablieren. Ein Mann der ersten Stunde ist Dr. Uwe Kracke, Geschäftsführer des Linux-Spezialisten emlix. Im Gespräch verriet er, woran am Campus gearbeitet wird und wo Linux zurzeit steht.

Anbieter zum Thema

Herr Dr. Kracke, Ihre Firma emlix hat im Sommer dieses Jahres eine Niederlassung in Nürnberg eröffnet. Ein Grund ist auch die Zusammenarbeit mit dem Linux Business Campus. Worum geht es dort?

Die Idee von Richard Seibt, dem Vorstandsvorsitzenden des Vereins, war es, die Unternehmen die in der Metropolregion Nürnberg am Thema Linux arbeiten, zusammen zu bringen. Zu den Aktivitäten zählen zahlreiche Projekte zu Themen wie Embedded-Linux oder Verfahren von Open-Source-Softwareentwicklung. Ferner existiert eine enge Zusammenarbeit mit der Friedrich–Alexander−Universität. Der Campus hat derzeit 89 Mitglieder, davon 55 Firmen, 29 Einzelpersonen und 5 institutionelle Mitglieder. Er hat damit mittlerweile auch eine Größe erreicht, mit der man etwas bewegen kann.

Der Linux Business Campus bietet auch kostenlose Beratung zum Thema Linux an.

Die Organisation hat mittlerweile etwa 50 Campus Coaches die aus der Berufspraxis von Open-Source-Unternehmen kommen. Wenn zum Beispiel jemand eine Geschäftsidee hat und Kontakt zu Leuten aus der Praxis sucht, die diese unter technischen, wirtschaftlichen und rechtlichen Gesichtspunkten beurteilen können, hat er die Möglichkeit, zu solch einem Linux-Experten Kontakt aufzunehmen. Im vergangenen Jahr gab es 160 Coaching Sessions. Ferner gibt es ein Finanzierungsforum, um junge Unternehmen und Kapitalgeber zusammen zu bringen und einen Business-Plan-Wettbewerb für Geschäftsideen aus dem Open-Source-Bereich.

Sie persönlich sind stark im Embedded-Projekt engagiert.

Dieses Projekt liegt an der Schnittstelle zwischen Linux Business Campus und dem Embedded Systems Insituts an der Friedrich-Alexander-Universität ESI und soll mehr Austausch zwischen Wirtschaft und Universität schaffen. Meine Aufgabe an dieser Stelle ist es, alle Mitglieder der Wertschöpfungskette zu verbinden. Dazu gehören Chiphersteller die Linux auf ihren Chips einsetzen wollen, Distributoren, die Halbleiterbausteine zu Paketen schnüren sowie Software-Integratoren, System-Integratoren und Anwender, ferner Forschung und Wissenschaft. Ich versuche, diese Akteure an einen Tisch zu bringen und die unterschiedlichen Informationsbedarfe zu kanalisieren. Zum Beispiel können sich Universitäten mit ihrer Forschung in Richtung Unternehmen orientieren, und die Firmen haben wiederum eine Anlaufstelle um zu erfahren, was an der Universität passiert. Das Problem ist ja, dass man nebeneinander arbeitet oder forscht aber nicht viel voneinander weiß.

Was passiert an der Universität derzeit in Richtung Linux?

Zunächst forscht die Universität ja frei von konkreten Technologien, also betriebssystemunabhängige. Eine Frage, mit der man sich derzeit beschäftigt, ist, wie sich der Entwicklungsprozess von Hard- und Software parallel betreiben lässt. Die Arbeitsweise ist ja typischerweise so, dass die Hardwareentwickler Anforderungen aus der Applikationsentwicklung erhalten und auf dieser Basis eine funktionierende Hardware auf den Tisch legen. Dann kommen die Softwareentwickler und setzen darauf auf. Wir arbeiten an vielen Stellen sequentiell. Ein anderer Ansatz wäre, sich zu überlegen, wie man diesen Entwicklungsprozess parallelisiert und schneller die wechselseitigen Ansprüche und Randbedingungen in den Entwicklungsprozess integriert. Weitere klassische Fragen sind Systemgestaltung und Softwareverwaltung.

Eine wesentliche Frage ist auch, wie sich ein hochgradig modulares Betriebssystem, das aus vielen Teilbausteinen besteht, in einem Prozess reproduzierbar darstellen lässt. Im Gegensatz zu älteren Betriebssystemen haben wir bei Linux ja keine monolithische Struktur. Viel mehr ist man mit einem sich permanent ändernden Umfeld konfrontiert, das immer wieder interessante Komponenten für den Entwicklungsprozess bietet. Das sind Fragen des Softwaremanagements die man vor zehn Jahren so noch nicht hatte.

Für das Management modularer Linux-Software haben sie ein Build System entwickelt.

Diese Lösung ist Ergebnis firmeninterner Forschungs- und Entwicklungsaktivitäten und beantwortet unmittelbar Anforderungen aus der Praxis. Interessant diesbezüglich war, dass ich in einem der ersten Gespräche am ESI eben diese Anforderungen aus der Praxis geschildert habe. Wir haben festgestellt, dass wir mit anderen Worten und in einem anderen Kontext von dem selben Problem reden. Dahinter steht letztendlich die Frage, wie man ein Betriebssystem als resultierende Softwareschicht zwischen der Hardware und der Applikation entwickelt. Die Hardware gibt uns Randbedingungen vor, die Applikation und der Einsatzkontext ebenfalls.

Die Frage ist, ob ein Betriebssystem, das dazwischen liegt, statisch und in seinen Funktionen fest umrissen sein muss oder ob es nicht eigentlich flexibel auf die Anforderung der beiden Seiten reagieren können sollte. Wir waren sehr schnell der Meinung, dass die Mittelschicht eher eine resultierende als eine feste statische Schicht ist. Zurzeit testen wir eine neue Version des Build-Systems. Dort sind auch schon Anregungen und Fragestellungen, die aus diesem Gespräch resultieren, mit eingeflossen.

Welche Herausforderungen beherrschen derzeit den Linux-Markt?

Im Gegensatz zu vor fünf Jahren ist die Entscheidung für oder gegen Linux mittlerweile kein Glaubenskampf mehr sonder eine ganz pragmatische Entscheidung auf Basis technischer oder ökonomischer Überlegungen. In sofern haben wir die gleichen Anforderungen wie die Hersteller proprietärer Betriebssysteme. Aktuell ist das Thema grafische Benutzeroberflächen, die optisch immer mehr her machen sollen. GUIs und Multimedia-Darstellung finden sich heute auch in Bereichen wie der Maschinensteuerungen, wo man dies bisher vielleicht gar nicht vermutet hatte. Auch im Medizintechnik-Bereich ist dies ein starker Trend.

Charakteristisch für Linux ist ferner, dass es gerne eingesetzt wird, wenn Geräte hochgradig vernetzt werden sollen, wo es also Schnittstellen geben soll zwischen Feldebene zum einen und in die vertikale Richtung zum anderen, also z. B. wenn Prozessdaten direkt in ein SAP-System übergeben werden sollen. Diese Fälle sind typisch für Linux, weil es modular aufgebaut ist und die notwendigen Kommunikationsprotokolle und Infrastrukturkomponenten mitbringt.

Welche Probleme ergeben sich daraus?

Es gibt immer Anforderungen die man noch nicht befriedigen kann oder Fälle, in denen mit sehr kostengünstigen Chips Grafikleistung erwartet wird, die technisch einfach nicht machbar ist. Gerade im Bereich Video ist dies ein Thema, also z.B. die Decodierung von MPEG auf sehr schwach ausgestatteten Boards. Hier trifft uns die Tatsache, dass Linux ein komplettes und umfangreiches Betriebssystem ist. Man kann es nur in einem bestimmten Maße klein und schlank machen. Deshalb gibt es auch Grenzen, was die Nutzung angeht. Dann ist Linux zwar potentiell auf einer Hardwareplattform lauffähig, wenn aber obendrauf eine Anwendung kommt, die mit Grafik, Video und Sound arbeiten soll, ist das System nicht adäquat für den Einsatzkontext.

Wann würden sie insbesondere zu Linux raten?

Linux wird dann gerne von unseren Kunden genommen, wenn es darum geht, langfristig technische Transparenz zu schaffen. Der Hauptvorteil ist, dass das Gesamtsystem im Source Code verfügbar ist. Selbst wer nicht auf dieser Ebene einsteigen will, hat potentiell die Möglichkeit. Da die Community die älteren Versionen weiterentwickelt bzw. wartet, schützt dies vor Abkündigungen oder fehlendem Support.

Ein zweiter Aspekt trägt überall dort, wo die Themen Vernetzung und offene Standards eine wichtige Rolle spielen und ich heute möglicherweise noch gar nicht weiß, welche Anforderungen der Anwender eines Systems übermorgen hat.

Ein Beispiel ist die Medizintechnik. Testsysteme die in der pharmazeutischen Industrie eingesetzt werden hatten vor fünf Jahren weder USB noch Ethernet. Nachdem die FDA ihre Bestimmungen geändert hatte und zwischen Open und Closed Systems unterschieden wurde begannen die Gerätehersteller ihre Produkte kommunikationsfähig zu machen. Mit Linux war dies sehr einfach, denn die benötigte Softwareinfrastruktur war bereits verfügbar. Bei einem zugekauften Betriebssystemen ist es natürlich möglich, auf die Produkte der jeweiligen Hersteller zurückgreifen, mit den entsprechenden Investitionsentscheidungen, die dahinter liegen. Bei freier Software entfällt diese Schwelle.

Gibt es Rahmenbedingungen, unter denen Linux eher nicht in Frage kommt?

Generell kann man nicht sagen, hier oder dort passt Linux nicht. Es gibt aber Anforderungen die so strukturiert sind, dass man mit einem Produkt das genau darauf optimiert ist, technisch als auch wirtschaftlich besser fährt. Eine wichtige Überlegung ist, wie Hard- und Software zusammenwirken. Wenn ich eine Softwareplattform oder eine Hardware gegeben habe auf der ein Linux-System mit Multimedia nicht ausreichend schnell läuft, mag es sein, dass ein Windows CE dafür geeignet ist, weil es z.B. genau für diesen Chip optimiert wurde.

Weitere Überlegungen betreffen Entwicklungskosten, Anpassungsaufwand und Know-How der eigenen Mitarbeiter. Bei großen Firmen stecken gegebenenfalls strategische Entscheidungen auf Ebene des Topmanagements dahinter. Dann kommt es vor, dass eine ganze Produktfamilie mit Linux entwickelt wird, selbst wenn ein anderes System einfacher auf der gewählten Plattform laufen würde. Hintergrund ist, dass man sich langfristig den Vorteil der Investitionssicherheit und Transparenz verspricht. Und das Unternehmen baut Linux-Knowhow im Unternehmen auf.

Dann gibt es Bereiche in denen etablierte Lösungen vorhanden sind und ein Linuxsystem gar nicht erwogen wird. Auch dort mögen sich die Anforderungen ändern und Open Source in fünf oder zehn Jahren ein Thema sein – im Moment aber definitiv nicht. Open-Source-Software ist nicht die Antwort auf alle Fragen. Ich glaube, dass wir in den nächsten fünf oder zehn Jahren eine Vielfalt im Embedded-Bereich behalten werden, weil die Anforderungen zu unterschiedlich sind. Ein wachsender Teil ist jedoch Open-Source-fähig und prädestiniert dafür.

Wann empfehlen Sie eine Standarddistribution, wann eine individuelle Lösung?

Der große Vorteil der Standarddistribution von Anbietern wie Wind River, MontaVista oder auch Open-Source-Standard-Distributionen ist, dass es sich um fertig geschnürte Pakete handelt. Sie sind komfortabel bedienbar haben einen hochgradigen Produktcharakter, sind üblicherweise gut dokumentiert und es gibt spezielle Schulungen. Man kann also entsprechend schnell mit der Entwicklung starten, hat aber sicherlich Einschränkungen in der Flexibilität und bei der Hardwareunterstützung.

Aber es gibt natürlich Projekte, auf die diese Angebote genau passen. Dann gibt es Projekte in denen es um neueste Chip- oder Board-Technologie geht, die durch eine Standarddistribution nicht unterstützt wird. Die Individualdistribution macht auch dann Sinn, wenn der Anwendungskontext von vornherein so strukturiert ist dass mich die Standardlösung zu sehr einschränkt oder ich sie eigentlich auf links drehen müsste. Dann fahre ich mit einer individuellen, prozessorientierten Lösung besser. Ich muss mir aber auch überlegen, wie ich ein solches System mit unter Umständen bis zu Tausend Softwaredateien langfristig und unabhängig von einzelnen Mitarbeitern reproduzier- und wartbar mache. Insofern sehe ich eigentlich, dass der Markt beides braucht.

Wie steht es mit der rechtlichen Sicherheit rund um Linux?

Wir haben mittlerweile vier Urteile deutscher Gerichte die zunächst einmal die Gültigkeit der GPL im deutschen Rechtsraum bestätigen. Das war vor sechs, sieben Jahren noch anders. Damals war die Frage, ob dieses Lizenzmodell sich nach deutschem Recht etablieren kann, vollkommen offen. Durch die Urteile haben wir an einigen Stellen mehr Klarheit, was z.B. dem Umgang mit freier Software angeht. Dass Modell, Software im Quelltext zu lesen, zu verändern, wieder freizugeben und weiter zu distribuieren, ist also rechtlich gültig. Das heißt auch, dass Unternehmen, die sich an diese Spielregeln nicht halten, potentiell ein Problem haben und beispielsweise auf Unterlassung verklagt werden können oder ihre Produkte zurücknehmen müssen. Was nicht heißt, dass ich mein Kern-Knowhow unter die GPL stellen muss. Unter dem Strich kann man sagen, dass die Sicherheit in den letzten Jahren zugenommen hat.

Wie steht es mit dem Thema Patentrechtverletzungen?

Hier stehen sich die unterschiedlichen patentrechtlichen Situationen in Europa und USA gegenüber. An der Stelle gibt es rechtlich ungeklärte Fragen, aber stärker in den USA als in Europa. Falls wir eine Verschärfung des Patentrechts bekommen, mit dem Trivialpatente einklagbar sind−, werden wir alle für Deutschland als Kernland der Softwareentwicklung unabhängig von Open Source riesige Probleme bekommen. Wenn die Politik nicht erkennt, dass man gerade im Bereich technischer Software mit Trivialpatenten den gesamten Markt kaputt machen kann, werden nur noch einige wenige Großunternehmen übrig bleiben, die sich mit ihren Patenten bekriegen. So etwas wie Innovation auf der breiten Ebene wird es nicht mehr geben.

Man kann in USA teilweise schon sehen, dass Patente gehortet und als Geschütze gegeneinander aufgefahren werden. Leider gibt es in der Politik vielleicht aus Unkenntnis heraus Bestrebungen, siehe EU, das Recht so umzubauen, dass den Vertretern dieser Trivialpatente mehr Rechte an die Hand gegeben werden. Alle hoffen, dass das nicht passiert.

Welche technologischen Entwicklungen gibt es derzeit bei Embedded-Linux?

Interessant sind z.B. die Aktivitäten rund um das Thema Echtzeitfähigkeit. Hier stehen Firmen aus dem Embedded-Bereich wie Maschinenbauer seit etwa eineinhalb Jahren mit ihren Anforderungen nicht mehr alleine, Determinismus in den Betriebssystem-Kernel zu bekommen. Auch in der IT-Branche werden solche Rufe immer lauter - denkt man z.B. an die Virtualisierung. Dort braucht man jetzt also plötzlich Echtzeitfähigkeit. Das hat dazu geführt, dass im Linux-Kernel im Augenblick massiv daran gearbeitet wird, die Echtzeitfähigkeit direkt in den Standard-Kernel zu integrieren, anstatt auf spezifische Echtzeiterweiterungen wie Xenomai oder RTLinux zu nutzen, die man unter den Linux-Kernel schiebt.

Im Augenblick kann ein Maschinenhersteller, der Echtzeitanforderungen hat, mit einem Linux-System bis zu bestimmten Reaktionszeiten ohne Erweiterungen arbeiten. Sobald er aber Netzwerkkommunikation benötigt, braucht er einen Echtzeitzusatz. Ziel ist es auch, den Knowhow-Schutz zu verbessern, indem man bestimmte Hardwarezugriffe, die im Moment nur auf der Treiberebene möglich sind, auf die Applikationsschicht verlagert.

Welche typischen Fallstricke erleben Sie bei Kunden in Linux-Projekten

Grundsätzlich sieht man bei kleineren wie größeren Unternehmen, dass viele sich stärker als bisher mit dem Thema Software auseinander setzen müssen. Bei Open-Source-Software kommt hinzu, dass man auf einen anders strukturierten Markt trifft. Beim Produktanbieter, bei dem ich vielleicht bisher mein Betriebssystem gekauft habe, gibt es einen Ansprechpartner, ein Marketing, einen Vertrieb und einen Support. Beginne ich, das Thema Linux zu evaluieren, stehe ich plötzlich vor vielen Anbietern und einer weltweit verteilte Community. Ich habe also zunächst eine Orientierungsaufgabe.

Es gibt Linux-Projekte die haben massiv Probleme in der Spezifikationsphase, weil man es versäumt hat sich einen Augenblick zurückzulehnen und mit den Fragen zu beschäftigen, wie dieser Markt eigentlich strukturiert ist und welche Anforderungen an die Software vorhanden sind. Es gilt also zunächst, sich zu überlegen, was das Gerät können und leisten soll, und danach die Frage zu beantworten, welche Softwarekomponenten oder Fertigprodukte benötigt werden oder auch Support oder Beratung. An der Schwelle von 8 zu 16 Bit und mit dem Umstieg auf echte Betriebssysteme zieht das Embedded-Software-Management nicht immer im gleichen Maße mit den wachsenden Anforderungen mit.

Falsch ist auch die Annahme, Open-Source bedeute, dass ich an dieser Stelle nicht zu investieren brauche. Ich muss meine Mitarbeiter in die Lage versetzen, ein Linux-basiertes Projekt umzusetzen. Dazu gehört, sich das benötigte Wissen anzueignen, sei es durch Schulungen, einschlägige Literatur, oder andere Unternehmen, die Erfahrung bereit stellen. Hier schließt sich übrigens auch wieder der Kreis – denn genau der Erfahrungsaustausch ist es, der den Embedded Linux Cluster für alle beteiligten wertvoll macht.

(ID:227225)