Auf dem vorangegangenen Webmontag wurde im Vortrag eines kommerziellen Anbieters sehr abfällig über Open Source Software gesprochen. Open Source Programme wurden als "eh-da-Ressourcen" bezeichnet, die zwar existieren, aber in professionellen Enterprise-Umgebungen nichts zu suchen hätten.

Da wir bei comm-press mittlerweile unser gesamtes Business-Modell auf Open Source ausgerichtet haben, habe ich angeboten, auf dem Webmontag gestern im Werkheim Altona einen Vortrag über Business-Konzepte rund um Open Source zu halten.

Open Source sind quellcode-offene Produkte, die unter einer kostenlosen Lizenz veröffentlicht sind und von jeder Person heruntergeladen, eingesetzt und verändert werden können.

Nutzung von oder Wertschöpfung mit Open Source

Es stellt einen Unterschied dar, ob man eine Open Source Software einfach nutzt oder auf Grundlage der Software Dienstleistungen erbringen möchte.

Viele Open Source Produkte wie Linux, MySQL, OpenOffice, LibreOffice GnuPGP setzen wir als fertige Produkte so ein, wie sie sind. An anderen Projekten wie TYPO3, Contao, Joomla oder Wordpress arbeiten wir möglicherweise als Teil der Community mit, die die Software gemeinsam erstellt und pflegt und weiter entwickelt.

In diesem Vortrag möchte ich einen Einblick in die Arbeit mit Open Source vermitteln und Konzepte aufzeigen, wie sich mit der Arbeit auf Basis von Open Source Geld verdienen lässt.

Vorteile von Open Source

Das Rad muss nicht neu erfunden werden.

Anstatt im 100.000sten Web-CMS die immer gleichen Prozeduren für Warenkorb, Benutzer-Anmeldung, Passwort vergessen etc. programmieren zu müssen, ist es wirtschaftlicher, wenn viele Personen an unterschiedlichen Teilen eines Ganzen arbeiten, das anschließend wieder gemeinschaftlich genutzt werden kann.

Die Gestaltbarkeit der Software ist garantiert.

Alle Codes und Funktionen liegen transparent vor. Wenn ich als Anwender Wert auf eine bestimmte Funktion lege, an deren Implementierung ein kommerzieller Anbieter möglicherweise kein Interesse besitzt, kann ich dies selbst programmieren oder für mich programmieren lassen.

Eine riesige Testergemeinschaft sorgt für Code-Qualität.

Eine große Anwendergemeinschaft ist automatisch auch eine große Testergemeinschaft. Fehler treten häufig erst in einer Kombination bestimmter Sonderfälle auf, die nicht alle beim Testen berücksichtigt oder vorhergesehen werden. Je mehr Anwender Softwarebestandteile einsetzen, desto mehr Kombinationen werden getestet.

Sicherheitskonzepte

In großen Projekten arbeiten abgetrennte Teams, die sich bei neu veröffentlichten Code-Bestandteilen um die Einhaltung von Sicherheitsstandards kümmern, die Codes kontinuierlich auf Sicherheitslücken untersuchen und diese gemeinsam mit den Maintainern schließen.

Collaboration in weltweit verteilten Teams.

Die Mitarbeit in verteilten Teams stellt eine besondere Herausforderung an Dokumentation, Planung und Abnahme dar. Dies implementiert Standards in der Zusammenarbeit, die auch eigenen Projekten im Tagesgeschäft zu gute kommen.

Sorge vor dem Einsatz von Open Source

Fehlende Nachhaltigkeit

"Wenn der Entwickler keine Lust mehr hat oder einen lukrativeren Job annimmt, bin ich aufgeschmissen."

Selbst wenn die Quellcodes vorliegen, ist dies häufig ein Problem individueller Softwareentwicklung, bei der die gesamte Entwicklung auf den Schultern einer Person ruht. Je mehr Open Source eingesetzt wird, desto größer wird vermutlich auch die Übereinstimmung mit bewährten / bekannten Konzepten sein, die es einem neuen Anbieter erleichtern werden, sich in ein bestehendes Projekt einzuarbeiten.

Die Community funktioniert nicht / schläft ein / entwickelt den Code nicht weiter.

"Was mache ich, wenn mein Projekt einschläft? Wie komme ich an meine Daten?"

Dies ist kein spezielles Problem von Open Source, sondern betrifft genauso auch proprietäre Projekte. Im Gegensatz dazu ist eine Datenübernahme bzw. Projekt-Migration durch die Quellcode-Offenheit eher zu garantieren als bei Closed Source, bei welcher der Hersteller in aller Regel kein Interesse daran hat, die Daten und Einstellungen exportierbar bereitzustellen.

Bei Open Source habe ich zumindest die Garantie, dass ich – mit welchem Aufwand auch immer – wieder an die Daten kommen kann. Liegen die Daten in einem proprietären und möglicherweise sogar verschlüsselten oder binären Format vor, habe ich keine Möglichkeit.

Diese Sorge ist ernstzunehmen und erfordert eine Beobachtung der Softwarelandschaft über den Tellerrand der eigenen Lieblings-Software hinaus. Wenn Projekte einschlafen, kann dies etwas – muss aber nicht – mit der Qualität der Software selbst zu tun haben. Business-Anforderungen, aus denen die Software ursprünglich entstanden sind, lösen sich in aller Regel nicht plötzlich in Luft auf.

Softwareentwicklung hat einerseits immer auch etwas mit Evolution von Konzepten zu tun, die möglicherweise in anderen Projekten besser, schlanker, moderner umgesetzt werden oder einfach nur erfolgreicher kommuniziert werden.

Andererseits liegt es auch im Geschick der Community, die eigenen Benefits vorteilhaft zu kommunizieren. Sympathie, Freundschaft, "Liebe"(!) und auch schnöde Politik spielen bei Open Source ebenfalls eine große Rolle.

Gechäftsgeheimnisse werden öffentlich.

"Durch die Veröffentlichung der Codes legen wir unsere sensible Geschäftsgeheimnisse offen."

Dies ist nicht zu befürchten, da die Umsetzung eines bestimmten Geschäftsmodells in der Regel das Zusammenspiel vieler komplexer Bausteine voraussetzt. Üblicherweise fehlen nur einige Bausteine, deren Funktionen sich abstrakt diskutieren lassen, ohne die Businesslogik im Ganzen offenlegen zu müssen.

Geld mit Open Source verdienen

Wie bei jeder professionellen Tätigkeit setzt auch eine Dienstleistung auf Basis von Open Source substantielle Kenntnis der Konzepte, Stärken und Schwächen des Systems voraus.

Geld lässt sich mit Open Source verdienen z.B. durch:

  • Beratung und Entwicklung von Lösungsansätzen.
  • Umsetzung von Projekten: Einrichtung, Konfiguration und Anpassung eines Projektes bis zum Launch.
  • Betreuung von Projekten, Wartung und Bereitstellung von Service Level Agreements.
  • Training und Schulung.
  • Entwicklung individueller Anforderungen.
  • Software as a Service: z.B. Providing von Branchenlösungen.
  • Theme Stores: kostenpflichtige Add Ons um die Software herum, wie z.B. Themes - grafische Layouts.
  • „Karma“, werbliche Effekte nutzen
    Auftraggeber, die eigene Arbeiten distribuieren, erhalten innerhalb der Community viel Aufmerksamkeit, Sympathie und eine hohe Sichtbarkeit mit ihrer Expertise.
    Dies kann durchaus einen Grund darstellen, eigene Projekte zu starten.

„Was nichts kostet ist auch nichts wert.“

Wir empfehlen Vorsicht im Umgang mit Kunden, die ihre Entscheidung für Open Source hauptsächlich von einer Lizenzkostenersparnis im Vergleich zu anderen Produkten abhängig machen.

Kunden, die die Werthaltigkeit nicht erkennen, die im "Prozess Open Source" selbst steckt, werden geleistete Arbeiten möglicherweise nicht wertschätzen können, was zu anstrengenden Honorar-Rechtfertigungen führen kann.

Arbeiten mit Open Source

Nachhaltigkeit herstellen

Feature-Requests öffentlich diskutieren, soweit sie keine Geschäftsgeheimnisse enthalten.

Aktionismus vermeiden: vor der Umsetzung bestimmter Anforderungen kann es zielführend sein, Issue-Queues zum Thema durchzuarbeiten, Konzepte zu verstehen und mitzudiskutieren sowie gegebenenfalls auch Reaktionen abzuwarten.

Eigene Arbeiten nach Fertigstellung kommentiert an die Community zurückgeben und der Community dadurch einen guten Zugang zu gewähren, damit die Vorteile von Open Source auch diesen Code-Bestandteilen zugutekommen.

Wir halten es für ratsam, Zeiten und Aufwände für Interaktionen mit der Community in Projekten gegebenenfalls mit einzuplanen und dem Auftraggeber zu kommunizieren.

Fragen aus dem Publikum

Im Anschluss kamen einige Fragen, die ich aus meiner Erinnerung hier wiedergebe. Ich hoffe, niemanden übersehen zu haben...

Ist es sinnvoll, Support-Pakete einer Open Source Distribution zu erwerben?

Die Frage zielte auf Magento ab, bei der jährliche Support-Pakete im fünfstelligen Bereich angeboten werden. Über den Nutzen gab es unterschiedliche Meinungen. Die Frage zielt aus meiner Sicht auf die Aktivität und Offenheit der Community ab, die hinter dem Projekt steht: Eine aktive Community ist aus meiner Sicht das wichtigste Entscheidungskriterium für oder gegen eine Software.

Darf ich OpenSource Projekte verschlüsselt an den Kunden distribuieren?

Dies konnte ich nicht beantworten. Über Twitter bekam ich die Info, dass dies wohl grundsätzlich in Ordnung ist, sofern die Quellcodes gleichzeitig zur Verfügung gestellt werden. Für die Performance einer Anwendung kann es zielführend sein, Codes kompiliert - in ein binäres Format gewandelt, in dem die Quellcodes dann nicht mehr offen vorliegen - auf dem System auszuführen. Dies ist mit der GPL vertretbar, sofern die Quellcodes mit distribuiert werden.

Wie sichere ich meine Projekte kaufmännisch ab?

Hier helfen saubere Abnahme- und Übergabeprozesse. Wenn der Auftraggeber anschließend dennoch nicht zahlt, ist dies ein rechtliches Problem und keines von Open Source.

In welchen Communitys bewegst Du Dich?

Dies war eine Fangfrage von @alextee, bei der ich auch prompt in die Falle getappt bin. ;-) Da wir in der Vergangenheit schon häufiger Drupal auf dem Webmontag vorgestellt haben, habe ich versprochen, Drupal während des gesamten Vortrags nicht zu erwähnen. Natürlich bin ich in den Web- und besonders Drupal-Communitys zuhause.

Fotos mit freundlicher Genehmigung von Petra Vogt, Fotolotsin