Open Source - Fluch oder Segen?
Open Source Software (OSS) ist eine gute Sache. Man kann den Source Code einsehen und, falls nötig, diesen selbst erweitern. Getrieben wird die Arbeit oft von der Entwickler-Community, dadurch werden Bugs schneller gefixt und Fragen über Foren und Mailinglisten kurzfristig und unkompliziert beantwortet. Ist das zu wenig, bieten viele Unternehmen auch kommerziellen Support an.
Soweit die positiven Seiten von OSS. Die meisten negativen Seiten sind, so glaube ich, bekannt;
- uneinheitlicher, oft schlecht dokumentierter Code
- komplizierte Abhängigkeiten zu anderen Projekten
- mangelnder cross-plattform-support
- keine Installer, komplexer Buildvorgang
Eine etwas subtilere Problematik hat sich im Rahmen eines Kundenprojektes gezeigt. Unsere Erfahrungen möchte ich hier anekdotisch festhalten.
Technologisch gesehen ging es um die Implementierung von Audio- und Video-Streaming auf der Basis der Bibliotheken von https://www.ffmpeg.org/. Zur Einordnung falls nicht bekannt, ffmpeg wird als das "Schweizer Taschenmesser" der Videobearbeitung bezeichnet und ist ein Open Source Projekt. Es besteht zum Einen aus ein Paar Kommandozeilentools zum bearbeiten, konvertieren, streamen, analysieren und wiedergeben von Mediendaten, zum Anderen gibt es eine Handvoll Bibliotheken, die von Entwicklern in eigene Software integriert werden können, um die o.g. Funktionen flexibel einbauen zu können. Ein weiterer, wichtiger Aspekt ist, dass ffmpeg für fast alle Plattformen und Betriebssysteme verfügbar ist.
Wir sollten mit Windows anfangen, also war der Plan, eine DLL zu erstellen, die die ffmpeg Funktionen kapselt, so dass Konsumenten einfache Methoden wie startStreaming, stopStreaming usw. aufrufen können.
Als erstes wollten wir die richtige Version von ffmpeg auswählen. Dazu besuchten wir die ffmpeg Website und stellten fest, dass es dort nur entweder den Source Code oder die Kommandozeilentools gibt. Nicht aber die vorkompilierten Bibliotheken für Entwickler. Glücklicherweise fanden wir die Seite von http://ffmpeg.zeranoe.com/builds/, der aktuelle Builds anbietet.
Allerdings stellten wir als nächstes fest, dass unsere erste, einfache Implementierung sich nicht mit dem aktuellen Zeranoe Build bauen lässt. Offensichtlich hat sich die API an wesentlichen Stellen geändert. Interessant dabei ist, dass selbst die Beispiele aus der aktuellen Codebasis nicht mit der aktuellen Bibliothek kompilierbar sind.
Also gingen wir wieder auf die Suche (sprich Google, Stackoverflow, etc.) und fanden zuerst eine gut versteckte und schlecht dokumentierte Deprecation-Liste von ffmpeg, in der die alten Methoden stehen, die nicht mehr verfügbar sind und ein Paar kryptische Hinweise auf die neuen Methoden. Weiter fanden wir einen Blog-Eintrag eines ffmpeg Entwicklers, der beschreibt, wie man die wichtigsten Methoden nutzen kann. Nun konnten wir weiter arbeiten.
Die Freude währte aber nicht lange. Als wir anfingen, ernsthaft Features umzusetzen, insbesondere was den Support bestimmer Codecs anbelangt, bekamen wir erneut Probleme. Grund dafür war, dass der Zeranoe-Build nicht alle Codecs beinhaltete, die wir benötigten. Also mussten wir unsere eigene ffmpeg Version für Windows bauen. Um diese Geschichte abzukürzen, mehrere Tage später hatten wir nun unsere eigene Version gebaut und unsere Implementierung lief.
Naja, halbwegs zumindest. Wir waren weit davon entfernt, Video und Audio in ordentlicher Qualität in so etwas wie echtzeit übertragen zu können. Audio und Video hingen extrem hinterher und waren komplett unsynchronisiert, sprich es gab mehrere Sekunden Versatz zwischen Audio und Video.
Ich möchte hier nicht auf die Enzelheiten der Implementierung einer eigenen Videostreaming-Lösung eingehen, das würde den Rahmen sprengen. Nur so viel sei gesagt, es ist alles andere als banal, auch wenn man, wie bei uns der Fall, über Vorkenntnisse in relevante Bereiche (Videostreaming, GStreamer, mpeg2 Decoding mit JS) verfügt. Vor diesem Hintergrund verwundert es ein wenig, dass es genau zu dem Thema keine funktionierenden Beispiele oder Anleitungen gibt, weder von ffmpeg noch sonst von der Community.
Nach vielen Versuchen und durch extensives Studieren des Source Codes kamen wir der Sache zwar näher, hatten aber bei ein Paar Themen noch immer keine befriedigende Lösung. Also dachten wir, es sei an der Zeit kommerziellen Support für diese spezifischen Themen in Anspruch zu nehmen. Auf der Website von ffmpeg gibt es die passende Seite mit einer Handvoll namentlich genannter Entwickler, die je nach Schwerpunkt kommerziellen Support anbieten.
Wir schrieben einige an und schilderten unsere Problemstellung. Ungefähr die Hälfte meldete sich nicht zurück. Einer meldete sich sofort zurück und gab an, dass es nicht sein Spezialgebiet wäre und wir sollten doch Entwickler A und B ansprechen. Das hatten wir schon. Entwickler A versuchte zuerst, uns auf all die schlechten, veralteten Beispiele zu verweisen, die wir mittlerweile auswendig im Schlaf rückwärts rezitieren konnten. Nach langem hin-und-her bekamen wir folgendes Angebot, frei übersetzt klang das in etwa so: "mein Kumpel hat nach der Arbeit an 2 Tagen in der Woche jeweils 3 Stunden Zeit und kann das für EUR 200 die Stunde in einem Zeitraum von 3 Monaten erledigen". Damit war das für uns schon mal gestorben. Mit Entwickler B kamen wir etwas weiter, auch wenn dieser manchmal fast zwei Wochen brauchte, um zu antworten. Als wir dann sagten, dass wir keinen Rewrite der Software, sondern nur eine Beratung zu punktuellen Themen benötigen, hieß es hier sinngemäß: "das ist dann für mich nicht mehr (finanziell) interessant. Viel Erfolg.".
Es gab noch einen Entwickler C, der auch nach sehr langer Zeit reagierte, als es aber soweit war hatten wir die Probleme bereits selbst gelöst.
Das mag vielleicht ein extremes Beispiel gewesen sein. Open Source Projekte, hinter denen ein kommerzielles Unternehmen steht sind meist anders aufgestellt. Allerdings ist die Software-Branche nach wie vor auch auf den Einsatz von Open Source Software angewiesen, die "nur" von der Community betreut wird. Ich glaube es macht Sinn, sich bei der Auswahl der Tools und Bibliotheken dieser Aspekte zumindest bewusst zu sein.
