von Christian Anger

- Eine Evaluation -

Diese Evaluation ist ein Kurzbericht aus unserem Forschungsbericht GeneAL, in dem Generische Architekturen für Leitstände untersucht werden. Im Rahmen dieser Untersuchungen betrachtet die C1 WPS auch die Einbindung von mobilen Endgeräten in Leitstände.

Der Smartphone-Boom der letzten Jahre führte neben der hohen Verbreitung auch zu schnellem Hard- und Softwaretechnischen Fortschritt auf dem Gebiet mobiler Endgeräte. Mittlerweile werden Smartphones auch in sehr vielen Unternehmen verwendet, wodurch sich laufend neue Anwendungsfälle für Smartphone- Anwendungen ergeben. Um unser Vorgehen im Bereich „mobile Endgeräte“ weiter koordinieren zu können, haben wir eine Evaluation zum State of the Art durchgeführt und sind zu folgendem Ergebnis gekommen:

Smartphone-Betriebssysteme
Der Markt für Smartphone-Betriebssysteme ist in Bewegung. Zwar ist Symbian OS noch immer Marktführer ist, aber iPhone OS, Android und BlackBerry gewinnen stetig Marktanteile hinzu. Im Unternehmensbereich werden vorwiegend Blackberry und iPhone OS eingesetzt. Folgende Grafiken geben einen Überblick über die Entwicklung und den aktuellen Stand des Smartphone-Marktes (zum Vergrößern bitte anklicken):

Alternativen zu nativer Anwendungsentwicklung
Durch die steigende Diversität an Smartphone-Betriebssystemen gewinnen plattformübergreifende Alternativen zur nativen Anwendungsentwicklung immer mehr an Bedeutung. Die unseres Erachtens interessantesten Ansätze sind:

• Hybride Applikation: In eine native Container-Anwendung wird eine Web-Applikation eingebettet und mit einer speziellen Anwendung (z.B. PhoneGap oder Titanium Mobile) in die gewünschte native Anwendung übersetzt.
• Web-Applikation per HTML5 und WURFL: HTML5 ist ein Spezifikationsentwurf, der viele interessante Neuerungen für mobile Endgeräte bietet und durch die Wireless Universal Resource File (WURFL) an spezielle Geräte angepasst werden kann.

Native Anwendungsentwicklung oder Alternativen?
Die gewählte Art der Anwendungsentwicklung ist derzeit noch stark von der Zielumgebung und den Anforderungen an die Anwendung abhängig. Die native Anwendungsentwicklung empfiehlt sich, wenn in Ihrem Unternehmen hauptsächlich ein Smartphone-Betriebssystem/Gerät eingesetzt wird oder eine besonders komplexe Anwendung zu realisieren ist. Sollen lediglich Informationen auf verschiedenen Geräten dargestellt werden, ist eine Web-basierte Lösung zu empfehlen. Wenn Sie neben der Informationsdarstellung auch Manipulationen durch eine plattformübergreifenden Anwendung vornehmen möchten, ist die Entwicklung einer hybriden Applikation empfehlenswert.

von Markus Heiden

Hat man ein Problem mit einer Open Source Software, wie z.B. fehlerhaftes Verhalten oder mangelnde Peformance, stellt sich die Frage, wer die Software anpassen kann. Hinter vielen OpenSource-Projekten stecken Firmen, die über Support-Verträge jeden Wunsch erfüllen können. Allerdings steht diese Option nicht allen offen, da die Kosten (verständlicherweise) ggf. auf dem Niveau von kommerzieller Software liegen. Dank Open Source bietet sich aber auch die Möglichkeit,  das Problem selbst zu beheben. Wenn man sich in die Benutzung eines Open-Source-Projekts so eingearbeitet hat, dass man auf dessen Fehler stößt, ist der Schritt zum Verständnis des Codes des Projekts meist nicht mehr groß.

Behebt man nun selbst sein Problem, hat man es zwar gelöst, ist aber vorerst an die konkrete, gepatchte Version gebunden. Das führt dazu, dass man den Patch für jede neue Version manuell anpassen müsste, was aber wahrscheinlich mangels Ressourcen nicht geschieht, womit man auf dem gepatchten Stand festhängt.

“Halt! – ist es nicht das Versprechen von Open Source, dass die Community Bugfixes und Features entwickelt, die in die Software einfließen und so das Produkt immer besser machen?”

Eine berechtigte Frage. Man kann den Patch schließlich beim Open-Source-Projekt einreichen. Das ist aber leider keine Garantie, dass der Patch auch zeitnah übernommen wird. Dazu aus eigener Erfahrung: Als wir einen Bugfix bei Hibernate einreichen wollten, gab einer der Hibernate-Entwickler zu, ein „Luxus-Problem“ zu haben; er musste nämlich entscheiden, welcher Input aus der Community in welcher Reihenfolge in das Produkt integriert wird. Das hört sich einerseits ganz gut an, weil viele Menschen an diesem Projekt interessiert sind und es auch weiterentwickeln, bedeutet aber andererseits, dass diese Menschen ggf. lange darauf warten müssen, bis ihr mühsam entwickelter Patch übernommen wird. Das frustriert und führt dazu, dass man lange auf veralteten, gepatchten Versionen festhängt oder viel Aufwand für den Versionswechsel hat.

Das Hibernate-Team hätte unseren Patch im Rahmen des bezahlten Supports natürlich sehr kurzfristig in das Produkt integriert. Das ist auch völlig nachvollziehbar. Nur erwartet es eben nicht jeder Gelegenheitsnutzer von Open Source Software so.

Man erkennt daran, dass der Einsatz von Open-Source-Software durchaus mit Folgekosten verbunden sein kann. Gerade in größeren Projekten oder Projekten mit speziellen Anforderungen, kann sich ein größerer Mehraufwand ergeben, der anfangs nicht eingeplant wurde. Die Arbeit, die viele Entwickler für Open Source Software leisten, muss bei professioneller Qualität letztendlich auf irgendeinem Wege bezahlt werden.

Serviceleistungen sind eigentlich nie wirklich kostenlos, auch nicht für Open Source Software.