I want to applaud the author for taking such a bold step, but I would like to disagree with the assertion in the manifesto that all forms of open source software are failing business models. I would like to encourage the author to dive deeper into the various ways that commercial companies that promote open source are finding ways to make it commercially viable.

By experience, I was founder and CEO of Codenvy, which ultimately made Eclipse Che open source workspace server. We created that with an EPL by taking the large majority of our intellectual property and open sourcing it. While Codenvy's IP was closed and commercially for sale, there were significant feature differences between Che (for workgroups) and Codenvy (for enterprises). We steered the entirety of our company's go-to-market to be Eclipse Che-first promotion, and as Che grew to 50,000 usage hours / day and 10s of 1000s of downloads, the cross-over to Codenvy was significant enough where we were able to build a nice business. It was a business that let us put more than 60% of our engineering resources into Che and we had 40 engineers. Codenvy was later acquired by Red Hat earlier this year.

I am CEO of WSO2, whose product line is entirely (well, almost) Apache licensed open source. WSO2 competes with large proprietary platform vendors like Oracle, IBM, Tibco, Software AG, and Mule Soft. Mule has an open core, but largely is still a proprietary vendor. We have 400 enterprise customers and - from what we can tell - probably another couple thousand installs of our various open source servers for identity, streaming SQL, integration, or API management. We estimate about 5 trillion transactions run through our software each year and our customers are some incredible high quality brands.

The company is 12 years old and has stayed committed to open source in this way. But we are commercially viable. We have 492 employees worldwide, offices in 5 countries, and a rich set of long-lived subscribing partners. This allows 100% (caveat below) of our engineers to work on pure open source development. Of our 492 employees, roughly 400 are technical. All of our technical people work in engineering, and then do rotations into support, consulting, training, or solution architecture / sales / marketing so that everything that we do related to our technology is witnessed by a full fledged engineer that can bring the advancements back into the product itself. And this also has an affect of building a strong ecosystem, where we have roughly 1000 other people who are certified and / or committers to our various open source initiatives. So I look at us as a healthy business, commercially viable, and found a way to make pure open source work.

The caveat - the way that we have been able to balance the trade off between a pure Apache license and the commercial viability is around subscriptions. Subscriptions offer customers specialized value for their implementation: support, indemnities, warranties, security scanning, incremental builds, and certified builds. To help us commercially, we only distribute patches, updates, and security addendums as binaries that are closed source. Customers who have a subscription get a perpetual license to the patch. Otherwise, the patch is also made into our project's code base, and at any time you can compile the code from the Apache base. Every 6 months or so, we update our open source binaries with the cumulative updates and patches. It's this sort of balance that allows us to create value for enterprises and gives them an incentive to get onto a subscription with us. And it's through those subscriptions that we have become a commercially viable company.

There are other models as well - with open core, and what I call open fringe, which are open source platforms that have closed-source "management" around it. These are all flavors of permissiveness that each company must find for itself to find an equilibrium between commercial interests and contributing to open source.

Again, I am very positive on the author's initiatives and do not want to provide a critique. But really do encourage a deeper exploration of the commercial ways many companies make OSS viable.