Die Domain yurna.info und was ein Name ausmacht

Zwei Jahre lang hieß mein Bot nichts Richtiges. Er hatte einen Arbeitstitel, der aus einem Wortspiel entstanden war, das nur ich lustig fand, und der auf jeder Einladungsseite ein bisschen peinlich aussah.

Im März 2022 habe ich eine Domain registriert und dem Projekt einen Namen gegeben: Yurna. Kein Akronym, keine Bedeutung, keine Geschichte. Ein Name, der kurz ist, sich aussprechen lässt und dessen Domain frei war.

Warum ein Name mehr ist als Kosmetik

Ich hätte vorher gesagt, dass ein Name egal ist. Was zählt, ist, was das Ding kann. Das stimmt für die Technik und für fast nichts anderes.

Ein Name macht ein Projekt benennbar. Vorher habe ich gesagt: „mein Bot", „das Dashboard", „das Ding". Jedes Gespräch fing mit einer Erklärung an. Danach hatte alles einen Namen, und man konnte über Teile reden, ohne den Zusammenhang neu aufzumachen.

Ein Name schafft eine Grenze. Mit dem Namen wurde klar, was dazugehört und was nicht. Der Bot, das Dashboard, die Verwaltungsschnittstelle — das ist Yurna. Mein Portfolio, meine Minecraft-Server, andere Projekte sind es nicht. Vorher war das ein einziger Brei aus „Sachen, die ich mache".

Ein Name erzeugt Erwartungen. Und zwar auch an mich. Ein Projekt mit Domain und Logo wirkt wie etwas, das gepflegt wird. Das ist Motivation und Druck zugleich.

Was daran Arbeit war

Die Domain zu kaufen dauerte fünf Minuten. Alles danach hat Wochen gedauert.

Umbenennen im Code. Der alte Name steckte in Paketnamen, Ordnern, Datenbanknamen, Umgebungsvariablen, Logausgaben, Fehlermeldungen und der Bot-Beschreibung. Suchen und Ersetzen erwischt das meiste und genau das Falsche mit: Ein Name, der zufällig auch ein normales Wort ist, taucht an Stellen auf, an denen er nichts mit dem Projekt zu tun hat.

Alte Verweise. Einladungslinks, Verweise in Discord-Servern, Lesezeichen. Das lässt sich nur durch Weiterleitungen abfedern, die man dann jahrelang stehen lässt.

Die Kleinteile der Außenwirkung. Ein Logo, ein Symbol, ein Farbschema, eine Startseite, eine Datenschutzerklärung, ein Impressum. Nichts davon ist schwierig, alles davon dauert länger als gedacht.

Infobox

Wenn ich das noch einmal machen müsste, würde ich den Namen früher festlegen und die Domain kaufen, sobald ein Projekt über ein Wochenende hinausgeht. Nicht wegen der Marke — sondern weil jede Woche mehr Stellen entstehen, an denen der Name auftaucht. Der Umbenennungsaufwand wächst linear mit der Projektgröße, die Kosten für eine Domain nicht.

Die Sache mit dem Impressum

Was mir vorher nicht klar war: Sobald eine Webseite unter einer eigenen Domain öffentlich erreichbar ist und nicht rein privat, gelten in Deutschland Pflichten. Impressum, Datenschutzerklärung, Angaben darüber, welche Daten wie verarbeitet werden.

Bei einem Bot, der Discord-IDs, Servereinstellungen und Punktestände speichert, ist das keine Formalie. Man muss beantworten können:

Welche Daten werden gespeichert?
Wofür?
Wie lange?
Wie wird man sie wieder los?

Der letzte Punkt war der, an dem ich tatsächlich etwas ändern musste. Es gab keinen Weg, seine Daten löschen zu lassen, außer mir zu schreiben. Ich habe daraufhin einen Befehl gebaut, der die eigenen Daten ausgibt, und einen, der sie löscht.

Das war lästig, es hat mir aber etwas gezeigt: Ich wusste selbst nicht genau, was mein System alles speichert. Die Liste zusammenzustellen war die eigentliche Erkenntnis, nicht das rechtliche Dokument.

Die technischen Nachwirkungen einer Umbenennung

Ein Name steckt an mehr Stellen als gedacht, und einige davon merkt man erst Monate später.

In Datenbanknamen und Tabellenpräfixen. Umbenennen bedeutet Migration, also habe ich es gelassen. Bis heute tragen einzelne interne Bezeichnungen den alten Namen.

In Umgebungsvariablen. Wer sie umbenennt, muss jede Umgebung nachziehen — und wenn eine vergessen wird, fehlt zur Laufzeit ein Wert.

In Protokollausgaben und Fehlermeldungen. Kosmetisch, aber verwirrend für jeden, der das Projekt kennt.

In Dateipfaden auf dem Server. Ein Verzeichnis umzubenennen bedeutet, jeden Dienst, jeden Zeitplan und jede Sicherungskonfiguration anzupassen.

In Verweisen von außen. Der Teil, den man am wenigsten kontrolliert und der am längsten nachwirkt.

Meine Konsequenz war ein Kompromiss, den ich bis heute für richtig halte: Nach außen konsequent umbenennen, nach innen nur dort, wo es billig ist. Ein interner Tabellenname, den drei Menschen sehen, ist keine Marke.

Was ein Name mit Verantwortung macht

Der Teil, über den ich am wenigsten nachgedacht hatte: Ein Projekt mit Namen und Domain wirkt nach außen wie ein Produkt — und Produkte haben Erwartungen.

Anfragen wurden formeller. Fehlerberichte kamen mit Reproduktionsschritten. Und zum ersten Mal fragte jemand, ob es eine Statusseite gibt.

Ich habe damals nichts davon gehabt. Aber die Fragen haben mich zu einer Haltung gebracht, die geblieben ist: Wenn etwas nach einem Produkt aussieht, sollte es sich auch so verhalten — mit einer Möglichkeit, Fehler zu melden, mit einer Antwort darauf, und mit Ehrlichkeit darüber, was gerade nicht geht.

Der einfachste Schritt in diese Richtung war eine Seite, auf der steht, was das Projekt ist, wer dahintersteht und wie man Kontakt aufnimmt. Drei Absätze, und sie haben mehr Vertrauen erzeugt als jede Funktion.

Was der Name mit dem Projekt gemacht hat

Rückblickend war der Namenstag ein Wendepunkt, aber nicht wegen des Marketings. Er hat eine Frage aufgeworfen, die ich vorher umgangen hatte: Was ist das hier eigentlich, und für wen?

Solange es „mein Bot" war, war die Antwort: für mich und meine Freunde. Mit einer Domain und einer Startseite kommen Leute, die ich nicht kenne. Dann sind Fragen wie Verfügbarkeit, Dokumentation, Support und Datenschutz keine Kür mehr.

Ich habe in den Monaten danach mehr Zeit in Dinge gesteckt, die man nicht sieht — Zuverlässigkeit, Fehlerbehandlung, Dokumentation — als in neue Features. Das war die richtige Reihenfolge, und ich glaube, ohne den Namen hätte ich sie nicht gewählt.