To flourish, Open Cloud Services need the right financial incentives. Key requirements for a successful revenue model are:
Rewards openness Incentives should reward sharing and re-use, not maximizing control. And to support open source in general.
Competitive Financial returns should have the potential to be competitive with proprietary alternatives to participants throughout the value chain. Leverage the advantages of the open source model. Capable of attracting sufficient investment.
Sustainable Scale, resistant to fragmentation, financial takeover, and system gaming
Decentralized Minimize central points of control both technically and in governance. Decentralization is key to scalability and avoiding market distortions and control.
Luckily cloud services are inherently metered and usage based so we have a natural point to insert a funding mechanism that meets these requirements. The sections below describe an initial version that we are building as part of the OneCommons platform and a future version enhanced as a decentralized service.
The OneCommons platform (itself an Open Cloud Service of course!) lets developers share open cloud services and users discover and deploy them on different cloud providers.
A “gratuity” is added but user can choose which projects (which can be any open source project the service depends on) to split it with. Similarly, projects that make a minimal revenue have a requirement to share a portion their revenue with the projects that they dependent on but they too can just which of those projects to commit to.
By letting all participants choose which projects to fund these fees serve more like investments than payments.
In order to scale we need to generalize the above system. The first challenge is creating a system that generates sufficient revenue without undermining the fundamental principle of open source software being freely available. For developers that want to maximize revenue we propose a dual license model that pairs a restrictive open source license (like AGPL) with a permissive one (like MIT) that is only available if the user enters in a contractual relationship with a payment service. An entity that doesn’t want to abide by the restrictive one can choose to agree to the usage terms of the payment service.
Of course one payment service isn’t enough – developers might want to be paid directly and as the system grows, we imagine cloud providers like AWS and developer platforms like GitHub might want to run their own services. Other reasons for multiple payment services, beside not wanting central controls, are jurisdictions, currencies, payment terms and methods. We also competitive services that differentiate with different service enhancements, for example, reputational validation, manage system gaming and fraud.
Because one developer’s application can depend on software associated with payment services that the end-customer isn’t party to there will also have to be standard agreements between payment services to prevent fragmentation of the ecosystem. It could implement the cloudfunding mechanism described above as a common denominator allocation strategy.
Distributing these transactions between payment services appears to be an ideal application for a blockchain-based decentralized ledger and that opens the door to using smart contracts to implement other allocation strategies if there is consensus between the participants.
The focus has been on a system that works for two very different kind of users:
Enable individuals to be compensated for their time so they have the freedom to devote themselves to the open source projects they are passionate about.
Provide an incentive for commercial entities to create open cloud services instead of proprietary ones or to release more of their development work as open source. Any business will have many considerations when deciding to release development work as open source: Whether that enhances or detracts from their core business, whether it will reduce or increase development costs, etc. Adding a direct revenue stream will hopefully shift the calculus in favor of open source often enough.
The goals for a successful “cloud-funding” mechanism listed earlier led to the following criteria for choosing this approach:
A key design decision is to avoid any pricing mechanism. Besides the initial “gratuity” end-customers must pay, how it is allocated is made by voluntary decisions from all participants. There are a few reasons for that:
First is that the very act of assigning a dollar value to code undermines open source’s unique advantages. Intuitively we can feel the “magic” of creating software is diminished when we start thinking about it as a means to a ruminative end; more concretely it can distorts incentives. Open source shines when passionate individuals are openly collaborating to craft the technically best software without agendas. Putting a price on it gets in the way – for example, if using someone’s else software library reduces how much money I make maybe I’ll won’t choose it even though it’s the best choice.
Second, proper pricing is difficult to do well and even if done well from a market perspective it can easily lead to the perception of unfairness – which would surely undermine the motivation to freely contribute.
Third, the risk of fragmentation – any mechanism that assigned a price to individual services or contributions would beg comparison with alternative mechanisms that could lead to competing pricing regimes. Such fragmentation would undermine one of the major benefits of openness and open source: universal availability and the network effects realized by that ubiquity.