Musikbots sterben, und ich habe meinen freiwillig abgeschaltet

Im Sommer 2021 verschwanden die großen Musikbots von Discord. Millionen Server, die von einem Tag auf den anderen keine Musik mehr hatten. Die Ursache war keine technische, sondern eine rechtliche: Die Bots holten Audio von einer Plattform, deren Nutzungsbedingungen genau das nicht erlauben.

Ich hatte selbst einen kleinen Musikbefehl in Yurna. Nichts Großes — Warteschlange, Überspringen, Lautstärke, ein paar hundert Zeilen. Ich habe ihn in derselben Woche entfernt.

Warum ich nicht weitergemacht habe

Die naheliegende Reaktion wäre gewesen abzuwarten. Mein Bot lief auf ein paar Dutzend Servern, war völlig unauffällig, und niemand hätte sich für ihn interessiert. Die Wahrscheinlichkeit, dass daraus ein Problem entsteht, war gering.

Ich habe ihn trotzdem entfernt, aus drei Gründen — und der dritte ist der eigentliche.

Erstens: Die Regel gilt unabhängig von der Größe. Wenn eine Nutzungsbedingung sagt, dass man Inhalte nicht herunterladen und weiterverteilen darf, dann ist ein kleiner Verstoß immer noch ein Verstoß. „Mich sieht ja keiner" ist keine Rechtsgrundlage, sondern eine Wette.

Zweitens: Der Aufwand stand in keinem Verhältnis. Ein Musikbot ist technisch der aufwendigste Teil eines Discord-Bots. Audio-Streams, Kodierung, Sprachverbindungen, die abbrechen, Warteschlangen, die den Neustart überleben. Ich habe dafür über die Zeit mehr Stunden aufgewendet als für die drei nächstgrößeren Features zusammen — für eine Funktion, die es besser fertig gab.

Drittens: Ich hing an einem Dienst, den ich nicht kontrolliere. Das ist der Punkt, der geblieben ist. Der Bot funktionierte nur, solange eine fremde Plattform sich nicht ändert. Jede Änderung ihrerseits — technisch oder rechtlich — hätte meinen Code kaputtgemacht, ohne dass ich etwas falsch gemacht hätte.

Was Abhängigkeit von fremden Diensten wirklich bedeutet

Ich habe das damals zum ersten Mal systematisch für mein ganzes Projekt durchdacht. Wovon hängt der Bot ab, das mir nicht gehört?

Abhängigkeit	Was passiert, wenn sie wegfällt
Discord selbst	Alles ist weg. Nicht abzusichern, das ist die Plattform.
Musikquelle	Ein Feature ist weg — und zwar sofort und rechtlich erzwungen.
Bild-APIs für Meme-Befehle	Einzelne Befehle scheitern; abfangbar.
Übersetzungsdienst	Ein Befehl weniger; abfangbar.
Hoster	Ausfall, aber umziehbar.

Die Zeile mit der Musik war die einzige, bei der ich weder ausweichen noch abfedern konnte. Das ist eine andere Kategorie von Abhängigkeit, und ich habe seitdem einen Namen dafür: Ein Feature, das nur existieren kann, solange jemand anderes wegschaut.

Was ich stattdessen gemacht habe

Der Befehl wurde entfernt, mit einer Nachricht, die erklärt, warum. Das ist mir wichtig gewesen — nicht wortlos verschwinden lassen, sondern sagen, dass es eine Entscheidung war und keine Panne.

Und ich habe die Zeit, die vorher in Audio-Fehlersuche ging, in zwei Sachen gesteckt, die tatsächlich benutzt wurden: das Ticket-System und die Serverstatistiken. Beide sind bis heute Teil des Projekts. Der Musikbefehl fehlt niemandem mehr.

Infobox

Wer trotzdem Musik auf seinem Server will, sollte das über einen Dienst tun, der die Lizenzen tatsächlich hat. Das ist heute möglich und war es damals schon. Der eigene Bot, der Audio von irgendwoher zieht, ist der bequemste und der wackeligste Weg.

Die Liste, die ich mir danach gemacht habe

Nach dieser Entscheidung habe ich zum ersten Mal systematisch aufgeschrieben, wovon meine Projekte abhängen. Nicht die technischen Bibliotheken, sondern die Dienste anderer Leute.

Für jeden Eintrag drei Angaben: Was passiert, wenn er ausfällt? Was passiert, wenn er sich ändert? Was passiert, wenn er es verbietet?

Die dritte Frage ist die, an die vorher niemand denkt. Ein Ausfall ist ein technisches Problem, eine Änderung ein Wartungsaufwand — ein Verbot ist ein Ende ohne Übergangsfrist.

Bei der Durchsicht kam heraus, dass fast alle meine Abhängigkeiten in die ersten beiden Kategorien fielen. Es gab genau eine, die in die dritte gehörte, und das war die Musikfunktion.

Was ich daraus für Kaufentscheidungen mitgenommen habe

Dieselbe Frage stelle ich seitdem bei allem, was ich einsetze, auch bei Bezahltem.

Ein gekauftes Plugin, dessen Lizenzprüfung gegen einen Server läuft, den ich nicht kontrolliere, ist eine Abhängigkeit dritter Art: Wenn dieser Server abgeschaltet wird, startet meine Software nicht mehr. Das ist kein hypothetisches Risiko — bei einem meiner gekauften Pakete ist genau dieser Fall eingetreten, und die Lösung hat einen eigenen Eintrag verdient.

Die praktische Konsequenz ist nicht, solche Dinge zu meiden. Es ist, sie zu kennen und für jede eine Antwort zu haben:

Gibt es einen Weg ohne diese Abhängigkeit, notfalls mit weniger Funktion?
Wie schnell könnte ich umstellen?
Was verliere ich dabei?

Wenn ich diese drei Fragen nicht beantworten kann, ist die Abhängigkeit größer, als sie aussieht.

Der allgemeinere Gedanke

Es gibt in jedem Projekt Features, die man aus Trotz behält. Weil man Arbeit hineingesteckt hat, weil sich jemand beschweren könnte, weil es „doch funktioniert".

Der Musikbefehl war bei mir das erste Mal, dass ich etwas entfernt habe, das lief. Und ich habe dabei gemerkt, dass Entfernen ein eigenes Handwerk ist, das man üben muss:

Ankündigen, bevor es weg ist. Zwei Wochen reichen, aber es müssen zwei Wochen sein.
Sagen, warum. Menschen akzeptieren fast jede Entscheidung, wenn sie den Grund kennen.
Nicht diskutieren, sondern erklären. Ich habe damals versucht, in einer Diskussion recht zu behalten. Das hat nichts gebracht. Was geholfen hat, war eine kurze, klare Begründung ohne Rechtfertigungsschleife.
Die Daten behalten, bis klar ist, dass sie niemand braucht. Ich habe die Warteschlangen-Tabellen noch ein halbes Jahr stehen lassen, bevor ich sie entfernt habe.

Diese vier Punkte habe ich seitdem oft gebraucht, in Projekten, die mit Discord nichts zu tun haben. Software wächst automatisch. Sie schrumpft nur, wenn jemand die Entscheidung trifft — und die Entscheidung ist fast immer unbequemer als das Weiterschleppen.