Extension SLAs for Agencies
TYPO3 Extension SLAs for Agencies - How do they work?
Find out how your business can benefit from our TYPO3 extension SLAs and why they will increase efficiency and reliability of your projects.
Estimated time to read: 7 minutes
The Legal Basis
Solving the "absolutely no warranty" dilemma of the GPL
The General Public License (GPL) is the basis for any kind of TYPO3 extension, since it is required by the GPL license of TYPO3 itself, that extensions have to provide a compatible license. On the one hand this is a good thing, since it makes sure that the code of TYPO3 and its extensions will give developers, resellers and users every freedom they need to get, use, modify and redistribute it. On the other hand it gives especially developers the freedom to refrain from any service or warranty. This is explicitely stated in the GPL.
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.
While this means freedom of choice for the developers, it raises problems for resellers and users, since they have to find a solution for the "couldn't care less" behaviour that often is a result of this freedom.
Agencies are selling ready made solutions to their clients and both are demanding that each part of this solution is working properly and as expected. Depending on the kind of contract there is an implied warranty agencies are obliged to grant to their clients, even though the GPL explicitely excludes it.
The TYPO3 extension SLAs provided by Coders.Care close exactly that gap for agencies and clients. Instead of dealing with bugs, refactoring and feature requests, they can rely on a team of top notch extension maintainers providing service for many publicly available or internal extensions. Finally agencies and clients can focus on the actual project work instead of taking care of problems with third party extensions.
Now let's see how this works.
What You Will
Compiling the Coders.Care extension pool together
Some people asked us about the number of available extensions supported by Coders.Care extension SLAs and about the coders who already joined the project. They complained about the whole project being kind of a black box which is hard to grasp for agencies and clients. They expected a kind of list to pick from before they can consider booking an SLA package.
It is just the other way around. The list of extensions we are going to support is determined by the extensions you want to have covered by an SLA. We are providing an empty box and it's up to agencies and clients to fill it with the mission critical pieces of their projects.
Together we will find out which of these extensions needs to be refactored beforehand, which of them should be replaced with a more convenient solution or which are superfluous because their features are provided by the TYPO3 core. In the end we will put a price tag on that package, that fits your demands regarding response time and service.
You can even create your own agency server containing those extensions that you are working with in your client projects anyway. Now you can cover that server with a larger SLA instead of having your clients buy their individual SLA. We call it the "built in crowd funding".
Of course there will still be extensions which are either abandoned or maintained by developers who did not join the team of Coders.Care extension maintainers yet. So the question remains how we are going to solve this for agencies and clients, since after all with our SLAs we promise to offer the warranty, that is actually excluded by the GPL.
The answer can be found in the GPL as well.
Freedom of Choice
3 ways for agencies to be on the safe side
The current way of many TYPO3 agencies to deal with the described dilemma is to make use of an option that is again provided by the GPL. There are lots of forks of publicly available extensions, exclusively maintained by agencies for their clients, containing lots of fixes for client specific problems that will never find their way back to the actual extension maintainers.
The results are a lot of wasted work time paid by clients, missing fixes for the publicly available originals and less income for the maintainers. Sometimes the fixes used within these forks even make it impossible to upgrade them, since they don't match their refactored originals anymore. But there are still three other ways to be on the safe side.
The first one is the preferable, since we will ask the extension maintainers to join our team of developers and to officially put their extensions into the Coders.Care pool. As soon as they agree they will get paid by hourly rates for the work they are going to provide.
The second way is the one to go for extension maintainers, who just want to make sure there are people taking care of their extensions. We will still have an official contract but the coding will be done by other members of the team then and the maintainers just make sure, that the fixes and changes will find their way back to the repositories of the original extension. They can even ask us to take over their extension keys, which is the same we will be trying to achieve with abandoned extensions.
When you have to make a choice and don't make it, that is in itself a choice.
Finally the third way is the one we are trying to avoid, since it will be due to the fact that the maintainer neither wants to get paid for the work nor wants to accept changes provided by others nor wants to transfer the key of an abandoned extension.
Actually this would be a questionable behaviour, since the idea of Open-Source movement is about joining forces to create and improve solutions together. Still the GPL allows us to deal with it in a way that is an improvement for developers, agencies and clients, since we will provide a single fork in the future while there are lots of them today.
The Agreement
Enabling companies, developers and the community to join forces and thrive
As already mentioned in the article about SLAs for TYPO3 extensions there is one particular thing, that should be different to most of the variants of service level agreements provided by other open-source projects. Having to buy a so called "enterprise" or "professional" edition of the extensions or TYPO3 itself just to become entitled for an SLA is a No-Go, since it will create two classes in the community and contradict the principles of free software implied by the GPL.
The benefit for the people agreeing to a certain service level should be defined by reliability and responsiveness, not by getting access to something, that is unavailable for the rest of the community. So there is an agreement to still share the improved public extensions with everybody in the community while getting a personal early or immediate access depending on the level and the priority you paid for.
For developers there is another agreement: They have to accept and publish fixes and changes to their extensions up to a certain degree, so the whole pool of developers can take care of the extensions covered by the SLAs. This will help to avoid forks but of course they are still possible even though the other two ways are preferable.
So the agreement we offer for agencies and clients is, that we will provide the missing warranty, a professional response team and professional developers taking care of your mission critical extensions based on the principles determined by the GPL.
TL;DR - Conclusion
This is how agencies and clients benefit from our Service Level Agreements
We need to solve the dilemma created by the "no warranty" clause of the GPL, since agencies and clients often need a warranty. Currently agencies provide lots of patches and forks to make sure that extensions are working for their clients.
There aren't any predefined packages available, since you name the extensions you want to get covered by the SLA. Add the necessary response time and a monthly price tag to determine an hourly rate for services which are not included in the monthly fees. We will take care of anything else either way and you can even resell an SLA for your agency server to your clients.
The 1st and preferable way will include extension maintainers bound by contract. The 2nd way will provide extension maintainers with code by our professional team still bound by contract. The 3rd way is what we are going to avoid, since it will offer a forked version of the extension maintained by the Coders.Care team.
Each of the three ways will be an improvement compared to the current state.
Latest Tweets
Recent Tweets
Testimonials
Coders.Care is the logical progression of the cooperation between providers of TYPO3 extensions and their users. Especially the point of communication during the preparation of a project will be optimized thereby. The developers can focus on their strenghts, while Coders.Care deals with questions, answers and management. In the consequence there will be clear statements about maintenance and further development of TYPO3 extensions, so the trust in TYPO3 and the projects implemented with it will be strengthened. As a TYPO3 agency we can only benefit of such a service.
© Copyright 2024 Cybercraft GmbH