10 Jahre indymedia-CMS
Nach zehn Jahren ist das Indymedia-Content-ManagementSystem (CMS),
welches uns die Seiten täglich produziert in die Jahre gekommen. Am
Anfang stand Indymedia mit "Free Speech" alleine da, heute droht es
zwischen den unterschiedlichsten kostenlosen Angeboten für Blogs und
Co unterzugehen. Der Spam und die Kritik an den Mods nimmt zu, die
Beteiligung ab. Die Lösung: Die NutzerInnen der Seite mehr Möglichkeit
der Betiligung einräumen! Nur wie? Ein neues CMS muss her...
Das Netzwerk Indymedia wurde dieses Jahr 10 Jahre alt. Im November
1999 ging begleitend zu den Protesten gegen die Tagung der
Welthandelsorganisation (WTO) in Seattle das erste Mal ein IMC, ein
Indymedia Center online. Es bildete eine Gegenöffentlichkeit zur
restlichen sensationshungrigen etablierten Presse. Die Information
über Repression und Gewalt von staatlicher Seite konnte nicht mehr
verheimlicht und die Mär der gewaltbereiten DemonstrantInnen nicht
mehr aufrechterhalten werden. Der technische Fortschritt wurde der
Graswurzelbewegung zugänglich gemacht. Menschen ohne technischen
Sachverstand konnten Artikel und Bilder veröffentlichen - AutorInnen
sein.
Ermöglicht wurde dies durch die Entwicklung von offenen Content-
Management-Systemen (CMS), welche das Erstellen eines Artikel so
einfach gestaltet wie das Schreiben einer Email. Von den mittlerweile
über 180 IMCs weltweit verwenden eine Vielzahl entweder "Mir" oder "SF-
Active".
Die Situation 1999
Der Inhalt im Internet wurde noch überwiegend von verhältnismäßig
wenigen kommerziellen Betreibern erstellt und kontrolliert. Wer
Informationen ins Netz bringen wollte, musste technisch versiert sein,
d.h. HTML-Kenntnisse besitzen. Der breiten Masse stand zwar die
Bandbreite zur Verfügung, sie konnte jedoch nicht Inhalte öffentlich
produzieren. In diesem Umfeld war Indymedia ein Wegbereiter.
Web 2.0
Durch die Weiterentwicklung und Verbesserung der Techniken im Netz
steht nun allen eine großer Werkzeugkasten zur Verbreitung von
Informationen zur Verfügung. Die Technik wurde grundsätzlich schon in
der ersten DotCom-Phase entwickelt, für Laien einsetzbare Frameworks
und Anwendungen entstanden aber erst in der zweiten DotCom-Welle.
Ferner ist die verfügbare Bandbreite zur Übertragung von Daten
gewachsen. Der Transfer auch von großen Videos und Streams stellen
keine Hürde mehr dar. Ein nicht unbeträchtlicher Anteil der
InternetbenutzerInnen beteiligt sich ganz selbstverständlich an
sozialen Netzwerken, zwitschert mit dem Handy und konsumiert sowie
(und das ist viel wichtiger!) produziert Filme auf der Seite der
größten Suchmaschine der Welt.
Und Indymedia?
Die beiden Indymedia-Content-Management-Systeme Mir und SF-Active
wurden zu Beginn des Jahrtausends von AktivistInnen entwickelt, da es
zu diesem Zeitpunkt keine Anwendungen gab, um das Ziel der
MedienaktivistInnen zu verwirklichen: Die Menschen an der
Medienlandschaft als ProduzentInnen zu beteiligen, in dem Leute
anonym, ohne Kenntnis der Web-Sprache HTML und ohne Zensurinstanz wie
etwa einer Redaktion Inhalte wie Texte oder Bilder veröffentlichen
können. Die politisch Aktiven sollten lernen, sich nicht auf die
kommerziellen bürgerlichen Medien zu verlassen, sondern aktive
JournalistInnen zu werden, die Zensur zu umgehen und den "Free Speech"-
Gedanken zu verwirklichen.
Mittlerweile ist es hingegen kein Problem mehr, Inhalte ins Internet
zu stellen. Kommerzielle Anbieter schaffen die Möglichkeit, dass jedeR
kinderleicht eigene Seiten für Lau zusammenstellen kann. Die für
Indymedia eingesetzten Systeme jedoch wurden über Jahre nicht mehr
weiter entwickelt. Vieles daran ist selbst geschrieben, es werden
nunmehr veraltete Frameworks verwendet und die EntwicklerInnen sind
nicht mehr verfügbar. Moderne Techniken wie etwa Flash sind nicht
realisiert. Ferner existieren eine Vielzahl von Beschränkungen wie
etwa die mangelnde BenutzerInnenverwaltung, die Möglichkeit, eigene
Texte noch einmal zu ändern oder die das Größenlimit für
Mediendateien. Trotzdem besitzen sie aber immer noch eine immense
Stärke und Alleinstellungsmerkmal, die von den ursprünglichen
EnticklerInnen als zentrales Element enwickelt wurde: Nach der Eingabe
des Artikels erstellt der Server (Producer) statische HTML-Seiten aus
der Datenbank, die dann sehr leicht auf Spiegel-Server (Mirrors)
kopiert werden können. Da die Anforderung an solche Mirrors sehr
gering sind, ist es leichter, welche zur Verfügung gestellt zu
bekommen. Die Vergangenheit hat gezeigt, wie es wichtig ist, den
Inhalt der Seiten auf viele Mirrors zu verteilen, denn so kann
einerseits eine größere Zugriffszahl verarbeitet werden und zweitens
Zensur und Repression erschwert werden.
Dennoch: Die Situation heute ist skurril: Die Indymedia-BenutzerInnen
sind mittlerweile teilweise auf sehr hohem journalistischen Niveau und
durchaus gewohnt, wie Inhalte aufzubereiten sind. Jedoch ist das
System, was ihnen dabei helfen soll dem nicht mehr gewachsen. Es
können eweder Inhalte korrigiert noch Videos eingebunden werden.
Benutzergruppen sind nicht vorgesehen und auch das Abstimmen über
Inhalte ist nicht möglich. Alles Techniken, welche die BenutzerInnen
gewohnt sind.
Brauchen wir wirklich ein neues System?
Die aktuelle strukturelle Situation des deutschen Indymedia-Ablegers
(sicherlich vergleichbar mit anderen IMCs) hat Anne Roth kürzlich ganz
gut auf den Punkt gebracht. Die Frage ist nun: Warum ist Indymedia so
zeitintensiv? Und warum gibt es nicht genug Leute, die helfen? Ich
denke - und ich stehe damit nicht alleine - , es gäbe genügend Aktive,
die mithelfen würden, die sich aber nicht gleich in die
Moderationsschichten einteilen lassen wollen und dafür auch noch
Kritik für die immer falsche Entscheidung zu bekommen. Ich denke auch,
dass sich eine Vielzahl der Arbeiten der ModaratorInnen auf derzeit
"normale" NutzerInnen der Seite übertragen ließe, was die anfallende
Arbeit nicht mehr auf ein bis drei sondern auf ganz viele Schultern
verteilte und die Schwelle zum Mitmachen verringerte. Es gibt in einem
Indymedia nun einmal mehr Gruppen als nur SchreiberIn, LeserIn und
ModeratorIn.
Indymedia braucht ein neues CMS, um einerseits Unzulänglichkeiten aus
den derzeitigen zu beheben und andererseits - und das ist viel
wichtiger - mehr Menschen mit mehr und unterschiedlichen Befugnissen
an einem emanzipatorischen, gleichberechtigten, unkommerziellen und
interessanten Nachrichtenportal einzubinden und die Transparenz zu
erhöhen. So etwas war vor 10 Jahren noch nicht möglich, heute aber
schon. Es geht nicht mehr darum, möglichst einfach irgendwelche
Informationen in die Welt zu setzen, sondern darum, wie Prozesse eine
heterogenen Gruppe von MedienaktivistInnen basisdemokratisch und offen
abgebildet werden und damit sich der Inhalt der Seite selbst
reguliert. ModeratorInnen sind nur noch in seltenen Streitfällen
benötigt.
Die Suche nach einem neuen CMS...
Im Jahre 2006 hat sich eine weltweite Arbeitsgruppe gegründet, die
nach Alternativen zu den derzeitigen Systemen sucht. Es gab mehrere
Techmeets und Diskussionen auf einer Mailingliste. Untersucht wurden
zunächst eine Vielzahl von existierenden OpenSource-CMS's auf deren
Tauglichkeit für Indymedia: Drupal, Joomla, Plone, Typo3, Wordpress
und noch einige mehr. Das Ergebnis: Anonym Artikel veröffentlichen ist
mit diesen Software-Systemen genau so möglich wie eine mehrstufige
BenutzerInnenverwaltung für AutorInnen zur Änderung eigener Texte.
Auch die Verwendung von multimedialen Formaten ist damit möglich.
Ungeklärt blieb bei allen untersuchten Systemen, ob und wie sich die
Artikel als statische Seiten produzieren und auf Mirrors verteilen
lassen. Alternativ könnte man sich vorstellen, mehrere identische
Server in einem Verbund ("Cluster", "Cloud"...) zu betreiben. Auch
hier ist noch nicht klar, ob das mit den OpenSource-Systemen möglich
ist. Entwickelt wurde von der Arbeitsgruppe ein Proof of Concept, in
dem eine Neuentwicklung unter Einsatz von leistungsstarken Frameworks
vorgeschlagen wird. Zwei andere Fraktionen der AG schlugen entweder
die Erweiterung von Drupal oder den Einsatz von Plone vor.
Einige IMCs haben das schon einmal umgesetzt: Drupal wird mittlerweile
beispielsweise von linksunten eingesetzt. Ferner gibt es auch schon
eine funktionelle Nachbildung von Mir in Plone. Ich denke für nicht
allzu große Indymedia-Seiten könnte dieser Weg eine Alternative sein.
Die Eigenentwicklung!
Vielleicht ist es töricht, erneut ein neues CMS zu entwickeln, wenn
wir doch gerade zwei selbst entwickelte Systeme nicht mehr warten
können. Jedoch heisst Indymedia selber machen. Deshalb betrachten wir
doch einmal das Konzept für eine Neuentwicklung:Basierend auf zwei
leistungsstarke Frameworks (ICE (Vernetzung der verschiedenen Module)
und CakePHP (Web-Framework)) soll ein leicht zu erweiterbares,
modulares, skalierbares und dynamisches System geschaffen werden. Das
System besteht aus drei Schichten und vier Modulen:
• Eine dynamische Webschicht: (ehem. Posting-Server/Producer):
Softwaremodul, über das man Artikel posten sowie suchen und Medien
hochladen kann.
• Eine statische Webschicht (ehem. Mirrors): Produzierte statische
HTML-Seiten werden auf schlanken HTML-Servern angeboten.
• Eine Gridmanagement-Schicht: Sie sorgt dafür, dass Anfragen in der
dynamischen Webschicht den Weg zur Datenbank finden und umgekehrt.
Dies übernimmt das ICE-Framework mittels Remote-Procedure-Calls
(RPC,sinngemäß "Aufruf einer fernen Prozedur"). Ferner müssen beliebig
viele Webserver mit beliebig vielen Datenbank-Servern vernetzt werden.
• Das Backend: Datenbanken, in der die Artikel gespeichert werden und
die Medien abgelegt werden.
Vorteile
• Flexible Anforderungen: Es kann beliebig viele Posting-Server,
statische Webserver und Datenbanken geben. Mirror-Betreibende können
entweder nur statische Seiten anbieten oder/und einen Posting-Server
stellen (hierfür wird nur noch PHP benötigt, jedoch keine Datenbank).
Indymedia Seiten können auf viele verschiedene Server (Idealfall: Jede
WG hat einen Mirror) aufgeteilt werden.
• Idealerweise können alle Mirrors für alle IMCs verwendet werden.
Die Gridmanagement-Schicht übernimmt die Zuordnung.
• Durch CakePHP stehen viele Erweiterungen zur Verfügung, die jedes
IMCs je nach Wunsch hinzufügen kann.
• Das ICE-Framework verbindet viele verschiedene Programmier-
Sprachen, sodass jedeR in seineR Lieblingssprache entwickeln kann.
• Durch die modulare Struktur kann an verschiedenen Enden des Projekt
unabhängig gearbeitet werden.
Als Beweis, dass diese Struktur funktioniert, wurde ein Prototyp
namens "Malandro" entwickelt, das man sich auch hier ansehen kann.
Konkret: Die WunschlisteVor allem für das Frontend lässt sich
resultierend aus der Arbeit mit den aktuellen Systemen folgende Liste
an Features (CMSWhatWeWant (en)) zusammenstellen, die noch lange nicht
vollständig, aber auch noch lange nicht zu Ende diskutiert sind. Eine
Möglichkeit zur Diskussion wird in Kürze auf cms.indymedia.org zur
Verfügung stehen.
• Userlogin: Möglichkeit Autorennamen zu reservieren. Es sollte
möglich sein schnell andere Artikel des selben Autors aufzufinden
sowie z.B. rss-Feeds mit Beiträgen einzelner Autoren zu abonnieren
oder Twitter-Follower des Autors über Veröffentlichungen zu
unterrichten. Ein einmal registrierter Autorenname sollte für alle
Indyseiten gelten. Evtl. Integration von social networking Elementen
wie Budylists o.ä. Möglichkeit Autoren zu kontaktieren ohne deren
Mailadresse zu kennen.
• Userstatus: Möglichkeit registrierte Autoren als verifiziert zu
kennzeichnen.
• Access Control: Abgestuftes System von Access Rechten, z.B. für
Moderatoren, erfahrende und gut bewertete User. Möglichkeit des
nachträglichen editierens eigener Beiträge.
• Version Control: Möglichkeit früher Versionen eines Artikels
einzusehen, falls dieser verändert wurde. Möglichkeit der
Deaktivierung dieses Features bei einzelnen Texten durch die
Moderation (z.B. um private Daten zu schützen).
• User Moderation: Möglichkeit Inhalte auf der Seite zu bewerten mit
Auswirkung auf die Darstellung der Inhalte (Uprgade, Downgrade, evtl.
auch Verstecken) und auf die Bewertung des Autors (bei vielen gut
bewerteten eigenen Berichten könnte z.B. die eigene Stimme stärker
gewichtet werden, bzw. evtl. könnten sehr viele gute Bewertungen auch
zu direkten Moderationsrechten führen).
• Notify Moderator Button: Einfache Möglichkeit die Moderation mit
einem Klick auf problematische Inhalte hinzuweisen.
• Anpassungsmöglichkeit der Seitendarstellung: Auf de.indymedia.org
existiert derzeit die Möglichkeit zwischen verschiedenen Stylesheets
zu wählen. Darüber hinaus evtl. die Möglichkeit bestimmte Inhalte
prominenter, weniger prominent oder auch gar nicht darzustellen.
• RSS Reader: Für den Blogwire wieder mit der Mögichkeit die Inhalte
zu bewerten, so das schlechte Feeds ohne Zutun der Moderatoren nicht
mehr dargestellt werden.
• Accessability: Auch Menschen mit älteren Rechnern (oder auch
Handies?) soll der Zugriff auf die Seite ermöglicht werden.
• xhtml Validation: Fehlerhaft gesetztes (x)HTML sollte korrigiert
und zumindest validiert werden
• Geographic Information System: Möglichkeit Artikel mit genauen
Kartendaten zu ergänzen.
• Fotogalerien: Ansprechende Darstellung von Bildern wie dies etwa
mit Lightbox realisert wurde
• Optionen zur Lizenzierung: Auf de.indymedia.org bereits umgesetzt.
• wysiwyg: Online Editor mit Formatierungsoptionen
• Anti-Bot System wie CAPTCHA
• Einfache Installation
• Benutzerfreundliche Videointegration: äußerlich sollte es laufen
wie YouTube, aber Flash ist natürlich doof, Untertitelsupport
• Unterstützung der Mehrsprachigkeit: a) Wörterbücher integrieren, b)
Übersetzungen sollte ohne Umweg über Mailinglisten möglich sein. c)
Automatische Verlinkung übersetzter Inhalte unter den ursprünglichen
Artikel mit richtigen Sprach-Tag
• Notifying Optionen: Automatische Mails o.ä. z.B. bei Ergänzungen
eines Beitrages oder neuen Beiträgen bestimmter Autoren
• Hilfe / Dokumentation: Im Frontend integrierte Hilfefunktionen
• Direkte Moderation: Moderieren von Beiträgen aus der normalen
Seitenansicht heraus, ohne erst in die Admin Oberfläche wechseln zu
müssen.
• API: Simple Schnittstellen zur Weiternutzung von Inhalten. (RSS, etc)
• Einfache Administration: Aussehen und Funktionalität des Frontends
sollten ohne großes technisches Know-How anpassbar sein. (einzeln
installierbare Module)
• Bidirektionaler Text: Vollständige Unterstützung von
bidirektionalem Text (in Formularen und im Seitenlayout) und
ungewöhnlichen Schriftzeichen (auch nicht in Unicode enthaltene)
• Automatisiertes Versenden gesperrter Inhalte: Bei Aufruf der URL
eines gesperrten Artikels, sollte die Möglichkeit bestehen, sich
diesen automatisiert zusenden zu lassen. Diese Option muss
deaktivierbar sein um persönliche Daten wirksam schützen zu können.
• Bildbearbeitung: Möglichkeit notfalls Gesichter unkenntlich zu
machen etc.
• P2P-Unterstützung: Möglichkeit, Medien über Peer-to-peer Netzwerke
zu übertragen (bitorrent etc.)
• Cross-Site Search: Suche über alle IMC
• VoIP
• Posibility of Multi-node, like estrecho.indymedia.org
Wie weiter?
Nun braucht's entschlossener EntwicklerInnen, die beispielsweise
lokale Entwicklergruppen bilden und an Modulen arbeiten.
--
rohrpost - deutschsprachige Liste zur Kultur digitaler Medien und Netze
Archiv: http://www.nettime.org/rohrpost
http://post.in-mind.de/pipermail/rohrpost/
Ent/Subskribieren: http://post.in-mind.de/cgi-bin/mailman/listinfo/rohrpost/
