RT @WapplerSystems: Die #TYPO3 community braucht in Sachen TER ein wenig Unterstützung
As a developer, reseller or user of open-source software you want a professional partner to make sure your solution is something your business can rely on. Sustainability and responsiveness outweigh license pricing.
Estimated time to read: 6 minutes
Starting with the prolonged LTS phase of TYPO3 4.5 another option appeared on the radar, which was quite new for the TYPO3 project, but actually had been available in the open-source world for quite some time already. Now that the TYPO3 Company has been founded they started to continue the successful concept of so called Service Level Agreements - aka SLA.
If people like you, they'll listen to you,
but if they trust you, they'll do business with you.
One of the most successful examples for the combination of open-source software and the SLA concept is RedHat, founded in 1993 and a 2 billion dollar global player today, creating a huge part of its revenue with services built around open-source.
Of course this is nothing that the TYPO3 project could currently be compared to, but still it shows, that in the business world people are willing to invest a lot more money as soon as they get a product they can trust.
So creating such a trusted environment for TYPO3 extensions in close collaboration with the TYPO3 Company and the TYPO3 core team could be another option for extension developers to still make a living based on a product they already shared for free.
The benefit of that collaboration is already visible each year at the TYPO3 User eXperience Week and the TYPO3 Developer Days, but since this would open up a completely new way of dealing with the financial aspects of TYPO3 extension development, we collected some details for this article.
Wealth, like happiness, is never attained when sought after directly.
It comes as a by-product of providing a useful service.
TYPO3, like most of the well-known content management systems, is built as a modular system. The rock solid base of the system is the TYPO3 core, provided by the core team and backed with budgets and man power by the TYPO3 company. Additional functionality is added by lots of different modules and plugins, provided by so called extensions. While there are service level agreements for the core now, they were not available for these extensions - so far - making the use of extensions somewhat risky.
Now a provider of SLAs for TYPO3 extensions has to make sure that each piece of your TYPO3 puzzle will fit not just today but even with upcoming new versions of the TYPO3 core. They should provide you with solutions for any kind of extension related problems within a reasonable time frame.
They must give you a reliable one-stop customer service regarding bug fixes, change requests and features for all the extensions you need to securely run your business relevant TYPO3 based websites and applications.
Today you still have to rummage through the scattered resources on TYPO3 Forge, TYPO3 Git and Gerrit, Github, Gitlab, Stack Overflow and several forums. Instead there should be one hotline for service calls, one ticket system for reports and one project team to manage a whole pool of officially approved and supported extensions.
The benefit for both, developers and users of extensions, will be the reduced administrative effort and the built in crowd funding of the SLAs. As a result developers can focus on coding and gain more sustainability for their business, while agencies and customers will get a guaranteed and reliable service for a reasonable price.
Taking a look at the service level agreements provided by the TYPO3 company, there seem to be several sticking points when it comes to define the actual level of an SLA and the price tag to be attached to it. Besides a certain limit to the number of sites per SLA there is a difference between priority and non priority bug fixing and of course a difference regarding the response time needed to be on the safe side with a particular project.
With extensions you have to take care of an additional level, since there is a significant difference between internal extensions, which are kept private, and public extensions taken from the TER. So in the end there will be a combination of the number of extensions, prioritization, response time and availability that creates a certain price tag.
Now let's take another look at the SLAs provided by the TYPO3 company: At least the non priority fixes for public TER extensions should be free of charge for each of the extension SLA levels too. This way the motto "inspiring people to share" can still be adhered to.
Of course it won't be enough to have just the same five ready made levels, since due to the huge number of extensions and their possible combinations and use cases it is not as easy as for the TYPO3 core to provide a perfect match for your individual scenario. So there will be a need for individually adjusted levels. Depending on the price tag of any level the hourly rates for services which are not free of charge should be adjusted accordingly too. So higher a level would mean lower rates.
Additionally it should be possible for agencies to run a single service level testing server, while providing the actual bug fixing services as a reseller to their clients. This would create another built in crowd funding effect, while increasing the possible level for the agency server itself, still reducing the administrative efforts for the project management team of the SLA provider.
There is one particular thing, that should be different to most of the variants of service level agreements provided by other open-source projects though. 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 must be 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 the need for 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 avoid forks.
There are several nice side effects of these agreements. For example it would reduce the number of extensions which are maintained by a single person and therefor the risk of loss when using these extensions. Due to the four-eyes principle this would increase the quality of each extension in the approved pool and at the same time reduce the amount of "me too" extensions in the TER.
There would be a powerful team of developers backing the service levels, so it would be easy to keep the approved extensions on a level with upcoming versions of the TYPO3 core. And since this would be done in close collaboration with the TYPO3 core team and the security team, core bugs and security holes affecting extension behaviour could be fixed and published much more easily as well.
With the TYPO3 company offering SLAs for the TYPO3 core, having similar agreements to maintain and improve extensions seems to be just a logical consequence.By providing joint forces, built in crowd funding and paid development,
SLAs combine the advantages of the approaches we already discussed in former articles, while getting rid of most of their drawbacks.
Compared to donations and association budgets they provide the better income, compared to crowd funding they create more sustainability and compared to the current state of extension development they generate more man-power to improve security, reliability and overall code quality.
With more people covering both, work load and costs, SLAs are the business implementation of the TYPO3 motto "inspring people to share" especially when the result is accessible for the whole community in the end.
© Copyright 2023 Cybercraft GmbH