Code für alle? Software-Engineering als Muster für den Journalismus der Zukunft


Eigentlich sollten in unserer durch und durch digitalisierten Gesellschaft auch Journalisten mit HTML und Java Script arbeiten können. Aber ist es wirklich notwendig? Der Internet-Pionier und Medien-Unternehmer Christoph Kappes macht sich ein paar grundsätzliche Gedanken über Software-Engineering als Muster für den Journalismus der Zukunft.

*

Datenjournalismus ist eine sehr ansehnliche Sache mit neuen Sichtweisen auf Daten, die sich interaktiv erschließen lassen, die große Datenmengen leichter verständlich macht und bei der man auch über logische und mathematische Operationen neue Daten erzeugen kann. Wer Datenjournalismus nicht kennt, bekommt bei Mirko Lorenz eine brauchbare Einführung und in der Berliner Gazette das Dossier Datenjournalismus zu übergreifenden Fragen.

Spannende Praxisanwendungen finden sich im Data-Journalism-Blog des Guardian. In der New York Times ist jüngst auch ein Überblick über die besten interaktiven Grafiken des Jahres 2012 erschienen, die ähnliche Ergebnisse zeigen. Auch in Deutschland gibt es gute Beispiele: In der Süddeutschen Zeitung etwa gab es ein Beispiel mit Zugverspätungen und ZEIT Online hat Bewegungsdaten veröffentlicht von jemandem, der sich mit seinem Handy bewegt hat und dessen Daten dabei von der sogenannten Vorratsdatenspeicherung erfasst wurden.

Sollen Journalisten künftig diese Art von Journalismus beherrschen, noch weitergehender: sollen Journalisten programmieren können? Meine Meinung: Das kann nicht schaden, aber es muss nicht sein. Wichtiger wäre, die Prinzipien des professionellen Softwareentwicklungsprozesses auf den Journalismus anzuwenden. Doch der Reihe nach.

Zur Programmierung selbst

Programmierung ist ein Handwerk, das sicherlich gut erlernen kann, wer ein Grundverständnis für Analyse, Mathematik und Logik mitbringt. Es zu Erlernen braucht – wie jedes andere Handwerk auch – seine Zeit. (Ich weiß gar nicht, wie viele Jahre ich programmiert habe, es mögen 15 sein; ich würde mich heute immer noch nicht als guten Programmierer bezeichnen.)

Die hohe Dynamik dieses Gebiets sollte nicht darüber hinwegtäuschen, dass viele Grundstrukturen von Dauer sind, also zum Beispiel Rekursion (sich selbst aufrufende Funktionen), Befehlsabfolgen, Schnittstellen (mit denen Programme miteinander kommunizieren) oder Datenstrukturen – auch dort ändert sich nicht so viel, zum Beispiel wie Tabellen funktionieren. Es mag dann ein Jahr oder ein halbes Jahr dauern, bis man da Grundkenntnisse hat und das erste Gefühl dafür entwickelt.

Gegen das Erlernen einer Programmiersprache spricht nichts. Ich denke sogar, dass es heute in die Schulausbildung gehört. Auch in der Journalistenausbildung ist es sinnvoll, Programmieren zu vermitteln. Es ginge dann dort aber nicht nur um das bloße Programmieren, sondern um Informationsverarbeitung im weitesten Sinne. Zum Beispiel darum, wie man auf welche Datenquellen zugreift, wo diese Datenquellen sich befinden, wie der Zugriff rechtlich zu handhaben ist und wie Nutzer-Interaktion konzipiert werden muss.

Es ginge also nicht nur um Datenoperationen, sondern auch um Werkzeuge, Anwendungskonzepte, Interaktionskonzepte und User Experience. Ein weites Feld, für das es in “meiner Internetbranche” schon mehrere Spezialberufe gibt, die mit Massenmedien gar nichts zu tun haben. En passant würde wohl auch besser erlernt werden, wie vielfältig Daten interpretiert und missinterpretiert werden können.

Universalbildung vs. Spezialisierung

Hinzu kommt: Programmierung ist das Paradigma des digitalen Zeitalters. Viele Erscheinungen lassen sich nur vor diesem Hintergrund erklären und verstehen; und zwar nicht nur naheliegende Strukturen von Internet-Informationsökosystemen (Aggregation, Filter usw.), sondern auch weiter entfernte Themen wie Finanztransaktionen, Logistikfortschritt, E-Partizipation.

Datenjournalismus aber ist, genauso wie Bewegtbild-Journalismus und eine Unmenge weiterer Spezialisierungen, eine Unter-Disziplin von Journalismus. Ich glaube nicht, dass diese Spezialisierung jeder können muss, im Hinblick auf das Ergebnis von gutem Journalismus hat Programmierkompetenz unter allen Spezialisierungen keine herausragende Sonderrolle. Aus diesem Grund würde ich es ablehnen, ganz allgemein zu fordern, dass Journalisten programmieren können müssten.

Manche Leute fordern, jeder solle Javascript und HTML können. Das halte ich nicht für zwingend. Es ist in einer modernen Gesellschaft aus meiner Sicht nicht mehr möglich, die Technik, die uns umgibt, im Detail zu verstehen und zu beherrschen, zumal – das vergessen Onlineprofis gerne – auch in anderen Fachgebieten sich Wissen vermehrt, das man eigentlich haben müsste, beispielsweise in Biologie, Chemie, Neurowissenschaften, Psychologie und Soziologie.

Ich würde sogar behaupten, dass jemand, der Menschen und Gesellschaft beobachtet, seine Zeit besser in Psychologie und Soziologie stecken sollte, weil sein Beobachtungsgegenstand nach den Gesetzen dieser Wissenschaften funktioniert und nicht programmierbar ist. Schön ist natürlich, wenn jemand alle Fähigkeiten und Kenntnisse aus Informatik, Politologie und Soziologie mitbringt, gut und verständlich schreiben kann sowie einen guten Riecher für Relevanz und Zusammenhänge hat. Das sollte man jedoch angesichts der typischen Bezahlung nicht erwarten.

Software-Engineering als moderner Prozess der Informationsverarbeitung

Ich glaube, dass hinter der vordergründigen Diskussion vielleicht ganz andere Fragen stecken. Programmierung (oder besser: Software-Engineering insgesamt) ist etwas möglicherweise Modellhaftes für informationsverarbeitende Berufe, weil die Dienstleistungsgesellschaft in ihrer modernen Prägung vor allem eine so genannte „Informationsgesellschaft“ ist und auch Medienberufe im weitesten Sinne zu den informationsverarbeitenden Berufen gehören.

Und weil beim Gegenstand von Medien häufig die Komplexität zunimmt, sind Phänomene im Software-Engineering möglicherweise hoch interessante Hinweise auf Lösungen zur Bewältigung dieser Komplexität:

1. Verteilte Wissensverarbeitungsprozesse entwickeln…

Wir haben in der Softwarebranche fast immer Teams, die eng zusammenarbeiten. Natürlich kann man Programme alleine schreiben und häufig sind Kernteams von Software auch sehr klein. Bei einem Softwarehersteller mit 1.000 Mitarbeitern sind es manchmal keine zehn Core-Entwickler. Aber Software-Engineering ist oft auf verteilte Wissensverarbeitungsprozesse ausgelegt: Teams arbeiten in Gruppen mit bestimmten Rollen zusammen und der Anspruch an die Zusammenarbeit ist sehr hoch, weil die einzelnen Gewerke (Module) nahtlos miteinander zusammenwirken müssen.

In jüngerer Zeit wird auch verteiltes Arbeiten an entfernten Standorten zum Normalfall, wobei auch die Organisation zunehmend loser, entgrenzter wird (vor allem im Offshore- und Nearshore-Bereich). Das Phänomen ist zunehmende Arbeitsteilung bei gleichzeitig stärkerer prozessualer Verzahnung und Steuerung der Einzelschritte.

… um die Qualitätsprobleme der Journalisten zu lösen

Dies weist meines Erachtens für den Journalismus in eine Richtung, um die Qualitätsprobleme zu lösen, die immer mehr wahrzunehmen sind. Vielleicht ist nämlich, was von Journalisten als „Zeitdruck“ und vom Leser als „Schlamperei“ wahrgenommen wird, das Ergebnis gestiegener Anforderungen. Mein Vorschlag ist, beispielsweise Tandems zweier Personen zu bilden oder Arbeitsprozesse mehrstufig anzulegen.

Zum Beispiel (ich kenne das von eigenen Texten zu Internetthemen nur zu gut) kann ein Experte am Anfang einer journalistischen Arbeit Input geben, wie ein Problem angegangen werden könnte, also beispielsweise ein WLAN-Sniff von Google, und auch am Ende könnte vielleicht ein Fachmann nochmal auf das Ergebnis schauen und die Qualität sichern. Es gibt Tausende von Experten, die das aus dem Stand könnten.

In diesem Beispiel mit dem WLAN-Problem hätte jeder Experte sofort erklärt, dass auch eine Google-Software gar nicht anders operieren konnte, als erst alle Daten „abzuhören“ (einschließlich der WLAN-Namen!), bevor sie entscheiden kann, ob sie die Daten speichert.

Auch wir müssen erst die Trillerpfeife hören, bevor wir uns die Ohren zuhalten. Und am Ende hätte vielleicht ein Experte einmal vorrechnen können, wie homöopathisch die E-Mail-Dosis sein muss, wenn man nur Netto-Daten betrachtet, nur Mails und nur die Sekundenbruchteile, in denen sinnhafte Worteinheiten erkennbar waren. Am Ende schaut also ein Fachmann darauf, genauso wie bei Texten über irgendwelche Facebook-Miniaturbilder, was ja im Kern ein juristisches Thema ist. (Bei urheberrechtlichen Fragen wundere ich mich regelmäßig über das eigenartige Selbstverständnis von Journalisten, die über so ein Fachthema schreiben, ohne auch nur über Grundlagenkenntnisse zu verfügen).

Es gibt fast keinen Text auf meinem Fachgebiet, der in technischer, wirtschaftlicher und rechtlicher Hinsicht zugleich fehlerfrei ist – und ich laste das nicht so sehr den Journalisten an, sondern sehe die Ursache im Fachgebiet, das mit common sense nicht mehr durchdrungen werden kann.

Die Lösung ist, arbeitsteilig vorzugehen: Schulterblickverfahren, Pärchenverfahren, gewisse Schrittweise und Prozesse, bei denen man sich näherungsweise an die Lösungen heranarbeitet. Das benötigt natürlich ein bisschen Zeit. Aber auch die Softwarebranche kennt mit „Extreme Programming“ sehr kurze Zyklen und Verfahren, wie man zum Beispiel innerhalb eines Tages zusammenarbeitet. Auch Software entsteht ja häufig unter Zeitdruck.

Ich glaube übrigens auch, dass die Erfahrung von Teamarbeit sehr wichtig ist, damit das schillernd-schrullige Genie ein Korrektiv erfährt. Die tatsächliche Sozialkompetenz so manches Leitkommentators, der Dritte öffentlich herabsetzt (ich denke an Broder vs. Augstein beispielsweise), ist keinen Deut besser als das Zerrbild des bleichen und schüchternen Programmiernerds, der vom Ketchup Flecken auf der Hose hat.

2. Vom Prozess her denken – nicht von den Publikationen

Der zweite Punkt ist, dass man im Software Engineering Arbeitsergebnisse als Prozess versteht. Ich halte es für faszinierend, dass das Nachrichtensystem so Event-getrieben funktioniert und auch heute noch so kurzlebige Ergebnisse produziert, obwohl es vielleicht anders möglich wäre. Hier wird jemand erschossen, da sagt jemand einen Satz, dort lassen sich zwei scheiden – und schon rauscht für 72 Stunden der Blätterwald, um danach nur noch ein Annex-Link zum nächsten Text zu sein, der Ähnliches verhandelt.

Der alte Text wird dann nur an den neuen Text angehängt, meistens um Kontexte wiederherzustellen oder um den Traffic zu erhöhen. Doch dieses Verfahren ist meines Erachtens auf Dauer falsch. Von der Grundidee sind es Themen, die sich gewissermaßen „quer durch die News“ ziehen und die tatsächlich kontinuierlich über drei Monate, drei Jahre oder dreißig Jahre Gültigkeit haben.

Mehr vom Prozess und weniger von der Publikation her zu denken, ist eine Denkweise, die Journalisten helfen würde, nicht mehr so stark getrieben zu sein. Eine Denkweise zudem, die auch dem Publikum helfen würde, nicht ständig von einer Irritation in die nächste zu taumeln – es ist ja eigentlich das Wesen nicht von Wissenserwerb, sondern von Unterhaltung, das psychische System zu irritieren und diese Irritation dann wieder aufzulösen.

Was die Software-Branche hier bietet, ist eine ganz andere Sicht, nämlich Software als Prozess. Software wird natürlich wegen des Ergebnisses für Jahre geschrieben (natürlich hält sie keine zwanzig Jahre). Aber es gibt eben auf dem Weg dahin Methoden, wie man Software in verschiedenen Stages entwickelt, wie man Release-Stände weiterentwickelt, wie man Change-Requests verfasst und wie man das systematisch managet. Es hilft, wenn man einmal diesen Softwareprozess mitbeobachtet hat, um diese Grundstrukturen möglicherweise auch auf journalistische Prozesse zu übersetzen.

Ich glaube, dass dies grundsätzlich die richtige Richtung ist. Für bestimmte Bereiche gibt es natürlich immer Ausnahmen, viele Agenturnachrichten müssen in Windeseile vom Ticker zum Publikum. Für hochwertige Medienmarken wäre es aber die bessere Lösung, dieses Feld den Marktführern zu überlassen. Oder es zu delegieren und ansonsten alle Nachrichten als Micro-Beiträge zu einem größeren Wissensprozess zu begreifen.

So könnte man, wie es beispielweise Wikipedia macht, in Seiten denken, die miteinander verlinkt sind und die in komplexen Strukturen wachsen – mit neuen Zweigen, die weiter sich verzweigen und die aber auch sterbende Zweige haben, die man wieder pflegen muss. Hierzu muss man sich ein paar neue Ansätze ausdenken.

Das wäre gerade für den hochwertigen „Long-Tail-Content“ wichtig, der zwischen 20% und 50% des Inhaltes vieler Nachrichtenangebote ausmacht und den zu verwerten bei allen Nachrichten-Websites Schwierigkeiten macht. Er wird meistens mühselig wieder neu paketiert, als Dossier oder als ausgelagerte Website recycelt. Es wäre ein großer Fortschritt, wenn man diesen wertvollen Inhalt um seine tagesaktuellen Aufhänger gewissermaßen „entmanteln“ könnte, weil dann meistens ein hintergründiges und komplexeres Thema zum Vorschein kommt.

3. Quellen zusammenstellen und verlinken

Mein dritter Punkt ist, dass Software-Ingenieure die sogenannte Runtime (Laufzeitversion von Software) von Quellcode unterscheiden. Die Runtime ist, was im Computer des Benutzers ausgeführt wird; der Quellcode ist etwas anderes, er ist das lesbare Ausgangsmaterial (Informatiker mögen mir diese Beschreibung nachsehen).

Ich denke, da ist eine Parallele zum Quellmaterial und dem Textergebnis des Journalisten. Unter Journalisten ist es bisher nicht sehr üblich, dass man Quellen zusammenstellt und verlinkt (letzteres ein Dauerstreit zwischen Onlinern wie mir und klassischen Journalisten, das möchte ich hier nicht vertiefen). Aber das Verfahren, dass man die Quelle mit dem Arbeitsergebnis „zusammenhält“ und auch immer wieder den Prozess rückwärts vom Arbeitsergebnis auf die Quelle machen kann, wenn man Probleme mit dem Ergebnis hat, das ist eine grundsätzliche Struktur, die vom Software-Engineering abgeguckt werden kann.

Wenn ich als Leser einen Text nicht gut interpretieren kann, möchte ich einen Schritt auf das Quellmaterial zurückgehen können – und diese Option würde, wenn sie denn journalistischer Standard werden würde, auch die Qualität journalistischer Endergebnisse verbessern wie auch den Zwist um Fehlinterpretationen von Quellen verringern.

4. Von der Fehlerkultur von Software-Engineering lernen

Der vierte Punkt betrifft den Umgang mit Fehlern. Jeder Software-Ingenieur sagt ganz entspannt, wach wenn schwere Probleme auftreten, dass „Software Fehler“ habe sei „bekannt“. Es ist ja in der Tat ausführlich erforscht, wie hoch Fehlerquoten bei Software sind. Niemand dort würde sich gekränkt fühlen oder es sonstwie persönlich nehmen, wenn man ihm einen Fehler nachweist; vielmehr ist das gelangweilte Reaktionsmuster meistens: „Ja, bitte trag meinen Fehler ins Bugtrackingsystem ein und dann wird ihn jemand korrigieren.“ Auch gibt es die freudigen Ankläger nicht, die auf Twitter teilweise zu beobachten sind, und die wegen jedes Fehlers mit dem Empörungsfinger auf andere zeigen.

Fehlerkultur ist der vierte Gesichtspunkt, bei dem Journalismus von Software-Engineering lernen kann. Das gilt auch gegenüber dem Publikum, wo der Software-Entwickler seine Nutzer inzwischen regelmäßig zur Kritik einlädt, wer kennt nicht die Feedback-Flyouts am Rande moderner Webseiten (z.B. von UserVoice). Wo sind die Fehler-Flyouts auf Online-Publikationen während der ersten Stunden nach dem Onlinegang?

Und jetzt noch weiterdenken bitte!

Denkt man noch ein wenig länger nach, wird es noch viel mehr Punkte geben. Beispielsweise ist Cross-Plattform-Development möglicherweise ein Muster (pattern) für Cross-Media-Contenterstellung. Und Binnenpluralismus von Medienredaktionen in der Software-Welt einem Multi-Tasking/Threading-System vergleichbar, dessen Tasks/Threads parallel und gleichberechtigt ablaufen.

Wie wäre es, längere Texte als Featureliste vorzuplanen und ganze Artikelstrecken kollaborativ zu planen und zu schreiben? (Auch ich habe mich vor zwei Jahren noch dagegen gewehrt und arbeite heute so mit großer Freude und gutem Ergebnis.)

Ja, vielleicht sind auch manche Debattenthemen wie ein Virus, der von Akteur zu Akteur getragen wird, mit dem wir uns anstecken, der sich von Tag zu Tag modifiziert und der unser Informationsökosystem aus dem Gleichgewicht bringt. Oder ist der Lobbyist ein Virus, der fremde Systemressourcen für den eigenen Zweck nutzt? Brauchten wir den alten Rhythmus der Print-Publikationen zur Denkpause mit “Garbage collection”? Es lohnt sich bestimmt, den Faden noch ein bisschen weiterzuspinnen.

Software-Engineering als Muster für Journalismus der Zukunft by ckappes

Anm. d. Red.: Weitere Beiträge zum Thema in unserem Dossier Datenjournalismus. Die Grafik im Text stammt von Datameer.

28 Kommentare zu “Code für alle? Software-Engineering als Muster für den Journalismus der Zukunft

  1. das ist wirklich großartig! chapeau! viele gute gedanken und schön souverän vorgetragen, ein echter schatz. nur über eine stelle bin ich gestolpert, da, wo es heißt, man könne nicht alles verstehen, deshalb könne man sich zurücklehnen und müsse es erst gar nicht versuchen.

    “Es ist in einer modernen Gesellschaft aus meiner Sicht nicht mehr möglich, die Technik, die uns umgibt, im Detail zu verstehen—”

    ich finde, gerade was die technifizierung der umwelt angeht, ist das ja ein konservativer gemeinplatz und selbst wenn man nicht alles verstehen kann, sollte man doch wenigstens versuchen, die komplexitäten der progammiertern welt in ihrer struktur zu raffen, wenn man schon nicht in der lage ist, den code dafür selber zu schreiben. also zumindest verstehen, was die progammierer uns da vorsetzen.

  2. @r2d2: Das Argument, dass man nicht alles wissen könne, ist so isoliert natürlich ein argumentum unsinnium, weil es für alles gelten könnte. Ich hatte bei dem Text vor allem Journalisten vor Augen, denen man ständig das Gegenteil erzählt, dass sie nämlich programmieren können müssten. Meine Negation ist eigentlich nur eine Spiegelung. Im Ergebnis sollte es darauf ankommen, was es zur Ausübung des Berufes nützt und ob die aufzuwendenden Ressourcen dazu im Verhältnis stehen.

  3. Sehr schöner Artikel und Gedanken – Vielen Dank!

    Ich denke auch, die benannten Herausforderungen an den Journalismus der heutigen Zeit wie auch der Zukunft sind Themen und Trends, die von Anforderungen der sozial vernetzten Gesellschaft bestimmt werden.

    Journalismus ist nicht nur das “Journal schreiben”, sondern auch eine Art “New Storytelling” über soziale Handlungen von Individuen in ihrer sozialen Gruppe und umgebenden Gesellschaft. Damit interagiert der Berichterstatter automatisch mit der sozialen Situation, über die er/sie berichtet.

    Und hier setzen die benannten Trends ein: Jegliche Produktion oder Produkt wird sich heute und noch mehr in Zukunft mit dem sozialen Umfeld auseinandersetzen müssen, für das sie oder es gemacht wurde. Da Menschen stets sozial vernetzt agieren, befinden sich ihre Handlungen und Produkte stets in einem Zustand der Weiterentwicklung – ein grundlegendes biologisches Prinzip: “Permanent Beta” – denn alles Lebendige entwickelt sich permanent weiter.

    Ein weiterer relevanter Trend lässt sich kurz umschreiben mit “Power to the People”:

    Ein Produkt, wie es auch eine journalistische Arbeit ist, das von einer Gruppe von Leuten genutzt, vulgo gelesen, wird, sollte schon vorab die Stärke der Produktion in einer Gruppe nutzen, um für die Zielgruppe einen Qualitätsmehrwert zu bieten. Ist die Qualität schlecht oder hat Mängel, weil es zu einseitig oder zu isoliert erstellt wurde, dann wird die Zielgruppe eh darauf reagieren – entweder im direkten Dialog (Leserkommentare – MIT Einflussmöglichkeit des Autors) oder in anderen Foren (OHNE Kenntnis des Autors).

    Darum lieber gleich die Stärke der sozialen Gruppe nutzen. Die zum übergreifenden Trend “Power to the People” zugehörigen einzelnen Themen und Trends sind bekannt:
    Sharing, Peer to Peer (p2p), Coworking, Crowdsourcing, Schwarmwissen und weitere.

    Damit gilt: Journalismus, der zeitgemäß bleiben will, muss sich den aufkommenden Trends auch öffnen – und da reicht es nicht, einfach nur als externe Beobachter über diese zu berichten.

    Darum sehe ich hierzu auch großes Potential bei sozialen News-Plattformen, wie sie beispielsweise durch Wikinews als einer der Pioniere dargestellt werden.

    Walter Matthias Kunze

    PS: ich befasse mich auch beruflich für meine Kunden mit dem Finden von Potentialen und deren pragmatischer Umsetzung in der Praxis. Das gilt auch für diese:
    Wie die Zukunft für Newsmedien und Bücher aussehen könnte, erarbeiten wir morgen im Rahmen der Social Media Week Hamburg in einem offenen Zukunftsworkshop: http://m.socialmediaweek.org/imps/smw/event.html?event_id=53543&rnd=7241703 – und man sieht aufgrund des hohen Interesses, dass hier großer Bedarf besteht, diese Medien neu zu diskutieren und neu zu erschaffen. Der WS ist zwar schon recht voll, aber bei Interesse gerne einfach vorbeikommen, es findet sich immer noch ein Platz…

  4. Herr Kappes beschreibt am Beispiel von Software-Entwicklung, wie journalistische Recherche seit Jahrhunderten funktioniert. Sammeln, aufbereiten, aggregieren, das Wesentliche präsentieren und das Unwesentliche zurücklegen und mehrfach oder später oder als Serie nutzen. Außerdem empfiehlt er Teamarbeit. Die soll früher auch schon vorgekommen sein.
    Passt alles auf sieben Zeilen. :-)

  5. @E. Schneider: mag sein, dass es zwischen Programmierern und Journalisten geteilte Tugenden und Methoden gibt, warum auch nicht, entscheidend ist doch, was in Zukunft zählen wird, was also stärker akzentuiert werden sollte. Was Christoph Kappes hier beschreibt hat definitiv wenig mit der Mainstream Praxis des Journalismus zu tun, sondern vielmehr zeigt er einige undercurrents auf und entwickelt auf dieser Basis ein paar echte Visionen für eine ansonsten so visionenarme Branche, z.B.:

    “alle Nachrichten als Micro-Beiträge zu einem größeren Wissensprozess zu begreifen. So könnte man, wie es beispielweise Wikipedia macht, in Seiten denken, die miteinander verlinkt sind und die in komplexen Strukturen wachsen – mit neuen Zweigen, die weiter sich verzweigen und die aber auch sterbende Zweige haben, die man wieder pflegen muss. Hierzu muss man sich ein paar neue Ansätze ausdenken.”

  6. die Frage ist finde ich umgekehrt auch, inwiefern Programmierer lernen müssen so zu denken wie Journalisten, wenn sie schon immer wichtiger werden in der Welt und im Journalismus speziell.

    Gibt es Werte? Techniken? Denkweisen, die sie übernehmen emulieren müssten?

  7. @CK#3: ich verstehe, man nennt sowas glaube ich eine darstellung deren verkürzung dem argument, das man machen willen, geschuldet ist: simplification for the sake of the argument… dem kann ich folgen und zustimmen.

    unabhängig davon ist im sinne von buckminster fuller allgemein- und universalbildung von großer bedeutung heutzutage (und dazu gehört in meinen augen ganz zentral auch die technik und digitalisierung in einem größeren zusammenhang gedacht)

  8. @WMK#4: permanent beta, das ist ein wirklich schönes stichwort!

    mal eine andere frage: ist wikinews nicht gescheitert, bzw. nie wirklich abgehoben? ich meine, eine schöne idee, die nie wirklich die kritische masse einer wirklichkeit erreichen konnte…

    und so fehlen im journalismus leider die best practise beispiele im geiste einer power to the people bewegung: es gibt einfach kein pendant zu wikipedia im bereich von journalismus und news…

  9. […] Christoph Kappes fragt in der Berliner Gazette, ob Journalisten programmieren lernen sollten: “Es ginge dann dort aber nicht nur um das bloße Programmieren, sondern um Informationsverarbeitung im weitesten Sinne. Zum Beispiel darum, wie man auf welche Datenquellen zugreift, wo diese Datenquellen sich befinden, wie der Zugriff rechtlich zu handhaben ist und wie Nutzer-Interaktion konzipiert werden muss.” […]

  10. @r2d2#15 – ixch denke, Wikinews war/ist ein Vorläufer. Zudem gilt immer: Wer zu früh kommt, ist zwar Pionier und schafft gewissermaßen die ersten Trampelpfade, aber die Masse kommt erst, wenn da bereits ein breiterer Weg vorhanden ist – sprich: Eine Art crowdsourced Journalismus wird sicherlich auf solchen Plattformprinzipien wie WikiNews oder Liveleak wie auch den bereits von einzelnen Newsmedien integrierten Prinzipien der Bürgerjournalisten und Gastautoren basieren – aber noch ist vermutlich die ideale leicht und schnell nutzbare Plattform nicht gefunden.Eventuell könnte die auch eine Art Open-News-Aggregator-App sein, die dann mehrere offene-Journalismus-&-News-Quellen zusammenfügt…

  11. Danke für die vielen Kommentare.
    Dieser Beitrag ist nur als Anregung zu verstehen, ich sehe Programmierung nicht als Massgabe für etwas, das nicht Programmierung ist. Ich habe zwei Dinge nebeneinander aufgestellt, ein bisschen gedreht, und beobachtet, was da wirken könnte.
    Man kann die Frage, wie Helekin oben fragt, selbstverständlich auch andersherum stellen. Journalisten sind sich nach meinem Eindruck viel klarer als viele Programmierer, dass sie mit Kommunikation neue Wirklichkeit schaffen. Beide wiederum, Prorgammierer und Journalisten, sind sich wohl weniger darüber im klaren, dass sie Information dekontextualisieren und rekontextualisieren.

  12. @#17: nur mal so kurz zur historischen einordnung: wikinews wurde 2004 ins leben gerufen (http://de.wikipedia.org/wiki/Wikinews). darin einen frühen versuch grasswurzel online-journalismus im großen stile zu betreiben ist schon okay, aber ein vorläufer dieser betrebungen und bewegungen ist wikinews NICHT.

    dann müsste man schon eher indymedia (http://de.wikipedia.org/wiki/Indymedia) aufrufen. das wurde 1999 gegründet und ist ein power to the people medium, dass wirklich skalieren konnte. leidergottes seit einiger zeit in einer tiefen krise steckt.

    also weit und breit kein wikipedia des journalismus zu sehen — leider, leider… warum nur?

  13. there is so much to be learned from software development for so many fields (including sport)

  14. An der Erstrebenswertigkeit besteht wohl nicht nur für Journalisten kein Zweifel. Leider erschließt sich mir der inhaltliche Zugang zu dem für’s Programmieren notwendige Grundwissen bislang nur sehr widerwillig.

Kommentar schreiben

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.