Projektziele, Design-Kriterien für eigene Software

Der wichtigste Grundsatz lautet freie Lizenzierung. Seit der allgemeinen Verfügbarkeit von Digitaltechnologie und der darin inherenten Entkoppelung der Information von ihrem physischen Träger bei gleichzeitig immenser Skalierbarkeit durch den Computer als Universalrechenmaschine (Interoperabilität) steht fest, dass das prä-digitale Urheberrecht in seiner gegenwärtigen Form dringend reformbedürftig ist, weil es mittlerweile infolge technischer, rechtlicher, sozialer und ethischer Probleme das genaue Gegenteil von dem erreicht, wofür es eigentlich gedacht war. Seit den 80er-Jahren tobt der Kampf um digitale Grundrechte in den Bereichen Software, Musik, Video und jetzt auch bei den Büchern, wo aber die Öffentlichkeit wenig organisierte Interessensvertretung hervorgebracht hat und der Gesetzgeber tendenziell eher den Vorschlägen restriktiver Rechteverwerter folgt.

Bei Software und manchen Formaten ist eine Form von DRM schon allein aus technischen Gründen gegeben, sodass die unabhängige, eigenständige Datenverarbeitung effektiv unmöglich gemacht werden kann. Die Anwendung des Urheberrechts auf Software trotz ihres Charakters als Werke von praktischem Nutzen tut ihr Übriges, um Nutzer und andere Entwickler in Abhängigkeit zu bringen. Die einzigste Chance besteht im Moment darin, dass die Urheber ihre Software frei lizenzieren, indem Nutzern umfangreiche Nutzungsrechte eingeräumt werden und anderen Entwicklern die kollaborative Zusammenarbeit ermöglicht wird. Darum ist unsere Software unter der GNU Affero General Public License 3 or any later version lizenziert, um die Verfügbarkeit, Veränderbarkeit, Weiterverbreitbarkeit und unabhängige Verwendbarkeit langfristig sicherzustellen.

Wenn es um Medienwerke wie Bücher geht, ist freie Lizenzierung genauso wie bei der zugrundeliegenden verarbeitenden Software eine elementare Voraussetzung für einen ganzheitlich digitalverträglichen Literaturbetrieb. Vielfältig muss das digitale Potential im Hinblick auf den Umgang mit Texten unausgeschöpft werden, weil immer noch das Urheberrecht dazu missbraucht wird, das Geschäftsmodell des Verkaufs einzelner Dateikopien als Nachbildung der Knappheit aus der physischen Welt einzuführen, obwohl der digitalen Welt der Überfluss zugrundeliegt und die künstliche Verknappung dem Anliegen und Zweck einer Veröffentlichung direkt entgegensteht („Veröffentlichung“ hat etwas mit Öffentlichkeit zu tun). Ziel muss es deshalb sein, die Arbeit an und mit frei lizenzierten sowie gemeinfreien Texten aktiv voranzutreiben, die dafür vorhandenen Geschäftsmodelle weiter zu etablieren und so etwas wie eine freie digitale Bibliothek in welcher Form auch immer entstehen zu lassen, die in den Genuss umfangreicher als auch vielfältiger Community- und Softwareunterstützung kommen wird.

Mehr zum Thema von Richard Stallman (über Software, über andere Medienwerke), Cory Doctorow (über die Implikationen von Digitaltechnologie für das Konzept „Buch“, über DRM) und The League Of Noble Peers (Steal This Film 2).

Die nächste wesentliche Eigenschaft der Software in der Werkzeugkiste betrifft die Automatisierung. Es gibt einen ständig wachsenden Bestand an Texten und jeder dieser Texte bedarf umfangreicher Pflege, Anreicherung und Aufbereitung. Anstatt viel Zeit mit manueller Bearbeitung zu verschwenden, die bei der nächsten Gelegenheit schon wieder hinfällig werden kann, sollen wiederkehrende Arbeitsschritte möglichst automatisiert werden, damit mehr Zeit für automatisierungskompatible Anreicherungen bleibt. Die Automatisierung geht keineswegs zulasten der Qualität oder der Gestaltungsfreiheit, sondern kann im Rahmen der Verarbeitung durchaus Konfigurationseinstellungen oder die Einbindung externer Module zwecks Sonderbehandlung vorsehen, sodass der Workflow ein durchgängig datengetriebener ist und die Automatisierungssoftware lediglich die Methodik zur Verfügung stellt, um von einer definierten Eingabe zur gewünschten Ausgabe zu gelangen, womit der Prozess beliebig oft auf dieselben oder kompatible Eingabedaten neu angewendet werden kann.

Die technische Grundlage dafür stellt XML als universaler Standard zur Auszeichnung von textorientierten Daten dar, womit zahlreiche auf bestimmte Anwendungsbereiche spezialisierte Formate wie z.B. HTML, DocBook, ODT oder TEI definiert wurden, wofür in quasi allen Programmiersprachen Zugriffs- und Verarbeitungsbibliotheken zur Verfügung stehen, worauf mächtige Werkzeuge wie XML-Schema-Validierer, XSLT- und XSL-FO-Prozessoren operieren. XML sichert dabei die Interoperabilität, indem zwischen unterschiedlichen Formaten hin- und herkonvertiert werden kann, Nicht-XML-Quelldateien über Parser nach XML und XML-Daten über entsprechende darauf zugeschnittene Generatoren (evtl. irreversibel) in die gewünschten Zielformate überführt werden. Freilich sind Konzepte wie Single Source Publishing oder gar „Multi Source Publishing“ (Erzeugen mehrerer Zielformate unter der Zusammenfügung mehrerer Datenquellen, die womöglich ihrerseits jeweils mehrfach konvertiert werden müssen) ganz im Sinne der Automatisierung. Allerdings soll die technische Komplexität der Formate, der Verarbeitung und der Abstimmung der Werkzeuge vor dem Benutzer durch grafische Oberflächen komplett verborgen werden (siehe Robert Cailliau zu den Grundlagen des World Wide Webs), weil einerseits manuelle Eingriffe beim nächsten Durchlauf hinfällig wären und andererseits die Erstellung qualitativer Quelldokumente und die Definition von Workflows mithilfe von sinnvollen Standardvorgaben stark vereinfacht werden können.

Die Automatisierung profitiert ganz erheblich von der Modularität der Software in der Werkzeugkiste. Die meiste Software für Self-Publisher folgt einer monolithischen Architektur, d.h. ein einziges großes Programm vereint sämtliche angebotene Funktionalität in sich selbst mit dem Ziel, eine integrierte Arbeitsumgebung bereitzustellen. Der Nachteil davon ist, dass einzelne Funktionen oft nicht separat aufgerufen werden können, sondern stattdessen immer die komplette Arbeitsumgebung gestartet werden muss. Dann ist die Arbeitsumgebung in der Regel eine grafische, sodass die Bedienung des Programms primär mit der Maus erfolgt. Bei der Automatisierung macht es aber nur wenig Sinn, Klicks auf Buttons und Menüs auszulösen, denn die Eingabe von Daten soll ja schließlich von außen parametrisiert angesteuert werden, um einen rein datengetriebenen Ablauf zu erreichen.

Dementsprechend soll die Software, die im Rahmen des Projekts entwickelt wird, aus einer Reihe von kleinen Einzelprogrammen bestehen, die zu größeren automatisierten Workflows zusammengeschaltet werden können. Einerseits entsteht dadurch eine hohe Flexibilität, weil die Programme auch in anderen Kombinationen eingesetzt werden können, andererseits können zwischen den einzelnen Verarbeitungsschritten externe Komponenten aufgerufen werden. Dass die Programme auch abseits automatischer Workflows zur Bewältigung begrenzter Aufgaben in einem ansonsten manuellen Aufbereitungsworkflow genutzt werden können, versteht sich von selbst. Dieser Ansatz schließt übrigens keineswegs aus, dass vor oder während der Verarbeitung umfangreiche benutzerspezifische Einstellungen hinterlegt werden können, die dann von den jeweiligen Einzelschritten berücksichtigt werden. Eine optionale grafische Oberfläche ist dabei behilflich, die überdies auch zur Steuerung und Bedienung der Einzelprogramme, der Workflows und des Gesamtsystems dient. Um die Einzelprogramme möglichst unabhängig von den sie aufrufenden Workflows zu halten, erfolgt die Kommunikation über wohldefinierte Schnittstellen, über welche die Workflows die in „Jobs“ zusammengefassten Einstellungen einspeisen können. Ein Nachteil dieses Ansatzes ist, dass die Komplexität der Abhängigkeiten bei Änderungen an den Schnittstellen oder in den Einzelprogrammen umso mehr steigt, je mehr Workflows sich der betroffenen Programme bedienen – dem soll nach Möglichkeit mit zusätzlichen Abstraktionsebenen begegnet werden, welche Schnittstellendetails nach oben hin verbergen (kapseln).

Die entwickelte Software besteht sowohl aus Online- als auch Offline-Teilen. Die Ausführbarkeit der Programme auf dem lokalen Rechner ist wichtig, um die Hoheit über die eigene Datenverarbeitung (siehe das Grundrecht auf Gewährleistung der Vertraulichkeit und Integrität informationstechnischer Systeme, dessen Verletzung ja nicht fahrlässigerweise begünstigt zu werden braucht) aufrecht erhalten zu können. Ausgenommen davon sind logischerweise Funktionen, die nur in einem Vernetzungs-Kontext Sinn machen wie z.B. eine Benutzerverwaltung, mithilfe welcher die Aufteilung von Aufgaben für kollaboratives Arbeiten an einem Projekt organisiert werden kann. Allerdings können externe Online-Komponenten wie das MediaWiki oder WordPress von Online- und/oder Offline-Varianten unserer Programme angesteuert werden, wobei die Unterstützung von dezentralen Peer-to-Peer-Protokollen zwecks Bereitstellung derselben Funktionalität zu bevorzugen wäre. Ob die Einzelprogramme und Workflows mit einem Web-GUI versehen und online ausführbar gemacht werden sollen, hängt vom jeweiligen Nutzungsszenario ab, denn die Verwendung der Online-Version statt der Offline-Version muss im Gegensatz zur Bereitstellung von Diensten für kollaboratives Arbeiten oder für integrierte Plattformen nicht gerade herausgefordert werden.

Ein weiteres wichtiges Anliegen ist die Plattform-Integration. Statt Werke, Werkzeuge, Dienste, Veröffentlichungskanäle und Geschäftsmodelle für sich isoliert zu betrachten, können diese Einzelbausteine miteinander kombiniert werden zu ganzheitlich digitalverträglichen Ökosystemen, in welchen die Produzenten höher entlohnt werden bei gleichzeitig für den Konsumenten günstigeren, quantitativ mehr und qualitativ besseren Ergebnissen. Freilich gibt es keine feste Rollenverteilung in solchen Ökosystemen, jedermann kann gleichberechtigt jede beliebige Funktion den eigenen Fähigkeiten und Fertigkeiten entsprechend ausüben, auch in Kooperation und Kollaboration. Interoperabilität und Vernetzung sind probate Mittel, um die verschiedenen Teilnehmer näher zusammenzubringen. Digitalverträgliche Plattformen fördern die Produktion, Distribution und Rezeption von Werken und erschweren sie nicht künstlich, um Interessen einzelner Parteien zu schützen auf Kosten der ebenso berechtigten Interessen anderer Parteien. Größte Aufmerksamkeit gebührt der Vermeidung von Abhängigkeiten, welche durch Einseitigkeit ein bestehendes Ökosystem ins Ungleichgewicht, in die Instabilität stürzen können. Daher sollten besagte Plattformen flexibel genug konzipiert sein, um einzelne Komponenten austauschen oder den Benutzer vor die Wahl stellen zu können, welche davon eingesetzt werden sollen.

Eine Diskriminierung findet nicht statt. Inhaltliche, personelle, qualitative (nutzungsrechtliche und technische Anforderungen ausgenommen), quantitative, gestalterische, strategische und kommerzielle Präferenzen werden nicht besonders berücksichtigt, sondern sind den handelnden Personen eigenverantwortlich anheim gestellt.

Installationsanweisungen

Neben der Möglichkeit, die Programme der Werkzeugkiste aus dem Quellcode zu kompilieren, werden unter publishing-systems.org/downloads.php vorbereitete Download-Packages angeboten. Da für die Ausführung eine Java-VM benötigt wird, sollte mittels des Befehls

java -version

ermittelt werden, ob eine oder welche Java-VM auf dem System bereits installiert ist. Unterstützt wird Java 1.6 und höher. Weil die Verwendbarkeit der Werkzeugkiste für die 100% freien Distributionen des GNU-Betriebssystems stets gewährleistet werden soll, insbesondere aber gNewSense als Referenzsystem gelten kann, wäre, sofern noch nicht vorhanden, die Java Runtime Environment des OpenJDKs mittels

apt-get install openjdk-6-jre

zu installieren. Nachdem das Download-Package mit der höchsten Versionsnummer heruntergeladen und entpackt wurde, ist das Shell-Script

$/workflows/run_setup1.sh

auszuführen, woraufhin anschließend die einzelnen Tools und Workflows direkt oder über das dazugehörige Shell-Script aufgerufen werden können.

Sobald PDFs erzeugt werden sollen, ist auch ein installiertes LaTeX-Satzsystem erforderlich, dessen pdflatex-Programm aufgerufen wird. Mit

apt-get install texlive-latex-base

apt-get install texlive-latex-memoir

apt-get install texlive-lang-german

können die benötigten Pakete eingerichtet werden.

Die Werkzeugsammlung kann grundsätzlich auch in anderen Betriebssystem-Umgebungen als GNU eingesetzt werden. Die dafür notwendigen, oben beschriebenen Software-Komponenten sind infolge ihrer freien Lizenzierung auf beispielsweise Microsoft Windows oder Apple Mac OS X portiert worden, jedoch wird dringend von der Verwendung proprietärer Betriebssysteme als Grundlage für die Ausführung von portierten und an sich frei lizenzierten Programmen abgeraten, weil sonst von einer Hoheit über die eigene Datenverarbeitung und der Achtung digitaler Grundrechte ebenfalls keine Rede sein kann.

Beschreibung der Tools

Stand: Commit 107.

csv2xml1 unter $/csv2xml/csv2xml1/ ist ein Programm, welches eine CSV-Datei nach XML konvertiert. Das Trennzeichen zwischen den Werten kann über einen Parameter mitgegeben werden, außerdem werden mehrzeilige Felder über die Einklammerung in Anführungszeichen unterstützt. Die Namen der Tags in der resultierenden XML-Datei werden der ersten Zeile entnommen, welche von manchen Benutzern für Spaltenüberschriften bei der Bearbeitung in z.B. LibreOffice verwendet wird. Auch zu sehen in Workshop csv2all: Beschreibung Ausgangssituation.

csv2xml2 unter $/csv2xml/csv2xml2/ ist nahezu identisch mit csv2xml1 mit dem Unterschied, dass die Konvertierungs-Vorgaben über eine Konfigurationsdatei gesteuert werden. In selbiger wird das CSV-Trennzeichen festgelegt als auch, welche CSV-Spalte welchen XML-Tagnamen erhalten soll. Auf diese Weise kann auch eine Filterung der CSV-Daten erreicht werden, wenn nicht alle Spalten mit einer XML-Tagnamen-Zuordnung versehen werden.

epub2html1 unter $/epub2html/epub2html1/ leistet wenig mehr, als eine EPUB2-Datei zu entpacken. Obwohl eigentlich ein Zip-Programm für die Bewältigung dieser Aufgabe völlig ausreichen würde, hat epub2html1 den Effekt, dass die internen Dateien zur Organisation des EPUB-Containers nicht in den Ausgabe-Ordner übernommen werden und überdies eine flache Dateistruktur entsteht, wie sie für statische Webseiten typisch ist. Die zu entpackende EPUB-Datei sowie das Ausgabe-Verzeichnis werden in einer Konfigurationsdatei festgelegt. Im Ausgabe-Verzeichnis erstellt epub2html1 zwar keine index.html, jedoch wird eine index.xml generiert, welche die extrahierten XHTML-Dateien aufzählt, sodass aufrufende Software das Ergebnis weiterverarbeiten oder mittels XSLT eine index.html daraus abgeleitet werden kann. Das Programm unterstützt die automatische Ermittlung des DOCTYPEs noch nicht, sodass im Unterverzeichnis $/epub2html/epub2html1/entities/ die Datei config_xhtml1_1.xml nach config.xml kopiert werden muss, damit der Aufruf erfolgreich ist. Das Extraktions-Verzeichnis $/epub2html/epub2html1/temp/epub_extraction/ wird nicht automatisch aufgeräumt.

epub2html1_config_create_new1 unter $/epub2html/epub2html1/workflows/ ist ein Programm zur Workflow-Unterstützung, welches eine Konfigurationsdatei für epub2html1 mit Standardvorgaben generiert, welche von aufrufender Software anschließend mit den tatsächlichen Pfaden überschrieben werden können.

file_picker1 unter $/gui/file_picker/file_picker1/ dient der Workflow-Unterstützung, indem ein Dateiauswahl-Dialog bereitgestellt wird, dessen anzuzeigende Dateitypen über eine Konfigurationsdatei festgelegt werden können. Ist eine Auswahl erfolgt, wird der absolute Pfad der ausgewählten Datei auf stdout ausgegeben. Abseits der Aufrufe durch andere Tools und Workflows gibt es keinen Verwendungszweck für file_picker1.

html2epub1 unter $/html2epub/html2epub1/ packt XHTML-1.0-Strict-Dateien zu EPUB2 zusammen. Die internen Dateien zur Organisation des EPUB-Containers werden dabei automatisch generiert. Über eine Konfigurationsdatei können die Eingabe-XHTML-Dateien mit dem Titel, unter welchem sie in der EPUB-Navigation (Inhaltsverzeichnis) aufgeführt werden sollen, spezifiziert werden ebenso wie das Ausgabe-Verzeichnis, in welchem bei Erfolg eine out.epub abgestellt wird. Das Ausgabe-Verzeichnis muss bereits existieren, außerdem werden dort die Bestandteile des EPUBs ebenfalls abgelegt. Ferner können in der Konfigurationsdatei die Metadaten des EPUBs angegeben sowie eine Validierung der Eingabedateien deaktiviert oder wieder aktiviert werden, letzteres ist dringend zu empfehlen.

html2epub1_config_create_new unter $/html2epub/html2epub1/gui/html2epub1_config_create_new/ ist ein Programm zur Workflow-Unterstützung, welches eine Konfigurationsdatei für html2epub1 generiert. Zwingend erforderliche Angaben wie die Eingabe-XHTML-Dateien, das Ausgabe-Verzeichnis oder die Metadaten-Felder bleiben leer, sodass aufrufende Software die entsprechenden Werte vor Verwendung erst noch hinterlegen muss. Der Pfad für die Konfigurationsdatei kann, sofern der Dateiauswahldialog nicht aufgerufen werden soll, auch per Parameter mitgeteilt werden.

html2epub1_config_file_setup unter $/html2epub/html2epub1/gui/html2epub1_config_file_setup/ stellt einen Dialog bereit, mithilfe welchem eine per Parameter oder per Dateiauswahldialog angegebene html2epub1-Konfigurationsdatei hinsichtlich der beteiligten Datei- und Verzeichnispfade bearbeitet werden kann. So können XHTML-Dateien hinzugefügt, entfernt oder in ihrer Reihenfolge anders angeordnet werden. Deren Titel, welche für die EPUB-Navigation (Inhaltsverzeichnis) herangezogen werden, können editiert werden. Das Ausgabeverzeichnis kann hinterlegt und geändert werden. Ein Button „Check“ dient der Überprüfung der Angaben, deren Korrektheit mittels kleiner Icons signalisiert wird. Wenn alle Icons grün sind, kann mit „Save“ gespeichert werden. Ein Verlassen mit „Exit“ speichert die Änderungen nicht!

html2epub1_config_metadata_editor unter $/html2epub/html2epub1/gui/html2epub1_config_metadata_editor/ stellt einen Dialog bereit, mithilfe welchem die Metadaten einer per Parameter oder per Dateiauswahldialog angegebene html2epub1-Konfigurationsdatei hinterlegt und bearbeitet werden können. Ein Button „Check“ dient der Überprüfung der Angaben, deren Korrektheit mittels kleiner Icons signalisiert wird. Wenn alle Icons grün sind, kann mit „Save“ gespeichert werden. Ein Verlassen mit „Exit“ speichert die Änderungen nicht!

html2epub1_config_merge1 unter $/html2epub/html2epub1/workflows/ führt zwei html2epub1-Konfigurationsdateien zusammen, wobei von der ersten per Parameter angegebenen Konfigurationsdatei die Dateihinterlegungen der XHTML-Eingabedateien sowie das Ausgabeverzeichnis und von der zweiten per Parameter angegebenen Konfigurationsdatei die Metadaten übernommen werden, um sie in die mit dem dritten Parameter angegebene Datei rauszuschreiben.

html_prepare4latex1 unter $/html2latex/html_prepare4latex1/ dient dem Escapen von LaTeX-Sonderzeichen in einer XHTML-1.0-Strict-Datei. Ausgenommen davon sind die Zeichen <, > und &, weil diese zwecks XML-Wohlgeformtheit in der XHTML-Datei weiterhin als Entity erhalten bleiben müssen, sodass sich nach einer Transformation von XHTML nach LaTeX ein anschließendes Suchen-und-Ersetzen anbietet, wo & durch \& ersetzt werden sollte. Bei < und > kann davon ausgegangen werden, dass die Transformation nach LaTeX als Nicht-XML-Ausgabeformat ein Deescaping der XML-Entities vornimmt. $/html2latex/html2latex1/layout/txtreplace1_replacement_dictionary_post_preparation.xml stellt eine entsprechende Ersetzungs-Konfigurationsdatei für txtreplace1 bereit. Das Programm unterstützt die automatische Auflösung der XHTML-DTDs noch nicht, sodass im Unterverzeichnis $/html2latex/html_prepare4latex1/entities/ die Datei config_xhtml1-strict.xml nach config.xml kopiert werden muss, damit der Aufruf erfolgreich sein kann.

html2wordpress1 unter $/html2wordpress/html2wordpress1/ übermittelt eine XHTML-Datei an eine WordPress-Installation. Eine Internet-Verbindung ist erforderlich, ebenso muss seitens der WordPress-Installation die XML-RPC-Schnittstelle aktiviert sein, was aber standardmäßig der Fall ist seit WordPress 3.5. Um das Passwort des WordPress-Benutzers nicht im Klartext übermitteln zu müssen, muss serverseitig das „Secure XML-RPC“-Plugin von Eric Mann (Version 1.0.0, das ist Commit 31) installiert sein. Über eine Steuerungsdatei wird die zu übermittelnde XHTML-Datei und der URL der XML-RPC-Schnittstelle angegeben. Der Public- und Private-Key für die Benutzer-Authentifizierung kann im WordPress-Benutzerprofil für html2wordpress1 generiert werden und muss ebenfalls in die Steuerungsdatei eingetragen werden. Damit die neu generierten Keys auch abgespeichert werden, den Klick auf „Update Profile“ nicht vergessen. Der Private-Key sollte der Geheimhaltung unterliegen, weshalb darauf zu achten ist, dass dieser nicht in der Steuerungsdatei verbleibt, wenn auch andere Computerbenutzer lesenden Zugriff auf die Datei haben. Eine Möglichkeit besteht darin, nach der Übermittlung das Paar aus Public- und Private-Key im Benutzerprofil zu verwerfen. Der Text der XHTML-Datei wird im Klartext übermittelt. Ferner muss bzw. kann in der Steuerungsdatei die ID des entsprechenden Benutzers, welchen Post-Typ die übermittelte Ressource aufweisen soll (üblich sind „post“ und „page“, aber auch Custom Post Types können angewendet werden), mit welchem Status die Ressource versehen werden soll (diverse Stati wie z.B. „publish“, „pending“, „draft“, „future“ oder „private“ sind üblich), Titel und Kurzzusammenfassung, Datum und Uhrzeit (hiermit lässt sich auch eine automatische zukünftige Veröffentlichung realisieren), das Darstellungsformat, der Slug (leserlicher Namen für den URL), die Aktivierung oder Deaktivierung von Kommentaren und Pingbacks, das Sticky-Flag (angepinnte Ressource), eine Thumbnailbild-ID, die ID einer Parent-Ressource, Custom Fields (werden normalerweise für Metadaten genutzt), IDs der Einträge einer hierarchischen Taxonomie (müssen vorhanden sein) und die Namen einer Tag-Taxonomie (müssen nicht vorhanden sein, werden angelegt) festgelegt werden. Es findet eine Validierung der Eingabe-XHTML-Datei statt. html2wordpress1 beschränkt sich auf den Inhalt von <body> der Eingabe-XHTML-Datei, welcher unverändert übermittelt wird, dabei aber auch CSS-Angaben in <head> samt den dort enthaltenen Metadaten verloren gehen. Die Antwort des Servers wird direkt auf stdout ausgegeben.

html2wordpress1_jobfile_create_new1 unter $/html2wordpress/html2wordpress1/html2wordpress1_jobfile_create_new1/ dient der Workflow-Unterstützung, welches eine Steuerungsdatei für html2wordpress1 mit Standardvorgaben generiert, welche von aufrufender Software anschließend mit den tatsächlichen Angaben überschrieben werden können. Der Pfad für die Steuerungsdatei kann, sofern der Dateiauswahldialog nicht aufgerufen werden soll, auch per Parameter mitgegeben werden.

html_attributeanalyzer1 unter $/html_attributeanalyzer/html_attributeanalyzer1/ liest aus einer XHTML-Eingabedatei alle enthaltenen Attribute, deren Wert, deren Element sowie das Eltern-Element aus und schreibt diese in eine Ausgabe-XML-Datei. Jede Kombination aus Attribut-Name, Attribut-Wert, Attribut-Element und Eltern-Element wird nur einmalig ausgewiesen. Das Programm wird bisher in keinem Workflow eingesetzt.

html_attributereplace1 unter $/html_attributereplace/html_attributereplace1/ ersetzt Werte von Attributen in einer XHTML-Datei aufgrund einer Mapping-Konfigurationsdatei, wo die zu ersetzenden Attributwerte über den Element- und Attributnamen spezifiziert werden. Das Programm wird bisher in keinem Workflow eingesetzt.

html_concatenate1 unter $/html_concatenate/html_concatenate1/ fügt mehrere XHTML-Dateien aneinander und schreibt das Ergebnis in eine XHTML-Ausgabedatei. Die Steuerung eines Aufrufs erfolgt über eine Konfigurationsdatei, in welcher auch festgelegt werden kann, aus welcher XHTML-Datei die HTML-Kopfdaten übernommen werden sollen, wobei sich die Aneinanderfügung der referenzierten Eingabedateien immer auf den Inhalt des <body>-Tags bezieht. Die Datei, aus welcher die HTML-Kopfdaten übernommen werden sollen (inklusive <body>), muss nicht Teil der Liste der aneinanderzufügenden XHTML-Dateien sein. Wenn keine HTML-Kopfdatendatei angegeben wird, werden die Kopfdaten der ersten angegebenen XHTML-Datei herangezogen.

html_flat2hierarchical1 unter $/html_flat2hierarchical/html_flat2hierarchical1/ sorgt für sog. „Positional Grouping“. XML strukturiert Daten in aller Regel hierarchisch, wodurch ineinander verschachtelte Einheiten semantisch abgebildet werden. Es gibt jedoch auch die Möglichkeit, den Beginn (und theoretisch auch das Ende) logischer Einheiten über „Marker“ (manchmal auch „Milestones“ genannt) zu kennzeichnen, die auf derselben hierarchischen XML-Ebene stehen als ihre „Unterelemente“, für welche sie die umgebende Klammer darstellen sollen. Marker werden häufig verwendet, wenn sich überlappende Einheiten abgebildet werden sollen, was aber von html_flat2hierarchical1 nicht berücksichtigt wird. Ein anderer Verwendungsfall ist anzutreffen z.B. im ODT-Format, wo im Textverarbeitungsprogramm LibreOffice keine semantische Verschachtelung von Dokumentelementen hinterlegt werden kann, sodass intern nur eine „flache“ Struktur, sprich. eine Aufzählung der enthaltenen Elemente in der Reihenfolge ihres Auftretens, vorzufinden ist. Über eine Konfigurationsdatei kann html_flat2hierarchical1 angewiesen werden, solche Marker, die per Elementname und optional zusätzlich gemäß bestimmtem Attribut-Name und -Wert, versehen mit einer Angabe über deren hierarchische Wertigkeit, zu Parent-Elementen der darauffolgenden Elemente umstrukturiert werden, was sämtliche Unterelemente einschließt, bis der nächste Marker gleicher oder höherer hierarchischer Wertigkeit vorgefunden wird, woraufhin sämtliche vorhergehenden, noch geöffneten Marker-Verschachtelungsebenen geschlossen werden. Das Programm unterstützt die automatische Auflösung der XHTML-DTDs noch nicht, sodass im Unterverzeichnis $/html_flat2hierarchical/html_flat2hierarchical1/entities/ die Datei config_xhtml1-strict.xml nach config.xml kopiert werden muss, damit der Aufruf für XHTML 1.0 Strict erfolgreich sein kann.

html_split1 unter $/html_split/html_split1/ teilt eine XHTML-Eingabedatei in mehrere Ausgabedateien auf, wobei die Aufteilungskriterien in einer Konfigurationsdatei spezifiziert werden. Als Kriterium wird ein Elementname und optional zusätzlich Attribut-Name und -Wert herangezogen. html_split1 berücksichtigt immer nur das zuerst gefundene Element, welches einem Kriterium entspricht, bis zu dessen Ende. Darin enthaltene Unterelemente, auf welche ebenfalls Kriterien zutreffen, werden nicht weiter unterteilt, wobei html_split1 zu diesem Zweck erneugt und evtl. rekursiv auf die Ergebnis-Dateien aufgerufen werden könnte. Die Ergebnis-Dateien werden in einem Ordner als XML-Dateien abgelegt, da der ausgeschnittene Bereich nicht mit HTML-Kopfdaten versehen wird, welche aber per XSLT nachträglich wieder ergänzt werden können. Das Ausgabe-Verzeichnis wird mit einer Datei info.xml versehen, welche die erzeugten Aufteilungs-Dateien auflistet.

odt2html1 unter $/odt2html/odt2html1/ konvertiert eine ODT-Datei (Textverarbeitungs-Dokumentenformat des OpenDocument-Standards, welcher u.a. OpenOffice/LibreOffice zugrundeliegt) nach XHTML 1.0 Strict. Neben der Eingabedatei muss ein Ausgabeverzeichnis per Parameter mitgegeben werden. Entweder wird im angegebenen Verzeichnis eine XHTML-Datei mit demselben Namen wie die Eingabedatei, aber mit der Dateiendung *.html angelegt, oder optional kann über einen dritten Parameter ein abweichender Dateiname gewählt werden. Im Ausgabeverzeichnis werden neben der XHTML-Datei auch die enthaltenen Bilder abgelegt, welche überdies dort in einer info.xml verzeichnet werden. Außer Bildern werden auch Links und Stil-Hinterlegungen zwecks semantischer Weiterverarbeitung in die Ausgabe übernommen. Das temporäre Extraktions-Verzeichnis $/odt2html/odt2html1/temp/ wird möglichst aufgeräumt, was jedoch nicht immer gelingt und dann mit einer nicht weiter relevanten Warnung gemeldet wird.

txtreplace1 unter $/txtreplace/txtreplace1/ nimmt eine einfache Textersetzung vor, wo die zu ersetzenden und ersetzenden Zeichen über eine Konfigurationsdatei festgelegt werden. Da die Konfigurationsdatei in XML verfasst ist, können XML-Tags in XML-Dateien damit nicht ersetzt werden, weil die Hinterlegung derselben mit dem Aufbau der Konfigurationsdatei konfligieren würde. Textinhalt von XML-Elementen kann aber in Eingabe-XML-Dateien wie in jeder anderen Dateiform auch ersetzt werden. Es wäre darauf zu achten, dass nicht versehentlich auch Tag-Namen mitersetzt werden, wo txtreplace1 natürlich keine Unterscheidung trifft zu gewöhnlichem Textinhalt innerhalb von XML-Tags.

unzip1 unter $/unzip/unzip1/ ist ein primitiver Wrapper, um mithilfe der Java-Standardlibrary ein Zip-Archiv entpacken zu können, ohne ein externes Programm dafür aufrufen zu müssen.

html2epub1-Workflow unter $/workflows/ ist für odt2epub1-Workflow fest auf eine Eingabe-XHTML-1.0-Strict-Datei abgestimmt, die auf $/odt2html/templates/template1/template1.ott basiert, um daraus ein EPUB2 zu erzeugen. Die Verwendung mit einer XHTML-Datei, die aus einem reinen odt2html-Aufruf stammt, ist nicht möglich, da odt2html1-Workflow gewisse Vorarbeiten vornimmt. Mittels html_split1 wird gemäß html_split1_config_part.xml und html_split1_config_chapter.xml aus $/odt2html/templates/template1/ in die einzelnen Bestandteile zerlegt, welche dann von xsltransformator1 entsprechend html2epub1_html_part.xsl bzw. html2epub1_html_chapter.xsl aus $/odt2html/templates/template1/ zum Ergebnis-Layout aufbereitet werden. Außerdem wird xsltransformator via $/odt2html/templates/template1/html2epub1_html_title.xsl eine zusätzliche XHTML-Titelseite („Cover“) für das EPUB generieren. Mit $/odt2html/templates/template1/html2epub1_config.xsl wird xsltransformator1 eine html2epub1-Konfigurationsdatei anlegen, in welcher die Metadaten für das EPUB aus der html2epub1-Konfigurationsdatei, die per Parameter mitgeteilt wurde, per html2epub1_config_merge1 eingefügt werden. html2epub1 besorgt dann die Erstellung der EPUB2-Datei, die unter $/workflows/temp/epub/ als out.epub zu finden sein wird. Es wird versucht, den Inhalt des Verzeichnisses vorher rekursiv zu löschen. Die Dateien der Zwischenschritte unter $/workflows/temp/ werden nicht aufgeräumt.

html2pdf1-Workflow unter $/workflows/ erzeugt aus einer Eingabe-XHTML-Datei, die auf $/odt2html/templates/template1/template1.ott basiert und durch odt2html1-Workflow vorbehandelt wurde, eine Ausgabe-PDF-Datei. Die XHTML-Datei kann entweder als Kommandozeilenargument mitgeteilt oder in einem Dialog ausgewählt werden. Der Workflow bereitet die Eingabedatei erst mit html_prepare4latex1 aus $/html2latex/html_prepare4latex1/ samt einem Aufruf von txtreplace1 aus $/txtreplace/txtreplace1/ mit $/html2latex/html2latex1/layout/txtreplace1_replacement_dictionary_post_preparation.xml für die Aufbereitung durch LaTeX vor, um dann xsltransformator1 aus $/xsltransformator/xsltransformator1/ mit $/html2latex/html2latex1/layout/layout1.xsl die semantischen Stilkennzeichnungen gemäß der template1.ott an das LaTeX-Layout zu koppeln. Das Erebnis wird unter $/workflows/temp/pdf/ als out.tex abgelegt. Wenn pdflatex aufgerufen werden kann, findet sich dort dann auch eine entsprechende out.pdf. Es wird versucht, den Inhalt des Verzeichnisses vorher rekursiv zu löschen.

odt2all1-Workflow unter $/workflows/ erzeugt aus einer Eingabe-ODT-Datei, die auf $/odt2html/templates/template1/template1.ott basiert, HTML-, EPUB2- und PDF-Dateien, die in dem Verzeichnis abgelegt werden, welches per Kommandozeilenargument mitgeteilt wurde. Eine Steuerungsdatei, die ebenfalls per Kommandozeile referenziert wird, listet eine oder mehrere Eingabe-ODT-Dateien auf ebenso wie eine Konfigurationsdatei für html2epub1, aus welcher die Metadaten für das EPUB entnommen werden. Intern wird zuerst odt2epub3-Workflow und dann odt2pdf2-Workflow aufgerufen.

odt2all2-Workflow unter $/workflows/ ergänzt odt2all1-Workflow um grafische Dialoge zur Bedienung des Workflows, wo zuerst die odt2all1-Konfigurationsdatei ausgewählt oder neu angelegt wird, um dann mit odt2all1_config_edit2 aus $/workflows/gui/odt2all1_config_edit2/ die Eingabe-ODT-Dateien zu hinterlegen oder zu verändern. Daraufhin muss eine html2epub1-Konfigurationsdatei ausgewählt oder neu angelegt werden, welche anschließend mit html2epub1_config_metadata_editor aus $/html2epub/html2epub1/gui/html2epub1_config_metadata_editor/ bearbeitet werden kann. Zuletzt muss noch ein Ausgabe-Verzeichnis ausgewählt werden, sodass odt2all1-Workflow unter Verwendung der hinterlegten Angaben aufgerufen werden kann.

odt2epub1-Workflow unter $/workflows/ ruft erst odt2html1-Workflow auf, erlaubt über html2epub1_config_metadata_editor aus $/html2epub/html2epub1/gui/html2epub1_config_metadata_editor/ die Hinterlegung von Metadaten, um dann mit html2epub1-Workflow eine EPUB2-Datei unter $/workflows/temp/epub/out.epub zu erstellen. Es wird versucht, den Inhalt von $/workflows/temp/epub/ vorher rekursiv zu löschen.

odt2epub2-Workflow unter $/workflows/ unterscheidet sich von odt2epub1-Workflow nur dahingehend, dass statt der Eingabe der Metadaten des EPUBs per Dialog auf der Kommandozeile eine entsprechende html2epub1-Konfigurationsdatei und auch ein Pfad für das EPUB-Ergebnis mitgegeben werden kann.

odt2epub3-Workflow unter $/workflows/ nimmt aus einer Konfigurationsdatei mehrere hinterlegte Pfade zu ODT-Dateien und zu einer html2epub1-Konfigurationsdatei mit Metadaten entgegen, um daraus eine EPUB2-Datei zu generieren, die unter einem per Parameter angegebenen Pfad abgelegt wird. Hierzu wird odt2html1-Workflow auf jede Eingabedatei aufgerufen, welche dann mit html_concatenate1 zusammengefügt werden, html2epub1-Workflow packt dann zu EPUB2 zusammen.

odt2html1-Workflow unter $/workflows/ erzeugt aus einer ODT-Datei, die auf $/odt2html/templates/template1/template1.ott basiert (die hinterlegten benutzerspezifischen Stilvorlagen müssen auf den Text angewendet werden), eine Ausgabe-XHTML-Datei. Die Eingabedatei kann per Parameter mitgeteilt oder per Dialog ausgewählt werden. Nach odt2html1 werden aus $/odt2html/templates/template1/ prepare4hierarchical.xsl mit xsltransformator1, html_flat2hierarchical1_config.xml mit html_flat2hierarchical1 und html_clean.xsl mit xsltransformator nacheinander aufgerufen. Das Ergebnis wird unter $/workflows/temp/output_1/output_4.html (samt den dazugehörigen Bildern, die auch in besagtem Verzeichnis in einer info.xml aufgelistet sind) abgestellt, auch werden die Zwischenergebnisse output_1.html, output_2.html und output_3.html dort nicht aufgeräumt.

odt2html2-Workflow unter $/workflows/ ruft odt2html1 auf eine Reihe von Eingabe-ODT-Dateien auf, die in einer Steuerungsdatei hinterlegt sind, und fügt diese mit html_concatenate1 zusammen. Anschließend werden aus $/odt2html/templates/template1/ prepare4hierarchical.xsl mit xsltransformator1, html_flat2hierarchical1_config.xml mit html_flat2hierarchical1 und html_clean.xsl mit xsltransformator auf die zusammengesetzte XHTML-Datei aufgerufen. Die Steuerungsdatei kann per Parameter mitgeteilt oder per Dialog ausgewählt werden, ferner ist der Pfad anzugeben, unter welchem die Ausgabedatei abgelegt werden soll. Das Ergebnis wird unter $/workflows/temp/output_1/output_4.html (im Moment noch ohne den dazugehörigen Bildern und ohne info.xml) abgestellt, auch werden die Zwischenergebnisse output_1.html, output_2.html und output_3.html sowie die output_1_*-Verzeichnisse dort nicht aufgeräumt.

odt2pdf1-Workflow unter $/workflows/ erzeugt aus einer ODT-Datei, die per Kommandozeilenargument oder per Dialog mitgeteilt werden kann, ein PDF, indem zuerst mit xsltransformator1 und /odt2html/templates/template1/prepare4html2latex1_layout1.xsl transformiert wird, um html2pdf1-Workflow aufrufen zu können.

odt2pdf2-Workflow unter $/workflows/ unterscheidet sich von odt2pdf1-Workflow nur dahingehend, dass per Kommandozeilenargument eine Steuerungsdatei entgegengenommen wird, die mehrere Eingabe-ODT-Dateien referenziert, welche dann mit odt2html2-Workflow für die weitere Verarbeitung vorbereitet werden. Ferner muss der Pfad angegeben werden, unter welchem die Ergebnis-PDF-Datei abgelegt werden soll.

setup1-Workflow unter $/workflows richtet die Tool-Sammlung für die Verwendung ein, indem die Dateien aus $/w3c/ in die Verzeichnisse der Tools kopiert werden, damit diese jeweils eigenständig darauf zugreifen können.

epub2wordpress1-Workflow unter $/workflows/epub2wordpress/epub2wordpress1/ entpackt ein EPUB2 mittels epub2html1 aus $/html2epub/html2epub1/, wendet das Stylesheet $/workflows/epub2wordpress/epub2wordpress1/html2wordpress1.xsl mittels xsltransformator1 aus $/xsltransformator/xsltransformator1/ darauf an und übermittelt das Ergebnis an eine WordPress-Installation mithilfe von html2wordpress1 aus $/html2wordpress/html2wordpress1/, wobei die html2wordpress1-Steuerungsdatei, die per Kommandozeilenargument mitgegeben wird, als Quelldatei $/html2wordpress/html2wordpress1/input.html eingetragen haben muss. Die in der EPUB2-Datei enthaltenen XHTML-Dateien werden jeweils einzeln transformiert und übermittelt.

odt2all1_config_edit1 unter $/workflows/gui/odt2all1_config_edit1/ dient der Workflow-Unterstützung und erlaubt das Auswählen oder Neuanlegen einer odt2all1-Workflow-Konfigurationsdatei, wobei sowohl die Eingabe-ODT-Dateien als auch die html2epub1-Konfigurationsdatei hinterlegt werden können.

odt2all1_config_edit2 unter $/workflows/gui/odt2all1_config_edit2/ unterscheidet sich von odt2all1_config_edit1 nur dahingehend, dass die html2epub1-Konfigurationsdatei nicht hinterlegt werden kann (weil z.B. ein Workflow sich darum kümmert).

xsltransformator1 unter $/xsltransformator/xsltransformator1/ ist ein primitiver Wrapper, um mithilfe der Java-Standardlibrary eine XSLT-Transformation durchführen zu können, ohne ein externes Programm dafür aufrufen zu müssen. xsltransformator1 unterstützt die automatische Auflösung von DTDs noch nicht, sodass im Unterverzeichnis $/xsltransformator/xsltransformator1/entities/ die Datei config_xhtml1-strict.xml für XHTML 1.0 Strict oder config_xhtml1_1.xml für XHTML 1.0 nach config.xml kopiert werden muss, damit der Aufruf erfolgreich sein kann.

multitransform1 unter $/xsltransformator/xsltransformator1/workflows/multitransform1/ kann ein XSLT-Stylesheet zwecks XSLT-Transformation auf eine Reihe von XML-Eingabedateien anwenden, welche dem Programm per Steuerungsdatei mitgeteilt werden zusammen mit dem jeweilig gewünschten Pfad der Ausgabe-Datei. Intern wird xsltransformator1 aufgerufen.

Den Quellcode kompilieren

Weil die Tools unter der GNU Affero General Public License 3 or any later version lizenziert sind, hat jeder Nutzer der Software ein Recht darauf, den Quellcode der Programme erhalten zu dürfen und zu können, welcher verändert oder unverändert eingesetzt als auch beliebig weitergegeben werden darf, solange dies unter der gleichen Lizenz geschieht. Wenn die Tools lediglich als ausführbare Dateien (Java Bytecode) ohne Quelltext überlassen wurden oder auf einem Server ausgeführt werden, der über ein Netzwerk zugänglich ist, muss entweder kenntlich gemacht sein, wo der korrespondierende Quelltext heruntergeladen werden kann oder eine Anschrift genannt werden, die auf Anfrage den Quelltext postalisch zusendet (bis zu drei Jahre nach erfolgter binärer Distribution). Wenn es sich um die offiziellen Bezugsquellen wie das öffentliche Online-Repository https://github.com/publishing-systems/automated_digital_publishing oder die Download-Packages unter http://www.publishing-systems.org/downloads.php handelt, ist sichergestellt, dass der Quellcode mit Java 1.6 und höher sowie mit OpenJDK kompatibel ist. Die Kompilierbarkeit soll für die 100% freien Distributionen des GNU-Betriebssystems gewährleistet werden, wobei insbesondere gNewSense als Referenzsystem gelten kann. Auf debianbasierten Distributionen kann mit

apt-get install openjdk-6-jdk

ein JDK installiert werden. Weil GNU make üblicherweise vorinstalliert ist, genügt der Befehl

make

im Wurzelverzeichnis $/.

Da das offizielle öffentliche Repository auf GitHub gehostet wird, ist kollaboratives Arbeiten an der Software besonders einfach. Mit einem GitHub-Account kann zunächst ein „Fork“, eine eigene Kopie des Repositorys angelegt werden. Sofern git mittels

apt-get install git

installiert wurde, kann mit dem Befehl

git clone <HTTPS clone URL des Repositorys auf github.com>

eine lokale Kopie heruntergeladen werden, in welcher die Entwicklung stattfindet. Ist die Programmierung abgeschlossen, können die Änderungen mit dem Dreisatz

git add *

git commit -m "Beschreibung der Änderungen"

git push origin <Branch, erst mal master>

in den eigenen Fork hochgeladen und damit veröffentlicht werden. Zu berücksichtigen ist dabei, dass alle Änderungen ebenfalls unter GNU Affero General Public License 3 or any later version lizenziert werden müssen. Auf github.com kann dann in der Verwaltung des Fork-Repositorys ein „Pull Request“ zwecks potentieller Übernahme in das offizielle Repository angelegt werden, welcher nach Prüfung angenommen oder abgelehnt wird. Auf diese Weise können Patches zur Korrektur von Fehlern, neue Features, neue Tools usw. eingereicht werden, oder aber die Werkzeugkiste auch in eine ganz andere Richtung weiterentwickelt werden.

Erste Umsetzung in der Praxis

In Ansgar Warners E-Book-Newsletter vom 23.05.2014 habe ich erfahren, dass in Deutschland der Kladde-Verlag erstmals ausschließlich Crowdfunding für zu realisierende Buchprojekte zugrundelegt. Dabei dient die von Lesern und Investoren vorab bereitgestellte Finanzierung der Deckung der Produktionskosten, sodass der Refinanzierungsdruck herkömmlicher Verlagsmodelle vollständig entfällt. Die Entlohnung des Autors erfolgt über den Verkauf von gedruckten Exemplaren und E-Books, dies aber zu besonders günstigen Konditionen, da die Aufwendungen für die Herstellung bereits abgeglichen sind, sodass bei Fertigstellung eines Projekts vom Verkaufsstart weg die Reingewinn-Spanne angetreten wird. Der Autor kann die freie Lizenzierung der Ergebnisse wählen, sodass die digitalen Grundrechte der Leserschaft gewahrt bleiben und auch andere Bearbeiter, Verlage sowie Distributionskanäle in Betracht kommen können.

Freilich handelt es sich dabei um einen ersten Anfang, ein derartiges Konzept kann aber auch zu einem allgemeinen Marktplatz für Schaffende, Aufbereitende und Leser ausgebaut werden oder gar an eine Distributionsplattform angeschlossen werden. Ferner wären auch andere Autoren-Entlohnungsmodelle auf Basis von Crowdfunding denkbar, sei es pauschal für die Erstellung eines Werkes (Auftragsarbeit), sei es durch den Verkauf einzelner physischer sowie digitaler Exemplare (letzteres als bewusste Unterstützung oder infolge von Bequemlichkeit), sei es durch Subskription eines bestimmten Autors, eines Autoren-Kollektivs, einer Institution, eines Produzenten oder eines Themas, sei es durch Förderung gemeinnütziger Projekte oder über die sonstigen regulär bestehenden Entlohnungsmechanismen.

Ist Crowdfunding überhaupt praktikabel?

Es wird gesagt, dass Crowdfunding keine besonderen Vorteile aufweisen könnte, mit zunehmender Popularität von Crowdfunding die schiere Anzahl und Vielfalt der Projekte die Crowd überfordern würde, dass nur massentaugliche Literatur umsetzbar wäre und infolgedessen gewagte, unbequeme, abseitige Literatur untergehen würde, dass die Verlagerung des wirtschaftlichen Risikos an die Crowd unseriös sei. Dabei ist es doch schon immer schon so, dass es eher diejenigen Leute gibt, die nur passiv konsumieren und alles möglichst günstig oder gar umsonst haben wollen, und dass es diejenigen gibt, die ein gewisses monetäres Kontingent zur Verfügung haben, welches für kulturelle Bedürfnisse ausgegeben werden kann. Letztere Personengruppe sollte sich gut überlegen, ob es so sinnvoll ist, dieses Geld den restriktiven Rechteverwertern zukommen zu lassen, welche dem Autor nur wenig davon abgeben und nach dem Break-Even bis zu 70 Jahre nach dessen Tod weiter ohne Gegenleistung in die eigene Tasche wirtschaften (unter absichtlicher Beeinträchtigung von tatsächlichen und potentiellen Lesern), oder ob z.B. per Vorabinvestition Autor und Produzenten direkt unterstützt werden und anschließend das Ergebnis auch noch der Allgemeinheit frei zur Verfügung gestellt werden kann.

Es ist schon richtig, dass Crowdfunding in erster Linie nur dann besonders gut funktioniert (in den anderen Fällen kann man mit ein paar Anpassungen nachhelfen), wenn man bereits ein gewisses Publikum hat oder leicht Interesse wecken kann. Allerdings kann ein Autor ganz generell nicht erwarten, Unterstützung von irgendjemandem zu erhalten, wenn besagtes Interesse bei niemandem vorhanden oder zu wecken ist. Man könnte nun sagen, dass herkömmliche Verlage die Investition in inhaltlich weniger attraktiv scheinende Projekte per Quersubventionierung realisieren würden, dazu muss man aber längst nicht als restriktiver Rechteverwerter-Verlag agieren, da ja ausnahmslos jeder, der Geld für eine Quersubventionierung übrig hat, selbiges genauso in Crowdfunding-Projekte investieren kann, ohne die negativen Nebeneffekte des herkömmlichen Verlagsmodells. Dass Crowdfunding nicht besonders populär ist, muss nicht notwendig so bleiben, und die Annahme, dass es mit steigender Popularität weniger funktionieren sollte, halte ich für unbegründet. Die Filterung all der vielen zukünftigen Crowdfunding-Projekte ist ein technisch wie sozial lösbares Problem. Sobald Crowdfunding als akzeptiertes Entlohnungsmodell zunehmende Verbreitung findet, dürfte es auch verstärkt für allerlei Nischen- und Fachthemen zum Einsatz kommen, wo zwar die jeweils interessierte Crowd zahlenmäßig sehr überschaubar ist, dafür aber das Internet die Organisation dieser Interessensgruppen hinreichend vereinfacht hat, sodass die Produktion eigener Veröffentlichungen für solche kleinen, jedoch aktiven Communities methodisch stark vereinfacht wird. Solche Veröffentlichungen können eine große Rolle spielen, wenn sie zur Erhöhung von Relevanz, Reichweite oder Attraktivität des Themas beitragen sollen. Einen wichtigen Beitrag zur Entstehung von Ökosystemen dieser Art können Online-Plattformen und -Präsenzen leisten, die Leserinteresse in Richtung der passenden Projekte kanalisieren oder auch einen freien Markt für allerlei Produktionsdienstleistungen schaffen. Fernerhin käme sogar Mikro-Investment mit niedrigen Funding-Zielen und längeren Laufzeiten (oder wiederholter Neu-Einstellung unter Benachrichtigung aller vormals beteiligten Interessenten) nach dem Vorbild vieler Bibliotheken in Betracht, die bisher jede für sich isoliert die gemeinnützige Digitalisierung und Restauration alter Bücher durch mehr oder minder zufällige Besucher ihrer Webseiten zu finanzieren suchen. Ebenso kann auch die Arbeit an frei lizenzierten, digital vorliegenden Werken iterativ gestaltet werden, wenn einzelne Verbesserungen durch einzelne Interessenten veranlasst werden und somit ein gemeinsamer Fortschritt erzielt wird.

Crowdfunding ist auch kein Outsourcing des Risikos, stattdessen wird das Risiko gänzlich ausgeschaltet. Für den Autor, weil er gar nicht erst in ein Projekt investieren muss, für das es gar kein Publikum gibt. Für die Produzenten, weil sie nicht tätig werden müssen, bevor ihre Leistung durch die Crowd vollständig kompensiert werden kann. Für die Crowd, weil sie die getätigten Investitionen zurückerhält, wenn der benötigte Betrag nicht zustande kommt. Ein Verlag wirkt da schon eher wie ein Risiko-Spekulant, der bei Fehlkalkulation auch schnell mal Insolvenz anmelden kann (mit entsprechenden Folgen für Mitarbeiter, Autoren und die Kunden im Markt).

Verhältnis von Crowdfunding zur Kunst

Schreiben als kreativer Prozess unterscheidet ich von der Produktion materieller Güter. Bei letzterer können Prototypen als Entscheidungshilfe für die Crowd dienen, ob ein Projekt gefällt oder nicht. Bei Büchern finden viele Titel ihr Publikum nach der Veröffentlichung, während des Schreibens ändert der Autor die Handlung, der potentielle Leser könnte im Rahmen der Projektvorstellung den Inhalt bereits kennen lernen und somit den Anlass für die Investition verlieren, da das Ergebnis nichts neues oder überraschendes mehr zu bieten hätte. In der bildenden Kunst kann auch nicht im Voraus für ein Gemälde oder eine Skulptur bezahlt werden, welche dem Künstler gerade mal vor dem inneren Auge vorschwebt. Auch Erstlingswerke werden es mit Crowdfunding schwer haben, etablierte Autoren dagegen leichter.

Im Fall des Kladde-Verlags reichen Autoren wie sonst überall auch Manuskripte ein, die ganz normal geprüft werden (zusätzlich auch auf Crowdfunding-Tauglichkeit). Wenn jemand kein Manuskript hat, keine Anhängerschaft und keine attraktive Idee (letztere ist bekanntlich am allerwenigsten wert), dann besteht doch völlig unabhängig vom Kompensationsmodell generell keine Chance auf die Unterstützung einer Umsetzung, wenn man mal von Auftragsarbeit absieht. Irgend etwas muss der Autor schon von sich aus tun, und wenn das, was er tut, gut ist, kann er auch Unterstützer finden, sei es auf die eine oder andere Weise und unter Berücksichtigung des Wesens des angestrebten Werkes.

Wie beim Gemälde oder der Skulptur, wenn der Maler oder Bildhauer noch nie etwas geschaffen, seine künstlerischen Fähigkeiten unter Beweis gestellt hat, dann wird er auch von niemandem einfach so Geld dafür erhalten. Es wird an kein Finanzierungsmodell jemals der Anspruch gestellt, so etwas leisten zu müssen, also auch an Crowdfunding nicht.

Bei der Kunst geht es aber auch viel um die konkrete Ausgestaltung, um den im Kunstwerk festgehaltenen Ausdruck des Künstlers. Von daher ist es sehr wohl denkbar, die abstrakte Idee in all ihren Details den potentiellen Crowdfunding-Investoren vorzustellen, während gleichzeitig der Wert des Ergebnisses in den vielen Einzelentscheidungen des Künstlers im Rahmen der Umsetzung liegt, welche die Crowd weder abnehmen noch mitbestimmen kann. Für Werke der Unterhaltung trifft dies natürlich weit weniger zu, die Produktion derselben folgt wiederum anderen Regeln, wo die Eignung zum Crowdfunding z.B. durch Mitgestaltung, Serien-Fortsetzungen und gemeinsame Rezeption gegeben ist.

Fazit

Der Crowdfunding-Ansatz ist in der Lage, die Umsetzung frei lizenzierter Projekte erheblich zu vereinfachen und damit die ganz zentralen Nachteile des herkömmlichen Geschäftsmodells auf Basis der restriktiven Rechteverwertung aufzuheben. Wird deshalb die restriktive Rechteverwertung aufgegeben werden? Sicher (noch) nicht. Ist dadurch das Crowdfunding-Modell unbrauchbar? Natürlich ebenfalls nicht. Und sowie diese Alternative in der Praxis unter günstigeren Konditionen für alle Beteiligten mehr und qualitativ bessere Projekte realisieren wird, desto mehr bröckelt die Relevanz des alten Modells. Solange nur beide Optionen zur Auswahl stehen, ist auch ziemlich egal, welche davon mehr in Anspruch genommen wird, da es immer Menschen geben wird, die sich an den ganzheitlich geeigneteren Ansatz halten werden. Dies hängt auch ganz individuell davon ab, ob die eigene Zielsetzung darauf hinausläuft, einen künstlichen Exklusivismus aufbauen und vehement verteidigen zu wollen, oder ob der Wille zum Beitrag für die Gemeinschaft überwiegt. Mag sein, dass ein kooperativer Ansatz für den einen oder anderen nichts ist, für den ist aber auch Digitaltechnologie und das Internet nichts.

GNU AFFERO GENERAL PUBLIC LICENSE

Version 3, 19 November 2007

Copyright © 2007 Free Software Foundation, Inc. <http://fsf.org/>

Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed.

Preamble

The GNU Affero General Public License is a free, copyleft license for software and other kinds of works, specifically designed to ensure cooperation with the community in the case of network server software.

The licenses for most software and other practical works are designed to take away your freedom to share and change the works. By contrast, our General Public Licenses are intended to guarantee your freedom to share and change all versions of a program--to make sure it remains free software for all its users.

When we speak of free software, we are referring to freedom, not price. Our General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software (and charge for them if you wish), that you receive source code or can get it if you want it, that you can change the software or use pieces of it in new free programs, and that you know you can do these things.

Developers that use our General Public Licenses protect your rights with two steps: (1) assert copyright on the software, and (2) offer you this License which gives you legal permission to copy, distribute and/or modify the software.

A secondary benefit of defending all users' freedom is that improvements made in alternate versions of the program, if they receive widespread use, become available for other developers to incorporate. Many developers of free software are heartened and encouraged by the resulting cooperation. However, in the case of software used on network servers, this result may fail to come about. The GNU General Public License permits making a modified version and letting the public access it on a server without ever releasing its source code to the public.

The GNU Affero General Public License is designed specifically to ensure that, in such cases, the modified source code becomes available to the community. It requires the operator of a network server to provide the source code of the modified version running there to the users of that server. Therefore, public use of a modified version, on a publicly accessible server, gives the public access to the source code of the modified version.

An older license, called the Affero General Public License and published by Affero, was designed to accomplish similar goals. This is a different license, not a version of the Affero GPL, but Affero has released a new version of the Affero GPL which permits relicensing under this license.

The precise terms and conditions for copying, distribution and modification follow.

TERMS AND CONDITIONS

How to Apply These Terms to Your New Programs

If you develop a new program, and you want it to be of the greatest possible use to the public, the best way to achieve this is to make it free software which everyone can redistribute and change under these terms.

To do so, attach the following notices to the program. It is safest to attach them to the start of each source file to most effectively state the exclusion of warranty; and each file should have at least the “copyright” line and a pointer to where the full notice is found.

<one line to give the program's name and a brief idea of what it does.> Copyright (C) <year> <name of author>

This program is free software: you can redistribute it and/or modify it under the terms of the GNU Affero General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.

This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Affero General Public License for more details.

You should have received a copy of the GNU Affero General Public License along with this program. If not, see <http://www.gnu.org/licenses/>.

Also add information on how to contact you by electronic and paper mail.

If your software can interact with users remotely through a computer network, you should also make sure that it provides a way for users to get its source. For example, if your program is a web application, its interface could display a “Source” link that leads users to an archive of the code. There are many ways you could offer source, and different solutions will be better for different programs; see section 13 for the specific requirements.

You should also get your employer (if you work as a programmer) or school, if any, to sign a “copyright disclaimer” for the program, if necessary. For more information on this, and how to apply and follow the GNU AGPL, see <http://www.gnu.org/licenses/>.