[rohrpost] 10 Jahre indymedia-CMS

Don Dez 31 00:30:38 CET 2009

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.