Hendriks Blog

Settembrini, der selbsternannte Titan der Wahrheit des deutschen Rollenspiels will kein Rollenspieler mehr sein. Kaum zu glauben, wo er doch regelmäßig meint, wirklich zu allem, was mit dem Hobby zu tun hat, seine Meinung abgeben zu müssen – egal, wie wenig Ahnung er davon hat.

Sei’s drum, bedeuten kann das allerlei, ein Verlust für die deutsche RPG-Szene wäre Settembrinis Abgang aber sicherlich nicht. Eine arme kleine Spaßtrompete weniger, die meint, sich mit einer provokanten Kunstpersona produzieren zu müssen. Zumal ich bezweifle, dass er das lange durchhält – ist ja schließlich nicht sein erster beleidigter Abgang.

Gestern flatterte bei mir doch tatsächlich diese interessante Ankündigung vorbei. Erst mal dachte ich mir “Gut, wir leben in einer Demokratie, da ist es das gute Recht eines jeden, für seine Meinung zu demonstrieren”. Dann allerdings machte man mich auf die Details der ganzen Aktion aufmerksam: Im Rahmen der Veranstaltung soll ein Container aufgestellt werden, in dem man gewalthaltige Computerspiele zur späteren Vernichtung sammeln möchte. Hmm, woran erinnert mich das? Ach ja, genau:

Das Echo auf diese Aktion scheint bisher relativ einseitig zu bleiben: Computerspieler und diverse Jugendorganisationen laufen Sturm und protestieren, ansonsten bleibt es eher still. Dies zeigt ziemlich deutlich, dass die Öffentlichkeit noch gar nicht registriert hat, was da eigentlich gefordert wird. Wahrscheinlich muss man sich tatsächlich in brauner Uniform mit einem eigenen Container daneben stellen und die Leute dazu auffordern, Bücher in den Container zu werfen – mit weniger Aufwand scheinen die Zusammenhänge für den Otto-Normal-Bürger wie auch für seine politischen Vertreter nicht offensichtlich zu sein.

Für mich ist das absolut unverständlich. Wegen jedem Korinthenkack kommt sofort auch der letzte C-Promi-Möchtegernpoltiker aus seinem Loch gekrochen und ermahnt mich, doch ja unsere deutsche Vergangenheit und die Missetaten unserer Vorväter nicht zu vergessen, aber wenn jemand beginnt, genau diese Untaten zu wiederholen, dann schweigt man still. Was bleibt uns da noch zu sagen? Wohl nur: Armes Deutschland…

So, das Tanelorn Sommertreffen 2009 liegt hinter mir und nicht ganz ohne Stolz kann ich behaupten, mich des Wiederauflebenlassens der Workshopkultur und damit der Begründung einer neuen Tradition auf den bewährten Treffen des einzig waren Fantasy-Forums rühmen zu können (wobei es dem unkundigen Leser mitgeteilt sein, dass wir Tanelornis gern und oft neue Traditionen übernehmen – meist bereits nach erstmaligen Erfolg ): Dem Workshop.

Da mein Workshop, dank plötzlich auftretender sommerlicher Hitze nach draußen verlegt, trotz eines Vormittagstermins (den passionierte Rollenspieler ja eigentlich immer mal wieder gerne verschlafen) sehr gut besucht wurde (zur Hochzeit konnte ich immerhin 18 Teilnehmer zählen) und ich durchweg positive Resonanz für den Inhalt bekommen habe, möchte ich an dieser Stelle auch etwas zurück geben. Ihr werdet in den kommenden Wochen hier, in Form verschiedener Essays, eine Ausarbeitung aller angesprochenen Themen finden.

Auch ich habe vom Workshop noch einiges an Input mitnehmen können, und werde dies in die Ausarbeitungen einfließen lassen. Ich hoffe dem geneigten Leser dadurch noch einige positive Impulse geben zu können und würde mich über Kritik, Zustimmung und sonstige konstruktive Kommentare, entweder direkt hier an dieser Stelle oder auch gern im Tanelorn, freuen. Nun aber genug der Blubberei, steigen wir also ein die wunderbare Welt des pragmatischen Spielleitens.

Pragmatisches Spielleiten – Begriffsklärung und Definition

Im Rahmen der an dieser Stelle startenden Essay-Reihe möchte ich euch den von mir mittlerweile im Pen&Paper Rollenspiel vor allen anderen präferierten Spielstil ein wenig näher bringen. Es handelt sich dabei um ein modulares Konzept von einer überschaubaren Anzahl verschiedener Techniken, die ich je nach Anspruch und vor allem Anforderung kombiniere, um ein für mich (und in aller Regel doch hoffentlich auch für meine Mitspieler) optimales Spielerlebnis zu ermöglichen.

Den Anfang macht heute eine grobe Übersicht über‘s Thema und eine Definition der von mir verwendeten Begriffe und grundlegenden Prinzipien. Dem fachkundigen Leser mögen, gerade zu Beginn, einige Parallelen zum Lean Management und zur agilen Softwareentwicklung auffallen. Dies kommt nicht von ungefähr, da ich mich bereits seit längerer Zeit mit diesen Themen beruflich beschäftige und dies, durchaus positiv, auch auf meinen Spielstil im Rollenspiel abgefärbt hat.

Pragmatisches Spielleiten ist ein Begriff, den ich zur Bezeichnung meines eigenen Spielstils im Pen&Paper Rollenspiels gewählt habe. Dieser Spielstil ist sicherlich eher der erzählerischen Schiene des Hobbys zuzuordnen und rückt den kollaborativen Prozess des Geschichten Erschaffens in den Mittelpunkt des Rollenspiels. Kurz formuliert kann man dies wohl am ehesten folgendermaßen zusammen fassen: Wir als Gruppe wollen gemeinsam eine interessante Geschichte erzählen. Wie bekommen wir das mit möglichst wenig Arbeit hin?

Um das genannte Ziel zu erreichen, erlaube ich mir, einige wenige Kernprinzipien zu definieren, auf denen das Spiel der Gruppe fußen sollte.  Dies sind weder besonders viele noch besonders schwierig umzusetzende Punkte. Wenn ihr also irgendetwas von dieser ganzen Methodik im Hinterkopf behalten solltet, lasst es bitte dies sein .

1. Beachte Regel 0. Immer. Regel 0 besagt, dies kann man in der deutschsprachigen Forenlandschaft eigentlich ohne große Mühe in Erfahrung bringen, „Spiele nicht mit Idioten“. Wenn Du mit bestimmten Leuten im Rollenspiel nicht klar kommst, dann spiel nicht mit Ihnen. Und solltest Du selbst einmal der Idiot sein (was bei uns allen ja immer wieder mal vorkommt), dann arbeite erst ein wenig an Dir, bevor Du mit anderen spielst.
2. Pragmatismus ist die Maxime. Es soll genau so viel Arbeit ins Spiel investiert werden, dass alle Leute genau das erhalten, was sie sich vom Spiel erhoffen. In aller Regel, das zeigt die Erfahrung, bekommt man sogar deutlich mehr. Allerdings nur dadurch, dass man sich untereinander beflügelt und anspornt, nicht dadurch, dass man Tonnen an Material vor- oder auch nachbereitet, dass für das Spiel wenig bis keine Relevanz hat.
3. Kollaboration ist die Grundvorraussetzung. In der Regel bereitet es niemandem größere Schwierigkeiten zu erkennen, dass er nicht alleine am Spieltisch sitzt (Merke: Es gilt immer noch Regel 0!). Die zentrale Erkenntnis des pragmatischen Spielleitens ist aber, dass diese Techniken auf die Zusammenarbeit aller Mitspieler angewiesen sind. Der SL ist nahezu keinem Bereich der „Alleinentscheider“ und schon gar kein „Alleinunterhalter“ (ebenso wenig wie irgendjemand sonst). Stattdessen tragen alle, die am Tisch sitzen, gleichsam den kreativen Prozess auf ihren Schultern. Jedem Mitspieler steht es zu, einmal zu glänzen. Jeder hat aber genau so das Recht und vor allem auch die Pflicht, mal in den Hintergrund treten zu dürfen respektive zu müssen. Und alle sind dafür verantwortlich, aufeinander zu reagieren und sich gegenseitig die Bälle zuzuwerfen.
4. Ergebnisoffenheit ist die Methode. Die Geschichte entsteht im Spiel. Nicht davor. Nicht danach. Für die Gruppe heißt das, sich vorher schon über ein Ziel einig zu sein, und für den SL heißt das, eben nicht auf dieses Ziel hin zu arbeiten, sondern sich alle Alternativen offen zu halten. Was im Spiel behandelt werden soll, entscheiden alle zusammen im Vorfeld. Oder durch die Signale, die sie ihren Mitspielern im Spiel geben.
5. Mut ist die eine notwendige Voraussetzung. Probiere immer wieder neue Dinge aus. Techniken können nur funktionieren, wenn man sie ausprobiert. Sage häufiger mal „Heute möchte ich mal dies und das ausprobieren“. Trau Dich, denn selbst wenn es schief geht, werden Deine Mitspieler Dich auffangen. Ebenso ist es Deine Pflicht, laut und deutlich klar zu machen, dass Dich etwas stört, wenn genau dies der Fall ist. Deine Meinung und Deine Aussagen sind nämlich das Einzige, mit dem Deine Mitspieler arbeiten können.
6. Ehrlichkeit ist die andere notwendige Voraussetzung. Niemandem am Spieltisch ist damit gedient, wenn man nicht ehrlich miteinander umgeht. Das heißt zuallererst: Schummle nicht. Auch nicht als Spielleiter. Denn es gibt keinen Grund dafür (Ja! Doch! Wirklich! ). Verarsche Deine Mitspieler auch sonst nicht. Die klassische Methode (der auch ich viel zu lange gefolgt bin), dem SL alles aus der Nase ziehen zu müssen, ist nichts anderes als eine Verarsche. Der tolle Plot, der nur im Hirn des SL existiert und von dem die Spieler nichts mit bekommen ebenso. Also lass diesen Quatsch.

Eigentlich war es dann erst einmal für dieses mal. In Kürze geht es dann weiter mit der „Spielvorbereitung“.

Wie man heute morgen auf heise.de lesen konnte, drängt die KJM die Provider dazu, freiwillig alles zu sperren, was im Verdacht steht, jugendgefährdend zu sein. Und ähnlich wie bei unserer allseits beliebten Familienministerin geschieht dies natürlich mit ausgeprägter Polemik, aber ohne Sach- oder gar gesunden Menschenverstand.

Anstandsdamen für Chats? Ständig zu überprüfende Altersfreigaben für Onlinespiele? Wenn ihr nicht freiwillig alles sperrt, was irgendwie jugendgefährdend sein könnte, liebe ISPs, dann zwingen wir euch einfach dazu?

In der Tat, dass alles klingt nach erwachsenen, technisch versierten und überaus praktikablen Lösungen für ausgesprochen schwerwiegende Probleme.

In Zuge dieser ganzen Panikmache ist auch ein bisschen Prozentrechnung sicherlich nicht verkehrt, um uns wieder zurück auf den Boden der Tatsachen zu holen. In den beiden vergangenen Jahren gingen bei der KJM insgesamt 314 Beschwerden ein. Ausgehend davon, dass sich da jedesmal wirklich jemand anders beschwert hat, sind das doch glatt nach Adam Riese (und Wolfram Alpha) 0.000073888 % der Internetnutzer in Deutschland. Das ganze Ausmaß der Katastrophe sollte demnach jeder sofort erkennen können. Ich gebe zu, man kann natürlich, und das wäre jetzt völlig valide, anmerken, dass 314 Beschwerden im Vergleich zu den knapp 240 Millionen Seiten des Netzes (laut Netcraft) natürlich ebenfalls nur ein Fliegenpups sind. Aber, und das ist meiner Meinung der wesentliche Punkt – die KJM vertritt nicht die Meinung dieser Webseiten, sondern die Meinung unserer Politik – die sich wiederum nach der Meinung des Volkes richten sollte. Warum also der ganze Wirbel wegen 314 Menschen, die sich Sorgen um ihre Kinder machen, aber offensichtlich nicht fähig sind, diese aus eigener Kraft heraus vor den Dämonen des Internets zu schützen? Wie gute Eltern, die Verantwortung für das Wohl und die Erziehung ihrer Kinder übernehmen, das eigentlich tun sollten?

Was mir, pessimistisch wie ich nun einmal veranlagt bin, dies alles wieder überdeutlich zeigt – es lohnt sich nicht mehr wirklich, sich noch Hoffnungen zu machen, dass aus Deutschland einst ein moderner Staat der globalen Informationsgesellschaft werden wird. Geben wir es doch einfach zu, wir sind ein hoffnungslos überaltertes Land, und eine Lobby haben bei uns nur die Leute 40+ – wahrscheinlich ist das sogar das noch zu niedrig gegriffen.

Und entgegen den Äußerungen von Zensursula haben bei uns auch Kinder keine echte Lobby. Natürlich versucht man sie so gut wie möglich vor allen Gefahren zu schützen. Aber auf welche Art und Weise? Warum fördert, nein fordert man nicht die Verantwortung der Erziehungsberechtigten, der Betreuer, der Lehrer ein? Warum bekämpft man nur die oberflächlichsten Symptome, anstatt das Übel an der Wurzel zu packen? Ganz einfach, liebe Freunde: Weil man es nicht will. Kinder wählen nämlich nicht. Und wir haben nun einmal sehr viel mehr verbohrte, technikferne Senioren in diesem Land, die den Parteien bereitwillig ihre Stimmen schenken als junge, verantwortungsbewusste Eltern, die nachdenken, bevor sie ihr Kreuz machen.

In diesem Sinne möchte ich mit den folgenden Worten schließen: Kulturell stampfen wir geradezu wieder ab in ein neues Mittelalter, in dem freies Denken und verantwortungsbewusstes Handeln dem Untertan Bürger abgesprochen wird. Das gute daran – irgendwann kommt es bestimmt auch wieder zu einer Renaissance. Nur werden wir da nicht mehr sehr viel von zu sehen bekommen.

Im Laufe der letzten Woche habe ich mein Blog zu Grabe tragen dürfen. Was auch immer ich beim braven Einspielen des 2.8.2 Updates falsch gemacht habe, es hat mich sowohl das funktionierende Blog als auch die Datenbank gekostet. Ärgerlicherweise ließen sich die alten Datenbankbackups auch nicht in die aktuelle WordPress-Installation, die ich natürlich sofort aufgesetzt habe, integrieren.

Folglich dürfte ich die wichtigen Sachen alle von Hand in die neue Installation herüber retten. Immerhin hat das halbwegs vernünftig funktioniert und ich konnte die Gelegenheit gleich dazu nutzen, mal den ganzen alten  Müll raus zu werfen.   In diesem Sinne – herzlich willkommen in Hendriks neuem alten Blog…

… Nachruf auf GG Artikel 5.

Ohne viele Worte. Für spezielle Anwendungen ist Mono SIMD (wohlgemerkt Mono, nicht Microsoft .NET ) schneller als C++: http://www.betanews.com/article/Mono_22_may_overtake_NET_in_some_critical_categories/1232551276

So eine Beschleunigung um Faktor 8-10 gegenüber normalen .NET-Anwendungen für den numerischen Bereich macht ein Interfacing zu C++/C natürlich auch reichlich überflüssig. Schade, dabei mag ich Template Meta Programming so sehr – das ist so schön geekig-esoterisch…

Eigentlich hatte ich ja gedacht, mein letzter Eintrag hätte alle deutlichen Schwachpunkte von C# angesprochen. Aber wie sich nach einer Diskussion gezeigt hat, habe ich doch glatt zwei wichtige Dinge übersehen:

• C# unterstützt keine checked exceptions. Die mögen vielen Leuten, gerade denen, die von der C++ Seite zu C#/Java kommen, vielleicht eh unnötig restriktiv erscheinen. Die Compilezeit-Sicherheiten, die man durch diesen Mechanismus gewinnt, sind jedoch enorm und können eine ganze Menge Fehler im frühzeitig verhindern. C# unterstützt so etwas leider nicht von Haus aus, sondern geht in Punkto Exception-Handling eher wieder in Richtung C++. Was einerseits sehr schade, aber andererseits jetzt wohl auch nicht mehr zu ändern ist.
• C# unterstützt keine Konstanten in Interfaces. Ich weiß ehrlich gesagt nicht, woran das liegt und was das soll – die IL unterstützt das offenbar sehr wohl. Selbiges gilt für Enumerationen. An vielen Stellen wäre so etwas doch extrem nützlich, gerade wenn es darum geht, Komponenteninterfaces nach außen zu tragen. So muss das alles dann in zusätzliche Hilfsklassen aufsplitten, globale Enums anlegen oder statt Interfaces abstrakte Klassen benutzen – was in vielen Fällen dank verbotenener Mehrfachvererbung nicht geht.

An dieser Stelle noch einmal herzlichen Dank an Jochen dafür, dass er mich auf diese Punkte aufmerksam gemacht hat.

Der große Hype ist vorbei. Ich kann auf 2 Jahre professionelle Softwareentwicklung mit .NET unter C# zurück blicken und ein Resüme ziehen. Entgegen dem, was vielerorts behauptet wird, und was ich zu Beginn und für lange Zeit auch gerne geglaubt habe, ist C# eben kein besseres Java. Im Gegenteil, es löst viele Dinge nur vermeintlich elegant, und offenbart nicht selten einige eklatante Designschnitzer, die im normalen Tagesbetrieb nicht auffallen:

• Properties: Properties sind ein nettes Sprachschmankerl. Wirklich Zeit sparen sie aber nicht, denn das Implementieren dauert genau so lange wie bei normalen getter/setter Methoden. Zudem erkennt man im Produktionscode keine Fehler mehr, die das Data-Hiding-Prinzip verletzen, weil sich der Zugriff auf Datenattribute und der Zugriff über Properties optisch nicht voneinander unterscheiden. Das an sich wäre kein Problem, wenn man Datenmember nur als protected oder private deklarieren könnte – so allerdings ist das Ganze recht missverständlich.
• Structs: Eigentlich ist die Verwendung von benutzerdefinierten Werttypen eine schöne Sache, aber auch hier wurde meiner Meinung nach das Konzept nicht bis zum Ende durchgedacht. Ich lege Structs in C# mit new an – wie einen Referenztypen! Habe dann aber einen Werttyp. Wie soll ich das Leuten mit wenig Programmiererfahrung klar machen? Wie vermeide ich Fehler, sobald noch weitere Sprachen mit ins Spiel kommen (lege ich structs in C++/CLI mit gcnew an, habe ich nämlich plötzlich Referenztypen, die anstandslos kompiliert werden. Der ganze Mist funktioniert dann aber nicht mehr – und das bedeutet dann wieder stundenlanges Debuggen, wenn jemand mal kurz nicht aufgepasst hat!).
• Attribute: Sind zugegebenermassen toll. Aber die habe ich Form von Annotations in Java seit Version 1.5 auch.
• Lambda-Funktionen: Warum unterminiere ich eine objektorientierte Sprache durch funktionale Elemente, die dort eigentlich nicht das geringste verloren haben? Die Syntax ist Anfängern nicht begreiflich zu machen und verwendet einen Operator, der an anderer Stelle eine völlig andere Bedeutung hat. Zudem brauche ich die Dinger hier garnicht – wenn ich funktional entwickeln will, dann nehme ich F# oder IronPython – damit geht das dann nämlich auch komfortabel. Dazu kommt noch, dass ich denselben Effekt sowieso schon mit anonymen Delegaten erreichen kann. Und – wozu kann ich denn die Sprachen im CLI nach belieben mischen, wenn ich doch wieder alle Konzepte in eine Sprache packe? Was kommt als nächstes – prozedurale Erweiterungen für C#?
• Der neueste Gag: Dynamische Typisierung in C# 4.0. Jetzt wird also auch noch die statische Typisierung von C# ausgehebelt – die in kompilierbaren Sprachen durchaus ihre Berechtigung hat, da sie schließlich eine Vielzahl von Flüchtigkeitsfehlern verhindert.
• Konvertierungsoperatoren: In C# kann ich diese Operatoren überladen. Das implizite Konvertierungen böse (weil extrem fehleranfällig) sind, wissen wir aber schon seit langem aus C++. Anlegen kann ich sie hier trotzdem. Explizite Konvertierungen könnte ich auch prima über normalen Methoden abhandeln. C# benutzt dafür dagegen ein eigenes Sprachkonstrukt – und das auch nicht durchgängig – oder warum hat jedes Objekt eine Methode ToString? Sinnvoll dagegen wären implizite Konvertierungen dagegen bei der Umwandlung von primitiven Typen in Strings – genau das unterstützt C# aber wieder nicht.
• In eine ähnliche Kategorie fällt das Überladen von arithmetischen Operatoren. Das ist in beinahe allen Fällen unnütz (einzige Ausnahme – Zahlentupel aller Art (z.B. komplexe Zahlen oder Vektoren) oder Tensoren höherer Ordnung (z.B. Matrizen)), kann aber, da man die Operatoren beliebig implementieren kann, natürlich sehr schnell nach hinten los gehen. Auch hier bezahlt man ein klein wenig Bequemlichkeit mit einem großen zusätzlichen Risiko.
• Grobe Designschnitzer in der Sprache. Bestes Beispiel: Arrays implementieren die Schnittstelle einer Liste. Das heißt ich kann Arrays implizit in Listen konvertieren und darf mich dann wundern, warum meine Listenoperationen zur Laufzeit Ausnahmen werfen. In Java dagegen ist für eine Konvertierung einen expliziter Aufruf von as_list() notwendig. Da weiß man schon eher, woran man ist.
• Erweiterungsmethoden: Dieses neue Feature von C# 3.0 erlaubt es uns, nachträglich zu Typen, die eigentlich als sealed deklariert worden sind, neue Methoden hinzu zu fügen. Das führt natürlich das gesamte Konzept der Kapselung ad absurdum.
• Delegaten und Events: …sind eigentlich nur abgekürzte Schreibweisen für Funktionsreferenzen oder Funktoren. Während Events damit quasi dem Listener-Mechanismus in Java entsprechen (und eigentlich auch so verwendet werden könnten – da bräuchte man kein separates Schlüsselwort für), sind erstere extrem gefährlich, dank ihres =-Operators. Damit kicke ich nämlich ganz schnell registrierte Delegaten wieder heraus und wundere mich dann, warum meine dynamischen Aufrufe nicht mehr funktionieren.

Letztendlich komme ich zu folgendem Fazit: C# ist durch die ständige (und meiner Meinung nach überflüssige) Integration neuer Features auf dem besten Wege, ein zweites C++ zu werden. Das Orthogonalitätsprinzip wird von den Sprachdesignern immer wieder erneut verletzt, was die Fehleranfälligkeit erhöht, den Einstieg in die Sprache erschwert und das finden von Lösungen unnötig kompliziert macht. Java verzichtet auf diesen ganzen Schnickschnack; und dies ist nur oberflächlich ein Nachteil. Die Entwicklungen komplexerer Sprachkonstrukte erfolgt in Java traditionell durch automatisierte Funktionen in den gängigen IDE’s (Eclipse, z.T. auch NetBeans), weshalb in der Sprache selbst auf Bequemlichkeitsfunktionen wie Properties und LINQ verzichtet werden kann. Traurigerweise bietet auch das Visual Studio mittlerweile viele dieser Funktionen an (Implement interface, Refactoring, Create getter/setter), so dass diese Erweiterungen eigentlich garnicht nötig wären.

Eigentlich finde ich diese Entwicklung sehr schade; in vielen Belangen scheint Microsoft endlich im 21. Jahrhundert anzukommen (Endlich ein Visual Studio mit UML-Unterstützung, nach 20 Jahren hat man auch bei MS endlich begriffen, was ein Model-View-Controller-Pattern ist; man entwirft ein Framework, dessen Architektur nichts taugt, komplett neu) zu sein. Warum man dann beim Design der neuen Vorzeigesprache so grundlegende Fehler macht, die jeder Informatikstudent in Theorie von Programmiersprachen vermeiden lernt, ist mir persönlich ein Rätsel.

Letztendlich muss ich natürlich beruflich damit leben, weiterhin mit C# zu entwickeln (besser als Desktopprodukte mit C++ zu entwickeln ist es allemal) – dabei werde ich mich aber wie bisher ans K.I.S.S.-Prinzip halten und im Team darauf setzen, dass wir nur Techniken einsetzen, die auch alle nachvollziehen können. Keine Lambafunktionen, kein LINQ, so lange keine Datenbanken im Spiel sind, sparsamer Einsatz von structs und kein nachträgliches Erweitern von sealed-Typen. Auf das der Debugger nicht zu heiß läuft und es bei einer einstelligen Zahl von Abstürzen des Visual Studios am typischen Arbeittag bleibt…

Eigentlich würde ich mir ja nicht die Mühe machen, hier ein neues Metal-Album vorzustellen. Das Debut Denied by Reign von Severed Fifth hat allerdings schon allein auf Grund der Umstände seines Erscheinens ein wenig Aufmerksamkeit verdient. Severed
Fifth ist ein Musikprojekt des Ubuntu Community Managers Jono Bacon,
der mit seiner Veröffentlichung, der eigenen Aussage nach, “neue Wege
im Vertrieb von Musik” erforschen und beschreiten möchte.

Denied by Reign erscheint unter einer sehr liberalen Creative Commons Lizenz, ist frei verfügbar und darf nach eigenem Gutdünken weiter gegeben werden. Auch das Remixen ist explizit erlaubt. In diesem Sinne nimmt das Album also durchaus einen momentan absolut einzigartigen Ausnahmestatus ein. Jono sieht dabei seine kommerziellen Interessen auch keineswegs als gefährdet an. In einem aktuellen Interview mit Ars Technica sagt er, dass ihm der Weg über Konzerte, CDs und Merchandising immer noch Geld mit seiner Musik zu verdienen, ja immer noch offen stehe, auch wenn dies nicht sein Hauptinteresse sei.

Ach ja, das Wichtigste zuletzt, anhörbar ist das Ganze auch – zumindest, wenn man Metal mag.