Welche Zukunft haben Open-Source-Webapplikationen?

Einige Open-Source-Webapplikationen dominieren das Web – aber wie kommen kleinere Projekte zurecht?

Nach eigenem Bekunden sind weltweit mehr als 20 Prozent aller Webseiten mit WordPress realisiert. Manche Analysten kommen auf noch höhere Werte. WordPress ist der Prototyp einer Anwendung fĂŒr Webserver, die unter einer quelloffenen Lizenz steht und sich mit der weitverbreiteten Serverzusammenstellung Linux, Apache, MySQL und PHP -ebenfalls alles unter quelloffenen Lizenzen verfĂŒgbar – begnĂŒgt.

„Welche Zukunft haben Open-Source-Webapplikationen?“ weiterlesen

Sind soziale Netzwerke ein Unfall der Hosting-Branche?

datacenter server racks Image

Warum haben sich geschlossene Plattformen wie Facebook, Linkedin, Twitter so verselbstÀndigen können? Was wurde aus dem freien, offenen Web und sind propretÀre, soziale Inhalte- und Sharingplattformen vielleicht ein Unfall der Hosting-Industrie? Zumindest sind sie deren ernsteste Bedrohung.
Ende der 1990er Jahre waren Computeranwender endlich in der Lage, digitale Inhalte im offenen Internet selbst zu veröffentlichen. Private Publishing im neuen, offenen World Wide Web war möglich. Nicht nur Studenten an UniversitĂ€ten kamen in den Genuss dieser neuen Möglichkeit. Dank technischer Dienstleister, die das MassengeschĂ€ft ĂŒbernahmen, war – zumindest in freien Gesellschaften – die eigene WebprĂ€senz fĂŒr jedermann erschwinglich und möglich. Eine neue Branche entstand, die Hosting-Branche. FĂŒr kleines Geld konnte man sich ein BĂŒndel aus Domainregistrierung, Serverspeicherplatz und E-Mail-Dienst abonnieren.

Private Publishing im WWW anno 1997

Zu dieser Zeit gab es viele technische BeschrĂ€nkungen. Feedback von Usern einzuholen und zu verarbeiten, war schwer zu realisieren. Die eingesetzten Server waren noch nicht so leistungsfĂ€hig und Speicherplatz war noch teuer. Möglichkeiten fĂŒr Interaktionen und dynamische Inhalte waren gegeben, lĂ€ngst aber nicht selbstverstĂ€ndlich und eher aufwĂ€ndig. Die ersten AnsĂ€tze waren GĂ€stebĂŒcher und Feedbackformulare, vielleicht auch Umfragen und Ă€hnliche einfache Interaktionsmöglichkeiten.

Php & MySql brachten Anwendungen wie WordPress oder SugarCRM hervor

Erst mit der Verbreitung von PHP als quelloffene und somit kostenfreie Scriptsprache fĂŒr serverseitig auszufĂŒhrende Anweisungen und einer Datenbanklösung, in diesem Fall MySQL, war mehr machbar. So entstand das, was einige Zeit lang als Web 2.0 bezeichnet wurde, das „Mitmach-Web“. Speicher und ProzessorkapazitĂ€t war billiger zu bekommen, die Rechenzentren wuchsen.

Viele Hosting-Unternehmen haben Technologien wie PHP und MySQL unterstĂŒtzt, aber es versĂ€umt, dem Kommunikations- und Vernetzungsbedarf der Webseitenbetreiber Rechnung zu tragen. Als User konnte sich einzelne Webdokumente im Browser bookmarken, aber die Konnektierung mit Usern war schwierig. RSS/Atom/XML-Feeds sollten Contents syndidizierbar machen, setzten aber wieder eine eigene Technologie voraus.

Dank der hohen Verbreitung von PHP und MySQL entwickelte sich eine florierende Open Source Landschaft, aus der so phantastische Anwendungen wie WordPress, Joomla! und Co hervorgingen. Content im Web bereit zu stellen, war nie einfacher.

Das Modell des zufĂ€llig surfenden Users 

Webseiten bezogen sich mehr und mehr auf einen Gegenstand, eine Organisation, ein Unternehmen. Verlinkungen auf andere Domains wurden seltener. Das Hypertextprinzip wurde nicht mehr voll ausgeschöpft.

Die Folge: Inhalte im Web konnten zunÀchst nur per manuell editiertem Webkatalog, per Linkliste oder per Suchmaschine zugÀnglich gemacht werden. Suchmaschinen wurden zur meistgenutzten Anwendung. Dabei basiert Googles elementarer PageRank-Algorithmus vor allem auf der Idee des Hyperlinks und dem Modell des zufÀllig surfenden Users, der sich von Link zu Link hangelt. Ein Modell, das der Praxis zunehmend weniger entsprach. Es gab das Bild des Surfers bald nicht mehr.

WĂ€hrend der großen Zeit der Google Suche war die Position auf der jeweiligen Suchergebnisseite fĂŒr wichtige Keywords entscheidend. Der Traffic kommt heute mehr und mehr von Verlinkungen aus BeitrĂ€gen in Social Media Plattformen. Man liest einen Teaser online und klickt auf den Link, um den Rest der Story konsumieren zu können. Dabei ist die Story meist in Wort und Bild gekleidete Werbung, Native Advertising.

Native Advertising: Was ist Content, was ist Werbung?

Einige Inhalteanbieter, Contentaggregatoren oder -distributoren gehen sogar dazu ĂŒber, Inhalte nur ĂŒber Facebook oder Linkedin zu platzieren und die Story gar nicht mehr auf die eigene Website zu schreiben. Leute, die Modeblogs anbieten, prĂ€ferieren heute Instagram. Das ginge schneller, ist optischer und das Teilen der Inhalte ginge einfacher von statten. Vorteile, die nicht von der Hand zu weisen sind. Entscheidend ist, wieviele Augenpaare man erreicht, nicht wie viele Page Impressions auf der werbefinanzierten Webseite generiert werden. Dieses alte Web-GeschĂ€ftsmodell ist auch aufgrund der Verbreitung von Adblockern ohnehin in Gefahr. Fest steht, dass immer mehr Contents in geschlossene Plattformen verlagert wird. Das offene Web stirbt.

Steht man auf dem Standpunkt, dass das offene Web grundsÀtzlich ein Wert an sich ist, kann man fragen, wo ist was schief gelaufen?

Was ist aus dem offenen Web geworden – alles nur noch Timeline?

NatĂŒrlich haben auch die Apps fĂŒr ohnehin schon proprietĂ€re mobile Betriebssysteme dafĂŒr gesorgt, dass das offene Web zurĂŒckgedrĂ€ngt wird. Den Hauptteil an Traffic auf MobilgerĂ€ten erzeugen Apps, nicht der mobile Webbrowser.

Dank der Veröffentlichung von PHP und MySQL unter Open Source Lizenzen fanden Content Management System wie WordPress, Joomla!, Drupal und in Deutschland insbesondere auch Typo3 eine große Verbreitung. Dank der großen Verbreitung gab es auch große und agile Entwicklercommunities, die von Version zu Version ĂŒberzeugende Features geliefert haben.

Die Open Source CMS – Lösungen wurden von Hostingunternehmen gerne aktiv angeboten. FĂŒr Kunden entstand durch die einfache Installation Mehrwert. Allerdings ist kein Benefit an die Entwicklercommunities zurĂŒckgeflossen. Sie waren von Spenden abhĂ€ngig oder fanden einen Großsponsor, so dass neben der Community-Version bald eine lizenzpflichtige Version mit mehr Support und Funktionen erstellt wurde.

Wie hĂ€tte sich Open Source social software besser entwickeln können? 

Einige CMS haben sich gut entwickelt, ebenso Tools wie Piwik oder CRM-Anwendungen. Leider haben es Social Media Plattformen nicht ĂŒber Achtungserfolge hinaus geschafft. Leider war einem Friendica, einem Diaspora oder Elgg der große Durchbruch nicht vergönnt. Daneben gibt es noch eine Handvoll Social Media Frameworks mit einer dezentralen Struktur, die aber ĂŒber das Betastadium nicht hinauskommen.

Vielleicht hĂ€tten sich die vielen Rechenzentrumsbetreiber und Hoster frĂŒher um soziale Netzwerke bemĂŒhen sollen. Es gibt offene Standards, die einen Austausch von Profildaten und Graphen ermöglichen. Damit könnte eine quelloffene, dezentrale Struktur ermöglicht werden, so wie es in Friendica auch angelegt ist.

Zu lange haben Hoster zugesehen und zumindest insgeheim darauf gehofft, dass social media ein schnell vorĂŒbergehendes PhĂ€nomen ist, dem die User bald ĂŒberdrĂŒssig werden wĂŒrden. Ein Fehlschluss. Facebook und Co haben mit Hochdruck daran gearbeitet, fĂŒr immer neue Zielgruppen interessant zu werden und zu bleiben. Ein SelbstlĂ€ufer war das nicht, wie man am Schicksal von MySpace und StudiVZ unschwer erkennt.

Gibt es noch Leben in der Social Media Welt mit Open Source?

Die aktuelle Friendica Version trÀgt die Nummer 3.3.3, kann aber mit dem enormen Entwicklungstempo kommerzieller Plattformen nicht mithalten. Die User Experience ist mit Facebook oder Twitter einfach nicht zu vergleichen, von der Anzahl der Teilnehmer ganz abgesehen.

Das Problem des Sterbens des offenen Webs haben viele Unternnehmen erkannt. Einige haben sich in der Internet Defense Leage (https://www.internetdefenseleague.org) zusammengeschlossen. PHP, WordPress und Mozilla sind prominente Teilnehmer.

Eigentlich mĂŒsste auch Google daran interessiert sein, das offene, sich agil entwickelnde Web zu erhalten. Durch die Notwendigkeit, Milliarden Webseiten indizieren zu mĂŒssen, um Inhalte und Informationen zugĂ€nglich zu machen, hat Google viel Geld verdient. Die Anzeige von Werbebotschaften, die zu einer Sucheingabe passen, ist heute noch der mit Abstand grĂ¶ĂŸte Umsatzstrom fĂŒr Google, der geringer wird, wenn immer mehr User ĂŒber Social Media News und Informationen konsumieren und teilen.

Im Prinzip kann man Webseitenbetreiber nur ermutigen, die bisher betriebene OnlineprĂ€senz fortzufĂŒhren. Ein Verlass auf Social Media Plattformen zur Veröffentlichung eigener Contents ist gefĂ€hrlich: Was passiert, wenn die Plattform eingestellt wird, die Richtlinien Ă€ndert oder das GeschĂ€ftsmodell? Dann sind im extremen Fall alle Inhalte und Kontakte verloren. 

Ghost – einfach nur bloggen, aber erst mal installieren!

Einfach nur Bloggen – das ist die Leitidee der Macher der
neuen Blogsoftware Ghost.
Ghost unterliegt wie viele andere Bloganwendungen einer
quelloffenen Lizenz. Jeder kann mit- und weiterentwickeln und – eigentlich ist
das ein Nebeneffekt – die Software kostenlos verwenden.
Ghost ist nun öffentlich verfĂŒgbar. Wer jedoch glaubt, es
genĂŒge, eine Zip-Datei herunterzuladen, diese zu entpacken, auf einem
Serverspeicherplatz abzulegen und „install.php“ auszufĂŒhren, wird enttĂ€uscht. 
Ghost baut nicht auf PHP, sondern auf dem Node JS – Framework auf. Als
Datenbank ist standardmĂ€ĂŸig SQLite vorgesehen, aber auch mit mySQL funktioniert
das. Node JS verwendet einen eigenen http-Server.
Das hat einige Konsequenzen.

Server benötigt Node.js 

ZunÀchst muss der Server, egal, ob er unter Windows, MacOS
oder Linux lĂ€uft, node.js unterstĂŒtzen. Falls dies nicht der Fall ist, muss man
die Installation vornehmen. Das ist von System zu System unterschiedlich. Ich habe
versucht, Ghost auf einem virtuellen Server mit Debian Linux zu installieren
und musste node.js natĂŒrlich zunĂ€chst nachinstallieren. Node.js ist auch noch recht frisch. Daher Ă€ndern sich die Releases schnell. Die offiziellen Repositories der Distributionen könnten veraltet sein. Vielleicht ist ein Selbstkompilieren hier tatsĂ€chlich besser. 
FĂŒr meinen virtuellen Server
habe ich mich nach dieser Installationsanleitung gerichtet, was gut geklappt
hat: http://www.sysadminslife.com/linux/howto-node-js-installation-unter-debian-squeeze-wheezy-ubuntu/
ZunÀchst habe ich versucht, Git zu verwenden, was ich auch
erst nachinstallieren musste. 

Installation auch ĂŒber git möglich 

Da die Installation von Git auf dem V-Server
nicht reibungslos lief, habe ich die Installationsprozedur per Zip-Datei gewÀhlt.
Ich habe das Installationspaket von github geladen, aber spÀter gesehen, dass
Bitnami schon einen fertigen Stack bereit hÀlt, was ich jedoch nicht
ausprobiert habe: http://bitnami.com/stacks
Wenn Node.js installiert ist, kann man sich an die
Installation von Ghost wagen. Also: Datei hochladen, entpacken (oder je nach
Geschmack auch umgekehrt), und dann in die Konsole (ich habe das als Root
vorgenommen) den Installationsbefehl ausfĂŒhren: npm install –production .

Weird error 8

Mit „NPM Start“ kann man dann sehen, ob sich Ghost starten
lÀsst. In den meisten FÀllen, wenn man nicht gerade auf einem lokalen PC oder
Notebook installiert, wird man Fehlermeldungen erleben. Ich zum Beispiel
erhielt immer „Weird Error 8“, was auf Konfigurationsfehler hindeutet.
TatsÀchlich muss man in der config.js, die ich mit VI
bearbeitet habe, die Server-IP eintragen. Der standardmĂ€ĂŸig eingetragene Port, 2368,
hat auf meinen VServer-Umfeld nicht funktioniert. Die URL lieferte einen
404-Fehler. Zudem soll ich den Apache stoppen, sagt ein Forumsbeitrag. Als Port habe ich 8080
gewÀhlt. Mit diesen Parametern funktionierte der Aufruf auf die Startseite von
Ghost dann. Und auch der Apache ließ sich auf der gleichen virtuellen Maschine parallel betreiben. In diesem experimentellen Betrieb habe ich zumindest kein StabilitĂ€tsproblem gesehen. Klar ist aber: Beide, also Apache oder Node.js können nicht auf Port 80 koexistieren. 

Andere Basistechnologie – bessere Performance? Es scheint so. 

GrundsÀtzlich ist die Herangehensweise und die
Basistechnologie ganz anders und ĂŒberhaupt nicht mit WordPress, Joomla oder
auch Drupal vergleichbar. Der Installationsaufwand erinnert an die frĂŒhen Tage
von Typo3. Auch damals mussten viele serverseitige Voraussetzungen erfĂŒllt
sein, viele Konfigurationen waren vorzunehmen und das System lief lÀngst nicht
auf normalen, handelsĂŒblichen Shared-Hosting-Accounts. So ist es auch mit
Ghost. Man braucht definitiv Zugang zu den Serverressourcen, um Node.js
nachzuinstallieren. Kaum ein shared hoster stellt node.js defaultmĂ€ĂŸig bereit.
Wenn man die URL mit /ghost ergÀnzt, gelangt man ins
Backend. Hier soll man sich einen Blog-Account mit Namen und E-Mailadresse
anlegen. Der Mailtransportdienst kann in der Konfigurationsdatei festgelegt
werden, so dass der Accountinhaber benachrichtigt werden kann.
Dann kann man bereits versuchen, seinen ersten Blogbeitrag
zu erstellen und zu posten.
Ghost zeigt zwei Ansichten, das heißt unterteilt das
Browserfenster in vertikaler Richtung. Links gibt man den zu bloggenden Text
ein. Dabei kann man Markup verwenden, um die Formatierungen auszuzeichnen oder Bilder
einzufĂŒgen. Komfortablerweise gibt es dafĂŒr auch Tastaturshortcuts.
Auf der rechten Seite des Eingabebildschirmfensters sieht
man dann eine Vorschauansicht, die sich selbst und das sehr schnell
aktualisiert.
Überhaupt fĂ€llt auf, dass die Eingaben sehr schnell umgesetzt
werden. So typische leichte Latenzen, die man spĂŒrt, wenn man auf geteilten Servern
Wordpress oder auch Joomla administriert, sind hier ĂŒberhaupt nicht zu
erfahren. Alles lĂ€uft flott und ohne HĂ€nger. Möglicherweise ist das der große
Vorzug gegenĂŒber etablierten Systemen und Basistechnologien wie PHP.
Die von mir verwendete Version Ghost 0.3 bringt bereits eine
RSS-Funktion und Social Share-Features mit. Es ist ein Template in den
Installationsdateien vorhanden, das sich interessanterweise responsiv verhÀlt,
also auch auf meinem iPhone 4S sehr schnell und anders umgebrochen angezeigt
wurde und von der Aufteilung und der Ästhetik her an Google Plus erinnert. Es gibt
aber auch schon eine Hand voll anderer Themes. Sogar schon einige Plugins gibt
es, u.a. fĂŒr eine Migration von WordPress auf Ghost via eines JSON Files.

Serverseitiges Javascript scheint Performancevorteile zu bringen

Momentan gibt es in Ghost nichts, was WordPress und Co nicht
auch könnten. Spannend wird es, wenn es um die Performance geht. Ghost lÀuft
viel flĂŒssiger, möglicherweise aufgrund der Node.js Basistechnologie, die ja
bekanntermassen auf einer ressourcenschonendes Javascript-Laufzeitumgebung
basiert oder auch nur deshalb, weil in Ghost noch nicht so viel „drinsteckt“
wie in WordPress. Ich vermute aber, Node.js hat an der Performance einen großen
Anteil. 

Keine Chance mit Shared Hosting 

Dennoch kann Node.js am Beispiel von Ghost nun zeigen, was
es kann: Am PC ist Ghost genauso flĂŒssig zu bedienen wie Mircosoft Word, wobei
ich mit dem eigentlich sonst recht behÀbigen virtuellen Server auf einer mit
einem XEON Quadcore mit 3,20 GHz-Takt und 12 GB RAM bestĂŒckten Maschine verbunden
bin, die wohl irgendwo in einem Datacenter in Strassbourg steht.  Zumindest habe ich den Eindruck, dass Node.js
hier wirkliche Experience-Vorteile liefert, sowohl fĂŒr den Administrator als
auch fĂŒr den User, der durchs Blog surft.

Die Macher von Ghost arbeiten an einem hosted Service wie
blog.wordpress.com. Aber auch fĂŒr viele andere Hostingdienste gibt es bereits
fertige Images, wie zum Beispiel fĂŒr Amazon oder Rackspace. 
Über ghost: https://en.ghost.org/