Tine 2.0 Kristina und Collin im Test

klaikungwon sudsawat, 123RF

Fast ein Alleskönner

Tine ist eine seit 2008 entwickelte, webbasierte Kollaborationslösung, die beim Backend und Frontend konsequent auf Web-2.0-Technologie setzt. Ihr Web-Interface fühlt sich wie eine native Anwendung an. Wir haben uns die Groupware-Funktionen der Community-Version angeschaut.
Termine planen, Nachrichten austauschen, Kundendaten verwalten, am besten auch vom Smartphone aus. Das alles und noch viel mehr sollen moderne ... (mehr)

Tine-2.0-Collin-Neuerungen

Kurz vor Redaktionsschluss erschien die aktuelle Version "Collin" von Tine 2.0 mit interessanten Neuerungen. So erlaubt es der Active-Directory-Support, dass Anwender aus Tine heraus Benutzerkonten im Active Directory anlegen und verwalten können. Ferner haben die Entwickler den CalDAV- und CardDAV-Support noch verbessert. Außerdem kann Tine jetzt gegenüber OwnCloud-Clients als Synchronisationsserver auftreten. Ferner lassen sich an sämtliche Groupware-Daten jetzt Dateien anhängen, etwa an einen Termin im Kalender, die dann bei der automatisch versandten Mail mitgeschickt werden. Ebenfalls neu ist, dass Admins den maximalen Zeitraum begrenzen können, innerhalb dessen sich zurückliegende Termine mit Smartphones synchronisieren lassen, was vor allem die CPU-Last bei großen Installationen verringern soll. Außerdem funktioniert das Anmelden an Tine anstelle der Kombination Benutzername und Passwort jetzt auch mit einem Zertifikat.

Tine 2.0 verfügt über klassische Groupware-Funktionen hinaus auch über Module für CRM, Verkaufsunterstützung, Zeiterfassung und eine Dateiablage sowie eine VoIP-Integration mit Asterisk und Sipgate. Ferner enthält Tine einen eigenen E-Mail-Client und lässt sich in der jüngst erschienenen Version Collin auch in ein Active Directory einbinden. Ferner ist es mit Tine möglich, mithilfe des OwnCloud-Clients auf die Dateiablage zuzugreifen. Außerdem unterstützt Tine das Synchronisieren mobiler Geräte via CalDAV, CardDAV und ActiveSync, was die Lösung zum Rundumwohlfühlpaket für kleine Unternehmen im SOHO- und SMB-Segment macht.

Genau genommen ist Tine also weit mehr als eine Groupware-Lösung und versteht sich als Plattform, die sämtliche Aspekte der internen Koordination eines Unternehmens abbilden soll. Die Community-Variante [1] der momentan aktuellen Version 2013.10.1 (Collin) steht auf der Projektseite zum Herunterladen [2] zur Verfügung und ist unter Version 3 der GNU Affero General Public License (AGPL) veröffentlicht. Ferner gibt es eine Demo-Version [3] für einen schnellen ersten Blick. Unterstützung für die Community-Version gewährleistet die rege Entwickler- und Nutzer-Gemeinschaft in Form von Forum [4] und Wiki [5].

Historisches

Die Bezeichnung 2.0 im Produktnamen ist insofern irreführend, als dass es keine Version 1.0 gab. Die einzelnen Releases von Tine 2.0 tragen Datumsbezeichnungen und Code-Namen, wie etwa Neele (1/2011), Maischa (07/2011), Milan (03/2012) oder Joey (10/2012). Installiert haben wir die Versionen Kristina (2013.03.8) vom März dieses Jahres und das brandaktuelle Collin-Release, das kurz vor Redaktionsschluss erwartungsgemäß erschien und mit Unterstützung für Active Directory und OwnCloud aufwarten kann (siehe Kasten). Die Bezeichnung »2.0« soll zum einem auf die verwendeten Web-Technologien (Web 2.0, AJAX) hinweisen, ist aber auch als Fingerzeig auf die Tatsache zu verstehen, dass sich Tine 2.0 als Neuauflage von eGroupware versteht. So war Tine 2.0 ursprünglich als »eGroupware 2.0« geplant und sogar für kurze Zeit ein offizielles Subprojekt von eGroupware. Allerdings spaltete sich das Tine-Projekt wegen interner Unstimmigkeiten im Februar 2008 von eGroupware ab, ist aber dennoch kein Fork, weil Tine von Grund auf neu entwickelt wurde.

Open Source und Kommerz

Federführend für die Entwicklung von Tine ist Produktmanager Lars Kneschke – kein Unbekannter in der Entwicklung von Open-Source-Groupware-Lösungen. Kneschke hat seit 2000 an der Entwicklung zahlreicher Open-Source-Groupware-Lösungen mitgearbeitet und das Tine-2.0-Projekt 2007 gemeinsam mit Cornelius Weiss bei der Hamburger Metaways Infosystems GmbH [6] ins Leben gerufen.

Cornelius Weiss ist seit 2008 bei Metaways als Abteilungsleiter im Bereich Software für die Entwicklungsleitung von Tine 2.0 zuständig. Metaways ist ein 2001 mit Fokus auf Hosting und Software-Entwicklung im Kontext von Open Source gegründeter IT-Spezialist, der unter anderem kommerzielle Unterstützung [7] für Tine 2.0 sowie diverse Hosting-Varianten [8] der Lösung anbietet. Obwohl Metaways Tine finanziert, ist es ein echtes Community-Projekt mit einer stetig wachsenden Nutzergemeinschaft, die aktiv zur Mitarbeit [9] aufruft und mittlerweile viele externe Entwickler einbindet.

Die Symbiose aus Community-Projekt und dem Sponsoring durch Metaways beschert der Lösung eine Reihe von Vorteilen. Der gesicherte finanzielle Entwicklungshintergrund erlaubte es den Tine-Machern beispielsweise von Beginn an, Software-Ergonomie als wichtigen Faktor für die Akzeptanz einer Unternehmens-Software einzubeziehen. Bekanntlich scheitern technisch ausgezeichnete Projekte nicht selten an Mitarbeitern, die die Software nicht benutzen wollen, was insbesondere für eine Groupware-Lösung fatal ist. Daher erlaubte es man sich bei Metaways, beim Entwickeln der Funktionen sowie beim GUI-Design externe Experten der Open-Source-Usability-Labs [10] hinzuzuziehen. Die sind selbst keine Techniker, sondern verstehen sich als Anwälte der Benutzer und begleiten den gesamten Entwicklungsprozess mit Ratschlägen, die dazu dienen sollen, die Software für Anwender besser benutzbar zu machen.

Ein weiterer wichtiger Punkt in der Tine-Entwicklung bestand im Anspruch, von Anfang an eine hohe Code-Qualität zu bieten, denn immerhin handelt es sich etwa bei den ERP- und CRM-Modulen um Software, die unternehmenskritische Daten verwaltet. Das Tine-Team setzt daher auf automatisierte Tests auf Basis des Test-Framework JUnit. Die dreistufigen Tests umfassen das Backend, die Domain-Logik und externe APIs. Beim Backend-Test geht es etwa darum, ob SQL- und LDAP-Abfragen und Dateizugriffe wie geplant funktionieren. Die Tests der Domain-Logik und Zugriffskontrolle im zweiten Schritt stellen quasi eine Referenz für die interne API dar, während im dritten Schritt die externen APIs getestet werden, auf die die Clients zugreifen.

Ähnliche Artikel

comments powered by Disqus

Artikel der Woche

Eigene Registry für Docker-Images

Wer selber Docker-Images herstellt, braucht auch eine eigene Registry. Diese gibt es ebenfalls als Docker-Image, aber nur mit eingeschränkter Funktionalität. Mit einem Auth-Server wird daraus ein brauchbares Repository für Images. (mehr)
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Ausgabe /2020