CloudFunding

To flourish, Open Cloud Services need the right financial incentives. The nature of commercial cloud services provide us with an opportunity to create a funding mechanism for the open cloud services and open source projects that these commercial services depend on: At some point service providers almost always earn direct revenue for use of the service, whether its the hosting fees from a cloud provider or a commercial SaaS service, or directly from the service’s end-users.

The diagram above illustrates in broad strokes how such a funding model could work:

1. Service Providers pledge to commit a portion of their revenue to the Open Cloud Services they use. An allocation mechanism is used to divide that between those services.

2. In the same manner, open cloud services distribute a portion of the funds they received to the open cloud services and the open source projects that they depend on.

3. Those projects do the same to the projects that they depend on, and so on.

The Big Picture

Open source has come to dominate so much of software because there is little friction in how and where it can be used and in how easy it is for anyone to contribute to its design and development.

The downside of this arrangement is that the funding and motivation for development does not come directly from the product’s use. Instead the value must come indirectly (e.g. as part of a sales distribution strategy) or for unrelated reasons (e.g. personal satisfaction).

In contrast, proprietary products (generally) require a financial commitments upfront both for its use (i.e. purchase) and for its development through employee and work-for-hire arrangements.

This funds and incentives its productions but these financial commitments limits both its production and use.

However for products where the goods are non-rivalrous (like code and other forms of intellectual property) and its marginal transaction and distribution costs tend towards zero (as on the Internet) this imposes artificial scarcity and costs. What if we could have the best of both worlds?

Such an arrangement looks ideal but of course begs the question of exactly how we can manifest those green arrows:

• How do you get users to pay for something that is freely available?
• With everyone freely contributing and reusing each other’s work how can you possibly untangle much an individual contribution is worth?

These questions are addressed in more detail below, but in summary, while code and possibly data are freely available under open source licenses, a running service is not, and so a user’s decision to participate follows the same build vs. buy economics that has made cloud services so compelling.

For the second question, we cut that Gordian Knot by having those decisions made locally and voluntarily, and the infrastructure lays the groundwork for applying alternative mechanisms if local consensus is met.

The Bigger Picture

Besides code, there are other kinds of “goods” with these same economic characteristics and where there is also a strong interest in open distribution, both at the societal level and at the personal level by its creators.

Imagine if we could apply the same mechanisms and infrastructure to fund endeavors such as:

• Journalism
• Music
• Writing and art

The big proprietary platforms that dominate these fields – for example, Google and Facebook for content or Spotify for music – have come to dominate because they share the same characteristics of Open Cloud Services in the above diagram: it is very easy to “contribute” to those platforms, use is free (if you don’t mind ads) and some portion of the value realized by that use flows back to the contributor in an automated fashion without manual effort or decision making by the consumer or the contributor.

Open Cloud Services would make it easier and cheaper to build alternatives to these proprietary platforms and cloud funding open up the possibility of mechanisms that recognize the value of content based on democratic and decentralized decision making, not arbitrary algorithms that reward least common denominator content and drive an unhealthy Internet.

This is the long-term vision of OneCommons: to build a platform where you can create what you love, make it available to all, and get fairly compensated.

How It Works

Today^*

Open source developers sign up for cloud funding by registering their projects.

When a user deploys cloud services a service fee is added to fund the projects it depends on.

The cloud-funding process begins with the user choosing which of those projects to fund.

We are building an initial implementation of cloud funding on the OneCommons platform.

Cloud funding is illustrated in the diagram at top. Users can choose how to allocate their service fee among the projects they depend on. Similarly, projects that make a minimal revenue have a requirement to share a portion their revenue with the projects that they depend on but they too can choose which of those projects to commit to.

By letting all participants choose which projects to fund these fees serve more like investments than payments.

Tomorrow

Of course having only one website provide cloud funding isn’t enough – beside all the general risks and limitations of having one centralized service, there are specific reasons why multiple cloud-funding service providers would be needed. For example to accommodate different legal jurisdictions and currencies and to support a variety of payment terms and methods. As the network grows we could imagine cloud infrastructure providers like AWS or Google Cloud Platform wanting to run their own services. And at Internet scale we would need competitive services that differentiate with different service enhancements, for example, reputational validation and management tools to avoid system gaming and fraud if those unfortunately realities arose.

We could support multiple service providers by developing a standard open cloud service license every provider would use when licensing open cloud services to its customers. This license those service’s code and possibly data under an open license¹ in exchange for the customer committing to participating in cloud funding.

Conceptually, that cloud services license commits the user to contributing to the cloud fund a percentage of the infrastructure costs of running the service. How that is actually accounted for depends on the nature of the service provider. A service provider that is a cloud infrastructure provider or integrates through cloud infrastructure providers’ marketplaces can easily add a service charge. A service provider that supports on-premise installations might require per-cpu licensing with terms similar to enterprise software licenses.

If a user wants to run an Open Cloud Service without participating in cloud funding they of course can do so by using the service’s code under the terms of their original open source licenses. So one way developers can encourage participation is by licensing their work under a restrictive “copyleft” open source license such as the AGPL.

Developers (or to be more precise, the work’s copyright holder²) who wish to participate in cloud-funding enter into a cloud-funding license with a service provider that gives the service provider the right to sublicense their work to users under the terms of the standard open cloud license.

An Open Cloud Service licensee allocates their payments to the developers of services that they are using. In the same way, recipients of these funds agree to split their payments to the projects they depend³ on. The allocation is done by the recipient in a manner of their choosing unless the dependents have reached a consensus on an alternative allocation method.

Of course it won’t scale for each developer to have to enter into agreements with every service provider. So there would need to be standard cross-licensing agreements between service providers to enable cloud-funding data sharing and payment settlement. This would be an ideal application for a blockchain-based decentralized ledger that opens the door to using smart contracts to implement allocation strategies.

FAQ

• Why do you expect businesses to pay for something if they can get it for free?

We don’t! In the short term, on our platform these fees are bundled with the rest of the value it provides. Generalizing this position, all but the very largest IaaC and PaaS providers would benefit from this ecosystem, so it is in their long-term interest to nudge their customers towards participation through means such as their fee structures.

Longer term, individual open source projects can choose to encourage participation by leveraging the differences between permissive open source licenses and more restrictive “copyleft” licenses like AGPL, essentially charging for a more permissive license. And at scale, fees could be quite low and still viable in aggregate. In that scenario, indirect benefits (e.g. reputational, influence on the projects they depend on, etc.) would make participation worthwhile.

• How can you determine the value of a contribution? / How can we figure out what a service or contribution is worth?

Commercial cloud providers and SaaS have to figure out pricing and they provide the natural boundary to approximate pricing.

The voluntary scheme is designed to be a minimal allocation scheme everyone can agree to. If all the candidates for a particular allocation can form a consensus for alternative then that will be used. If this catches on we’d hope this inspires the invention and discovery of better schemes to determine value and pricing.

• How can this compete with proprietary business models?

Most “pure” open source business models are based on a loss-leader or freemium strategy that leverages the frictionless distribution of open source for marketing and sales and earns income from ancillary sources such as support or hosting or proprietary enhancements. The cloud funding model can be used in the market segments where these open source models are competitive – likely by those same companies as an additional revenue stream.

More generally, a business will have many motivations and considerations when deciding whether to release internal development work as open source: whether doing so 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.

Just as importantly, cloud funding provides funding opportunities for smaller and noncommercial open source projects and enables individuals to be compensated for their time so they have the freedom to devote themselves to the open source projects they are passionate about.

• It seems like projects lower down the dependency chain will likely only receive a small portion of the funds?

Not necessarily – projects deep in a web of dependencies tend to be more general and so they may receive funds from many sources even if each contribution is smaller. And projects below a minimum threshold will not need to split their share any further. But there will probably always be open source projects that will not participate because they won’t earn enough for it to be worth it to them. In those cases the upstream projects will earn more, creating a market equilibrium that will shift as the total pool grows.

• Is this “open cloud service license” an open source license?

The open cloud service license as described above is a usage agreement for an on-demand service so conceptually and legally it can’t qualify as an open source license. But it does provide that the open cloud service’s code is available under a permissive open source license while the service agreement is in effect. And an open cloud service’s code will always be available for use under its original open source license.

• How does this compare to open source funding services like Tidelift or Open Collective?

Services like Tidelift or Open Collective provide a means for someone to donate to an open source project. Cloud funding expands the source of funds by automatically charging a fee for the usage of an open cloud service. The funding will come from users that don’t necessarily care about supporting open source, the service just needs to be worth the value it provides them.

Design Notes

Critical Success Factors

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.

Design Criteria

The goals for a successful “cloud-funding” mechanism listed earlier led to the following criteria for choosing this approach:

• Efficient: we want to direct resources to the projects that will make the biggest impact.
• Fair: hard to define but the perception of unfairness will surely undermine any motivation to freely contribute.
• Intuitive and simple to understand.
• Resistant to gaming and perverse incentives arising from arbitrary quirks in the system.

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, 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, price discovery is hard and even if done well from a market efficiency 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.