4 ms·

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 softwar

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.

kemitchell 9y ago
I welcome critique! And greatly appreciate the time you've put into this comment. I've bookmarked it to read again, in case I've missed something the first time around. I'd also be interested in following up, publicly or privately, in a more direct way. I support what you're doing, and it sounds like you support at least the spirit of what I'm doing. We should talk. One point I'd like to go ahead and bring up: A common thread through the examples of success you've given is size. There are some examples of single-person, profitable operations, like Sidekiq, but they're very, very rare. Many successes boil down to economies of scale on services, information, relationships, corporate process compatibility and so on. L0 aims to make one business model that currently involves a lot of structure---dual licensing---available to very small, independent players. As an indie developer today, sure, you can set up an LLC and start e-mailing forms off the Internet to procurement departments. But doing all that will swallow you, as well as the time you already don't have to spend developing software. Part of making that play available to indies is automation. Part of it is standardization: one form for buyers to review. Part of it is network effects: one place for customers to get all the licenses they need, in one transaction. Part of it is recognizing a play that can, forgive me, "scale". Dual licensing is the most direct of the well known options, in that sense. The software is valuable. Pay for the software. Where does the pay go? Into the one who'll make more and better software.
- TylerJewell 9y ago
  Yes, of course - happy to discourse further. tyler at wso2 dot com. In seeing your response, it does occur to me that you may be tackling an alternative form of monetization that is suitable for micro-payments, or for open source project leaders that do not desire to oversee the more traditional commercial business aspects that you must under take to monetize a project. These are things such as support, consulting, and training. There is an investment (sweat, not monetary) that goes into thinking about how to deliver such services, meeting an SLA, and whether there are associated assets that must be created to support such a delivery. This is a lot of effort and maybe not commensurate with the time or objectives of the OSS developer. There is also the challenge of commercially transacting on such alternative forms of monetization (or value added software that is proprietary). So while these are profitable endeavors, there are any number of reasons that it may not be interesting to pursue them. It may not have to do with size of the project, but of the cost to pursue the alternative monetization strategy. So in that case, it may be interesting for a project to have different forms of licensing at different phases of development that are more conducive to either micro-monetization or classic-monetization, for which WSO2 falls into. And so perhaps it benefits us all to think of licensing for monetization as a spectrum to be applied given the objectives of the project leaders.

kemitchell 9y ago

I welcome critique! And greatly appreciate the time you've put into this comment. I've bookmarked it to read again, in case I've missed something the first time around. I'd also be interested in following up, publicly or privately, in a more direct way. I support what you're doing, and it sounds like you support at least the spirit of what I'm doing. We should talk. One point I'd like to go ahead and bring up: A common thread through the examples of success you've given is size. There are some examples of single-person, profitable operations, like Sidekiq, but they're very, very rare. Many successes boil down to economies of scale on services, information, relationships, corporate process compatibility and so on. L0 aims to make one business model that currently involves a lot of structure---dual licensing---available to very small, independent players. As an indie developer today, sure, you can set up an LLC and start e-mailing forms off the Internet to procurement departments. But doing all that will swallow you, as well as the time you already don't have to spend developing software. Part of making that play available to indies is automation. Part of it is standardization: one form for buyers to review. Part of it is network effects: one place for customers to get all the licenses they need, in one transaction. Part of it is recognizing a play that can, forgive me, "scale". Dual licensing is the most direct of the well known options, in that sense. The software is valuable. Pay for the software. Where does the pay go? Into the one who'll make more and better software.

TylerJewell 9y ago
Yes, of course - happy to discourse further. tyler at wso2 dot com. In seeing your response, it does occur to me that you may be tackling an alternative form of monetization that is suitable for micro-payments, or for open source project leaders that do not desire to oversee the more traditional commercial business aspects that you must under take to monetize a project. These are things such as support, consulting, and training. There is an investment (sweat, not monetary) that goes into thinking about how to deliver such services, meeting an SLA, and whether there are associated assets that must be created to support such a delivery. This is a lot of effort and maybe not commensurate with the time or objectives of the OSS developer. There is also the challenge of commercially transacting on such alternative forms of monetization (or value added software that is proprietary). So while these are profitable endeavors, there are any number of reasons that it may not be interesting to pursue them. It may not have to do with size of the project, but of the cost to pursue the alternative monetization strategy. So in that case, it may be interesting for a project to have different forms of licensing at different phases of development that are more conducive to either micro-monetization or classic-monetization, for which WSO2 falls into. And so perhaps it benefits us all to think of licensing for monetization as a spectrum to be applied given the objectives of the project leaders.