Interview mit den Entwicklern von Tine 2.0
Das Groupware-Projekt Tine 2.0 konnte kürzlich das Erreichen des 2. Meilensteins bekannt geben. Pro-Linux befragte die Entwickler über die Hintergründe und die Zukunft des Projektes.
Zwei Monate nach Erreichen des 1. Meilensteins blickt das Team zufrieden zurück. »Es war eine spannende Projektphase, die uns viel abverlangt hat. Vor allem die Diskussionen im eGroupWare-Team waren intensiv, aber fruchtbar«, resümiert Lars Kneschke, der Projektverantwortliche.
Damit spricht er die Unstimmigkeiten an, die direkt nach der Veröffentlichung des 1. Meilensteins im Projekt aufkamen. Deren Gegenstand waren vor allem der etwas provokante Projektname »eGroupWare 2.0« und die Frage, ob das altbewährte eGroupWare-Projekt überhaupt Innovation bräuchte.
Am Ende einigte man sich im Projekt aber glücklicherweise darauf, die neue Version als offizielles Subprojekt unter dem Namen Tine 2.0 aufzunehmen. »Das hat uns sehr überrascht, wir hätten nicht erwartet, dass wir dieses Ziel so schnell erreichen«, so Cornelius Weiss, der zweite eGroupWare-Kernentwickler im neuen Team.
Gabel (engl. fork). »Das ist ein schönes Wortspiel, da eGroupWare ja selbst aus einem Fork hervorgegangen ist. Wir verstehen uns ganz klar als Spitze dieser Anstrengungen« meint Lars, der damals selbst mit Initiator des Forks von phpgroupware war. »Außerdem ist Tine auch ein rekursiver Name: 'Tine is not eGroupWare', solche Namen sind in der Szene immer besonders beliebt«, pflichtet Cornelius grinsend bei.
Doch nun genug der einleitenden Worte, los geht es mit dem Interview.
Pro-Linux: Erst phpgroupware, dann eGroupWare und jetzt Tine. Es gibt doch schon unzählig viele Open-Source-Groupware-Lösungen. War es wirklich nötig, noch eine hinzuzufügen?
Cornelius: Wir fügen ja keine hinzu, sondern wir sind Teil eines altbekannten und erfolgreichen Open-Source-Projektes. Der Plan ist, dass die Anstrengungen rund um Tine mittelfristig die neue eGroupWare-Version ergeben. Projekte wie Typo 3 und KDE haben ja bereits bewiesen, dass es von Zeit zu Zeit notwendig ist, eine Pause einzulegen und die Code-Basis von Grund auf zu erneuern. Auch in vielen anderen Projekten ist es nichts Besonderes, dass es gleichzeitig eine alte und eine Next Generation-Version im stabilen Zustand gibt.
Lars: Bei genauerem Hinsehen stellt man fest, dass es in Wirklichkeit doch gar nicht so viele freie Lösungen in dem Bereich gibt. Da gibt es die witzigsten Lizenzvereinbarungen. Wenn man nach ernsthaften free as in freedom-Projekten sucht, landet man ganz schnell bei eGroupWare. Das ist in meinen Augen das einzige Projekt, dass auch eine richtige User-Community hat. Allerdings reicht das nicht mehr. Die kommerziellen Umsonst-Produkte sind uns mittlerweile bei den Themen Benutzbarkeit und Datenintegrität überlegen. Wenn wir jetzt nicht Gas geben, wird eGroupWare bald Geschichte sein.
Pro-Linux: Die Probleme mit einer kompletten Neuimplementierung sind bekannt: Nichts geht, bevor es halbwegs vollständig ist, Benutzer und Tester müssen ewig auf Neuerungen warten, usw... Projekte wie der Kernel oder GNOME haben doch erfolgreich gezeigt, dass es auch in kleineren Schritten geht. Warum macht ihr es dennoch anders?
Cornelius: Auf die Frage »Evolution oder Revolution« gibt es vermutlich keine eindeutige Antwort. Im Gegensatz zu den genannten Projekten hat sich bei uns die Programmiersprache dramatisch geändert. Das Programmier-Paradigma bis PHP 4 war prozedural, das zieht sich durch die über 200.000 Codezeilen von eGroupWare. Mit PHP 5 hat die objektorientierte Programmierung Einzug erhalten. Das sind so unterschiedliche Welten, dass man sie einfach nicht zusammen bekommt. Dann sind da natürlich die Fragen um Rückwärts-Kompatibilität und ob man wirklich alle Features übernehmen will. Das stellt sich bei einem Datenhaltungs-Projekt natürlich anders dar als bei einem Desktop-Manager. Ich denke, dass dies letztendlich auch der Grund bei Typo 3 war, eine zweite Code-Linie anzufangen.
Lars: Ich denke, der große Vorteil von zwei Codelinien ist, dass der Benutzer selbst entscheiden kann, ob und wann er wechseln will. Die 1.x-Codelinie wird ja weiter gepflegt und auch noch gelegentlich erweitert. Würden wir den alten Code komplett umgraben, so wäre der Benutzer zum einen gezwungen, alle Neuerungen mitzumachen, und zum anderen müsste er auch die Instabilitäten ausbaden, die so etwas immer mit sich bringt.
Pro-Linux: Was wollt ihr tun, um wieder den Anschluss zu den anderen Groupware-Produkten zu finden?
Lars: Das kann man natürlich nur schwer in ein ein paar kurze Sätze packen. Erst einmal geht es uns ums »Entrümpeln«. Das derzeitige eGroupWare-Paket besteht aus über 60 MB Skript-Code, der komplett vom uns selbst gepflegt werden muss. Das ist eine kaum zu bewältigende Aufgabe, zumal ein Großteil des Codes aus einer Zeit stammt, als automatisierte Tests noch ein Fremdwort in der Szene waren. So kommt es öfter vor, dass längst beseitigte Fehler wieder auftauchen. Da geht es darum, alles was wir nicht selbst machen müssen, konsequent aus Bibliotheken zu nehmen. So erreichen wir zum einen eine wesentlich übersichtlichere Code-Basis, die zum anderen auch noch 1A getestet ist. Natürlich wollen wir mit Unit-Tests auch die gleichen hohen Ansprüche an unseren eigenen Code stellen.
Cornelius: Vor allem müssen wir im Punkt Benutzbarkeit aufholen. Die Erfahrung mit eGroupWare zeigt, dass vor allem technisch versierte Benutzer (um nicht Geeks zu sagen), eGroupWare benutzten. Soll im Unternehmen eGroupWare auch für »normale« Benutzer eingeführt werden, so scheitern die Projekte meist daran, dass diese nicht bereit sind, die Software zu benutzten. Daher arbeiten wir zum einen mit Usability-Experten zusammen, die uns helfen, die Oberfläche produktiv und nutzbar zu machen. Zum anderen müssen wir im Hintergrund natürlich sehr viel dazu tun, um die Geschwindigkeit zu erreichen, die ein Benutzer braucht, damit ihm das Arbeiten Spass macht.
