OpenSource: Enterprise Editions are a mistake!

This week I was asked if, as part of the professionalization of the TYPO3 Association, we are planning to release an Enterprise Edition, i.e. an additional version of the freely available TYPO3 Edition that is only available for a fee (e.g. a bundled support package). I know it’s tempting to want to do what everyone is already doing. But in fact I think Enterprise Editions are quite nonsense strategically. They are old-economy business model thinking, even though at the moment it looks like they are the gold standard for open source companies to make money.

Reading time (4 minutes)

Enterprise Editions appear to be a logical step towards a revenue stream for OpenSource-based products. Why not go for this model?

Degradation of the community

In order to be able to argue for an Enterprise Edition with the customer, you need unique selling points. These can include, for example, additional functionality, additional support, additional interfaces, etc. What at first glance appears to be a good thing for the customer is in fact considerably inferior to the freely available Community Edition.

I am convinced that open source companies or organizations like the TYPO3 Association should focus on the community and find and build revenue streams around it. However, an Enterprise Edition does exactly the opposite. It makes the community product appear lower and, logically, the enterprise project must always be given priority (e.g. for bug fixes, etc.) if you don’t want to alienate your paying customers.

What is actually the great advantage of open source projects, namely this peer production, is systematically undermined in this way. It should come as no surprise that no large, active communities develop in this way.(Please do not confuse community with users in the forum!)

Support only for the Enterprise Edition

Many OpenSource companies link their support packages exclusively to the Enterprise Editions. I have never really understood this, even after more than 10 years in this environment. It’s a paradox: you go to great lengths to bring a product, the Enterprise Edition, onto the market, go to great lengths to actively sell it and then limit a promising, complementary revenue stream to this proportionally small installation base.

A few OpenSource vendors will now reply that the risk of providing support for the Community Edition is too great. Yes, that may well be the case, but precisely because instead of taking care of the community and organized and clean peer production, they have invested a lot in the Enterprise Edition and neglected the Community Edition. And, it’s not about giving a guarantee, it’s about providing official support. This is a real need in almost every large company. Especially when community editions are used.

So why not simply use the complete installed base in order to base a support offer on it (ideally in the 2nd and 3rd level area). Instead, open source companies try to attract customers to the Enterprise Edition, which is often not very easy because the requirements can usually be covered very well with a Community Edition.

The scalability thing

I can already hear a few people saying: “Yes, but support doesn’t scale.” That is indeed an argument. To offer support packages, you basically need manpower. Nobody who develops a business model particularly likes that. But that doesn’t mean that personnel costs are linear to the revenue curve. In practice, it’s more about guaranteeing base services and being able to react to peaks. Anyone who looks into this quickly realizes that structured support as part of a business model does not scale so badly. A prerequisite for this is, of course, a robust product.

Freemium vs Open Source

Many providers therefore do not make OpenSource in the true sense, but Freemium with an OpenSource component. The definition from Wikipedia:

Freemium is a business model in which the basic product is offered free of charge, while the full product is subject to a charge.

If you take a closer look at the vendors, most of the time where it says OpenSource, it actually says Freemium. The descriptions read like this: Community Edition: “Basic CMS/eCommerce functions” and for the Enterprise Edition: “Advanced features for companies”. I don’t think that’s a bad thing, but doing the splits over the OpenSource theme probably doesn’t help these companies much in the end. The Enterprise Edition slows companies down more than they imagine.

Voluntarily higher costs in development

From the provider’s point of view, there is another component that I don’t really want to understand. Why should I have a team developing the enterprise edition in addition to the community product (well, I know that this can also be due to historical reasons, e.g. in start-ups)? However, most companies sooner or later run into a scenario in which they have to maintain and further develop two versions in parallel. And then, logically, the Community Edition is usually neglected.

Who really earns money with the Enterprise Edition?

If you look around, you can see that there is actually no company that has really been able to leverage the Enterprise Edition model. I don’t mean that they couldn’t/can’t generate significant sales. However, many of the companies are (still) very small (<100) and it takes comparatively few (recurring) Enterprise subscriptions to cover a substantial part of the costs. However, for most of them, especially the shooting stars of recent years, it was never quite enough. Those who exploited their potential had to finance their growth externally, while those who committed to self-financing simply fell short of their potential.

How?

This is exactly the question I have been asking myself for a long time and I believe I now have a simple answer: By putting the community at the center.

All activities that you undertake as a commercial entity of an open source project should be there to help the community.

So before you go and simply define any sources of income, you should ask yourself what our entity can contribute to making the community better off. There are direct and indirect benefits. Direct services are, for example, funding for core development and product management, enablement costs and so on. Indirect services include marketing and public relations.

The commercial unit must ensure that services that are not provided on a voluntary basis for whatever reason are still provided or can be provided at a much higher rate. And it has to bear these costs itself. It is, so to speak, the contribution of the commercial entity to the OpenSource community.

On the other hand, you should analyze exactly where you can create win-win situations as a bridge builder in the community. How can you bring people together and fulfill needs, and how can community members mutually benefit from this? The revenue streams can then also be installed along these win-win constellations.

One example of such a win-win situation is the Marketplace, which I have already presented more broadly, or rather my vision of it: everyone benefits from the centralized, paid provision of extensive additional functionality. The agencies that have created these extensions up to now but have not published them for commercial reasons, the agencies that use such extensions for their customer projects, the customers who can obtain good, existing functionality more cheaply and ultimately TYPO3 as a brand, as this functionality is transparently available and can be used for marketing purposes, for example.

At this intersection of various interests, the commercial entity behind the open source project must take a royalty on the value added. This is completely legitimate and understandable for everyone. This is the perfect revenue stream in the open source environment: Everyone wins.

Finding a win-win pattern

The development of a business case for open source communities should therefore never consist of me-too or best practice. Because every community is individual.

Rather, it is about first identifying these win-win patterns (even if they are sometimes unusual) and building products and revenue streams based on them. In the case of TYPO3, this also means that all the money goes back to the community, because the TYPO3 Association belongs to the community. However, the development model of win-win patterns also works for commercially oriented companies. The mechanics are the same.

Admittedly, it is not easy to switch from an Enterprise Edition model to other models. I can’t think of an example right now where this has worked. Most open source products also lack a sufficiently large community. And this is also a chicken-and-egg problem: in order to run a platform-based win-win model, you need a large community, but the existence of an enterprise edition tends to prevent this.

From this perspective, such a change is associated with an immense economic risk. First of all, the change means a massive investment in the community and that starts with simply publishing the entire code under OpenSource. This is all the more difficult when customers, employees and the community have been committed to the Enterprise Edition for years.