Ich gebe Dir recht, dass jeder, der vorschlägt OTRS doch mal eben in (PHP|Python|Ruby|Whatever) neuzuprogrammieren, keine Ahnung von Software-Entwicklung hat. OTRS ist ein Monster (was die Quellcode-Menge betrifft) und hat sicherlich auch mehr als eine Programmierer-Sünde im Code versteckt... aber der Aufwand so eine Software neu zu entwickeln ist sicherlich mehrere Mannjahre groß. Dank OpenSource kann man sich an der Weiterentwicklung von OTRS beteiligen (auch wenn die Einstiegshürde hierzu nicht gerade gering ist).
ABER, sowohl das UI als auch die Geschwindigkeit sind teilweise stark verbesserungswürdig. Mal ein paar Beispiele aus meiner täglichen Arbeit mit OTRS (3.3.6)
Geschwindigkeit: das Aufrufen des Dashboards kann gerne mal mehrere(!) Sekunden dauern. Eine Suche dauert noch längerer. Letzteres kann ich meistens verschmerzen, weil man die Suche recht selten nutzt. Aber ein bisschen schneller wäre schon toll.
UI: Ein Beispiel, welches mich fast täglich in den Wahnsinn treibt: versuch mal, während Du gerade auf ein Ticket antwortest, in einem anderen Fenster oder Tab etwas in OTRS zu machen. Du bekommst dann recht schnell ein Popup mit der Frage, ob Du die Seite wirklich verlassen möchtest. Wenn Du das bestätigst, verlierst Du leider alle Eingaben in Deiner angefangenen Ticket-Antwort. Schnell noch mal was nachschlagen ist so leider nicht möglich.
UI #2: Ich habe ein Ticket von Kunden A. Aus dem Ticketverlauf schreibe ich an Hersteller B eine E-Mail (übe die Funktion "Leere E-Mail"). Bekomme ich nun eine Antwort von Hersteller B und antworte auf diese, so steht _immer_ auch Kunde A im "An:"-Feld. Wird dieser nicht explizit gelöscht, bekommt Kunde A automatisch meine Antwort an Hersteller B zugesendet. Das kann teilweise peinlich enden...
Ja, es gibt in der Tat einige verbesserungswürdige Bereiche, auch in der GUI.
Was die Geschwindigkeit betrifft haben wir in OTRS 4 einiges investiert. Das komplette Objekthandling wurde refactored und in einem neuen ObjectManager zentralisiert, der die Singletons verwaltet. Das macht den Code sehr viel einfacher, aber auch schneller, weil Objekte definitiv nur einmal erstellt werden, und nicht mehrmals (z. B. das Valid-Objekt in OTRS 3.3). Damit können wir auch erzwingen, dass es nur ein CacheObjekt gibt, und nicht viele. Diesem haben wir dann noch ein in-memory-caching spendiert. Zusammen mit der neuen Template-Engine Template::Toolkit ergeben sich hier deutliche Performance- und Skalierbarkeitsverbesserungen. Und ich hoffe damit auch zeigen zu können dass eine evolutive Veränderung der Software auch im Kern möglich ist. Eine Revolution (Neuschreiben) halte ich u. A. wegen des erforderlichen Migrationspfads für nahezu unmöglich.
Die hier vorgeschlagene Neuentwicklung scheint mir eher auf persönlichen Antipatien zu beruhen als auf inhaltlichen Erwägungen...
Ich gebe Dir recht, dass jeder, der vorschlägt OTRS doch mal eben in (PHP|Python|Ruby|Whatever) neuzuprogrammieren, keine Ahnung von Software-Entwicklung hat. OTRS ist ein Monster (was die Quellcode-Menge betrifft) und hat sicherlich auch mehr als eine Programmierer-Sünde im Code versteckt... aber der Aufwand so eine Software neu zu entwickeln ist sicherlich mehrere Mannjahre groß. Dank OpenSource kann man sich an der Weiterentwicklung von OTRS beteiligen (auch wenn die Einstiegshürde hierzu nicht gerade gering ist).
ABER, sowohl das UI als auch die Geschwindigkeit sind teilweise stark verbesserungswürdig. Mal ein paar Beispiele aus meiner täglichen Arbeit mit OTRS (3.3.6)
Geschwindigkeit: das Aufrufen des Dashboards kann gerne mal mehrere(!) Sekunden dauern. Eine Suche dauert noch längerer. Letzteres kann ich meistens verschmerzen, weil man die Suche recht selten nutzt. Aber ein bisschen schneller wäre schon toll.
UI: Ein Beispiel, welches mich fast täglich in den Wahnsinn treibt: versuch mal, während Du gerade auf ein Ticket antwortest, in einem anderen Fenster oder Tab etwas in OTRS zu machen. Du bekommst dann recht schnell ein Popup mit der Frage, ob Du die Seite wirklich verlassen möchtest. Wenn Du das bestätigst, verlierst Du leider alle Eingaben in Deiner angefangenen Ticket-Antwort. Schnell noch mal was nachschlagen ist so leider nicht möglich.
UI #2: Ich habe ein Ticket von Kunden A. Aus dem Ticketverlauf schreibe ich an Hersteller B eine E-Mail (übe die Funktion "Leere E-Mail"). Bekomme ich nun eine Antwort von Hersteller B und antworte auf diese, so steht _immer_ auch Kunde A im "An:"-Feld. Wird dieser nicht explizit gelöscht, bekommt Kunde A automatisch meine Antwort an Hersteller B zugesendet. Das kann teilweise peinlich enden...
Ja, es gibt in der Tat einige verbesserungswürdige Bereiche, auch in der GUI.
Was die Geschwindigkeit betrifft haben wir in OTRS 4 einiges investiert. Das komplette Objekthandling wurde refactored und in einem neuen ObjectManager zentralisiert, der die Singletons verwaltet. Das macht den Code sehr viel einfacher, aber auch schneller, weil Objekte definitiv nur einmal erstellt werden, und nicht mehrmals (z. B. das Valid-Objekt in OTRS 3.3). Damit können wir auch erzwingen, dass es nur ein CacheObjekt gibt, und nicht viele. Diesem haben wir dann noch ein in-memory-caching spendiert. Zusammen mit der neuen Template-Engine Template::Toolkit ergeben sich hier deutliche Performance- und Skalierbarkeitsverbesserungen. Und ich hoffe damit auch zeigen zu können dass eine evolutive Veränderung der Software auch im Kern möglich ist. Eine Revolution (Neuschreiben) halte ich u. A. wegen des erforderlichen Migrationspfads für nahezu unmöglich.
Die hier vorgeschlagene Neuentwicklung scheint mir eher auf persönlichen Antipatien zu beruhen als auf inhaltlichen Erwägungen...
Hallo Martin Gruner!
>Das komplette Objekthandling wurde refactored und in einem neuen ObjectManager zentralisiert, der die Singletons verwaltet.
aha, das komplette Objekthandling mit Singletons... sehr guter objektorientierter Ansatz
das wird nix mehr!...