Gedanken zu einem leistungsfähigen und quelloffenen Redaktionssystem in der technischen Dokumentation

Anlässlich einer Diskussion meine Gedanken zu einem leistungsfähigen und quelloffenen Redaktionssystem in der technischen Dokumentation.

Aus welcher Motivation heraus entstehen “leistungsfähige” Open Source-Projekte? Und für welche Zielgruppe, welchen Markt werden derartige Software-Produkte geschaffen?
Damit meine ich die originäre Zielrichtung, und nicht, für welche Bereiche die Produkte auch “in etwa” geeignet wären. Denn “leistungsfähig” ist für mich ein Produkt, dessen Entwickler die Zielgruppe und deren Anforderungen sehr gut kennen und verstanden haben.

In der technischen Dokumentation gibt es sehr viele unterschiedliche Arten, die aus meiner Sicht Folgendes eint:

  • (Geforderte) Verständlichkeit (zunächst unabhängig vom diskutierten Werkzeug)
  • Standardisierung (abhängig vom Werkzeug)
  • Struktur (abhängig vom Werkzeug)
  • Wiederverwendbarkeit (abhängig vom Werkzeug)
  • Verschiedene Ausgabemedien/-formate (abhängig vom Werkzeug)

Eine landläufig als Content Management System bezeichnete Software, sei es Drupal, Typo 3, oder welche auch immer, ist primär mit dem Ziel HTML/Web-Ausgabe konzipiert. Diese Systeme sind erweiterbar, aber gibt es ernsthafte und brauchbare Ergebnisse für die technische Dokumentation?

Spätestens bei der Wiederverwendung wird es sehr schwer. Selbst viele spezialisierte Systeme schaffen lediglich einfache Konzepte umzusetzen.
Komplexe Produkte aber auch Prozessdokumentationen und auch nicht technische Texte, wie im Marketing, benötigen für einen ausgewogenen wirtschaftlichen Einsatz (Balance des Aufwandes zwischen Erstellung, Pflege und Weiterentwicklung von Inhalten) eine höhere Flexibilität von einer Dokumentationssoftware.

Konzepte, wie DITA, bieten einen strukturellen Ansatz, die die (technischen) Forderungen erfüllen. Auf einem solchen Konzept sollte ein leistungsfähiges und quelloffenes Redaktionssystem aufgebaut sein.

Ein existierendes System, das mit anderen Zielen konzipiert wurde, an diese Forderungen anzupassen, dürfte aufwendiger sein, als ein von Grund auf neues System zu konzipieren. Dabei soll nicht jeder Dialog neu programmiert werden. Nicht ohne Grund setzen Ixiasoft und Instinctools für ihre DITA-Lösungen auf Eclipse und DITA-OT. Leider scheitern auch solche Lösungen oft, da Produkte meist ohne ausreichende Kundennähe (weiter-)entwickelt werden. Damit könnte ich jetzt abschweifen und die agile Produktentwicklung (für Software) diskutieren.

Einen interessanten Ansatz hat einmal die quelloffene Software Daisy CMS verfolgt (Anonymous read-only SVN: http://dev.outerthought.org/svn_public/outerthought_daisy/).

Jetzt bietet Oxygen ein gutes (kommerzielles) Produkt, dass gut individuell in Eclipse mit quelloffener Software erweitert werden kann.

Einen weiteren Aspekt habe ich noch nicht erwähnt: Validität der Verarbeitungsprozesse einer Software. Die ist in den Branchen Automotive und Aviation und damit auch für der Zulieferindustrie verpflichtend.