Audacity, eine Übernahme und Telemetriefunktionen

Vor einigen Tagen ging die Meldung durch den Ticker, dass die Audiobearbeitungssoftware Audacity (Link zu audacityteam.org) durch Muse Group gekauft wurde. (LinuxNews und heise.de berichteten). Ich war über diese Meldung etwas überrascht, weil es etwas seltsam ist, ein OSS-Projekt zu „kaufen“. Die Software an sich ist GPLv2-lizenziert und ansonsten lässt sich lediglich eine US-Wortmarke finden. Ich konnte nicht einmal eine deutsche/europäische Marke hierzu ausfindig machen. Es geht bei dem Vorhaben der Muse Group sicherlich eher darum, den Einfluss auf die Entwicklung von Audacity auszubauen, um das eigene Produktportfolio zu erweitern.

Tantacrul hat diesbezüglich ein 15-minütiges Video zu seinen neuen Aufgaben erstellt, das auf YouTube verfügbar ist.

Es ist sehr zu begrüßen, dass ein Unternehmen die Mittel bereitstellt, eine Software wie Audacity weiterzuentwickeln. Ein Vorteil von kommerziell getriebener Entwicklung ist es, dass Leute dafür bezahlt werden, die unschöne, aber nötige Arbeit zu erledigen, um die Qualität beim Gesamtprodukt zu steigern. Auf der anderen Seite tauchen natürlich bei einer solchen „Übernahme“, die sich bei so einem Projekt immer noch ungewohnt anhört, Befürchtungen auf, dass Interessenkonflikte zu einer Strategieänderung bei der Entwicklung führen. Darüber hinaus ändert sich mitunter die Kultur der Entwicklung und die Gemeinschaft wird mit neuen Vorstellungen konfrontiert.

Dass es irgendwann Krach gibt, habe ich nicht ausgeschlossen. Dass es aber so schnell geht, hätte ich auch nicht gedacht. Am Dienstag, dem 04. Mai wurde ein Pull Request eröffnet, der den Namen „Basic telemetry for the Audacity“ trägt. Zum Zeitpunkt, an dem ich diesen Artikel hier schreibe, umfasst der Diskussionsthread schon über 850 Beiträge und wurde als „Draft“ zurückgestuft. Bei diesem offenbar kontrovers diskutierten Thema geht es darum, Audacity Telemetriefunktionen zu verpassen.

Ich könnte jetzt mit euch die konkreten Änderungen Stück für Stück auseinander nehmen, aber die dort verknüpften GitHub-Kommentare (besonders die Emojis) sprechen für sich. Alle, die einen C++-Hintergrund haben und CMake kennen, können sich die Implementierung zu Gemüte führen. Ich werde an geeigneter Stelle vereinzelt darauf eingehen.

Ein Glaubenskrieg

Telemetrie ist immer ein heikles Thema, besonders in der Open-Source-Welt. Hierbei geht es darum, die Nutzungsweise der Software an eine zentrale Stelle, dem Hersteller, zu melden, damit dieser Schlüsse daraus ziehen kann. Geht man noch einen Schritt weiter zurück, geht es darum, die Nutzung der Software messbar zu machen. Dies ist besonders im Management beliebt, da es Außenstehenden die Möglichkeit gibt, die Nutzung der Software zu analysieren und die Entwicklung zu regeln. Fragen wie „Entwickle ich an der richtigen Stelle?“, „Wollen die Nutzer das?“ oder „Haben wir genug Nutzer?“ sollen damit beantwortet werden.

In der vollen Ausbaustufe gleicht die Telemetrie einer Bildschirmaufnahme, bei der jeder Klick, jede Eingabe und jede Ausgabe an den Hersteller versendet werden. Das alles ist bei dem oben genannten Pull Request nicht der Fall, wie das Team nachdrücklich beteuert. Datenschutzrechtliche Aspekte lasse ich in dieser Betrachtung erst einmal außen vor, weil diese Diskussion das eigentliche Problem verschleiert.

Das Problem an diesem gesamten Umstand mit der Telemetrie ist, dass FOSS, also freie, offene Software, vom „mündigen Anwender“ ausgeht. Ich habe dieses Thema schon mal im Blog thematisiert. Dabei wird eine sehr aufgeklärte Weltanschauung vertreten: hat ein Anwender ein Problem, meldet er sich in einem Issue Tracker oder der Mailing Liste. Nur hat dieses Wunschdenken nichts mehr mit der Realität zu tun, vor allem, wenn die Zielgruppe nicht größtenteils aus Softwareentwicklern besteht, die diese Verfahrenswege kennen. Jetzt gibt es zwei Möglichkeiten: entweder auf das Feedback verzichten oder andere Wege finden, die Metriken zu erheben. Die Metriken sind zudem nur dann aussagekräftig, wenn sie eine repräsentative Nutzermenge abbilden - ergo: man müsste sie bei allen erzwingen.

Erschwerend kommt bei Audacity dazu, dass wir es hier mit einer Offline-Anwendung zu tun haben. Ist man es bei Webseiten gewohnt, dass die Inanspruchnahme von solchen zwangsläufig Verkehrsdaten erzeugt (seien es die Browserhistory, Logfiles auf dem Server, Analytics, o. ä.), so erwartet man bei lokaler Software nicht, dass diese „nach Hause telefoniert“. Zumindest früher.

Genau das soll bei Audacity jetzt allerdings passieren. Hierzu wurde extra die cURL-Bibliothek in den Source Tree eingefügt, was nebenbei noch eine komplett neue Abhängigkeit mit sich bringt. Diese Abhängigkeit wurde sogar sehr brachial hinzugefügt, wie aus dem diff hervorgeht, da während des Bauens sich Inhalte aus dem Git-Repository heruntergeladen werden sollen.

Die Telemetriedaten werden an ein zentrales Konto bei Google Analytics und Yandex geschickt.

FOSS-Prinzipein

Hier ergibt sich teilweise ein Bruch mit den üblichen FOSS-Prinzipien. Bei FOSS gibt man seinen Quelltext nicht frei, damit andere in diesem lediglich Lesen können, sondern, damit andere ihn in ihre Systeme integrieren können. Nutze ich z. B. den NetworkManager, der einen Connectivity Check durchführt, um zu erkennen, ob ich in das Internet komme, wird als Endpunkt meist ein von meinem Distributor bereitgestellter Server genutzt. Der Distributor ist es auch, dem ich mein ultimatives Vertrauen schenken muss, da dieser oft vorkompilierte Pakete bereitstellt. Ist ein Build nicht reproduzierbar, kann ich als Anwender nicht zweifelsfrei feststellen, ob lediglich die Inhalte ausgeführt werden, die auch angegeben sind. Unter diesem Aspekt ist der Umstand, dass der Distributor durch oben genannte Connectivity Checks meine IP-Adresse erfahren kann, fast zu vernachlässigen.

Freie Open Source Programme sind somit nur Bausteine, die von einem Intermediär aufbereitet und zur Verfügung gestellt werden. Somit sollte es aus meiner Sicht faktisch keinen Durchgriff von FOSS-Maintainern auf die Endnutzer geben, sofern nicht ein triftiger Grund dafür spricht.

Ein solcher triftiger Grund wären in meinen Augen Crashdumps: stürzt ein Programm ab, bieten einige Programme die Möglichkeit an, hilfreiche Daten zur Crash-Ursache (Tracebacks, Umgebungsvariablen, etc.) an die Hersteller zu melden. Oftmals wird dem Nutzer hier die Wahl gelassen, ob er diese Informationen mit den Entwicklern teilen möchte.

FOSS-Geschäftsmodelle

Freilich ist es schwierig, Geschäftsmodelle bei einer solch schwierigen Beziehung zwischen Softwarehersteller und -anwender zu etablieren. Dabei ist die „letzte Meile“ zwischen Distributor/OEM und Endkunden am attraktivsten, da dort Support verkauft werden kann. Beste Beispiele sind hier Red Hat und SUSE. Red Hat wurde für 34 Milliarden US-Dollar an IBM verkauft und der in Deutschland ansässigen SUSE GmbH steht am 19. Mai ein mit 5,7 Milliarden Euro bewerteter Börsengang bevor. Das bloße Schaffen und (entgeltliche) Zurverfügungstellen von Softwarequelltext und den Binaries wird heutzutage immer unattraktiver.

Fazit

Was Audacity angeht, bin ich optimistisch. Am Ende kann der Anwender nur gewinnen: entweder wird die Software verbessert oder es bildet sich ein Fork (wie schon geschehen), der die Nutzerschaft übernimmt.

Audacity ist eine Software, die ihren Zweck erfüllt. In meinen Augen kein Anwärter für Designauszeichnungen, aber plattformübergreifend und funktional.

Trotzdem muss man schauen, wie sich Audacity nun weiterentwickelt. Meine Prognose ist, dass die nächste Änderung, die ähnliche Kritik hervorruft, ein Auto-Updater wie bei MuseScore sein wird. ;-)