Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

11.01.2006

Broker helfen bei Open-Source-Auswahl

Kai Dupke 
Die ungeheure Menge der Open-Source-Projekte behindert Entscheider. Ein Broker kann zwischen Entwicklern und Anwendern vermitteln. Die Anforderungen sind allerdings hoch.
Der Open-Source-Broker muss in der Lage sein, eine hinreichend große Übereinstimmung zwischen den Interessen zweier Welten herbeizuführen.
Der Open-Source-Broker muss in der Lage sein, eine hinreichend große Übereinstimmung zwischen den Interessen zweier Welten herbeizuführen.

Die Suche nach einer Open-Source-Strategie stellt Entscheider regelmäßig vor schier unüberwindbare Hürden. Der Versuch, entsprechende Software einzusetzen, scheitert häufig schon daran, einen Überblick über potenziell nützliche Projekte zu gewinnen. Allein das Portal Sourceforge.net, der bekannteste Hoster von Open-Source-Initiativen, führt über 98000 Projekte mit mehr als einer Million beteiligten Entwicklern auf.

Hier lesen Sie …

• was die Zusammenstellung der passenden Open-Source-Programme so schwer macht;

• welche Aufgaben ein Broker als Schnittstelle zwischen Anwendern und Entwicklern hat;

• über welche Qualifikationen ein Broker verfügen sollte;

• wie sich Anwender gegenüber Open-Source-Projekten verhalten sollten.

Zusätzlich werden Entscheidungen für Open Source durch fehlende Informationen über Return on Investment und Total Cost of Ownership oder die Zukunftsfähigkeit eines Arbeitsansatzes behindert. Vielerorts fehlen Informationen über den erfolgreichen Einsatz in Unternehmen. Auch werden in der Regel keine Aussagen über die Aufwendungen für Migration, Einführung oder Betrieb getroffen. Letztendlich vermag der Anwender häufig keinen schnellen Einblick in die Struktur oder den Hintergrund eines Projektes zu gewinnen, weshalb er dessen Überlebensfähigkeit nicht bewerten kann.

Die hier dargestellten Hürden liegen in der Natur von Open Source begründet. Fast alle quelloffenen Lösungen werden unabhängig von Firmenstrukturen oder unternehmerischen Überlegungen entwickelt. Daher muss ein Anwender auf jene Informationen verzichten, die ein klassisches Produkt-Marketing zur Verfügung stellen würde.

Das Gute daran ist, dass diese Open-Source-Projekte keinen marktpolitischen Einflüssen oder Überlegungen ausgesetzt sind. Fast immer arbeiten die Entwickler regelrecht kompromisslos auf ihr Ziel hin. Und das besteht normalerweise darin, die technisch beste Lösung zu finden. Dadurch ist im Open-Source-Umfeld kaum mit Lösungen zu rechnen, die noch gar nicht fertig sind, das aber vorgaukeln.

Für den Anwender ist Open Source ein Rohdiamant, der seinen Vorstellungen entsprechend geformt werden kann. Hier kommt der Open-Source-Broker ins Spiel. Er vermittelt zwischen der Entwickler-Community und dem potenziellen Anwender. Dazu begleitet er den Anwender vom Wunsch, Open Source einzusetzen, bis zum erfolgreichen Betrieb.

Was passt zum Anwender?

Nachdem der Broker ein Projekt identifiziert hat, prüft er, wie es zur Strategie des Kunden passt. Hierzu wird er immer nach einer festen Methode vorgehen. Im ersten Schritt analysiert der Open-Source-Broker die Übereinstimmung zwischen Projektstand und Kundenwünschen. Hier sind die bekannten und klassischen Produkte am einfachsten einzuordnen. Um in anderen Fällen das volle Potenzial von Open Source nutzen zu können, untersucht der Broker das Projekt an sich.

Wie auch bei proprietärer Software steht die aus strategischer Sicht wichtigste Frage zur Dauerhaftigkeit eines Projektes am Anfang. Hierbei ist selten das Alter einer Open-Source-Lösung maßgeblich, sondern die potenzielle künftige Entwicklung und damit Anpassungsfähigkeit an sich ändernde Anforderungen. Es gibt Projekte, an denen mehrere hundert oder tausend Entwickler mitarbeiten, aber weitaus mehr mit deutlich unter zehn Aktiven. Von der Anzahl der Entwickler unabhängig ist die Aktivität eines Projektes zu bewerten - auch ein Projekt mit wenigen Mitgliedern kann extreme Fortschritte machen, wenn das geeignete Know-how und die Motivation zur Entwicklung vorhanden sind.

In beiden Fällen kann das weitere Vorgehen von der Projektpolitik abhängen, die sich von Fall zu Fall unterscheidet. Auf der einen Seite gibt es Projekte, die eine klare Struktur in den Bereichen Entwicklung oder Mitarbeit haben. Andere Projekte haben scheinbar gar keine Organisation, sondern werden eher spontan abgestimmt.

Ist ein Open-Source-Projekt für den Anwender bereits in einem produktionsreifen Zustand, so ist die Beurteilung klar: Je größer ein Projekt und je höher die Teilnehmerzahl, desto geringer ist die Gefahr einer überraschenden Entwicklung oder Einstellung des Projektes. Sofern für den produktiven Ansatz jedoch Features - egal welcher Größenordnung - fehlen, muss die Frage in den Vordergrund gestellt werden, wie diese sich erstellen lassen.

Wünsche in Projekte einbringen

Hier können kleine Projekte im Vorteil sein, da entweder externe Entwickler auf einfachem Wege Programmcode einbringen können oder sich sogar Entwickler des Originalprojektes für die Entwicklung gewinnen lassen. Bei großen Projekten hingegen ist die Mitarbeit häufig bereits formalisiert, es existieren klare Regeln. Hier besteht dann jedoch die Gefahr, dass gerade ein gewünschtes Feature von den Projektentscheidern abgelehnt oder durch andere Interessenten in den Hintergrund gedrängt wird. In beiden Fällen untersucht der Open-Source-Broker das Projekt auf ähnlich gelagerte Vorkommnisse in der Vergangenheit.

In vielen Projekten sind einzelne Teilnehmer, fast immer ihre Initiatoren, in einer herausragenden Position. Der Broker versucht, Kontakt zu diesen Leuten aufzubauen. Die wichtigste Aufgabe hierbei ist fast immer die Darstellung seiner Open-Source-Affinität sowie seiner Kenntnisse des Open-Source-Modells. Denn in nicht wenigen Projekten wird der Einstieg eines kommerziellen Partners eher gefürchtet. Im optimalen Fall schafft es der Open-Source-Broker, den Kunden als gleichwertigen Partner in einem Projekt zu etablieren.

Wichtig für den Kunden ist, dass sich das Ziel einer für beide Seiten vorteilhaften Situation nur erreichen lässt, wenn er sowohl Beiträge zu einem Projekt als auch organisatorische Mitarbeit leistet. Der Broker kann helfen: sei es durch die Einbeziehung von durch ihn vermittelten Ressourcen oder durch die direkte Mitarbeit an einem Projekt. Die Rückgabe eigener Leistungen an ein Projekt ist ein zentrales Element jeder Open-Source-Strategie.

Über Implementierung hinaus

Neben der Auswahl der passenden Open-Source-Projekte kümmert sich der Broker auch um die Zeit nach der Einführung eines Produkts. An vorderster Stelle stehen der Investitionsschutz sowie die Verfügbarkeit und Fehlerfreiheit der eingesetzten Lösung. Während die Mitarbeit an einem Projekt fast immer der beste Schutz ist, beinhaltet Open Source natürlich an sich bereits die Sicherheit, dass das Produkt nicht einfach vom Markt verschwindet. Dadurch ist eine faktische Verfügbarkeit des Produktes gewährleistet. Für die tatsächliche Verfügbarkeit mag es notwendig sein, im Rahmen des Produktzyklus später entweder eigene Wege zu gehen, indem das Projekt komplett durch eigenes oder zugekauftes Personal gewartet wird, oder aber abgesplitteten Projekten zu folgen.

Die Absplitterung ist im Open-Source-Bereich ein häufig auftretendes Moment der Weiterentwicklung. Bedingt durch die freie Verfügbarkeit des Sourcecodes, finden sich immer wieder Teams von Entwicklern zusammen, denen die Entwicklung des Ausgangsprojektes nicht schnell genug oder in die falsche Richtung geht. Der Broker muss die Projekte fortlaufend beobachten, um solche Entwicklungen zu erkennen und zu bewerten. Unter Umständen kann die Zustimmung oder Ablehnung eines kommerziellen Anwenders eine Absplittung erst ermöglichen beziehungsweise verhindern.

Entwicklung weiter beobachten

Daneben muss der Open-Source-Broker immer ein Auge auf andere Projekte und Entwicklungen haben. Projekte, die bei der Erstauswahl als nicht geeignet erschienen, können sich im Laufe der Zeit zu einem vollwertigen Kandidaten entwickeln oder Features bekommen, die sich sinnvoll in das bereits eingesetzte Projekt integrieren lassen. Durch die fehlenden Lizenzkosten für Open Source wird ein Wechsel zwischen Projekten und ihren Lösungen auf die Frage der Produktivitätssteigerung und des Return on Investments (ROI) reduziert.

Für den produktiven Einsatz mindestens genauso wichtig wie die Verfügbarkeit ist die Frage nach dem Support für die eingesetzten Lösungen. Der Broker sollte hierbei aus den unterschiedlichen Modellen für seinen Kunden eine passende Lösung erarbeiten. Den Support können Mitarbeiter des Kunden bereitstellen oder Mitglieder des eigentlichen Projektteam, oder Entwickler aus dem Netzwerk des Open-Source-Brokers. Je nach Projektstruktur empfiehlt es sich, den Broker als zentrale Ansprechstelle für Support zu etablieren.

Der Broker ermöglicht es Unternehmen, Open Source erfolgreich einzusetzen. Er muss dazu die Sprache beider Seiten verstehen und sprechen. Für den optimalen Kundennutzen hat der Broker daher sowohl Erfahrung im Bereich von Projekten und dem Einsatz von proprietären Systemen im produktiven Umfeld als auch Erfahrung und Kontakte in der Open-Source-Szene. (ls)