Extension SLAs für Agenturen
TYPO3-Extension-SLAs für Agenturen - wie funktioniert das?
Finden Sie heraus, wie Ihr Unternehmen von unseren TYPO3-Extension-SLAs profitieren kann und warum sie Effizienz und Zuverlässigkeit Ihrer Projekte steigern.
Geschätzte Lesezeit: 7 Minuten
Rechtliche Grundlagen
Lösungen für das "absolutely no warranty"-Dilemma der GPL
Die General Public License (GPL) ist die Basis jeder TYPO3-Extension, weil die TYPO3-eigene GPL-Lizenz voraussetzt, daß Erweiterungen eine kompatible Lizenz vorweisen können. Einerseits ist das eine gute Sache, weil damit sichergestellt wird, daß der Code von TYPO3 und seinen Erweiterungen für Entwickler, Wiederverkäufer und Anwender alle Freiheiten bietet, um ihn erhalten, verwenden, modifzieren oder verbreiten zu können. Andererseits steht es dadurch insbesondere Entwicklern auch frei, keinerlei Garantien zu geben. Dies ist in der GPL ausdrücklich vorgesehen.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
See the GNU General Public License for more details.
Während Entwickler die freie Wahl haben, entstehen dadurch Probleme für Wiederverkäufer und Anwender, weil sie eine Lösung für das "mir doch egal"-Verhalten benötigen, das oft aus dieser Freiheit resultiert.
Agenturen verkaufen fertige Lösungen an ihre Kunden und beide sind darauf angewiesen, daß jeder Bestandteil dieser Lösung einwandfrei und wie erwartet funktioniert. Je nach Vertrag ist eine Garantieleistung durch Agenturen für deren Kunden verpflichtend, obwohl die GPL diese ausdrücklich ausschließt.
Die TYPO3-Extension-SLAs von Coders.Care schließen genau diese Lücke für Agenturen und Kunden. Anstatt sich mit Bugs, Refactoring und Feature-Wünschen selbst herumzuschlagen, können Sie sich auf ein Team von exzellenten Extension-Maintainern verlassen, das Serviceleistungen für viele öffentliche und interne Extensions bietet. Endlich können Agenturen und Kunden sich auf die eigentliche Projektarbeit konzentrieren, anstatt sich um Probleme mit Extensions von Drittanbietern kümmern zu müssen.
Schauen wir uns mal an, wie das funktioniert.
Was Ihr wollt
Wie wir gemeinsam den Coders.Care-Extension-Pool zusammenstellen
Wir wurden des öfteren nach der Anzahl der aktuell von Coders.Care unterstützen Extensions oder nach den Entwicklern gefragt, die bereits aktiv beim Projekt mitmachen. Coders.Care wird dabei als eine Art "Black Box" gesehen, die für Agenturen und Kunden nur schwer durchschaubar ist. Erwartet wurde dabei eine Art Auswahlliste, die man vor der Buchung eines Pakets berücksichtigen kann.
Es ist genau umgekehrt. Welche Extensions wir unterstützen wird dadurch bestimmt, welche Extensions Sie mit einem SLA abdecken wollen. Wir stellen eine leere Box bereit, die von Agenturen und Kunden mit erfolgskritischen Teilen ihrer Projekte befüllt wird.
Gemeinsam mit Ihnen stellen wir fest, weche dieser Extensions vorher überholt werden müssen, welche mit sinnvolleren Lösungen ersetzt werden sollten oder überflüssig sind, weil ihre Features vom TYPO3-Core bereitgestellt werden. Zuguterletzt geben wir diesem Paket ein Preisschild, das zu Ihren Ansprüchen bzgl. Reaktionszeit und Service passt.
Sie können sogar einen eigenen Agentur-Server aufsetzen, der die üblicherweise in Ihren Kundenprojekten verwendeten Extensions enthält. Nun können Sie diesen mit einem größeren SLA absichern, anstatt Ihre Kunden jeweils ein individuelles SLA kaufen zu lassen. Wir nennen das "eingebautes Crowdfunding".
Selbstverständlich gibt es weiterhin Extensions, die entweder aufgegeben wurden oder deren Entwickler bisher nicht dem Team von Coders.Care beigetreten sind. Daher bleibt die Frage, wie wir das für Agenturen und Kunden lösen, weil wir letzten Endes mit unseren SLAs eine Garantie zusagen, die von der GPL eigentlich ausgeschlossen wird.
Die Antwort darauf findet sich ebenfalls in der GPL.
Freie Auswahl
3 Wege für Agenturen, um auf der sicheren Seite zu sein
Der aktuelle Umgang vieler TYPO3-Agenturen mit dem Dilemma, besteht in einer Option, die wiederum durch die GPL bereitgestellt wird. Es gibt viele Forks von öffentlichen Extensions, die exklusiv von Agenturen für deren Kunden betreut werden. Sie enthalten zahlreiche Korrekturen für kundenspezifische Probleme, die niemals ihren Weg zurück zu den eigentlichen Extension-Maintainern finden.
Das Resultat sind verschwendete von Kunden bezahlte Arbeitszeit, fehlende Fixes für öffentliche Originale und weniger Einkommen für Maintainer. Nicht selten machen Korrekturen dieser Forks einen späteren Upgrade unmöglich, weil sie nicht mehr zum überarbeiteten Original passen. Dennoch gibt es drei weitere Wege zur sicheren Seite.
Der erste Weg ist der wünschenswerte, weil wir Extension-Maintainer bitten, sich unserem Entwickler-Team anzuschließen und Ihre Extension offiziell im Coders.Care-Pool bereitzustellen. Sobald sie zustimmen, werden sie auf Stundenbasis für ihre Arbeit bezahlt.
Der zweite Weg eignet sich für Extension-Maintainer, die sicher gehen wollen, daß sich jemand anderes um ihre Extensions kümmert. Es gibt auch dann einen offiziellen Vertrag, aber das Coding wird von anderen Teammitgliedern erledigt und die Maintainer stellen lediglich sicher, daß Fixes und Änderungen ihren Weg zurück in die Repositories der Original-Extension finden. Sie können uns natürlich auch bitten, den Extension-Key ebenso zu übernehmen, wie wir das mit aufgegebenen Extensions versuchen.
Wenn man eine Entscheidung treffen muß und sich nicht entscheidet,
so ist selbst das eine Entscheidung.
Letztlich ist es der dritte Weg, den wir vermeiden wollen, weil das bedeutet, daß die Maintainer weder für ihre Arbeit bezahlt werden wollen, noch Änderungen anderer akzeptieren oder den Extension-Key einer aufgegebenen Extension an uns übergeben wollen.
Eigentlich wäre das ein fragwürdiges Verhalten, weil die Idee der Open-Source-Bewegung darin besteht, gemeinsam Lösungen zu schaffen oder zu verbessern. Dennoch erlaubt uns die GPL einen Umgang damit, der für Entwickler, Agenturen und Kunden eine Verbesserung bedeutet, weil wir in Zukunft einen einzelnen Fork dort zur Verfügung stellen, wo heute noch viele verschiedene nötig sind.
Das Agreement
Die Chance für Firmen, Entwickler und die Community, gemeinsam zu wachsen
Wie bereits im Artikel über SLAs für TYPO3-Extensions erwähnt, gibt es eine Besonderheit im Vergleich zu den meisten Varianten von SLAs, wie sie in anderen Open-Source-Projekten zum Einsatz kommen. So genannte "Enterprise" oder "Professional" Versionen von TYPO3 oder Erweiterungen kaufen zu müssen, nur um sich für den Erwerb von SLAs zu qualifizieren, ist ein No-Go. Letztlich würde das zwei Klassen innerhalb der Community erzeugen, was im Grunde den Prinzpien der Freien Software im Sinne der GPL widerspräche.
Die Vorteile eines SLA sollten sich über Verläßlichkeit und Reaktionszeiten definieren, nicht über einen Zugang, der für den Rest der Community unerreichbar bleibt. Daher gibt es eine Übereinkunft, daß öffentliche Erweiterungen später der gesamten Community zur Verfügung stehen, während Kunden einen Vorab- oder Sofort-Zugang erhalten, je nachdem, für welches Level und welche Dringlichkeit sie bezahlt haben.
Entwickler wiederum müssen einer weiteren Vereinbarung zustimmen: Akzeptanz der Veröffentlichung von fremden Korrekturen und Änderungen ist eine Voraussetzung, damit der gesamte Pool an Entwicklern sich um die Erweiterungen kümmern kann, die von den SLAs abgedeckt werden. Damit lassen sich unnötige Forks vermeiden, wobei sie natürlich weiterhin möglich sind, auch wenn die beiden anderen Wege wünschenswert wären.
Also besteht unser Agreement für Agenturen und Kunden darin, daß wir die fehlende Garantie, ein professionelles Response-Team und professionelle Entwickler bereitstellen und uns basierend auf den Prinzipien der GPL um Ihre erfolgskritischen Extensions kümmern.
TL;DR - Fazit
So profitieren Agenturen und Kunden von unseren Service-Level-Agreements
Wir müssen das Dilemma lösen, das durch die "no warranty"-Klausel der GPL entsteht, weil Agenturen und Kunden oft trotzdem eine Garantie benötigen. Aktuell stellen Agenturen selbst Patches und Forks bereit, um sicherzustellen, daß Extensions für ihre Kunden funktionieren.
Es gibt keine vordefinierten Pakete, weil Sie selbst die Extensions benennen, die Sie mit einem SLA abdecken wollen. Fügen Sie nötige Reaktionszeit und monatlichen Preis hinzu, um Stundensätze für Services zu ermitteln, die nicht in monatlichen Gebühren enthalten sind. Wir kümmern uns auf drei Wegen um alles andere und Sie können sogar SLA für Ihre Agentur-Server an Ihre Kunden weitergeben.
Der erste und wünschenswerte Weg besteht in einer vertraglichen Bindung bezahlter Extension-Maintainer. Der zweite Weg versorgt ebenfalls vertraglich geregelt Extension-Maintainer mit Code unseres professionellen Teams. Der dritte Weg soll vermieden werden, weil er in einem Fork der Extension besteht, der dann vom Coders.Care-Team betreut wird.
Jeder dieser Wege stellt gegenüber dem aktuellen Status eine Verbesserung dar.
Empfehlungen
Coders.Care ist die logische Weiterentwicklung in der Zusammenarbeit zwischen Anbietern von TYPO3 -Extensions und deren Nutzern. Insbesondere das Thema Kommunikation im Vorfeld eines Projekts wird hierdurch optimiert. Die Entwickler können sich ganz auf ihre Stärken konzentrieren, während Coders.Care sich um Beantwortung von Fragen und Management kümmern kann. Die Folge eines solchen Angebots sind klare Aussagen zum Thema Pflege und Weiterentwicklung von TYPO3-Erweiterungen und somit wird das Vertrauen in TYPO3 und die damit umgesetzten Projekte gestärkt. Als TYPO3-Agentur können wir von einem solchen Angebot nur profitieren.
© Copyright 2024 Cybercraft GmbH