It is certainly true that successful TYPO3 extensions increase the visibility for companies and thus also improve the reputation and competence to the outside world. It is also true that this generates valuable inquiries and, in some cases, paid orders for feature X or Y of the expansion. But no company can survive from this in the long term. Why is that?
Maybe we should start looking at the past. How did it all start? The TYPO3 ecosystem got going with the introduction of the Extension Manager. The model we were so familiar with was new at the time and still allows the range of functions of TYPO3 to be expanded or changed today. But the Extension Manager is more than that. In connection with the TER (https://extensions.typo3.org) this is also a showcase for the entire ecosystem. Especially in the early years, a well-functioning extension was the best means for self-marketing and thus for new leads.
The "feature-driven" business model also established itself here. Users request new functions and the developer can earn his living with it. It works pretty well at first and is mutually supportive. Good new features are attracting more users. More users have more needs, which ends up in new feature requests.
It would be nice if it could go on and on. But everything is evolving. Small businesses also become lone fighters and, if everything works out, they will grow. Simple extensions become extensive solutions with many thousands of lines of code. Code that can no longer simply be maintained on the side. And employees whose passion is not necessarily programming for TYPO3 in their little free time.
And this is where the real problem begins. Many extensions are now more or less Feature Complete and are also used in many projects. The expectation of users is that compatible versions of these extensions should also be available for all new TYPO3 ELTS versions. And of course such an extension has to be error-free and yes, pull requests should ideally also be reviewed and merged in real time. What is often overlooked: All of this takes time. Either free time or working time. In the latter case, it also costs money (in the form of wages and, at the same time, opportunity costs in the form of lost sales).
I am of the opinion that we have to develop a functioning business model for our ecosystem so that we can keep the variety and quality of the extensions high.
What solutions do we actually have?
- The TYPO3 Association should fix it. We could also use part of the budget for the extension ecosystem. Sounds very simple, but in my opinion it would be the wrong way to go. The funds are very limited anyway and I think that with the focus on core development, education and research we can achieve more in the long term.
- Paywall: Then we'll just sell the extensions. Sounds logical and simple. The implementation is then a little more difficult. That would mean that you need a sales process, suitable support offers and also a strategy for how to approach upgrades. We tried this way ourselves and it works for individual solutions that offer a special USP. Another major problem is that a majority in the community still equate open source with “free beer”. The marketing of the content publisher works for us. A maintenance agreement is always mandatory for each customer. In this way, we can also guarantee continuous further development. Nitsan's t3terminal is also a potential channel for the sale of less complex solutions.
- Freemium model: DkD exemplifies a mixture of free availability and chargeable add-ons with SOLR. We do it ourselves in a similar way with Lux. There are basic functions free of charge via the TER and individual special functions can be purchased.
- Crowdfunding: Volunteers come together to develop a role together. We have also had this model several times in the community with varying degrees of success. Basically you can say that this route would be nice, but in practice it takes a lot of time. We currently use this route primarily to make free stock extensions compatible. That is, if there is a demand for an expansion, we try to finance it through our own customers and through the community. Nevertheless, it takes a lot of time and does not always lead to the goal.
- Verified extensions & integrations for TYPO3: I am including the concept here for the sake of completeness. The idea was published by TYPO3 GmbH in mid-2021. "Verified extensions" should be specially marked and thus bring better visibility for the companies (or authors) behind them. Improved marketing would be the main benefit here. However, the requirements for this are relatively high (which is also a good thing in my opinion). But I cannot see a fixed income stream.
So what could a workable concept look like that reflects the many different needs? The aim should be that:
- Extensions remain largely freely available
- Quality standards and safety standards remain high
- Contribution is promoted or rewarded
- Early availability of extensions for new major versions is guaranteed
- Visibility is maintained at a central point (TER)
- Authors receive better remuneration for their work (regardless of feature releases)
There was already the approach of a central marketplace for TYPO3 (in the way that Nitsan is currently offering). But I think that does not fully reflect the open source idea. My idea could be a mixture of the "Verified extensions & integrations for TYPO3" approach, crowd funding and firmly defined support services.
My idea consists of the following building blocks: The implementation could take place on the basis of the current TER in connection with the existing ecommerce platform of TYPO3 GmbH. Authors could then join an adapted "Verified extensions & integrations for TYPO3" program, which is supplemented by some components:
- Visibility of the contribution: Authors and contributors to extensions should have improved visibility within the TYPO3 community. This can be done, for example, in the form of public personal profile pages. Companies should be able to collect the contributions of their employees. The aim is to reward the participants in the community with visibility and awards that also contribute a lot to the ecosystem. The whole thing should of course also be carried over to other areas (core contribution, team contribution, ...).
- Pull requests: Processing pull requests (PR) takes time. It must be checked whether the quality delivered is correct, whether the change in function makes sense and whether the documentation needs to be updated. It should therefore be possible to pay for the processing of PRs in a standardized way. This means that the person who creates a PR should also finance it. If the PR writer doesn't want to do it himself, it could be funded through the community. It is important that it is always transparent for everyone.
- Issue handling (features / bug fixes): New issues and feature requests should always be checked and evaluated. This means that a price tag can be stored to implement the issue so that different users can come together to sponsor the specific topic. However, the author must always communicate clearly if, for example, a feature is rejected, so that no unnecessary PRs are generated.
- Release handling (minor / major): Releases also cost time. More tests have to be carried out, partly for different TYPO3 versions. It should therefore be possible to find funding for releases as well. One way would be, for example, similar to how it works with Patreon, to support extensions permanently so that regular releases are also possible. But here, too, it is important to focus on transparency and purpose. These funds also include obligations to carry out releases. Larger upgrades in particular could thus be financed transparently.
- Support Guarantee / Professional Support: Urgent support inquiries should be resolved by users via paid support at fixed conditions. The author should be the primary contact. If this is not available (or ready), it should be able to be passed on to "support professionals" via the platform. Of course, there should always be free community support. For this purpose, there should be firmly defined forums via the extensions (e.g. https://talk.typo3.org)
- Escalation management: If you participate in the program as an author, there should also be an escalation management. For example, if the author no longer complies with the rules, it must be possible for the extension key to be withdrawn. This guarantees binding availability and opens up opportunities for further development for the community.
What do you think about the idea? I look forward to your feedback. Write to me on Twitter @in2code_stefan #typo3-professional-extensions. Maybe we will manage to build a sustainable and transparent model for TYPO3 extension development.
