Crossmediales Publizieren. Das ist toll, denn: „Erst der Inhalt, dann die Kanäle“, so das Kernprinzip, bedeutet weniger Arbeitszeit für mehr Produktausstoß. Also höhere Profitraten dort, wo zu diesem Zweck geschrieben werden muss. Denn die Arbeitenden müssen bei der „Content-Produktion“ nicht nur ein sondern gleich alle möglichen Formate mitdenken. Für sie bedeutet Crossmedialität also Arbeitsverdichtung. Und die Unternehmer (Unternehmenden?) können gleich mehrere Redaktionen zusammenschmeißen und dabei viele zu bezahlende Mitarbeiter_innen loswerden und dennoch Produktion und Warenangebot ausweiten. Denn die Inhalte werden ja jetzt formatunabhängig vorproduziert und dann möglichst automatisch auf die diversen Kanäle multipliziert.
Aber was ist eigentlich schlecht an der Idee, die inhaltliche Arbeit nur einmal zu machen (dafür vielleicht mal zur Abwechslung mit der notwendigen Sorgfalt?!), um dann durch die Publikation möglichst vieler Formate aus einer einzigen Quelle („Single Source Publishing“) eine möglichst große Aufmerksamkeit zu erzielen? Nichts. Die Idee ist gut. Das Problem sind Eigentums- und Produktionsverhältnisse, in denen gute Ideen nur dann zur Umsetzung kommen, wenn sie auch geeignet sind, die Reichen noch reicher zu machen und die Lohnabhängigen noch mehr unter Druck zu setzen.
This said (auch: this sad), kann ich weitermachen mit meinem eigentlichen Anliegen, dem Hinweis auf ein FOSS-Betriebspaket für Single-Source-Publishing. Ein Poster sagt mehr als tausend Worte:
Single-Source-Publishing mit Swapfire (so bezeichnen die AutorInnen ihr Software-Bündel) und OJS nach Axel Dürkop, Isabella Meinecke, Dr. Tim Boxhammer, Florian Hagen, Albert Krewinkel (2020), doi.org/10.15480/882.2902
Das Poster zeigt einen Workflow für Single-Source-Publishing (SSP):
- Artikeltext, Metadaten und Referenzen werden in Open Journal Systems (OJS) eingereicht, begutachtet und
- nach der Annahme mit Pandoc in Markdown konvertiert.
- Der Textkorpus wird manuell bereinigt,
- die Referenzen für die Verwendung der eingereichten BibLaTeX-Datei aufbereitet.
- Metadaten werden mit Decap (früher: Netlify) CMS erfasst,
- HTML, PDF und andere Formate kontinuierlich mit GitLab, Docker und pandoc-scholar produziert.
- Die finalen Dateien werden in OJS hochgeladen und veröffentlicht.
Zentrale Redaktions- und Arbeitsplattform ist OJS. Die Zeitschrift Prokla z.B. bildet ihre Redaktionsarbeit mit OJS ab, so wie weltweit mehr als 25.000 weitere Zeitschriften (Stand: 2021). Und eine Single-Source-Publishing-Community gibt es auch. Und sie hat ernst gemacht: Indem sie sich mit Hilfe von Git organisiert, wendet sie das SSP-Prinzip auf sich selbst als Community an. Git ist eigentlich ein Programm zur kollaborativen Bearbeitung und Verwaltung von Quellcode und wurde „erfunden“ als die Arbeiten am Linux-Systemkern zu unübersichtlich wurden, als dass sie jemand noch mit Händen und Füßen hätte verwalten können. Die SSP-Community hat ihr Wiki, ihr Diskussionsforum und ihre Homepage auf Github, der vielleicht populärsten Git-Plattform, die mittlerweile von Microsoft unterhalten wird. Viele sind daher schon zu alternativen Git-Plattformen gewechselt oder betreiben ihre eigene. Vorbildlich hier die Inititaitve des Codeberg e.V., die ihre Git-Plattform Forgejo nicht nur als FOSS weiterentwickeln, sondern sich selbst und ihre gemeinsame Entwicklungsarbeit als e.V. auch noch gezielt unkapitalistisch verfassen.
