Ohne Software entsteht im Verlag kein Buch mehr. Von der Produktplanung über Manuskriptbearbeitung, Satz, Datenkonvertierung bis hin zur Auslieferung – viele lebenswichtige Prozesse sind heute ohne die Unterstützung von Software nicht mehr denkbar. Dabei machen sich Verlage nicht selten von einzelnen Software-Anbietern abhängig. Open-Source-Software, offene Standards und offene Schnittstellen bieten einen Ausweg.
Während man bei Papier-Engpässen auf einen anderen Papierlieferanten ausweichen kann, ist ein Anbieterwechsel bei Software nicht ohne weiteres möglich. Oftmals fehlt auf dem Markt ein Produkt mit der gleichen Funktionalität. Vielleicht sind die Daten in einem proprietären Dateiformat gespeichert und können nur mit der Anwendung des Herstellers verarbeitet werden. Oder die Kosten eines Umstiegs wären schlicht zu hoch.
Diese Form der Abhängigkeit von einem einzigen Anbieter wird als Vendor-Lock-In bezeichnet. Wer schon mal versucht hat, für seinen Staubsauger einen passenden Beutel zu kaufen, kennt das Prinzip. Unter nüchternen Typenbezeichnungen wie MX 88, Y 101 oder S 67 wartet ein schier undurchdringlicher Dschungel an zueinander inkompatiblen Staubsaugerbeuteln. In der Software-Industrie ist es auch üblich, die Interoperabilität absichtlich einzuschränken. Epische Endbenutzer-Lizenzvereinbarungen, proprietäre Datenformate, herstellerspezifische Standards und nicht-öffentliche Dokumentationen sind probate Mittel. Auf diese Weise wird versucht, einen Wechsel des Kunden zu einem anderen Anbieter unwirtschaftlich zu machen.
Die Risiken eines solchen Vendor-Lock-Ins sind vielfältig. Die Software entwickelt sich zwar weiter, aber nicht in die gewünschte Richtung. Bei InDesign werden etwa im Gegensatz zum XML-basierten IDML-Format die nativen XML-Features seit CS4 von Adobe nicht weiter entwickelt. Noch schwerer wiegt es, wenn der Anbieter Entwicklung und Support ganz einstellt, wie bei Chikriis VBA-Plugin Word2TeX geschehen. Was ein Wechsel des Lizenzmodells bedeutet, ist seit der Einführung der Creative Cloud bekannt. Nachdem neue Versionen ausschließlich über ein Abo bezogen werden konnten, war die Stimmung unter Anwendern ähnlich trüb wie die dunkelgrauen InDesign-Paletten.
Doch wie lassen sich für Verlage solche Abhängigkeiten minimieren? Souveränität lässt sich mit den Worten des Kybernetikers Heinz von Foerster als Anzahl der existierenden Wahlmöglichkeiten beschreiben. Je weniger die Entscheidung durch die Anzahl der Wahlmöglichkeiten determiniert ist, desto mehr Freiheitsgrade bestehen. Souveränes Handeln muss nach Foerster die Anzahl seiner Wahlmöglichkeiten erhöhen. Mehr Wahlmöglichkeiten versprechen Open-Source-Software, offene Standards und offene Schnittstellen.
Open Source
Die Zeiten sind vorbei, als Open-Source-Software noch das Image von Bastelprojekten idealistischer Feierabend-Programmierer anhaftete. Android, Apache HTTP Server, Blender, Chromium, Firefox, Libre Office, MySQL, VLC Media Player und WordPress sind Beispiele für erfolgreiche Open-Source-Projekte, und selbst der frühere Open-Source-Gegner Microsoft wirbt, dass in seiner Azure Cloud auch Linux läuft.
Grundlage des Erfolgs von Open-Source-Software ist frei zugänglicher Quelltext, der dank permissiver Lizenzen wie der GPL oder BSD-Lizenz beliebig oft kopiert, verbreitet und genutzt werden darf. Die Freiheit gegenüber proprietärer Software liegt auf der Hand: Man hat das Recht, die Software notfalls unabhängig vom ursprünglichen Anbieter zu nutzen, zu kopieren und auch weiterentwickeln zu lassen.
Zur typischen Software eines Verlags gehören Schriften. Nachdem Monotype sich Linotype, Bitstream und im letzten Jahr auch FontShop einverleibte, existiert im Markt der Schriftanbieter jedoch nur noch ein großer Player. Infolge der Monopolstellung besteht daher auch bei Schriften das Risiko höherer Lizenzkosten. Für E-Books, Websites und Apps waren die bestehenden Lizenzmodelle für viele Verlage ohnehin nicht mehr wirtschaftlich.
In diesem Bereich haben sich freie Schriften mit SIL Open Font License (OFL) etabliert. Sofern ein Verlag die Schrift nicht als solche verkauft, erlaubt die Lizenz die uneingeschränkte Verwendung in kommerziellen Projekten, ganz gleich ob in gedruckter oder digitaler Form. Unter der Bedingung, dass man nicht den Original-Schriftnamen beibehält, darf man den Zeichensatz verändern oder erweitern lassen. Man kann ruhig mal Monotype fragen, was ein solches Paket kosten würde.
Durch Open-Source-Alternativen ist die Risiko eines Vendor-Lock-Ins bei Schriften noch vergleichsweise gering. Anders sieht es freilich bei WYSIWYG-Satzprogrammen aus. Hier führt kein Weg an InDesign vorbei. Der ewige Konkurrenten Quark ist technologisch abgehängt und auch nicht viel günstiger zu haben. Das freie Satzprogramm Scribus zeigt zwar mit Farbmanagement und PDF-Export-Optionen vielversprechende Ansätze, aber zu einer wirklichen professionellen Alternative reicht es bislang noch nicht. In anderen Segmenten wie z.B. Bürosoftware, Datenbanken, Content-Management-Systemen, sowie Prüf- und Konvertierungs-Tools finden Verlage einfacher professionelle Open-Source-Lösungen.
Dennoch kann auch Open Source Software Abhängigkeiten verursachen, selbst wenn diese geringer ausfällt als bei proprietärer Software. Wenn eine Geschäftsbeziehung in die Brüche geht, kann man zwar jederzeit den Code abzweigen und weiterentwickeln lassen. Doch je komplexer und anspruchsvoller die Software ist, desto schwieriger gestaltet sich die Suche nach geeigneten Kandidaten für die Weiterentwicklung. Für dieses Problem stellen offene Standards einen Schlüssel dar.
Offene Standards
Die Verlagsbranche fußt auf einer Vielzahl von Standards: Die DIN-Formatreihe, ISBN zur eindeutigen Identifikation von Publikationen, ONIX zum Austausch von Metadaten, DOCX zur Textverarbeitung, PDF für Druckvorlagen und nicht zuletzt EPUB für elektronische Bücher.
Diese Standards haben gemein, dass es sich um offene Standards handelt. Non-Profit-Organisationen wie DIN, IDPF und ISO tragen Sorge dafür, dass die Standards öffentlich zugänglich sind. Zwar gibt es auch bei DIN und ISO Lizenzen und Schutzgebühren, allerdings sind diese diskriminierungsfrei, sprich sie sind für alle gleich. Die Weiterentwicklung von offenen Standards geschieht unabhängig von einem einzelnen Anbieter und ist für Dritte offen. Dass ein Format wie PDF ursprünglich als proprietäres Format von Adobe entwickelt wurde, ist kein Widerspruch. Oft werden Formate erst nachträglich einer Normierungsorganisation zur Standardisierung übergeben, weil sich der Hersteller durch eine Freigabe eine weitere Verbreitung erhofft.
Bevor PDF ein offener Standard wurde, galt es in der Verlagsbranche schon als Industriestandard. Adobes Format vereinfachte den Austausch von Druckdaten in einer Weise, dass es schnell Eingang in zahlreiche Software-Anwendungen fand. Im Unterschied zu offenen Standards werden Industriestandards jedoch nicht von unabhängigen Non-Profit-Organisationen, sondern von einzelnen Unternehmen definiert und unterliegen damit noch stärker kommerziellen Interessen. Adobe wollte mit dem PDF auch Segmente jenseits der Druckvorstufe erobern und überfrachtete es dabei mit interaktiven Features wie JavaScript, Adobe Flash und Video. In der Folge löste PDF zwischenzeitlich sogar Word als größten Vektor für Malware ab.
Standards bilden den technologischen Kanon einer Branche. Anders verhält es sich bei herstellerspezifischen Standards. Diese wurden durch einen Hersteller oder ein Konsortium mehrerer Hersteller aufgestellt und sind üblicherweise durch proprietäre Lizenzen geschützt. Spezifikation und Dokumentation sind meistens nicht öffentlich verfügbar bzw. ist der Zugang auf Lizenznehmer beschränkt.
Herstellerspezifische Standards sind jedoch nichts Ungewöhnliches. Jeder Hersteller stellt für eigene Prozesse oder Formate in irgendeiner Form Standards auf. Vielleicht besteht noch kein industrieweit anerkannter Lösungsweg, bestehende Standards haben sich nicht bewährt oder einfach nicht am Markt durchgesetzt. Die Frage ist nur, ob man als Unternehmen einen herstellerspezifischen Standard wählen sollte, wenn für den gleichen Zweck auch offene Standards existieren?
Vor dieser Entscheidung stehen Verlage, wenn sie sich für ein XML-Schema bzw. eine DTD entscheiden müssen. Es gibt drei Möglichkeiten: Der Verlag kann eine verlagseigene DTD entwickeln, eine Dienstleister-DTD auswählen oder sich für eine Standard-DTD entscheiden.
Eine verlagseigene DTD ist ein herstellerspezifischer Standard, nur dass der Verlag selbst der Hersteller ist. Die Entwicklung einer verlagseigenen DTD entsteht meist aus dem Eindruck, dass die eigenen Inhalte sich weder durch Standard- noch durch Dienstleister-DTDs gut abbilden lassen.
Man sollte sich gut überlegen, ob die Entwicklung eines eigenen Schemas auf der grünen Wiese lohnt. Zunächst ist es aufwändig, für alle Inhalte von Grund auf neue XML-Strukturen zu entwickeln. Der Prozess der Definition eines Schemas zieht sich nicht selten über Jahre hin. Oft kristallisieren sich in diesem Prozess Probleme erst spät heraus. So tauchen häufig mit neuen Titeln unerwartete Inhaltselemente auf oder Anforderungen von beteiligten Systemen blieben unberücksichtigt. Zudem ist eine Eigenbau-DTD nicht gerade billig und birgt die Gefahr eines Self-Lock-In. Die Aufwände für Entwicklung und Pflege des Schemas trägt der Verlag allein. Die Kosten steigen auch, beteiligte Systeme und Dienstleister in die eigene Insellösung zu integrieren. Für die Inhalte können keine Bearbeitungswerkzeuge von der Stange verwendet werden, was die Kosten zusätzlich erhöht.
Eine vom Dienstleister entwickelte DTD mag hier als Ausweg erscheinen, schließlich hat er bereits die Kosten für die Entwicklung getragen und sich die Lösung bei seinen Kunden bewährt. Die Risiken eines Vendor-Lock-Ins sind hier aber offensichtlich. Die DTD ist erstmal nur zur Toolchain des Dienstleisters kompatibel. Drittanbieter sind meistens rar, nicht zuletzt wenn der freie Zugang zur DTD durch Lizenzen oder andere Barrieren eingeschränkt ist. Dienstleister-DTDs enthalten aber auch bestimmte Eigenheiten, die sich aus der speziellen Arbeitsweise des Dienstleisters erklären.
Das Hub-Schema von le-tex basiert z.B. auf der Standard-DTD DocBook, jedoch lässt es eine flache Ansammlung von Absätzen und Tabellen zu, und es wurde um das tab-Element für Tabulatoren und CSS-Attribute für Stilinformationen ergänzt. Daher wird das Hub-Schema auch nur als temporäres Zwischenformat für Prüfungen und Konvertierungen verwendet, am Ende erhält der Kunde das Verlags-XML in einer Standard-DTD. Die CSS-Attribute lassen sich dank XML-Namespace mit einem einzeiligen Template entfernen.
Dienstleister-DTDs enthalten bestimmte Elemente nur aus prozesstaktischen Gründen, die sich für den Hersteller als günstig erwiesen haben. Ist die Zahl der Stufen eines Registereintrags wie bei InDesign auf vier beschränkt? Werden Inhalte, die das Schema nicht abbildet, einfach in Pseudo-Elemente gepackt? Oder sieht das Schema Anweisungen für einen speziellen Satzautomaten vor? Eine Dienstleister-DTD kann ihre Herkunft nicht verbergen.
Offene Standards wie DocBook, JATS/BITS und TEI sind hingegen allgemeingültig und herstellerunabhängig. Aufgrund ihrer weltweiten Verbreitung profitiert man von Netzwerkeffekten. Für TEI existiert bereits eine Reihe von Tools und man kann sich bestehende Erfahrungen und Best Practices von anderen Nutzern zu Eigen machen. Dieser Ansicht schließt sich auch die Deutsche Forschungsgemeinschaft zum Thema Digitalisierung an:
„Wenn nicht triftige Gründe dagegen sprechen, müssen Volltexte von Drucken und Handschriften nach dem Modell der Text Encoding Initiative (TEI) kodiert bzw. mit Markup versehen werden. Als transparentes XML-Format ist TEI, sofern sorgfältig dokumentiert, auch für die Langzeitarchivierung die prospektiv beste Wahl.“*
Offene APIs
Die Softwareausstattung eines Verlags erschöpft sich heute nicht mehr in ein paar DTP- und Office-Lizenzen. Hinzu gekommen sind Systeme für Content-Management, Customer Relationship Management, Metadatenverwaltung, Production Tracking usw. Verlage sollten daher schon im eigenen Interesse darauf achten, dass eine Software auch offen in Bezug auf ihre Schnittstellen ist. Eine wesentliche Aufgabe bei der Einführung neuer Software ist es, diese in die bestehende Systemlandschaft zu integrieren. Bestimmte Funktionen einer Software können in Form einer Programmierschnittstelle anderen Programmen zur Verfügung gestellt werden. Dafür hat sich der englische Begriff Application Programming Interface, kurz API etabliert. Je mehr Funktionen die API bietet und je besser diese dokumentiert sind, desto leichter fällt es Entwicklern die Software mit anderen Systemen zu verknüpfen. Zudem können Drittanbieter die API nutzen um Plugins zu schreiben, welche neue Funktionen hinzufügen.
Im Gegensatz zu offenen APIs setzt der Zugang von proprietären APIs eine Lizenz vom Anbieter voraus. Auf diese Weise kann der Anbieter den Kreis möglicher Drittanbieter klein halten und an deren Entwicklungen noch mitverdienen. Benötigt ein Verlag neue Features, ist also sichergestellt, dass der erste Weg immer über den Software-Anbieter geht.
Dabei ist es kein Geheimnis, dass eine Software mit einer offenen API attraktiver für Drittanbieter ist und viel Software von Drittanbietern mithin wiederum den Nutzen der Software steigert. Ein Beispiel für diesen Netzwerk-Effekt ist die Blogging-Plattform WordPress. Der Erfolg von WordPress gründet sich nicht darauf, dass es im Vergleich zu anderen Blogging-Systemen mehr Funktionen geboten hätte, sondern auf sein reiches Ökosystem an Plugins. Die Grundlage schuf der sogenannte WordPress Codex, eine gut dokumentierte, offene API mit der man auf fast alle Funktionen des Systems zugreifen konnte.
Je weniger eine Software isoliert funktioniert, desto nützlicher erweist sich eine offene API. Sie senkt die Barriere für das Schreiben von Plugins und erleichtert die Integration in die bestehende Systemlandschaft.
Wie Print und E-Book können offene APIs auch ein Distributionskanal sein. Das Nachrichtenportal The Guardian stellt seinen Content über eine offene API zur Verfügung. Damit kann der Content von Drittanbietern in deren Webseiten, Apps oder Widgets verwendet werden. Auf diese Weise erreicht man eine größere Zielgruppe und stärkt auf Umwegen die eigene Marke. Zudem kann man von der Entwicklung neuer Ideen profitieren und diese für die eigene Plattform adaptieren. Nicht zuletzt lässt sich eine offene API selbst monetarisieren. So kann man für zahlende Nutzer unbegrenzte Zugriffe zulassen oder zusätzlichen Premium-Content ausliefern.
Verlage können mit offener Software nicht nur von Netzwerkeffekten profitieren und ein Vendor-Lock-In vermeiden. Die Paradigmen offener Software – Transparenz, Kooperation und freier Zugriff auf Information – haben nicht nur wesentlich zur Entwicklung des World Wide Webs beigetragen, sondern auch die Verlagsbranche beeinflusst. Open Access ist inzwischen bei Wissenschaftsverlagen ein selbstverständliches Geschäftsmodell. Verlage kooperieren im Rahmen des IDPF bei der Weiterentwicklung des EPUB-Standards und offene APIs sind ein wichtiger neuer Distributionskanal. Wer mehr Openness wagt hat nicht viel zu verlieren – außer ein paar Abhängigkeiten.