Technologie · Journalismus · ProdukteDas Projektarchiv · 1999–2026

Aus Code werden Geschichten.

Ich habe Webseiten entwickelt, als das Internet noch Neuland war. Publishing-Plattformen modernisiert, Geschäftsmodelle erfunden und mit Deep Learning experimentiert, lange bevor KI zum Hype wurde. Aus Code wurden Projekte, aus Ideen Produkte. Heute bringe ich Technik, Journalismus und Geschäft zusammen. Ich weiß, wie Entwickler, Redakteure, Vermarkter, Strategen und Juristen ticken. Und vor allem, wie man sie dazu bringt, gemeinsam etwas auf die Beine zu stellen.

Die Geschichten dahinter.

Projekte, Produkte, Ideen – von heute bis 1999

2026 · FUNKE Digital GmbH

Eine Nachricht beantwortet die klassischen journalistischen W-Fragen. Was ist passiert? Wer ist beteiligt? Wann und wo? Doch für Leser beginnt das Interesse häufig erst danach.

Welche Folgen hat die Entscheidung? Wen betrifft sie? Was ändert sich konkret? Und welche Konsequenzen ergeben sich daraus?

Genau hier setzt der AI-Mentor an: ein direkt in das Redaktionssystem integrierter KI-Assistent, der Artikel aus der Perspektive ihrer Leser betrachtet und mögliche Informationslücken aufzeigt.

Den AI-Mentor habe ich von der ersten Idee bis zum produktiven Einsatz selbst entwickelt. Ich konzipierte den zweistufigen Ablauf, implementierte die Funktionen direkt im CMS und übernahm auch die Einführung in den Redaktionsalltag.

Dabei war mir wichtig, dass die KI nicht eigenständig journalistische Entscheidungen trifft, sondern Redakteure dabei unterstützt, ihre Artikel aus der Perspektive der Leser zu betrachten.

Erst die Fragen, dann die Antworten

Der AI-Mentor folgt einem zweistufigen Verfahren. Im ersten Schritt analysiert die KI den vorhandenen Artikel und entwickelt Fragen, die Leser nach der Lektüre noch haben könnten.

Die Redaktion entscheidet anschließend, welche Fragen relevant sind und welche zusätzlichen Informationen den Artikel tatsächlich verbessern würden.

Erst im zweiten Schritt formuliert die KI auf Wunsch passende Textvorschläge. Die Redakteure können diese prüfen, bearbeiten und in den Artikel übernehmen.

Damit bleibt die journalistische Entscheidung beim Menschen. Die KI liefert Anregungen, keine verbindlichen Vorgaben.

Ein zweites Augenpaar

Besonders für Volontäre kann der AI-Mentor eine zusätzliche Perspektive bieten. Er macht auf fehlende Erklärungen, vorausgesetztes Hintergrundwissen oder unbeantwortete Leserfragen aufmerksam.

Der Assistent ersetzt weder erfahrene Kollegen noch redaktionelles Feedback. Er ergänzt die tägliche Arbeit um ein zweites Augenpaar, das den Text konsequent aus Lesersicht betrachtet.

Ein weiteres Einsatzgebiet sind bestehende SEO-Evergreen-Artikel. Statt ausschließlich neue Inhalte zu produzieren, können Redaktionen vorhandene Beiträge gezielt ausbauen und ihren Nutzwert erhöhen.

Ein Werkzeug, kein zusätzlicher Arbeitsschritt

Der AI-Mentor ist vollständig in das CMS integriert. Redakteure müssen keine Texte in externe Chatbots kopieren, zwischen Anwendungen wechseln oder KI-Ergebnisse umständlich zurückübertragen.

Die Benutzeroberfläche bleibt bewusst zurückhaltend. Der Assistent unterstützt die redaktionelle Arbeit, ohne sich in den Vordergrund zu drängen oder den gewohnten Arbeitsablauf zu unterbrechen.

Auch die Herkunft der Texte bleibt nachvollziehbar: Ursprüngliche KI-Vorschläge und spätere redaktionelle Änderungen werden getrennt erfasst. Das ermöglicht Qualitätssicherung, die Weiterentwicklung der Prompts und eine Bewertung des menschlichen Bearbeitungsanteils.

Mehr Journalismus statt mehr Text

Der AI-Mentor soll Artikel nicht einfach länger machen. Entscheidend ist, ob zusätzliche Informationen den Lesern tatsächlich helfen.

Eine kurze Nachricht kann vollkommen ausreichen. Bei anderen Themen entsteht der eigentliche Nutzwert erst durch die Einordnung von Folgen, Hintergründen und Konsequenzen.

Der AI-Mentor unterstützt Redaktionen dabei, diesen Unterschied zu erkennen.

Denn die wichtigste Frage nach einem fertigen Artikel lautet nicht, ob noch mehr Text möglich wäre. Sondern ob der Leser jetzt wirklich besser informiert ist.

Golem.de · 2013–2014 · Produkte & Geschäftsmodelle

Heute begegnet das PUR-Modell vielen Internetnutzern als Alternative zur Einwilligung in Werbetracking. Seine Geschichte begann jedoch Jahre vor der Datenschutz-Grundverordnung. Und mit einer ganz anderen Frage: Wie kann ein unabhängiges Onlinemedium Geld verdienen, wenn immer mehr Leser Werbung blockieren?

Für Golem.de wurde diese Frage Anfang der 2010er-Jahre zunehmend dringlich.

Als das Werbegeschäft unter Druck geriet

2012 war für digitale Medien ein schwieriges Jahr. Große Werbekunden reduzierten ihre Buchungen, während leistungsfähigere Adblocker die Einnahmen zusätzlich belasteten.

Bei Golem.de reagierten wir mit verschiedenen Ansätzen: Wir erklärten unseren Lesern, wie sich journalistische Angebote finanzieren, arbeiteten an besseren Werbeformaten und suchten nach alternativen Erlösquellen.

Eine Paywall war damals keineswegs die naheliegende Lösung. Kostenpflichtige Zugänge zu journalistischen Onlineinhalten waren im deutschsprachigen Markt noch selten. Für ein vergleichsweise kleines, rein digitales Medienunternehmen erschien uns das wirtschaftliche Risiko zu hoch.

Leser, die freiwillig bezahlen

Einen wichtigen Hinweis lieferte unser früheres Projekt Spenden-Button. Bereits 2010 hatten wir den Spendenservice Flattr auf Golem.de integriert. Die Einnahmen blieben überschaubar, entwickelten sich aber kontinuierlich.

Bemerkenswert war weniger die Höhe der Beträge als das Verhalten dahinter: Leser waren bereit, für unser journalistisches Angebot Geld auszugeben, obwohl sie dafür keine zusätzlichen Leistungen erhielten.

Auch in der Kommunikation mit unserer Community tauchte ein Wunsch immer wieder auf: Golem.de ohne Werbung nutzen zu können.

Aus diesen Beobachtungen entstand die Idee, ein kostenpflichtiges Angebot zu entwickeln, das nicht zusätzliche Inhalte freischaltet, sondern störende Elemente entfernt.

Ein Abo ohne Vorbild

Im Frühjahr 2013 begannen wir mit der konkreten Umsetzung. Für unser Team war nahezu jeder Schritt Neuland.

Wir hatten keine klassische Abonnementabteilung, kaum Erfahrung mit direkten Endkundenbeziehungen und keine fertige technische Lösung für digitale Abonnements. Unser Vorteil: Wir mussten keine Rücksicht auf bestehende Verlagsstrukturen nehmen.

Neben der eigentlichen Softwareentwicklung mussten wir Fragen klären, die für traditionelle Verlage längst zum Alltag gehörten: Vertragsgestaltung, Mehrwertsteuer, Rechnungsstellung, Kündigungsfristen, Kundenservice und Zahlungsabwicklung.

Auch bei der Preisgestaltung fehlten uns etablierte Vergleichsmodelle. Gerade die technische Zahlungsabwicklung erwies sich als aufwendig. Wer heute nur moderne Zahlungsdienste wie Stripe kennt, kann sich kaum vorstellen, wie kompliziert deren Integration damals noch war.

Wie verkauft sich ein Produkt, das etwas weglässt?

Selbst die Namensfindung stellte uns vor eine ungewöhnliche Herausforderung.

Ein klassisches Premiumangebot verspricht zusätzliche Funktionen oder exklusive Inhalte. Unser neues Modell sollte dagegen etwas entfernen: Werbung.

Namen wie „Club“ oder „Plus“ standen zur Diskussion. Schließlich fiel die Wahl auf „PUR“.

Der Name gefiel uns besonders, weil er ein schwieriges Kommunikationsproblem löste: Wie beschreibt ein Unternehmen den Mehrwert eines Produkts, das seinen Nutzern etwas wegnimmt?

PUR brachte diese Idee auf den Punkt. Das journalistische Angebot in seiner puren Form.

Startklar im Mai, veröffentlicht im August

Rund ein Jahr nach dem Projektbeginn war die technische Umsetzung abgeschlossen. Im Mai 2014 konnte ich als Projektmanager intern verkünden: PUR ist einsatzbereit.

Die öffentliche Einführung folgte im August 2014. Ausschlaggebend für den späteren Termin waren vor allem Marketingüberlegungen und interne Veränderungen.

Die Leser nahmen das Angebot unmittelbar an. Auch andere deutschsprachige Verlage zeigten früh Interesse an unserem Modell.

Welche Bedeutung PUR später für die Medienbranche bekommen würde, konnten wir damals allerdings nicht absehen.

Eine Lösung, die größer wurde als ihr ursprüngliches Problem

Mit der zunehmenden Bedeutung von Datenschutz und Tracking-Einwilligungen erhielt das PUR-Modell Jahre später einen neuen Kontext.

Ursprünglich hatten wir es jedoch weder als Datenschutzinstrument noch als Antwort auf regulatorische Anforderungen entwickelt.

PUR entstand aus einer konkreten wirtschaftlichen Herausforderung, aus dem Feedback unserer Leser und aus der Bereitschaft unseres Teams, ein Geschäftsmodell ohne etablierte Vorlage zu entwickeln.

Auf meine Rolle als Mit-Erfinder dieses Modells bin ich bis heute besonders stolz.

Aus dem Wunsch nach einem werbefreien Golem.de wurde eine Idee, die weit über Golem.de hinaus Wirkung entfaltete.

Mehr zur Einführung von Golem PUR bei Golem.de

2021–2022 · Golem.de

Eine Paywall einzuführen, klingt zunächst einfach: Bestimmte Artikel sind nur noch für zahlende Abonnenten zugänglich.

In einem gewachsenen Nachrichtenportal ist die Sache allerdings komplizierter. Schließlich existieren bereits Nutzerkonten, Abonnements, redaktionelle Abläufe und ein Content-Management-System. All das muss mit dem neuen Angebot zusammenspielen.

Bei Golem.de kam eine Besonderheit hinzu: Mit PUR gab es bereits ein Abonnement für werbefreies Lesen. Das neue Angebot sollte einen anderen Zweck erfüllen.

Nicht weniger Werbung, sondern mehr Journalismus

Während PUR den Zugang zu den regulären Inhalten ohne Werbung ermöglichte, sollte Golem Plus zusätzliche journalistische Angebote finanzieren.

Dazu gehörten ausführliche Hintergrundberichte, praxisnahe Fachartikel und spezialisierte Themen für Leser, die sich beruflich mit IT beschäftigten.

Die bestehenden frei zugänglichen Nachrichten sollten weiterhin kostenlos lesbar bleiben.

Für die technische Umsetzung bedeutete das: Zwei unterschiedliche Abonnementmodelle mussten nebeneinander funktionieren, ohne die bestehende Nutzerverwaltung unnötig zu verkomplizieren.

Nicht alles selbst entwickeln

Bei der Auswahl der technischen Grundlage spielte neben dem Funktionsumfang vor allem die Wirtschaftlichkeit eine Rolle. Praktisch alle geprüften kommerziellen Lösungen schieden aufgrund ihrer Lizenzkosten aus.

Unsere Wahl fiel deshalb auf REMP, eine Open-Source-Plattform mit Werkzeugen zur Leserbindung und Monetarisierung.

Damit mussten wir nicht sämtliche Funktionen einer Paywall-Plattform selbst entwickeln. Allerdings löste die Entscheidung für eine bestehende Software noch nicht die Frage, wie sie sich in unsere Infrastruktur integrieren ließ.

Das Setup der REMP-Plattform übernahm ein externer Dienstleister, dessen Arbeit ich technisch steuerte und koordinierte.

Die Anbindung an Golem.de und unsere bestehende Account-Plattform Mein Golem setzte ich selbst um.

Wenn aus mehreren Systemen ein Produkt wird

Die eigentliche Integrationsarbeit bestand darin, das neue Angebot mit den vorhandenen Strukturen zu verbinden.

Das CMS musste berücksichtigen, welche Artikel zum Plus-Angebot gehörten. Die Website musste zwischen frei zugänglichen und kostenpflichtigen Inhalten unterscheiden. Und die bestehende Nutzerverwaltung musste mit der neuen Abonnementplattform zusammenspielen.

Für die Leser sollte daraus ein möglichst einheitliches Angebot entstehen. Welche Systeme im Hintergrund beteiligt waren, durfte für die Nutzung keine Rolle spielen.

Gerade bei solchen Projekten liegt ein erheblicher Teil der Arbeit an den Übergängen zwischen den Komponenten.

Ein neues Geschäftsmodell auf bestehender Grundlage

Im Juli 2022 startete Golem Plus.

Damit ergänzte Golem.de sein bestehendes Geschäftsmodell um ein kostenpflichtiges journalistisches Angebot, ohne die frei zugängliche Berichterstattung hinter eine allgemeine Bezahlschranke zu verschieben.

Für mich war das Projekt auch eine Weiterentwicklung früherer Arbeiten: Mit PUR und Mein Golem hatten wir bereits wesentliche Grundlagen für nutzerbezogene Angebote geschaffen. Nun kam eine zusätzliche Plattform hinzu, die mit diesen Strukturen zusammenarbeiten musste.

Eine Paywall ist schnell beschrieben. Die eigentliche Produktentwicklung beginnt dort, wo Bezahlsystem, Nutzerverwaltung und redaktioneller Alltag zuverlässig zusammenfinden.

Originalartikel: Golem.de startet Plus-Angebot ↗

REMP auf GitHub ↗

2023–2026 · FUNKE Digital

2023 holte ich mir privat eine Lizenz für GitHub Copilot. Ich wollte ausprobieren, ob KI tatsächlich beim Programmieren helfen konnte.

Das Ergebnis war zunächst eher ernüchternd. Copilot fühlte sich vor allem wie eine glorifizierte Autovervollständigung an. Gelegentlich hilfreich, aber weit entfernt von einem Werkzeug, das größere Entwicklungsaufgaben eigenständig bewältigen konnte.

Trotzdem empfahl ich meinen Kollegen, die Technologie unbedingt selbst auszuprobieren. Denn auch wenn die Möglichkeiten noch begrenzt waren, zeichnete sich bereits ab, dass sich hier etwas grundlegend verändern könnte.

2024: Mehr als Autovervollständigung

Im Laufe des Jahres 2024 etablierte sich die KI-Unterstützung langsam in unserem Entwicklungsteam.

Erstmals gelangen Versuche, größere zusammenhängende Codeabschnitte generieren zu lassen. Gleichzeitig wurden die Grenzen der damaligen Modelle deutlich: Ergebnisse mussten intensiv geprüft, korrigiert und häufig überarbeitet werden.

Die Erfahrungen waren trotzdem wertvoll. Wir lernten, welche Aufgaben sich für KI eigneten, wie Anforderungen formuliert werden mussten und wann klassische Entwicklungsarbeit schneller zum Ziel führte.

KI sollte nicht nur beim Programmieren helfen

Parallel zur Einführung von KI-Werkzeugen in der Softwareentwicklung beschäftigte ich mich ab 2024 mit einer anderen Frage: Wie könnten wir generative KI direkt in unsere redaktionellen Arbeitsabläufe integrieren?

Dabei ging es nicht darum, möglichst viele Texte automatisch erzeugen zu lassen. Mich interessierte vor allem, wie KI Redakteure bei ihrer eigentlichen Arbeit unterstützen könnte, ohne zusätzliche Bedienungsschritte oder neue Medienbrüche zu schaffen.

Aus diesen Überlegungen entwickelte sich unter anderem das Konzept des KI-Mentors, der Artikel aus Leserperspektive betrachtet, Informationslücken identifiziert und ergänzende Inhalte vorschlägt.

2025 musste ich die weitere Betreuung dieses Themenbereichs an einen Kollegen übergeben, um mich auf die anstehende Migration unserer Videoplattform zu konzentrieren.

Damit liefen zwei Entwicklungen parallel: KI veränderte die Werkzeuge der Softwareentwickler und eröffnete zugleich neue Möglichkeiten für die Produkte, die wir entwickelten.

2025: Aus dem Experiment wird der Standard

Mit leistungsfähigeren Sprachmodellen ließen sich zunehmend Aufgaben bewältigen, an denen wir zuvor gescheitert waren.

KI-gestützte Codegenerierung wurde zum festen Bestandteil unserer Entwicklungsarbeit.

Die Auswirkungen waren erheblich. Nicht nur einzelne Aufgaben ließen sich schneller erledigen. Auch die Qualität des Codes profitierte, weil KI half, Schwachstellen zu erkennen, bestehende Lösungen zu verbessern und konsistentere Implementierungen zu entwickeln.

Aus den praktischen Erfahrungen des Teams entstanden gemeinsame Standards für den KI-Einsatz. Wir verglichen regelmäßig unterschiedliche Modelle und prüften, welche Werkzeuge für welche Aufgaben die besten Ergebnisse lieferten.

Was 2023 als privates Experiment begonnen hatte, war inzwischen ein wesentlicher Bestandteil unserer Softwareentwicklung geworden.

Plötzlich war nicht mehr das Programmieren der Engpass

Die höhere Entwicklungsgeschwindigkeit brachte allerdings neue Probleme mit sich.

Solange das Schreiben von Code einen großen Teil der Zeit beanspruchte, waren viele Abstimmungsprozesse darauf eingestellt. Mit KI konnten Funktionen plötzlich schneller entstehen, als Anforderungen geklärt, Ergebnisse geprüft oder Änderungen an andere Beteiligte kommuniziert werden konnten.

Der Flaschenhals hatte sich verschoben.

Nicht mehr die eigentliche Implementierung bestimmte zwangsläufig das Tempo, sondern die Stellen im Entwicklungsprozess, an denen Menschen eingreifen mussten.

Das führte auch zu einer unerwarteten Herausforderung: Neue Funktionen waren teilweise bereits umgesetzt und ausgerollt, bevor alle Beteiligten überhaupt ausreichend über sie informiert waren.

Die Entwicklungsgeschwindigkeit hatte damit nicht nur technische Engpässe verschoben, sondern auch neue Anforderungen an Abstimmung, Kommunikation und Produktmanagement geschaffen.

2026: Vom KI-Assistenten zum Agentic Workflow

Die nächste Frage lautete nicht mehr, wie wir noch schneller Code generieren konnten. Wir mussten den gesamten Entwicklungsprozess betrachten.

Ich hatte früh dafür plädiert, Agentic Workflows aufzubauen: Entwicklungsabläufe, bei denen KI nicht nur einzelne Codeabschnitte erzeugt, sondern zusammenhängende Aufgaben weitgehend eigenständig bearbeitet.

Die Idee war allerdings leichter formuliert als umgesetzt. Uns fehlten zunächst einige technische Voraussetzungen und praktische Erfahrungen, um daraus einen verlässlichen Workflow zu machen.

Den entscheidenden Schritt leisteten schließlich zwei engagierte Entwickler aus unserem Team. Sie schufen die technische Grundlage und brachten die ersten funktionierenden Abläufe auf den Weg.

Meine Rolle verlagerte sich in dieser Phase vor allem auf das Testen und die Produktperspektive.

Mich interessierte insbesondere, ob sich solche Workflows auch für Product Owner nutzen ließen, die nicht selbst tief in der Softwareentwicklung stecken. Welche Anforderungen mussten sie verstehen? Wie konnten sie Aufgaben formulieren? Und an welchen Stellen brauchten sie weiterhin Unterstützung durch Entwickler?

Bis Oktober 2026 hatten wir mehrere Projekte erfolgreich mit Agentic Workflows umgesetzt.

Die nächste Herausforderung liegt außerhalb des Codes

Rückblickend war die Einführung von KI keine einmalige technische Entscheidung, sondern ein mehrjähriger Lernprozess.

Aus ersten privaten Experimenten entstanden gemeinsame Entwicklungsstandards, neue Möglichkeiten für redaktionelle Produkte und schließlich Veränderungen an der Organisation der Softwareentwicklung selbst.

Dabei wurde auch deutlich, dass neue Werkzeuge allein nicht ausreichen. Teams müssen Erfahrungen sammeln, Arbeitsweisen verändern und immer wieder neu entscheiden, welche Aufgaben Menschen übernehmen und welche sie der KI anvertrauen.

Wenn Software schneller entsteht, muss sich auch die Art verändern, wie Menschen Anforderungen formulieren, Entscheidungen treffen und zusammenarbeiten.

2016–2017 · Golem.de · Journalismus & Wissen · Innovation

„Mach doch mal das Fenster zu! Ich erfriere!“ – „Dann zieh dir doch mehr als ein T-Shirt an!“

Über die richtige Bürotemperatur lässt sich wunderbar streiten. Aber wie warm ist es eigentlich tatsächlich in deutschen Büros?

2016 machten wir bei Golem.de daraus ein Mitmachprojekt. Unsere Leser sollten die Temperaturen an ihren Arbeitsplätzen messen und uns die Daten zur Verfügung stellen.

Für mich war das zugleich eine Gelegenheit, etwas Neues auszuprobieren. Ich wollte mich intensiver mit Datenjournalismus beschäftigen, die einschlägigen Werkzeuge kennenlernen und eigene Erfahrungen mit der Erhebung, Verarbeitung und Visualisierung größerer Datenmengen sammeln.

Aus einer Alltagsfrage wird ein Mitmachprojekt

Statt Leser nach ihrer bevorzugten Bürotemperatur zu fragen, wollten wir wissen, welche Temperaturen tatsächlich herrschten.

Dafür konnten Interessierte eigene kleine Messstationen bauen, die regelmäßig Temperaturwerte an Golem.de übermittelten. Die notwendigen Anleitungen und Programme stellten wir bereit.

Das Projekt verband eine journalistische Fragestellung mit der Experimentierfreude unserer technikaffinen Leserschaft.

Und es hatte einen besonderen Reiz: Wir wussten vorher nicht, welche Ergebnisse uns erwarten würden.

8,5 Millionen Antworten

Über einen Zeitraum von rund einem Jahr sammelten wir etwa 8,5 Millionen Messwerte aus elf Ländern.

Aus den Daten ließen sich Temperaturverläufe, regionale Unterschiede und typische Schwankungen im Tagesverlauf untersuchen. Wir verglichen unsere Ergebnisse auch mit Wetterdaten und stellten sie in zahlreichen Diagrammen dar.

Dabei zeigte sich eine grundlegende Herausforderung des Datenjournalismus: Eine große Datenmenge bedeutet nicht automatisch, dass sich daraus jede beliebige Frage zuverlässig beantworten lässt.

Nicht alle Messwerte waren plausibel. Die Teilnehmer waren regional sehr unterschiedlich verteilt. Und ohne verpflichtende Registrierung ließ sich nicht einmal die genaue Anzahl der beteiligten Messstationen zweifelsfrei bestimmen.

Die Auswertung musste solche Einschränkungen berücksichtigen.

Die Werkzeuge waren Teil des Experiments

Mich interessierte nicht nur, welche Temperaturen wir messen würden, sondern auch, wie sich der gesamte Prozess möglichst effizient gestalten ließ.

Von der Bereinigung der Rohdaten über die statistische Auswertung bis zur Visualisierung wollten wir möglichst viele Schritte automatisieren.

Am Ende gelang uns das weitgehend. Auch spätere Auswertungen ließen sich dadurch mit überschaubarem Aufwand erstellen.

Für mich war das eine wichtige praktische Erfahrung: Datenjournalismus besteht nicht nur aus interessanten Diagrammen. Die eigentliche Arbeit beginnt lange vorher, bei der Qualität der Daten und der Frage, welche Aussagen sie überhaupt zulassen.

Und dann kam HTTPS

Eine unerwartete Lektion lieferte uns ausgerechnet die eigene Website.

Die Umstellung von Golem.de auf HTTPS brachte Probleme für die Datenübertragung unserer Messstationen mit sich. Was als journalistisches Experiment begonnen hatte, wurde zwischendurch auch zu einer Lehrstunde darüber, wie technische Veränderungen bestehende Projekte beeinflussen können.

Im August 2017 veröffentlichten wir schließlich unsere abschließende Auswertung. Die Rohdaten und den Auswertungscode stellten wir ebenfalls öffentlich bereit.

Nicht jede Antwort ist wichtiger als der Weg dorthin

Das Projekt lieferte interessante Einblicke in die Temperaturen unserer Arbeitsplätze. Für mich lag der größere Gewinn allerdings woanders.

Ich hatte Gelegenheit, Datenjournalismus praktisch auszuprobieren: eine Frage formulieren, Leser an der Datensammlung beteiligen, Millionen Messwerte verarbeiten, Ergebnisse kritisch hinterfragen und verständlich präsentieren.

Und ich hatte gelernt, dass sich selbst hinter einer scheinbar banalen Frage eine ziemlich anspruchsvolle Recherche verbergen kann.

Datenjournalismus beginnt mit Neugier. Ob aus den gesammelten Zahlen tatsächlich Erkenntnisse werden, entscheidet sich erst bei der Auswertung.

Projektstart: Wie warm ist es in euren Büros?

Abschlussbericht: HTTPS vermiest uns den Wetterbericht

2025–2026 · FUNKE Digital

Mit Kaltura waren wir technisch in einer Sackgasse angekommen. Die Wunschliste für neue Videofunktionen wurde immer länger. Gleichzeitig kämpften wir gemeinsam mit der Videoabteilung darum, die vorhandene Plattform überhaupt stabil zu betreiben.

Neue Funktionen waren unter diesen Bedingungen kaum noch realistisch. Wir brauchten eine andere Lösung.

Erst testen, dann entscheiden

Anfang des vierten Quartals 2025 fiel die Entscheidung, mehrere externe Videodienstleister systematisch zu evaluieren.

Präsentationen, Funktionslisten und Anbieterinformationen gab es reichlich. Entscheidend war aber, wie sich die verschiedenen Lösungen unter realen Bedingungen bewährten.

Deshalb ergänzten wir die klassische Anbieterauswahl um mehrmonatige A/B-Tests. Ich verantwortete deren technische Durchführung und die dafür notwendigen Integrationen in unsere bestehenden Angebote.

Im Frühjahr 2026 fiel die Entscheidung für TargetVideo.

30.000 Videos ziehen um

Mit der Auswahl des neuen Anbieters begann die eigentliche Migration.

Die Videoabteilung kümmerte sich um den Transfer von mehr als 30.000 bestehenden Videos. Parallel dazu begann ich, TargetVideo in unser CMS zu integrieren und die bisherigen Datenverweise von Kaltura auf den neuen Dienst umzustellen.

Denn mit dem Austausch der Videoplattform allein war es nicht getan. Die bestehenden Artikel mussten weiterhin die richtigen Videos anzeigen, die redaktionellen Arbeitsabläufe mussten funktionieren und die Portale auf den neuen Dienst umgestellt werden.

Die Aufgaben liefen parallel und mussten bei der Umschaltung zusammenpassen.

Drei Monate Entwicklung für 14 Portale

Im Juni 2026 begann die technische Umsetzung der neuen Integration.

Die eigentliche Entwicklungsphase dauerte rund drei Monate. Zwischen September und Oktober stellten wir sämtliche 14 Portale schrittweise auf TargetVideo um.

Bei der Entwicklung ging es nicht nur darum, die bestehende Videoplattform zu ersetzen. Wir wollten zugleich eine technische Grundlage schaffen, auf der sich zusätzliche Funktionen entwickeln ließen.

Einige dieser Möglichkeiten konnten wir bereits während der Migration umsetzen.

KI als Teil der Entwicklungsarbeit

Eine Besonderheit war der umfangreiche Einsatz generativer KI in der Softwareentwicklung.

Die TargetVideo-Integration war unser erstes größeres Projekt, bei dem wir einen wesentlichen Teil der Entwicklungsarbeit KI-gestützt umsetzten.

Das veränderte die Arbeitsweise im Projekt. Architekturentscheidungen, technische Anforderungen, die Koordination der Umsetzung und die Qualitätssicherung blieben zentrale Aufgaben des Entwicklungsteams. KI unterstützte vor allem bei der konkreten Implementierung.

Damit konnten wir innerhalb der dreimonatigen Entwicklungsphase nicht nur die notwendigen Integrationen realisieren, sondern auch die Grundlage für weitere Funktionen schaffen und erste Erweiterungen umsetzen.

Mehr über diese Entwicklung im Artikel Wenn der Code schneller entsteht als die Abstimmung.

Nicht nur ersetzen, sondern weiterkommen

Mit der Umstellung auf TargetVideo endete die Abhängigkeit von einer Plattform, deren technische Grenzen unsere Weiterentwicklung zunehmend blockiert hatten.

Die Migration schuf wieder Spielraum für neue Funktionen und Verbesserungen im redaktionellen Umgang mit Videos.

Für mich verband das Projekt technische Evaluation, Integrationsarbeit, Projektsteuerung und eine neue Arbeitsweise in der Softwareentwicklung.

Eine erfolgreiche Migration ersetzt nicht einfach ein altes System. Sie schafft wieder Möglichkeiten, die das alte System längst verhindert hatte.

2025 · FUNKE Digital · Technologie

In einem modernen Publishing-System entstehen Inhalte längst nicht mehr ausschließlich im klassischen Redaktionsworkflow.

Daten werden verarbeitet und zu neuen Informationen zusammengeführt. Mit generativer KI kamen zusätzliche Möglichkeiten hinzu, aus strukturierten Daten veröffentlichungsfähige Inhalte zu erzeugen.

Bei FUNKE Digital beschäftigte sich unser Data-Team früh damit, solche Prozesse nicht nur experimentell, sondern auch mit großen Datenmengen im produktiven Betrieb umzusetzen.

Damit stellte sich eine praktische Frage: Wie gelangen die Ergebnisse zuverlässig ins CMS?

Zwei Fachbereiche, zwei Perspektiven

Das Data-Team arbeitete bereits seit einiger Zeit mit den Redaktionen zusammen. Es stellte Dashboards bereit und half dabei, die Nutzung journalistischer Inhalte besser zu verstehen.

Allerdings stand das Team damit bislang überwiegend am Ende der redaktionellen Prozesskette: Artikel waren bereits veröffentlicht, die Daten wurden anschließend ausgewertet.

Mit der automatisierten Verarbeitung großer Datenmengen und dem Einsatz generativer KI veränderte sich diese Rolle grundlegend. Plötzlich ging es nicht mehr nur darum, veröffentlichte Inhalte zu messen, sondern selbst Inhalte zu erzeugen und in den redaktionellen Produktionsprozess einzuspeisen.

Dafür reichten Kenntnisse über Datenstrukturen und technische Verarbeitungsschritte nicht mehr aus. Das Team musste verstehen, wie Redaktionen arbeiten, welche Bearbeitungs- und Freigabeprozesse existieren und welche Anforderungen ein CMS an neue Inhalte stellt.

Meine erste Aufgabe bestand deshalb nicht darin, eine API zu entwickeln. Zunächst vermittelte ich dem Data-Team, wie redaktionelle Prozesse funktionieren und welche Anforderungen sich daraus für die technische Integration ergeben.

Auf dieser Grundlage konnten wir gemeinsam die notwendigen Schnittstellen planen. Das Data-Team entwickelte die Verfahren zur Verarbeitung und Erzeugung von Inhalten. Ich kümmerte mich darum, dass die Ergebnisse zuverlässig in unsere Publishing-Plattform gelangten, und erweiterte die Schnittstellen mit den wachsenden Anforderungen.

Von der einmaligen Migration zum regelmäßigen Import

Die Anforderungen waren unterschiedlich.

Bei Migrationen mussten teilweise große Inhaltsbestände einmalig übernommen werden. Andere Prozesse lieferten regelmäßig neue Inhalte, die automatisiert ins CMS eingespielt werden sollten.

Beide Fälle benötigten zuverlässige Schnittstellen, stellten aber unterschiedliche Anforderungen an die technische Umsetzung.

Deshalb ging es nicht um einen einzelnen Importmechanismus für ein bestimmtes Projekt, sondern um die schrittweise Erweiterung der Integrationsmöglichkeiten unseres Publishing-Systems.

Automatisierung braucht Zusammenarbeit

Der Erfolg solcher Projekte hing nicht allein davon ab, ob das Data-Team Daten verarbeiten oder Inhalte erzeugen konnte. Ebenso wichtig war, dass die Ergebnisse ohne unnötige manuelle Zwischenschritte in den produktiven Veröffentlichungsprozess gelangten.

Dafür mussten wir Anforderungen zwischen den Fachbereichen abstimmen und die jeweiligen Systeme aufeinander ausrichten.

Die Zusammenarbeit entwickelte sich damit über einzelne Projekte hinaus zu einer wiederkehrenden Form der Produktentwicklung.

Die eigentliche Leistung lag nicht darin, zwei Systeme miteinander reden zu lassen. Sondern darin, aus unterschiedlichen technischen Fähigkeiten einen gemeinsamen, verlässlichen Publishing-Prozess zu machen.

2025 · FUNKE Digital · Technologie

Wer Nachrichten einer Agentur wie der Deutschen Presse-Agentur (dpa) in ein Content-Management-System integrieren will, erwartet zunächst eine technische Herausforderung.

Bei der dpa war das überraschend unspektakulär. Die Agentur verfügt über jahrzehntelange Erfahrung darin, Nachrichten für unterschiedlichste Abnehmer bereitzustellen. Entsprechend ausgereift waren die technischen Möglichkeiten, ihre Inhalte abzurufen und weiterzuverarbeiten.

Die eigentlichen Fragen begannen erst danach: Was sollte mit den Meldungen passieren, sobald sie unser CMS erreichten?

Eine Meldung ist noch kein Workflow

Für die Redaktionen reichte es nicht, dass neue Agenturmeldungen technisch verfügbar waren.

Sie mussten auch davon erfahren. Welche neuen Inhalte waren eingetroffen? Welche davon waren für die eigenen Portale relevant? Und wie ließen sie sich möglichst einfach in den redaktionellen Arbeitsalltag übernehmen?

Damit wurde aus einer vermeintlichen Schnittstellenaufgabe schnell ein Projekt zur Gestaltung redaktioneller Prozesse.

Denn eine zuverlässige Datenübertragung allein garantiert noch nicht, dass die richtigen Inhalte zur richtigen Zeit bei den richtigen Redakteuren ankommen.

Wenn die Agentur schneller ist als die Redaktion

Besonders interessant wurde es bei der Möglichkeit, Agenturmeldungen direkt zu veröffentlichen.

Damit entfiel zwar ein manueller Zwischenschritt. Gleichzeitig entstanden neue Fragen.

Was passiert, wenn die dpa eine bereits übernommene Meldung aktualisiert oder korrigiert? Soll das CMS die veröffentlichte Fassung automatisch ersetzen? Und was geschieht, wenn die Redaktion den Artikel inzwischen selbst bearbeitet hat?

Auch die Kategorisierung erforderte Aufmerksamkeit. Eine Meldung konnte technisch korrekt importiert werden und trotzdem im falschen Ressort oder an einer unpassenden Stelle erscheinen.

Solche Fehler sind bei einer rein manuellen Veröffentlichung leichter zu erkennen. In einem automatisierten Prozess müssen die Abläufe darauf vorbereitet sein.

Die Technik muss den Redaktionsalltag verstehen

Meine Aufgabe bestand deshalb nicht nur darin, die Anbindung an die dpa umzusetzen, sondern gemeinsam mit den beteiligten Redaktionen die notwendigen Workflows zu durchdenken.

Wie werden neue Meldungen sichtbar? Wann ist eine automatische Veröffentlichung sinnvoll? Welche Änderungen dürfen automatisiert übernommen werden, und wann braucht es eine redaktionelle Entscheidung?

Die Antworten auf solche Fragen bestimmen, wie eine technische Integration im Alltag tatsächlich funktioniert.

Die Schnittstelle liefert die Nachricht. Der Workflow entscheidet, was daraus wird.

Die dpa-Integration war ein gutes Beispiel dafür, dass technische Komplexität und Produktkomplexität nicht dasselbe sind.

Eine ausgereifte Schnittstelle kann die Entwicklung erheblich vereinfachen. Die Verantwortung für einen funktionierenden Veröffentlichungsprozess nimmt sie den beteiligten Redaktionen und Entwicklern aber nicht ab.

2024 · FUNKE Digital · Technologie

Nicht jeder journalistische Artikel verliert mit der Zeit seine Relevanz. Ratgeber, Hintergrundberichte und Servicethemen können noch lange nach ihrer ursprünglichen Veröffentlichung Leser interessieren.

Die Herausforderung besteht darin, solche Inhalte im großen Artikelbestand wiederzufinden und ihre Sichtbarkeit gezielt zu steuern.

Bei FUNKE Digital entwickelten wir dafür einen automatisierten Prozess, der Nutzungsdaten, redaktionelle Regeln und das Publishing-System miteinander verband.

Wenn Zugriffsdaten zu Aktionen werden

Ausgangspunkt waren die Daten zur Nutzung unserer Artikel. Das Data-Team konnte daraus Inhalte identifizieren, die bestimmte, zuvor festgelegte Kriterien erfüllten.

Welche Kriterien galten, bestimmte die Redaktion. Die technische Infrastruktur sorgte anschließend dafür, dass sich die daraus abgeleiteten Maßnahmen ohne zusätzliche manuelle Arbeit ausführen ließen.

Meine Aufgabe war es, die technischen Voraussetzungen für diesen automatisierten Publishing-Prozess im CMS zu schaffen. Die eigentliche Herausforderung lag dabei weniger im Umfang der Funktionen als in ihrer Zuverlässigkeit.

Schließlich griff die Automatisierung in bereits veröffentlichte Artikel ein. Änderungen an Veröffentlichungsdaten, URLs und Weiterleitungen mussten zuverlässig ineinandergreifen. Fehler konnten nicht nur einzelne Artikel beeinträchtigen, sondern auch deren Auffindbarkeit in Suchmaschinen und damit Reichweite und Werbeerlöse gefährden.

Die Schnittstellen mussten deshalb zuverlässig funktionieren. Denn selbst eine kleine technische Änderung kann erhebliche wirtschaftliche Folgen haben, wenn sie in einen geschäftskritischen Publishing-Prozess eingreift.

So entstand eine Verbindung zwischen Datenanalyse und Veröffentlichung: Das Data-Team konnte auf Basis redaktioneller Vorgaben gezielt Publishing-Prozesse auslösen.

Ein neuer Veröffentlichungszyklus

Im Mittelpunkt stand das erneute Publizieren bereits vorhandener Artikel.

Dafür musste das CMS mehr können, als einen bestehenden Beitrag erneut zu speichern. Der Prozess umfasste die Anpassung des Veröffentlichungsdatums und die Vergabe einer neuen URL nach einem deterministischen, aber flexiblen Schema. Die bisherige URL wurde auf die neue Adresse weitergeleitet.

Ziel war, dass Suchmaschinen den Beitrag erneut erfassen und seine Sichtbarkeit neu bewerten konnten.

Automatisierung statt zusätzlicher Handarbeit

Die technische Herausforderung bestand darin, diese Abläufe zuverlässig und kontrolliert in den bestehenden Publishing-Prozess einzubinden.

Redaktionelle Regeln bestimmten, welche Artikel infrage kamen. Das Data-Team identifizierte die passenden Inhalte und löste die Aktionen aus. Die CMS-Schnittstellen übernahmen die technische Umsetzung.

Damit entstand ein Workflow, der datenbasierte Entscheidungen unmittelbar in Veröffentlichungsprozesse übersetzte.

Nicht jede Automatisierung im Publishing erzeugt neue Inhalte. Einige verändern vor allem, wann und wie bestehende Inhalte erneut sichtbar werden.

2023 · FUNKE Digital · Technologie

Eine Redaktion, die sieben Tage die Woche in mehreren Schichten arbeitet, hat ein ganz alltägliches Problem: den Überblick behalten.

Welche Themen sind bereits bearbeitet? Was muss noch erledigt werden? Welche Artikel sind veröffentlicht, welche stehen fertig im Stehsatz? Und was hat die vorherige Schicht bereits vorbereitet?

Die Informationen existieren meistens irgendwo. Die Herausforderung besteht darin, sie zur richtigen Zeit am richtigen Ort verfügbar zu haben.

Jede Redaktion findet ihre eigene Lösung

Über die Jahre entwickeln Redaktionen dafür eigene Organisationsformen. Tabellen, Dokumente, Listen und spezialisierte Planungssysteme helfen dabei, Aufgaben zu verteilen und den aktuellen Stand festzuhalten.

Manche dieser Lösungen wachsen organisch, andere kosten beträchtliche Lizenzgebühren. Und selbst umfangreiche Redaktionsplanungssysteme werden im Alltag häufig nur mit einem Bruchteil ihrer Funktionen genutzt.

Bei FUNKE Digital wollten wir diesen Wildwuchs reduzieren und eine gemeinsame Lösung schaffen, die sich direkt in die vorhandenen Publishing-Prozesse einfügt.

Warum Informationen doppelt pflegen?

Das größte Ärgernis war die Trennung zwischen Redaktionsplanung und CMS.

Ein Artikel wurde im CMS angelegt, bearbeitet und veröffentlicht. Sein Status musste aber häufig zusätzlich in einer Tabelle oder einem anderen Planungssystem festgehalten werden.

Das bedeutete Copy-and-paste, doppelte Datenpflege und die Gefahr, dass Informationen auseinanderliefen.

Meine Idee war, die Redaktionsübersicht direkt ins CMS zu integrieren, statt ein weiteres Planungssystem einzuführen. Gemeinsam mit der Redaktion entwickelte ich daraus ein Konzept, das sich an den tatsächlichen Abläufen im Schichtbetrieb orientierte.

Dort waren viele der benötigten Informationen bereits vorhanden: Artikel, Veröffentlichungsstatus und vorbereitete Inhalte. Statt sie in ein zweites System zu übertragen, wollten wir sie unmittelbar für die redaktionelle Planung nutzbar machen.

Ein gemeinsamer Blick auf den Tag

Die technische Umsetzung übernahm ich selbst. Dafür ergänzte ich das CMS um eine zusätzliche Artikelkategorisierung, mit der sich Beiträge aus Sicht des Chefs vom Dienst bestimmten Themen zuordnen ließen.

Das Herzstück war das CvD-Dashboard, eine zentrale Übersicht über die so organisierten Inhalte.

Über eine einfache Umschaltung konnten die Redaktionen zwischen Entwürfen, bereits veröffentlichten und geplanten Artikeln eines Themas wechseln.

Auch die Zuordnung ließ sich direkt in der Übersicht ändern: Per Drag-and-drop konnten Artikel von einem CvD-Thema in ein anderes verschoben werden, ohne dafür die Artikelbearbeitung öffnen zu müssen. Wer einen Beitrag bearbeiten wollte, konnte ihn wiederum direkt aus dem Dashboard heraus aufrufen.

Damit ließ sich schnell erkennen, was zu einem Thema bereits erschienen war, welche Beiträge noch vorbereitet wurden und was für eine spätere Veröffentlichung vorgesehen war. Gleichzeitig konnten die Redaktionen ihre Themenübersicht unmittelbar organisieren.

Die Redaktion musste dafür keine zweite Artikelliste pflegen oder Informationen aus dem CMS in externe Dokumente übertragen.

Weniger Verwaltung, mehr Überblick

Der entscheidende Gedanke war, vorhandene CMS-Funktionen zu nutzen, statt ein weiteres eigenständiges Planungssystem aufzubauen.

Die zusätzliche Kategorisierung schuf die notwendige redaktionelle Ordnung. Das Dashboard machte sie für den Arbeitsalltag zugänglich.

So entstand mit überschaubarem technischen Aufwand ein Werkzeug, das sich unmittelbar in bestehende Abläufe einfügte.

Ein gutes Redaktionswerkzeug verlangt nicht, dass die Redaktion ihre Arbeit zusätzlich dokumentiert. Es nutzt die Informationen, die bei dieser Arbeit ohnehin entstehen.

FUNKE Digital · 2023 · Technologie

Die Zentralredaktion hat sich im deutschsprachigen Onlinejournalismus weitgehend etabliert. Inhalte entstehen an einer Stelle und werden von mehreren Portalen genutzt. Hinzu kommen Kooperationen zwischen spezialisierten Angeboten, die passende Artikel untereinander austauschen.

Eigentlich müsste das ganz einfach sein. Schließlich arbeiten unsere Portale bei FUNKE Digital mit demselben Content-Management-System.

Doch ein gemeinsames CMS bedeutet noch lange nicht, dass ein Artikel auf jeder Website auf dieselbe Weise funktioniert.

Ein Artikel ist mehr als sein Text

Wer einen Beitrag von einem Portal auf ein anderes überträgt, muss mehr berücksichtigen als Überschrift und Fließtext.

Kategorien und Schlagwörter unterscheiden sich zwischen den Angeboten. Bilder müssen in den passenden Formaten und Größen vorliegen. Und spezielle Inhalte wie Rezepte bringen eigene strukturierte Daten mit, die auch auf dem Zielportal korrekt verarbeitet werden müssen.

Ein Artikel kann technisch vollständig übertragen worden sein und trotzdem im falschen Ressort landen, ungeeignete Bilder verwenden oder wichtige Zusatzinformationen verlieren.

Die Herausforderung besteht deshalb darin, die Inhalte nicht nur zu transportieren, sondern sie an die Anforderungen des jeweiligen Zielportals anzupassen.

Was passiert nach der Übernahme?

Mit der ersten Veröffentlichung ist die Arbeit noch nicht erledigt.

Was geschieht, wenn die Ursprungsredaktion einen Artikel später korrigiert oder ergänzt? Sollen die Änderungen automatisch auf allen beteiligten Portalen erscheinen? Dürfen die Zielredaktionen eigene Anpassungen vornehmen? Und was passiert, wenn ein Artikel auf dem Ursprungsportal gelöscht wird?

Auch die Suchmaschinenoptimierung spielt eine Rolle. Wenn derselbe Inhalt auf mehreren Websites erscheint, müssen Entscheidungen über seine Auffindbarkeit und die Beziehung zwischen den verschiedenen Fassungen getroffen werden.

Solche Fragen lassen sich nicht allein durch eine technische Schnittstelle beantworten. Sie erfordern Regeln, die redaktionelle Anforderungen, Geschäftsinteressen und technische Möglichkeiten miteinander verbinden.

Komplexität im Hintergrund halten

Meine Aufgabe war es, diese Anforderungen in technische Abläufe zu übersetzen und die Verteilung der Inhalte über unsere Publishing-Plattform zu ermöglichen.

Dabei galt eine zentrale Vorgabe: Für die beteiligten Redaktionen sollte möglichst wenig zusätzliche Arbeit entstehen.

Die Zuordnung von Kategorien, die Anpassung von Bildern und die Übertragung spezieller Daten erfolgen deshalb weitgehend automatisiert.

Das Verhalten bei späteren Änderungen am Ursprungsartikel war individuell für jede Kooperation zwischen Quell- und Zielportal konfigurierbar und konnte bei Bedarf für einzelne Artikel abweichend festgelegt werden.

Ein gemeinsames CMS ist erst der Anfang

Die eigentliche Herausforderung der Content-Orchestrierung liegt nicht darin, mehrere Websites miteinander zu verbinden.

Sie besteht darin, unterschiedliche redaktionelle und technische Anforderungen so aufeinander abzustimmen, dass Inhalte zuverlässig zwischen den Portalen genutzt werden können.

Ein gemeinsames CMS erleichtert das. Es ersetzt aber nicht die Entscheidungen darüber, wie die einzelnen Angebote mit den Inhalten umgehen.

Gute Content-Orchestrierung sorgt dafür, dass ein Artikel auf mehreren Portalen funktioniert, ohne dass die Redaktion ihn für jedes Portal neu bearbeiten muss.

Über Golem.de hinaus.

Vier journalistische Arbeiten mit Resonanz über das eigene Medium hinaus

Mehr als 500 Artikel für Golem.de. Diese vier Arbeiten wurden auch von anderen Medien aufgegriffen und teilweise international zitiert.

2017 · Technik & Recht

Puppenverbot gefährdet das Smart Home und Bastler

Welche Konsequenzen hat das Verbot einer vernetzten Puppe für Smart-Home-Geräte und Elektronikprojekte?

Originalartikel bei Golem.de ↗ 2014 · Experiment

Internetausdrucker 4.0

Ein ungewöhnliches Experiment an der Schnittstelle von Browser und 3D-Druck.

Originalartikel bei Golem.de ↗ 2013 · Medienkritik

Böser, böser Toaster

Was ein vermeintliches Hacker-Symbolbild bei genauer technischer Betrachtung verrät.

Originalartikel bei Golem.de ↗ 2017 · Recherche · mit Friedhelm Greis

Warum Digitalcourage falsch informiert hat

Eine kritische Analyse technischer Argumente rund um die Gesichtserkennung am Berliner Südkreuz.

Originalartikel bei Golem.de ↗

2007–2022 · Golem.de

Die erste Reaktion auf meine Bewerbung bei Golem.de war eine Rückfrage: Wollte ich mich eigentlich als Entwickler oder als Redakteur bewerben?

Meine Antwort war eindeutig: als Entwickler. Aber wenn sich gelegentlich die Gelegenheit ergäbe, würde ich auch gern Artikel über Entwicklerthemen schreiben.

Aus dem gelegentlich wurde mit der Zeit regelmäßig. Und am Ende meiner Zeit bei Golem.de standen mehr als 500 veröffentlichte Artikel.

Eine zweite Rolle entsteht

Anfangs schrieb ich über Themen aus meinem unmittelbaren technischen Umfeld. Doch dabei blieb es nicht.

Mit der Zeit erschloss ich innerhalb der Redaktion neue Themenbereiche, insbesondere DIY-Elektronik sowie technisches Lern- und Spielzeug für Kinder und Jugendliche. Die Themen fanden beim Publikum Anklang und wurden von Golem.de auch nach meinem Weggang weitergeführt.

Mein journalistisches Spektrum wuchs darüber hinaus über klassische Entwickler- und Technikthemen hinaus. Ich schrieb über Start-ups, beschäftigte mich mit politischen Fragestellungen und bewegte mich zunehmend selbstverständlich in unterschiedlichen Ressorts.

Das Schreiben war längst keine gelegentliche Ergänzung meiner Entwicklerarbeit mehr.

Zwischen zwei Berufswelten

Innerhalb des Unternehmens gehörte ich zur IT-Entwicklung. Gleichzeitig nahmen mich Kollegen und externe Gesprächspartner als Teil der Redaktion wahr.

Diese Doppelrolle funktionierte im Alltag erstaunlich gut. Bei formalen Fragen wurde es gelegentlich komplizierter.

Was sollte eigentlich auf meiner Visitenkarte stehen? Und in welcher Funktion nahm ich an Veranstaltungen teil – als Entwickler oder als Journalist?

Mitunter führte das zu amüsanten Situationen. Gesprächspartner, die mich als Journalisten kennengelernt hatten, waren gelegentlich überrascht, wenn ich plötzlich sehr spezifische technische Fragen stellte.

Sie hatten nicht unbedingt damit gerechnet, dass der Journalist auf der anderen Seite auch selbst Software entwickelte.

Journalismus verändert den Blick auf Technik

Für meine Arbeit als Entwickler und später als Produktmanager war diese zweite Rolle besonders wertvoll.

Ich kannte redaktionelle Abläufe nicht nur aus Anforderungsgesprächen oder Projektmeetings. Ich arbeitete selbst als Autor mit Themen, Recherche, Texten und Veröffentlichungen.

Gleichzeitig brachte ich in die journalistische Arbeit die Perspektive eines Entwicklers ein: technisches Verständnis, Erfahrung mit komplexen Systemen und die Fähigkeit, bei Fachthemen genauer nachzufragen.

Beide Seiten beeinflussten sich gegenseitig.

Mehr als 500 Artikel später

Aus dem Angebot, gelegentlich einen Artikel beizusteuern, war eine langjährige journalistische Tätigkeit geworden.

Ich hatte eigene Themenbereiche aufgebaut, neue Themen erschlossen und war für Kollegen ebenso wie für externe Gesprächspartner Teil der Redaktion geworden.

Die ursprüngliche Frage aus dem Bewerbungsgespräch ließ sich damit nach einigen Jahren nicht mehr eindeutig beantworten.

Ich war als Entwickler gekommen. Aber ich war längst auch Journalist.

2019 · Golem.de

Was macht man mit Lesern, die Werbung blockieren, Tracking ablehnen und auch kein kostenpflichtiges Abo abschließen möchten? Man könnte ihnen den Zugang verwehren. Oder man fragt sie, ob sie nicht etwas anderes beisteuern können: ihr Wissen.

Genau diese Idee steckte hinter Golem Act, intern auch Act2Access genannt. Statt Geld oder Werbeeinblendungen sollten Leser kleine Aufgaben erledigen, deren Ergebnisse Golem.de oder gemeinnützigen Projekten zugutekommen.

Drei Fragen für 15 Minuten

Der erste Test begann im Frühjahr 2019. Zehn Prozent der Leser mit Adblockern oder vergleichbaren Werkzeugen bekamen ein Popup angezeigt. Wer drei kurze Fragen beantwortete, konnte Golem.de anschließend 15 Minuten ohne Werbung und unerwünschtes Tracking nutzen.

Die Reaktionen waren, vorsichtig formuliert, lebhaft. Manche Leser kündigten empört an, Golem.de künftig zu meiden. Andere fanden die Idee gut oder wollten zumindest wissen, wie das Ganze funktioniert.

Das Feedback war trotzdem wertvoll. Technische Fehler wurden behoben, Aufgaben angepasst und das Konzept weiterentwickelt.

Von der Idee zum Experiment

Ab November 2019 begann der schrittweise Rollout. Leser konnten unter anderem das gemeinnützige Common-Voice-Projekt von Mozilla unterstützen, indem sie deutsche Sprachaufnahmen überprüften und Daten verifizierten. Andere Aufgaben halfen dabei, KI-Anwendungen von Golem.de zu trainieren.

Die ersten Ergebnisse waren ermutigend: Viele angesprochene Leser nahmen die Aufgaben an. Einige entschieden sich stattdessen für ein Golem-pur-Abo. Ein Rückgang der Leserzahlen war zunächst nicht zu erkennen.

Ein anderes Verständnis von Gegenleistung

Golem Act war der Versuch, das Verhältnis zwischen Lesern und Medienangebot neu zu denken. Nicht jeder kann oder will bezahlen. Nicht jeder akzeptiert Werbung. Aber vielleicht ist jemand bereit, fünf Minuten seiner Zeit und einen Teil seines Wissens einzubringen.

Aus dieser Überlegung entstand eine ungewöhnliche Kombination aus Gamification, Crowdworking und digitalem Geschäftsmodell.

Golem Act blieb ein Innovationsprojekt und wurde kein dauerhaft etabliertes Geschäftsmodell. Die zentrale Frage dahinter ist allerdings bis heute interessant: Muss die Gegenleistung für Journalismus eigentlich immer Geld oder Aufmerksamkeit sein?

2016–2017 · Golem.de

Wann bekommt mein Heimatort endlich Glasfaser? Wann erscheint das nächste Update für mein Smartphone? Und wann startet eigentlich der neue Dienst, über den gestern noch berichtet wurde?

Die Antworten stehen häufig irgendwo. In Nachrichtenartikeln, Pressemitteilungen oder Ankündigungen. Man muss sie nur finden. Und genau das ist oft erstaunlich mühsam.

Vom Artikel zur Wissensdatenbank

Mit dem Projekt „Wann kommt was?“ wollte Golem.de das ändern. Die Idee: Informationen mit zeitlichem Bezug automatisch aus journalistischen Texten extrahieren, strukturiert speichern und anschließend so aufbereiten, dass Nutzer konkrete Fragen schnell beantworten können.

Als Grundlage diente das umfangreiche Golem-Archiv mit seinen Artikeln über Technik, IT und Digitalisierung. Hinzu kamen Pressemitteilungen und andere Ankündigungen.

Statt Leser immer wieder durch ganze Artikel suchen zu lassen, sollte aus den vorhandenen Informationen eine Wissensdatenbank entstehen.

Deep Learning, bevor jeder darüber sprach

Technologisch setzte das Projekt auf eine Kombination aus maschinellem Lernen und Computerlinguistik. Die Fortschritte beim Deep Learning eröffneten damals neue Möglichkeiten, Zusammenhänge und Zeitangaben aus natürlichsprachlichen Texten zu erkennen.

2016 war das für ein mittelständisches Medienunternehmen keineswegs selbstverständlich. Golem.de erhielt für „Wann kommt was?“ zum zweiten Mal eine Förderung aus Googles Digital News Initiative (DNI).

Der Ansatz ging über eine bessere Suchfunktion hinaus: Journalistische Inhalte sollten nicht nur veröffentlicht und archiviert werden, sondern als strukturierte Informationen erneut nutzbar sein.

Die Nachricht als Ausgangspunkt, nicht als Endstation

Onlinejournalismus war lange vor allem darauf ausgelegt, neue Informationen möglichst schnell zu veröffentlichen. Wer später eine konkrete Antwort suchte, musste sich oft selbst durch ältere Meldungen arbeiten.

„Wann kommt was?“ stellte eine andere Frage: Warum sollte eine Nachricht nur als Artikel existieren, wenn die darin enthaltenen Fakten auch direkt auffindbar und miteinander verknüpfbar sein könnten?

Das Projekt blieb im Innovationsstadium. Die dahinterstehende Idee ist aber bemerkenswert aktuell: Aus unstrukturierten Texten Wissen gewinnen und Menschen genau die Information liefern, nach der sie tatsächlich suchen.

2016 · Golem.de

Zu lang, nicht gelesen. So lautet die übliche Bedeutung von „Tl;DR“. Aber was wäre, wenn ein Artikel gar nicht zu lang sein könnte? Weil jeder Leser selbst entscheidet, wie tief er in ein Thema einsteigen möchte?

Genau diese Idee steckte hinter „Not too long, did read“, einem Innovationsprojekt von Golem.de aus dem Jahr 2016.

Ein Artikel, der beim Lesen wächst

Das Konzept stellte eine der selbstverständlichsten Eigenschaften des Onlinejournalismus infrage: Ein Artikel hat einen Anfang, ein Ende und eine vom Autor festgelegte Länge.

Tl;DR sollte das ändern. Mithilfe linguistischer Inhaltsanalyse und maschinellen Lernens sollten Artikel absatzweise untersucht und mit relevanten Informationen aus dem Golem-Archiv verknüpft werden.

Wer sich nur einen schnellen Überblick verschaffen wollte, las den ursprünglichen Artikel. Wer mehr wissen wollte, konnte zusätzliche Informationen direkt in den Text einblenden lassen.

Und zwar nicht einfach als Link zu einem anderen Artikel, sondern als passende Absätze aus bereits veröffentlichten Beiträgen. Der Artikel sollte sich auf Wunsch seiner Leser selbst verlängern.

Eine andere Art zu lesen

Golem.de gehörte 2016 zu den Gewinnern der ersten Förderrunde von Googles Digital News Initiative (DNI). Unterstützt wurde die Entwicklung eines Prototyps.

Technisch ging es darum, Inhalte linguistisch zu analysieren, relevante Textpassagen zu erkennen und diese in einen neuen Lesekontext einzubinden.

Das war weit mehr als eine verbesserte Empfehlung für verwandte Artikel. Statt Leser immer wieder auf neue Seiten zu schicken, sollten Informationen genau dort erscheinen, wo sie gebraucht wurden: mitten im Text.

Weg vom starren Artikel

Hinter Tl;DR stand eine größere Überlegung. Warum betrachten wir journalistische Inhalte als abgeschlossene Dokumente, obwohl sie aus vielen einzelnen Informationen bestehen, die auch in anderen Zusammenhängen nützlich sein könnten?

Das Ziel waren flexible Absatzfragmente, aus denen sich individuelle Leseerlebnisse zusammensetzen lassen. Nicht mehr der Hyperlink als einzige Verbindung zwischen Artikeln, sondern der Inhalt selbst als wiederverwendbarer Informationsbaustein.

Tl;DR blieb ein Innovationsprojekt und wurde kein reguläres Produkt. Doch die Frage dahinter ist mit dem Aufkommen generativer KI noch interessanter geworden:

Warum sollten alle Leser denselben Artikel lesen müssen, wenn sie unterschiedliche Fragen und unterschiedlich viel Vorwissen mitbringen?

2012–2013 · Golem.de

Ein Nutzerkonto klingt nach einer Selbstverständlichkeit. Doch wenn verschiedene Angebote über Jahre hinweg unabhängig voneinander entstehen, kann die Anmeldung schnell zu einer Sammlung getrennter Zugänge werden.

Bei Golem.de wollten wir die verschiedenen Nutzerfunktionen deshalb auf eine gemeinsame technische Grundlage stellen.

Von der zentralen Anmeldung zum PUR-Abo

Bereits vor der Entwicklung des PUR-Modells begannen wir bei Golem.de mit dem Aufbau einer zentralen Nutzerverwaltung. Sie sollte die Grundlage schaffen, um verschiedene Angebote künftig über ein gemeinsames Konto zugänglich zu machen.

Mit der Entwicklung des PUR-Abonnements ab 2013 erhielt diese Infrastruktur einen konkreten Anwendungsfall. Für das werbefreie Angebot benötigten wir eine zuverlässige Nutzerverwaltung, die auch Abonnements und Zugriffsberechtigungen berücksichtigen konnte.

In den folgenden Jahren wurde die Plattform schrittweise erweitert. 2018 kam die Newsletter-Anmeldung hinzu, 2020 folgte die Integration des Forums.

Ein Konto, unterschiedliche Berechtigungen

Besonders die Einbindung des Forums erforderte Sorgfalt: Bestehende Nutzer sollten ihre gewohnten Zugangsdaten weiterverwenden können, ohne dass andere Angebote davon beeinträchtigt wurden.

Eine Sperre im Forum durfte beispielsweise nicht automatisch den Zugriff auf ein bezahltes PUR-Abonnement oder den Newsletter betreffen. Die gemeinsame Anmeldung und die Berechtigungen für einzelne Angebote mussten getrennt bleiben.

So entstand nach und nach eine zentrale Stelle für Nutzerzugänge und Einstellungen, während die einzelnen Angebote ihre eigenen Regeln behielten.

Infrastruktur, die Produkte möglich macht

Der Single Sign-on war kein spektakuläres Produkt für sich allein. Er wurde zur Grundlage dafür, neue Angebote anzubinden, ohne jedes Mal eine eigene Nutzerverwaltung aufzubauen.

Ein besonders wichtiger Anwendungsfall war das PUR-Modell, das auf dieser bereits vorhandenen Infrastruktur aufbauen konnte.

Eine gemeinsame Anmeldung ist dann erfolgreich, wenn die Nutzer nicht mehr darüber nachdenken müssen, wie viele Systeme dahinterstecken.

Neuer Login für Forennutzer bei Golem.de ↗

2000 · PHP Magazin · Journalismus & Wissen

Eigentlich wollte ich programmieren. Dass ich irgendwann regelmäßig für ein Fachmagazin schreiben würde, gehörte nicht zu meinem ursprünglichen Plan.

Der Weg dorthin begann mit meiner Mitarbeit am Open-Source-Projekt PEAR. Dort hatte ich zunächst kleinere PHP-Pakete beigesteuert, mich dann aber zunehmend um die technische Dokumentation und ihre deutsche Übersetzung gekümmert.

Diese Arbeit blieb nicht unbemerkt.

Eine Anfrage, die einiges veränderte

Eines Tages meldete sich der Chefredakteur des PHP Magazins bei mir. Ob ich nicht einen Artikel über PEAR schreiben wollte?

Warum nicht? Mit dem Projekt kannte ich mich aus, und technische Zusammenhänge verständlich zu erklären, gehörte durch die Dokumentationsarbeit inzwischen zu meinem Alltag.

Also schrieb ich den Artikel und lieferte ihn ab.

Kurz darauf kam die nächste Frage: Ob ich nicht Lust hätte, für jede Ausgabe des Magazins eine feste Rubrik zu übernehmen?

Alle zwei Monate sollte ich über Neuigkeiten, Entwicklungen und Veränderungen im PEAR-Projekt berichten.

Aus einem einzelnen Fachartikel wurde damit eine regelmäßige journalistische Aufgabe.

Plötzlich gehörte Schreiben dazu

Die neue Aufgabe veränderte meinen Blick auf die Arbeit an Software.

Bei PEAR beschäftigte ich mich damit, wie Komponenten entwickelt wurden und wie Entwickler sie einsetzen konnten. Für das PHP Magazin musste ich zusätzlich entscheiden, welche Entwicklungen für die Leser interessant waren und wie ich sie verständlich und präzise vermitteln konnte.

Damit wurde aus der technischen Dokumentation journalistische Arbeit.

Rückblickend war diese Anfrage ein entscheidender Schritt auf meinem beruflichen Weg. Ich hatte einen Einstieg in den Fachjournalismus gefunden, ohne die Verbindung zur Softwareentwicklung aufzugeben.

Ich wollte lernen, professionell zu programmieren. Dass mich ausgerechnet die Dokumentation zum professionellen Schreiben bringen würde, hatte ich nicht erwartet.

Zur PEAR-Geschichte

2013–2014 · Golem.de

Warum sollten Leser freiwillig für journalistische Inhalte bezahlen, die sie ohnehin kostenlos lesen können? Ohne zusätzliche Funktionen und ohne einen persönlichen Vorteil?

Bei Golem.de wollten wir genau das herausfinden. Und die Antwort war überraschend einfach: Einige Leser zahlten tatsächlich.

Ein grüner Button für freiwillige Zahlungen

2013 diskutierten wir bei Golem.de intensiv über Werbeblocker und alternative Finanzierungsmodelle. In unserem Forum erklärten Leser immer wieder, dass sie Golem.de gern finanziell unterstützen würden, statt Werbung anzusehen.

Also gaben wir ihnen die Möglichkeit dazu.

Im Oktober 2013 integrierten wir den Mikrozahlungsdienst Flattr in die Artikelseiten. Leser konnten damit einzelne Beiträge finanziell unterstützen. Der Dienst verteilte das monatlich eingezahlte Guthaben auf die ausgewählten Inhalte.

Die Integration erfolgte gemeinsam mit einer Überarbeitung unserer Social-Media-Buttons. Statt beim Seitenaufruf automatisch Daten an Facebook, Twitter oder Google+ zu übertragen, lieferten wir die notwendigen Informationen selbst aus. Auch Flattr banden wir datensparsam ein.

Kein Geschäftsmodell. Aber eine Erkenntnis.

Nach drei Monaten fiel die Bilanz ernüchternd aus. Von rund 1,5 Millionen monatlichen Besuchern hatten gerade einmal 460 Leser Artikel über Flattr unterstützt.

Die erste Abrechnung brachte rund 450 Euro, die zweite 240 Euro und die dritte 216 Euro.

Das waren keine Beträge, mit denen sich eine Nachrichtenredaktion finanzieren ließ. Flattr war keine ernsthafte Alternative zum Werbegeschäft.

Trotzdem fand ich das Ergebnis bemerkenswert.

Wir hatten unseren Lesern die Möglichkeit gegeben, uns freiwillig Geld zu geben. Und sie hatten es getan.

Ohne Paywall. Ohne einen unmittelbaren Gegenwert.

Nicht viele Leser, aber immerhin einige. Und das regelmäßig.

Was Leser wirklich wollten

Noch interessanter war die Diskussion rund um den Spenden-Button. Viele Leser wollten Golem.de unterstützen, hatten aber wenig Interesse an einem weiteren Zahlungsdienst oder an der Verteilung kleiner Beträge auf einzelne Artikel.

Ihr Wunsch war häufig viel konkreter: Sie wollten für Golem.de bezahlen und dafür die Website ohne Werbung nutzen.

Für uns war das ein wichtiger Hinweis. Leser waren grundsätzlich bereit, für unser journalistisches Angebot Geld auszugeben. Die Herausforderung bestand darin, daraus ein Produkt zu entwickeln, das einen klaren Nutzen bot.

Diese Erfahrungen flossen in die Überlegungen zum späteren PUR-Modell ein.

Kleine Beträge, große Wirkung

Flattr wurde für Golem.de kein tragfähiges eigenständiges Geschäftsmodell. Der Spenden-Button lieferte uns aber eine wichtige Erkenntnis über die Beziehung zwischen einem Medium und seinen Lesern.

Freiwillige Zahlungen waren möglich. Die Zahlungsbereitschaft existierte. Und sie ließ sich durch ein passendes Angebot vielleicht auf eine breitere Grundlage stellen.

Der wirtschaftliche Erfolg eines Experiments ist eben nicht immer sein wichtigstes Ergebnis.

Manchmal reicht schon die Erkenntnis, dass Leser bereit sind, für etwas zu bezahlen, das sie bisher kostenlos bekommen haben.

Neue Social-Buttons mit Flattr bei Golem.de ↗

Die Flattr-Bilanz nach drei Monaten bei Golem.de ↗

2008 · Golem.de

Meine Anmeldung bei der VG Wort erledigte ich Ende der 1990er-Jahre noch ganz analog: per Brief.

Während meiner Zeit als Printautor musste ich mich mit den Meldeprozessen im Hintergrund kaum beschäftigen. Die Verlage kümmerten sich um die notwendigen Abläufe.

Mit dem Onlinejournalismus änderte sich das. 2007 kündigte die VG Wort METIS an, ein Meldesystem, das erstmals auch die automatisierte Erfassung von Onlineveröffentlichungen ermöglichen sollte.

Für Golem.de eröffnete sich damit 2008 eine zusätzliche Einnahmequelle. Allerdings musste die Technik erst einmal in unser Publishing-System integriert werden.

Eine API nach deutscher Behördenart

Die eigentliche Integration war technisch keine besonders außergewöhnliche Aufgabe. Die Herausforderung lag vielmehr in der Schnittstelle und ihrer Dokumentation.

METIS war nach meinem Eindruck ein Musterbeispiel für bürokratisch geprägte Softwareentwicklung: komplexe Vorgaben, formalisierte Abläufe und eine Dokumentation, die mehr Fragen aufwarf, als sie beantwortete.

Für Entwickler, die flexible Webschnittstellen gewohnt waren, bedeutete das eine besondere Geduldsprobe.

Eine Erfahrung, die mich Jahre später bei ähnlich regulierungsgetriebenen Themen wie der DSGVO zumindest nicht mehr völlig überraschen sollte.

Eine Integration, die einfach funktionierte

Trotz dieser Hürden konnten wir METIS nach kurzer Entwicklungszeit bei Golem.de produktiv einsetzen.

Die Integration erfüllte ihren Zweck: Veröffentlichte Onlineartikel konnten für die VG-Wort-Ausschüttungen berücksichtigt werden, ohne dass die Redaktion jeden Beitrag einzeln melden musste.

Bemerkenswert war vor allem die Langlebigkeit. Die Integration lief über viele Jahre hinweg weitgehend unverändert und zuverlässig. Und ich würde mich nicht wundern, wenn sie bis heute genauso ihren Dienst verrichtet.

Keine ständigen Neuentwicklungen, keine regelmäßigen großen Umbauten. Eine technische Lösung, die im Hintergrund ihre Arbeit erledigte.

Warum eigentlich nicht überall?

In den folgenden Jahren wunderte ich mich immer wieder, dass selbst deutlich größere Verlage teilweise noch keine vergleichbare METIS-Integration umgesetzt hatten.

Denn der wirtschaftliche Nutzen war offensichtlich: Bereits veröffentlichte journalistische Inhalte konnten eine zusätzliche Erlösquelle erschließen.

Natürlich musste die technische Grundlage dafür erst geschaffen werden. Aber sobald sie funktionierte, entstand der Nutzen Jahr für Jahr erneut.

Nicht jede erfolgreiche Produktentwicklung braucht eine spektakuläre Idee. Manchmal genügt eine sauber umgesetzte Schnittstelle, die über Jahrzehnte Geld verdient.

2009 · Golem.de

2009 konkurrierten im Onlinejournalismus zwei grundverschiedene Konzepte für die Gestaltung von Nachrichten-Startseiten.

Bei der sogenannten weißen Seite platzierten Redakteure jeden Artikel bewusst an einer bestimmten Position. Das gab ihnen die volle Kontrolle darüber, welche Themen besonders prominent erschienen. Allerdings musste die Startseite auch ständig gepflegt werden.

Das Gegenmodell war die chronologische Nachrichtenliste, manchmal nach Ressorts unterteilt. Neue Artikel erschienen automatisch oben, ältere wanderten nach unten. Das erforderte kaum redaktionelle Betreuung, hatte aber einen entscheidenden Nachteil: Ein wichtiger Beitrag konnte innerhalb kurzer Zeit von neueren Meldungen verdrängt werden.

Bei Golem.de hatten wir uns bis dahin für die chronologische Variante entschieden. 2009 wollten wir das ändern – ohne die Vorteile der Automatisierung aufzugeben.

Chronologie als Standard, Redaktion als Ausnahme

Die Idee war einfach: Die Startseite sollte sich weiterhin grundsätzlich chronologisch aufbauen. Der Chef vom Dienst (CvD) sollte aber jederzeit eingreifen können, wenn ein Artikel besondere Aufmerksamkeit verdiente.

Dafür entwickelten wir ein Werkzeug, das beide Philosophien miteinander verband. Eine wichtige Vorgabe war, die gesamte Startseite über eine einzige Oberfläche zu steuern. Keine separaten Boxen für einzelne Bereiche, keine unterschiedlichen Bearbeitungsmasken. Der CvD sollte die Startseite als zusammenhängenden Nachrichtenfluss sehen und bearbeiten können.

Die Oberfläche bestand deshalb im Wesentlichen aus einer einzigen nummerierten Liste. Jede Zeile repräsentierte eine feste Position auf der Startseite, die das System zunächst automatisch mit dem jeweils passenden Artikel aus der chronologischen Reihenfolge füllte.

Wollte der CvD einen Beitrag länger sichtbar halten, genügte ein Doppelklick. Der Artikel wurde an seiner Position festgetackert und rückte nicht mehr mit jeder neuen Veröffentlichung nach unten.

Doppelklick, Drag-and-drop, fertig

Die festgetackerten Artikel ließen sich per Drag-and-drop auf andere Positionen verschieben.

Über ein Kontextmenü konnte der CvD außerdem einen angehefteten Beitrag gezielt durch einen anderen Artikel ersetzen. Der bisherige Beitrag kehrte anschließend in den normalen chronologischen Nachrichtenfluss zurück.

Damit war die Startseite weder ein vollständig manuell zusammengestelltes Schaufenster noch eine starre Nachrichtenliste.

Die Redaktion konnte Schwerpunkte setzen, ohne jede einzelne Position betreuen zu müssen. Alles, was sie nicht ausdrücklich festlegte, übernahm weiterhin die Automatik.

Wenn Zugriffszahlen Teil des Werkzeugs werden

Eine zusätzliche Funktion machte die Oberfläche besonders interessant.

Wir integrierten die Entwicklung der Zugriffszahlen direkt in die Artikelliste. Für jeden Beitrag zeigte das CMS die Veränderung der Zugriffe an – unabhängig davon, ob er automatisch einsortiert oder redaktionell festgetackert war.

Der CvD konnte dadurch unmittelbar erkennen, welche Artikel gerade an Aufmerksamkeit gewannen und welche möglicherweise an einer ungünstigen Position standen.

Vielleicht gehörte das zu den frühen Beispielen datenunterstützter Startseitensteuerung in deutschen Redaktionssystemen. Jedenfalls war die Verbindung von redaktioneller Platzierung und aktuellen Nutzungsdaten 2009 alles andere als selbstverständlich.

Die Zugriffszahlen trafen keine Entscheidungen. Sie lieferten zusätzliche Informationen, mit denen die Redaktion ihre Entscheidungen überprüfen und gegebenenfalls korrigieren konnte.

Automatisieren, ohne Kontrolle abzugeben

Das eigentlich Neue an unserem Werkzeug war nicht der Doppelklick und auch nicht das Drag-and-drop.

Entscheidend war die Aufgabenteilung: Die Technik übernahm die Routine, die Redaktion behielt die Kontrolle über die Ausnahmen.

So konnten wichtige Artikel sichtbar bleiben, während die übrige Startseite automatisch aktuell gehalten wurde.

Gute Automatisierung ersetzt keine redaktionellen Entscheidungen. Sie sorgt dafür, dass die Redaktion ihre Zeit für die Entscheidungen einsetzen kann, die wirklich wichtig sind.

2007–2008 · Golem.de

Etwa 2020 hielt ich einen Vortrag über die Geschichte des Golem.de-CMS. Geplant waren 45 Minuten. Am Ende wurden daraus zwei Stunden voller technischer Anekdoten und Erinnerungen.

Dabei ging es um ein System, dessen Ursprünge bis in die Anfangsjahre des deutschen Onlinejournalismus zurückreichten.

Ein CMS aus einer anderen Zeit

Als Golem.de 1997 gegründet wurde, war der Markt für Content-Management-Systeme noch überschaubar. Die studentischen Gründer hatten wenig Geld, dafür aber technische Kenntnisse und jede Menge Ideen.

Also entwickelten sie eigene Lösungen. Was fehlte, wurde selbst gebaut. Diese pragmatische Herangehensweise ermöglichte den Aufbau eines Nachrichtenportals mit begrenzten Mitteln.

Doch fast zehn Jahre später stieß die ursprüngliche Architektur zunehmend an ihre Grenzen. Um 2006 war klar, dass die bestehenden Systeme kaum noch Raum für technische Weiterentwicklung boten.

Golem.de brauchte ein neues Fundament.

Ein neues Backend, ohne alles neu zu machen

Genau deshalb kam ich 2007 zu Golem.de: Meine Aufgabe war die Entwicklung eines neuen CMS-Backends.

Die Herausforderung bestand darin, die technische Grundlage grundlegend zu erneuern, ohne gleichzeitig sämtliche gewachsenen Arbeitsabläufe der Redaktion umzuwerfen.

Die Benutzeroberfläche wurde deshalb zunächst nur behutsam modernisiert. Hinter den Kulissen änderte sich dagegen einiges.

Technologisch bedeutete die Migration den Abschied von Borland Pascal und den Wechsel zu PHP und JavaScript.

Es ging nicht einfach darum, vorhandene Funktionen in einer anderen Programmiersprache nachzubauen. Die neue Architektur sollte den langfristig stabilen Betrieb ermöglichen und ausreichend Spielraum für künftige Erweiterungen schaffen.

Modernisierung ohne große Inszenierung

Für die Redaktion sollte sich zunächst möglichst wenig verändern. Die eigentliche Arbeit fand unter der Oberfläche statt.

Das klingt unspektakulär, ist aber eine besondere Herausforderung bei der Modernisierung gewachsener Systeme: Die Entwickler müssen grundlegende technische Veränderungen umsetzen, während das Tagesgeschäft möglichst ungestört weiterläuft.

Mit der neuen Backend-Architektur entstand die Grundlage für spätere Weiterentwicklungen des Publishing-Systems.

Die unsichtbare Voraussetzung für neue Ideen

Rückblickend war die Migration eines der wichtigsten technischen Grundlagenprojekte meiner Zeit bei Golem.de.

Nicht, weil Leser anschließend eine spektakulär neue Website vorfanden. Sondern weil die technische Erneuerung überhaupt erst wieder Raum für zukünftige Funktionen und Produkte schuf.

Der Vortrag über die CMS-Geschichte dauerte übrigens mehr als doppelt so lange wie geplant. Vielleicht auch deshalb, weil hinter jeder technischen Entscheidung eine Geschichte steckte.

Die Qualität eines CMS zeigt sich nicht nur darin, was es heute kann, sondern vor allem darin, was es morgen möglich macht.

ab 1999 · PEAR · Open Source

Als Student wollte ich möglichst früh professionell programmieren. Nur: Wie sammelt ein Student praktische Erfahrung, wenn er noch nicht in einem Entwicklungsteam arbeitet?

Die naheliegende Antwort war Open Source.

Als 1999 das PHP-Projekt PEAR ins Leben gerufen wurde, war ich sofort dabei. PEAR sollte eine Sammlung wiederverwendbarer PHP-Komponenten schaffen, auf die Entwickler bei ihren eigenen Projekten zurückgreifen konnten.

Ich steuerte einige kleinere Pakete bei und unterstützte die Arbeit an anderen Komponenten.

Mein erstes Entwicklerteam saß im Internet

Bis dahin hatte ich überwiegend allein programmiert. Bei PEAR arbeitete ich zum ersten Mal mit anderen Entwicklern an gemeinsamen Projekten.

Quellcode wurde ausgetauscht, Änderungen diskutiert, Probleme gemeinsam gelöst. Die Beteiligten saßen an unterschiedlichen Orten und arbeiteten trotzdem an derselben Software.

Damit sammelte ich bereits Ende der 1990er-Jahre meine ersten Erfahrungen mit verteilter Teamarbeit – zu einer Zeit, als die Zusammenarbeit über das Internet noch alles andere als selbstverständlich war.

Und ich lernte noch etwas anderes: wie gut andere programmieren konnten.

Die anderen konnten das besser. Jedenfalls gefühlt.

Die Zusammenarbeit war lehrreich, aber nicht immer gut fürs Selbstbewusstsein.

Wenn ich mir ansah, wie andere Entwickler Probleme lösten und welche Qualität ihr Code hatte, kam ich mir mit meinen eigenen Beiträgen gelegentlich ziemlich klein vor.

Natürlich konnte ich mitarbeiten. Aber ich hatte das Gefühl, dass die anderen mir technisch deutlich voraus waren.

Also suchte ich nach einem Bereich, in dem ich mehr beitragen konnte als nur ein weiteres kleines PHP-Paket.

Code allein reicht nicht

Die Dokumentation von PEAR war damals noch rudimentär. Und für deutschsprachige Entwickler fehlte eine Übersetzung der bereits vorhandenen Inhalte.

Hier konnte ich etwas bewegen.

Ich begann, mich intensiver um die Dokumentation zu kümmern und an der deutschen Übersetzung zu arbeiten.

Das war keine Abkehr von der Softwareentwicklung. Im Gegenteil: Wer eine Programmbibliothek verständlich dokumentieren will, muss sich mit ihrer Funktionsweise beschäftigen, die richtigen Fragen stellen und technische Zusammenhänge präzise erklären.

Die Arbeit verband zwei Fähigkeiten, die mich auch später begleiten sollten: Technik verstehen und komplexe Inhalte so aufbereiten, dass andere etwas damit anfangen können.

Der Rest ist Geschichte

PEAR war für mich weit mehr als ein frühes Open-Source-Projekt. Ich lernte, wie gemeinsame Softwareentwicklung funktioniert, wie Zusammenarbeit über räumliche Distanz gelingt und wie wichtig verständliche Dokumentation für den Erfolg einer Technologie ist.

Vor allem aber lernte ich, dass ein Entwicklerteam von unterschiedlichen Stärken profitiert.

Mein wichtigster Beitrag begann dort, wo ich aufhörte, mich ausschließlich mit den besseren Programmierern zu vergleichen.

2003–2006 · community4you

Mein erster richtiger Job als Softwareentwickler begann noch während des Studiums. Bei community4you arbeitete ich an einer Plattform zur Verwaltung von Unternehmensdaten.

Das Hauptprodukt des Unternehmens war kein klassisches Content-Management-System, sondern eine technische Grundlage für unterschiedliche Unternehmensanwendungen. Auf dieser Basis entstanden kundenspezifische CMS-, CRM- und Dokumentenmanagement-Lösungen.

Ich entwickelte an dieser gemeinsamen Plattform mit – nicht an einzelnen Kundenanwendungen.

Wenn Daten mehr können müssen als gespeichert werden

Bei solchen Anwendungen geht es um weit mehr als die Darstellung und Bearbeitung von Inhalten.

Unterschiedliche Nutzer benötigen unterschiedliche Zugriffsrechte. Metadaten müssen Informationen strukturieren und auffindbar machen. Geschäftsprozesse verlangen definierte Abläufe, Zuständigkeiten und Bearbeitungszustände.

Für mich war das der Einstieg in die Entwicklung komplexer Enterprise-Anwendungen: Rechte- und Rollenmodelle, Metadatenmanagement und die technische Abbildung von Workflows.

Softwareentwicklung als Unternehmensprozess

Eine weitere wichtige Erfahrung lag jenseits des eigentlichen Programmierens.

Durch meine vorherige Arbeit an Open-Source-Projekten kannte ich bereits die Zusammenarbeit mit anderen Entwicklern. Bei community4you lernte ich nun die Softwareentwicklung im Unternehmensumfeld kennen.

Anforderungen, Entwicklungsentscheidungen und die Zusammenarbeit innerhalb einer Organisation gehörten ebenso zum Arbeitsalltag wie der Code selbst.

Damit lernte ich nicht nur eine neue Klasse von Anwendungen kennen, sondern auch die organisatorischen Abläufe, in denen professionelle Software entsteht.

Ein Fundament für spätere Projekte

Die Arbeit zeigte mir früh, dass sich die Komplexität einer Anwendung häufig nicht an ihrer sichtbaren Oberfläche erkennen lässt.

Hinter einer scheinbar einfachen Funktion können umfangreiche Berechtigungsregeln, Datenmodelle und Prozessabhängigkeiten stehen.

Diese Erfahrungen begleiteten mich in späteren Projekten weiter – insbesondere beim Aufbau und der Modernisierung von Publishing-Plattformen.

Ein CMS verwaltet nicht einfach Inhalte. Es verbindet Daten, Menschen, Berechtigungen und Arbeitsprozesse.

Buchprojekt · 2004–2005 · erschienen März 2005

Angefangen hatte alles mit Open Source. Durch meine Mitarbeit am PEAR-Projekt war ich in der PHP-Community sichtbar geworden. Ich dokumentierte Software, schrieb Fachartikel und beschäftigte mich damit, komplexe technische Zusammenhänge verständlich zu erklären.

2004 erreichte mich die Anfrage, ob ich an einem Fachbuch mitarbeiten wollte.

Die Anfrage war eine direkte Folge meiner Arbeit an PEAR. Was als Engagement in einem Open-Source-Projekt begonnen hatte, führte mich nun in die klassische Buchpublikation.

200 Seiten im Briefkasten

Artikel für das PHP Magazin kannte ich inzwischen. Ein Buch war allerdings eine andere Erfahrung.

Besonders in Erinnerung geblieben ist mir ein dicker Umschlag, der eines Tages im Briefkasten lag. Darin: rund 200 Seiten ausgedruckter Text, versehen mit handschriftlichen Korrekturen.

Meine Aufgabe bestand darin, die Korrekturfahnen durchzugehen, die betreffenden Stellen am Computer zu finden und die Änderungen dort einzuarbeiten.

Ich war es gewohnt, Quellcode und technische Dokumentationen digital zu bearbeiten. Nun lag die Rückmeldung zu meiner Arbeit auf einem Stapel Papier vor mir.

Das war keine unüberwindbare Schwierigkeit. Aber eine bemerkenswerte Begegnung mit den Arbeitsabläufen der klassischen Buchproduktion – und eine Erfahrung, die sich in dieser Form für mich nie wiederholen sollte.

Ein Buch im Regal

Im März 2005 erschien „PHP 5 – Einsteigen und durchstarten“ (ISBN 978-3898642361).

Für mich war die Veröffentlichung ein besonderer Meilenstein. Aus der Dokumentation eines Open-Source-Projekts waren zunächst Fachartikel entstanden, schließlich die Mitarbeit an einem gedruckten Fachbuch.

Rückblickend war es der Höhepunkt meiner Arbeit im klassischen Printbereich – auch wenn ich noch viele Jahre für Fachzeitschriften schrieb.

Von der Dokumentation zum Journalismus

Das Buch war kein isoliertes Projekt, sondern Teil einer Entwicklung, die mit PEAR begonnen hatte.

Die Mitarbeit am Open-Source-Projekt führte zur technischen Dokumentation. Daraus entstand meine Arbeit für das PHP Magazin. Und aus der öffentlichen Wahrnehmung dieser Tätigkeit ergab sich schließlich die Anfrage zur Buchmitarbeit.

Der Weg vom Programmieren zum Schreiben verlief damit nicht als bewusster Berufswechsel. Eine Aufgabe ergab die nächste, und aus technischer Arbeit wurde zunehmend auch publizistische Arbeit.

Vom Quellcode zum Fachartikel und schließlich zum Buch: Meine ersten Schritte im Journalismus begannen nicht in einer Redaktion, sondern in einem Open-Source-Projekt.

Aus Code werden Geschichten.

Die Geschichten dahinter.

AI-Mentor

Erst die Fragen, dann die Antworten

Ein zweites Augenpaar

Ein Werkzeug, kein zusätzlicher Arbeitsschritt

Mehr Journalismus statt mehr Text

AI-Mentor

Erst die Fragen, dann die Antworten

Ein zweites Augenpaar

Ein Werkzeug, kein zusätzlicher Arbeitsschritt

Mehr Journalismus statt mehr Text

PUR-Modell

PUR: Wie aus einem Problem ein Geschäftsmodell wurde

Golem Plus: Eine Paywall für ein bestehendes Publishing-System

Nicht weniger Werbung, sondern mehr Journalismus

Nicht alles selbst entwickeln

Wenn aus mehreren Systemen ein Produkt wird

Ein neues Geschäftsmodell auf bestehender Grundlage

Golem Plus: Eine Paywall für ein bestehendes Publishing-System

Nicht weniger Werbung, sondern mehr Journalismus

Nicht alles selbst entwickeln

Wenn aus mehreren Systemen ein Produkt wird

Ein neues Geschäftsmodell auf bestehender Grundlage

Wenn der Code schneller entsteht als die Abstimmung

2024: Mehr als Autovervollständigung

KI sollte nicht nur beim Programmieren helfen

2025: Aus dem Experiment wird der Standard

Plötzlich war nicht mehr das Programmieren der Engpass

2026: Vom KI-Assistenten zum Agentic Workflow

Die nächste Herausforderung liegt außerhalb des Codes

Wenn der Code schneller entsteht als die Abstimmung

2024: Mehr als Autovervollständigung

KI sollte nicht nur beim Programmieren helfen

2025: Aus dem Experiment wird der Standard

Plötzlich war nicht mehr das Programmieren der Engpass

2026: Vom KI-Assistenten zum Agentic Workflow

Die nächste Herausforderung liegt außerhalb des Codes

Wie warm ist es in euren Büros? Mein Experiment mit Datenjournalismus

Aus einer Alltagsfrage wird ein Mitmachprojekt

8,5 Millionen Antworten

Die Werkzeuge waren Teil des Experiments

Und dann kam HTTPS

Nicht jede Antwort ist wichtiger als der Weg dorthin

Wie warm ist es in euren Büros? Mein Experiment mit Datenjournalismus

Aus einer Alltagsfrage wird ein Mitmachprojekt

8,5 Millionen Antworten

Die Werkzeuge waren Teil des Experiments

Und dann kam HTTPS

Nicht jede Antwort ist wichtiger als der Weg dorthin

30.000 Videos, 14 Portale, drei Monate: Abschied von Kaltura

Erst testen, dann entscheiden

30.000 Videos ziehen um

Drei Monate Entwicklung für 14 Portale

KI als Teil der Entwicklungsarbeit

Nicht nur ersetzen, sondern weiterkommen

30.000 Videos, 14 Portale, drei Monate: Abschied von Kaltura

Erst testen, dann entscheiden

30.000 Videos ziehen um

Drei Monate Entwicklung für 14 Portale

KI als Teil der Entwicklungsarbeit

Nicht nur ersetzen, sondern weiterkommen

Wenn Data auf Redaktion trifft: Zwei Welten, ein Publishing-Prozess

Zwei Fachbereiche, zwei Perspektiven

Von der einmaligen Migration zum regelmäßigen Import

Automatisierung braucht Zusammenarbeit

Wenn Data auf Redaktion trifft: Zwei Welten, ein Publishing-Prozess

Zwei Fachbereiche, zwei Perspektiven

Von der einmaligen Migration zum regelmäßigen Import

Automatisierung braucht Zusammenarbeit

DPA-Integration: Die Schnittstelle war das kleinste Problem

Eine Meldung ist noch kein Workflow

Wenn die Agentur schneller ist als die Redaktion

Die Technik muss den Redaktionsalltag verstehen

DPA-Integration: Die Schnittstelle war das kleinste Problem

Eine Meldung ist noch kein Workflow

Wenn die Agentur schneller ist als die Redaktion

Die Technik muss den Redaktionsalltag verstehen

Alte Inhalte, neue Sichtbarkeit: SEO als automatisierter Prozess

Wenn Zugriffsdaten zu Aktionen werden