Warum gemeinsame Infrastruktur im gemeinnützigen Journalismus scheitert

Zwanzig Journalistinnen und Journalisten. Neun Redaktionen. Eine gemeinsame Recherche über Ernährungsunsicherheit im ländlichen Amerika. Die Berichterstattung des Rural News Network von INN war beeindruckend. Beim Lesen dieses Berichts über das Zustandekommen der Zusammenarbeit fragte ich mich jedoch ständig, was darin fehlte: Wie sah das technische Setup aus? Wie wurden Artikel zwischen den Publikationen ausgetauscht? Liefen diese neun Redaktionen überhaupt auf kompatiblen Plattformen? Solche Fragen tauchen in keiner Zusammenfassung auf. Und sie werden auch nie im Vorfeld geklärt, genau das ist das Problem.

Das Argument für gemeinsame Infrastruktur unter gemeinnützigen und community-orientierten Medienpartnern liegt auf der Hand. Kleinere Organisationen bündeln Ressourcen, vermeiden doppelte Kosten und erweitern ihre Reichweite, ohne ihr Budget proportional zu belasten. In der Theorie funktioniert das gut. In der Praxis kommen die meisten Versuche, Technologie gemeinsam zu nutzen, innerhalb eines Jahres zum Stillstand oder kommen über erste Gespräche nie hinaus. Ich möchte konkret benennen, warum das so ist, und beschreiben, wie ein Setup aussieht, das wirklich trägt.

Wo "Gemeinsam" Meistens Scheitert

Der erste Schwachpunkt ist das CMS. Die meisten kleinen Redaktionen landen bei WordPress, weil es zugänglich ist und das Ökosystem groß. Das ist in Ordnung. Das Problem ist, dass jede Installation anders angepasst wird: unterschiedliche Themes, unterschiedliche Plugin-Kombinationen, unterschiedliche Permalink-Strukturen, unterschiedliche redaktionelle Abläufe im Backend. Zwei Redaktionen, die technisch gesehen beide WordPress nutzen, betreiben nicht zwangsläufig kompatible Systeme. Das Übertragen von Inhalten erfordert manuelles Nacharbeiten, und Syndizierung wird zu einem eigenen Projekt statt zu einer selbstverständlichen Funktion.

Der zweite Schwachpunkt ist Verantwortung und Governance. Gemeinsame Hosting-Arrangements erfordern jemanden, der den Account verwaltet, Verlängerungen organisiert, Sicherheitsupdates einspielt und Supportanfragen beantwortet. In einem Netzwerk aus Redaktionen, die stark auf Ehrenamtliche angewiesen sind oder personell dünn besetzt sind, wandert diese Verantwortung erfahrungsgemäß zu der Person, die am technischsten versiert ist, wird dann zu einem unbezahlten Zweitjob und fällt schließlich weg, wenn diese Person ausbrennt oder geht. Ohne klare Absprachen darüber, wer wofür verantwortlich ist, wird gemeinsame Infrastruktur zur Belastung.

Der dritte Schwachpunkt ist das Newsletter-Tooling. E-Mail ist oft der Bereich, in dem Kooperationspartner am stärksten füreinander werben wollen. Aber Newsletter-Plattformen sind eng an individuelle Organisationskonten, Abonnentenlisten und Absenderreputation gebunden. Ein gemeinsames Mailchimp-Konto für mehrere Organisationen klingt einfach, bis man merkt, dass es die Markenidentität verwässert, rechtliche Fragen rund um die Einwilligung von Abonnenten aufwirft und es nahezu unmöglich macht, nachzuvollziehen, welche Organisation welches Wachstum antreibt.

Was Wirklich Funktioniert

Gemeinsame Infrastruktur funktioniert am besten, wenn sie thematisch eng gefasst ist und von Anfang an durch schriftliche Vereinbarungen geregelt wird.

Beim Hosting ist ein einziger verwalteter WordPress-Host, der mehrere separate Installationen unter einem Account betreibt, tatsächlich kostengünstig und technisch unkompliziert. Jede Redaktion behält ihre eigene Website, ihr eigenes Theme, ihre eigene Domain. Was geteilt wird, ist der Server, der Backup-Rhythmus und das Sicherheitsmonitoring. Dafür gemeinsam zu zahlen, lohnt sich. Redaktionelle Umgebungen darüber hinaus zusammenzuführen, lohnt sich nicht.

Für den Inhaltsaustausch ist Syndizierung der bessere Weg. Ein schlankes RSS- oder API-basiertes Setup, bei dem eine Redaktion veröffentlicht und Partnerredaktionen freigegebene Inhalte korrekt formatiert und mit Quellenangabe in ihr eigenes CMS ziehen können, ist weit stabiler als der Versuch, Publishing-Umgebungen zu vereinheitlichen. Die redaktionelle Kontrolle bleibt lokal, während die Verbreitung geteilt wird. Das ist etwas, das ich für ein Netzwerk aufbauen und pflegen kann, ohne dass das Redaktionspersonal etwas Neues lernen muss.

Bei Newslettern ist das bessere Modell koordinierte gegenseitige Werbung statt gemeinsamer Tools. Jede Organisation behält ihre eigene Liste und ihr eigenes Plattformkonto. Die Zusammenarbeit besteht aus einem gemeinsamen Redaktionskalender, abgestimmten Werbetexten und vielleicht einer co-gebrandeten Landingpage, die neue Abonnenten erfasst und sie je nach Region oder Sprachpräferenz der passenden Liste zuordnet. Einfacher, klarer, und überlebensfähig auch dann, wenn die Kapazität eines Partners vorübergehend sinkt.

Die Frage, Wer Aufbaut und Pflegt

Hier möchte ich direkt sagen, wie Rainsystems dazu steht. Ein Webstudio, das vorwiegend mit Community-Medien und gemeinnützigen Organisationen arbeitet, ist kein neutraler Infrastrukturanbieter. Der Mehrwert liegt nicht allein im Aufbau des technischen Stacks, sondern im Verständnis dafür, dass zwei Partnerredaktionen, selbst wenn sie benachbarte Communities bedienen, unterschiedliche Zielgruppen, unterschiedliche redaktionelle Identitäten und unterschiedliche Beziehungen zu den Menschen haben, über die sie berichten. Gemeinsame Infrastruktur sollte diese Unterschiede stärken und nicht einebnen.

Die meisten Projekte für gemeinsame Infrastruktur im gemeinnützigen Journalismus scheitern nicht, weil die Technologie falsch ist, sondern weil niemand mit sowohl technischem Können als auch Branchenkenntnissen die Verbindung zwischen beidem pflegt. Die Recherche zu Ernährungsunsicherheit des Rural News Network funktionierte, weil jemand Stakeholder koordinierte, Zeitpläne managte und das Projekt am Laufen hielt. Dasselbe gilt für die technische Seite. Gemeinsame Infrastruktur ohne kontinuierliche Betreuung ist nur aufgeschobener Wartungsstau.

Wenn Ihre Redaktion gerade erste Gespräche über eine Inhaltspartnerschaft oder Netzwerkkooperation führt, ist der richtige Zeitpunkt, über die technische Ebene nachzudenken, bevor der erste gemeinsam gezeichnete Artikel erscheint, nicht danach.