anyone is free to access, use, modify, and share — subject, at most, to measures that preserve privacy and openness.
an online service delivered on demand over the Internet without the user needing to use their own hardware.
Open Cloud Services are cloud services that provide the same openness and freedom to users and developers as open source software. They give you all the benefits of the cloud without compromising freedom and control.
Open Cloud Services are to cloud services what open source is to code – cloud services that are freely available, reusable, re-mixable and developed in the open.
Cloud services are more than just code – they consume and generate data and they are hosted on cloud infrastructure. If we extend the principles of openness to data, users gain control over their data. If we apply those principles to hosting, service operators gain independence from cloud providers and, if fully realized, services would be location-independent and decentralized.
Just as open source software builds on each other to point that today it basically runs the Internet, our servers and most of our phones, Open Cloud Services grow stronger as they connect and depend on each other. And most will be revenue generating services – and so with the right protocols and licenses we can finally create a sustainable and competitive business model for funding open source software.
If we build an open cloud then not only can we create an alternative to the big tech monopolies but we can provide a foundation for more sustainable, equitable, and meaningful economy. A bold claim for sure, but “the cloud” is everywhere: as the IoT (Internet of things), behind machines learning and AI, as XaaS (“Everything as a Service”). Broadly speaking, “the cloud” is about the virtualization and automation of services and know-how – and as it develops hand-in-hand with technologies such as robotics, 3D printing, and lights out manufacturing, the cloud will encroach more and more on the “real-world” economy.
This is a future with tremendous risks but also tremendous rewards if we build a cloud that rewards openness, collaboration and individual autonomy.
A first step to getting a clear picture of what open cloud services would be to define “cloud services”. A practical definition might be: “an online service delivered on demand over the Internet without the user needing to use their own hardware”.
Now let’s define “open”: The Open Knowledge Foundation defines openness as:
Knowledge is open if anyone is free to access, use, modify, and share it — subject, at most, to measures that preserve provenance and openness.
If we apply this to cloud services, we get:
Knowledgeis open if anyone is free to access, use, modify, and share it — subject, at most, to measures that preserve provenanceand openness.
A related term is “free software”, which the Free Software Foundation defines as:
“Free software” means software that respects users’ freedom and community. Roughly, it means that the users have the freedom to run, copy, distribute, study, change and improve the software. [Emphasis theirs]
This focus on the user – “We call this free software because the user is free” – is particular relevant for us because cloud services aren’t solely about developers and source code; they explicitly involve the user. The free software definition codifies these rights into four essential freedoms (numbered 0 through 3) which we will gloss as the rights to Access, Modify, Share, and Remix (and redistribute) a program’s source code.
We can uncover what requirements a cloud service needs to be fully open by considering what these four freedoms imply for the following basic aspects of cloud services:
‣ Code: Having the code of a cloud service be open source is foundational not because it is a basic right but also because it provides the transparency necessary to implement the other freedoms. We can think of these as freedoms for developers since they are the ones that exercise them.
‣ Data: All cloud services need data to function and for nearly all the data either is generated as users use the service or is contributed by the users of the service. In this way data freedoms are freedoms for the users.
‣ Hosting: Hosting refers to where and how a cloud service is run. A cloud service that is locked into a proprietary cloud provider and is dependent on proprietary services can not be considered fully free or open. These are freedoms for the operators of a cloud service because it gives them the freedom to choose how and where a service is run.
The Free Software Foundation developed the four freedoms with code in mind, so for anyone familiar with open source code there shouldn’t be any surprises in the table below.
|Freedom||Open source Code|
|0 Access (Run)||Access code and use as you see fit|
|1 Modify||Right to modify the code|
|2 Share||Right to freely redistribute the code|
|3 Remix||Right to Modify and redistribute (fork)|
|Freedom||Requirements for Data|
|0 Access||Data Portability|
|1 Modify||Extensible formats|
|2 Share||Open data and data privacy|
|3 Remix||Open APIs|
|0 Access (Run)||Reproducibility|
|1 Modify||No proprietary dependencies|
These are freedoms as they apply to an individual service as it appears from the perspective a user interacting with it – not about the ability to create new copy of a service (that is already a given if its code and data are free). For example, the WordPress blogging platform doesn’t support open hosting as defined here: even though anyone can run their own WordPress instance, users have to create separate accounts and those sites will be perceived as separate services by its visitors. In contrast, the Mastodon micro-blogging platform is: user identities are shared and data is freely exchanged between instances.
These are freedoms granted to operators of a service but they also give users the freedom to be an operator. And even if a user doesn’t choose to do that, these freedoms still redound onto the user, because from user’s point of view this gives them the freedom to choose who the service is operated by without locking the user into one particular operator or host.
Reviewing these requirements shows how challenging it can be for an open cloud service to be fully open. So let’s define levels of as a simple way to indicate how open a cloud service is. At the very least an open cloud service needs to be open source, so we can set that as the minimum level. And open hosting isn’t possible without open source and open data, so we can set that the final level. Putting that together we get:
Let’s consider some existing websites and cloud services and see where they fit in:
Level 1: Wordpress (but not wordpress.com, which is a proprietary service).
Level 2: Wikipedia releases both its source code and its data under open licenses so it is a Level 2 cloud service. But not level 3 since it does not support open hosting (nor would that necessarily be a good thing).
Level 3: Mastodon micro-blogging; Matrix chat; git is as a stand-alone service (but not gitlab.com, which is a proprietary service despite depending on git and the open source gitlab software).
The Internet as we know it exists today because network providers have agreed to freely exchange the data packets between them and these peering arrangements form the backbone of the Internet. We can envision Open Cloud Services having something like these peering arrangements between them, forming a network from which an open cloud emerges.
The ability of cloud infrastructure and SaaS services to easily interconnect through APIs built on standard protocols is already one of the key reasons cloud technology has come to dominate but with open cloud services these abilities are turbocharged. Open Cloud Services can integrate much more deeply and with greater agility. Its open source code provides transparency; open data means their data can be shared and integrated; open hosting enables them to be remixed and relocated.
The guarantees provides by open cloud services already enable an implicit sharing of code and data but the adoption of standard peering arrangements or protocols between open cloud services that automated establishing connections and data sharing will accelerate the emergence of an open cloud. As these networks of services form, with the connections and operational data themselves open, these aggregations will function as open cloud services themselves, enabling higher-level (and likely more end-user focused) services to build on top of them.
For example, a service that aggregates and processes data might rely on variety of other services for database servers, data processing and machine learning. Another service want to leverage both the data and the data processing infrastructure for some other purpose. With proprietary services, the business that developed this infrastructure has to make the business decision that they want to make this available then invest in building a commercial offering. Anyone using that platform is now the dependent on the whims of that company. A network of Open Cloud services eliminate these frictions and business risks. Any participating service is free to discover, connect to, adapt and build on any other service.
This example also illustrates how the more services that are available and interconnected, the more data that is pooled together, the more the open cloud can achieve the same economics of scale and network effects (the more people use it, the more useful it becomes) that has driven the consolidation of Internet around a few big players.
As we can see, building an open cloud service that is fully free is quite an ambition undertaking. Why should we bother?
Many in the open source world are skeptical of or even openly hostile to the idea of rely on the cloud, for them it goes against the ethical core of open source. As Richard Stallman forthrightly puts it:
SaaSS is equivalent to running proprietary software with spyware and a universal back door. It gives the server operator unjust power over the user, and that power is something we must resist.
SaaSS always subjects you to the power of the server operator, and the only remedy is, Don’t use SaaSS! Don’t use someone else’s server to do your own computing on data provided by you.
As an individual choice this is well and good but as a long term strategy for open source I’d just ask you to consider: When was the last time you sewed your own clothes? Or only wore handmade clothes? The tremendous efficiencies of mass manufacturing and the amount of specialized skills needed to produce a presentable wardrobe makes this an absurd proposition.
If we don’t want user-facing open source software to go the way of sewing – an interesting hobby a few of us occasionally enjoy but basically no one personally relies on when we wake up in the morning – then we need to figure how to move it to the cloud in a way that is sustainable without compromising the freedoms it affords.
And of course: provide a way for open source development to make money.
Open Cloud Services expand the reach and accessibility of open source software and make it available to more people and in more areas of their life and work. It will empowers users with more control over their data and provide a platform where the technologies and practices of open collaboration can reach new domains and markets.
Finally, the introduction bears repeating:
If we build an open cloud then not only can we create an alternative to the big tech monopolies but we can provide a foundation for more sustainable, equitable, and meaningful economy. A bold claim for sure, but “the cloud” is everywhere: as the IoT (Internet of things), behind machines learning and AI, as XaaS (“Everything as a Service”). Broadly speaking, “the cloud” is about the virtualization and automation of services and know-how – and as it develops hand-in-hand with technologies such as robotics, 3D printing, and lights out manufacturing, the cloud will encroach more and more on the “real-world” economy. This is a future with tremendous risks but also tremendous rewards if we build a cloud that rewards openness, collaboration and individual autonomy.
How can we go from this sketch of an idea to a vibrant cloud of open services? Here are some of the things that need to be build for this to happen.
Having a consistent set of licenses and policies for open cloud services is important for interoperability, sharing, and trust. The latter is worth highlighting: the trust that comes from its rights and guarantees along with the transparency of open source code is a crucial advantage of the open cloud.
In order for open cloud services to reach their full potential we have to develop new technologies, standards and protocols. Here are some of the key ones:
Here at OneCommons we building the tools to make this a reality, starting with Unfurl. Unfurl is a tool for managing and deploying your online infrastructure. Its core technology are “ensembles”: git repositories that package open cloud services. They are designed to be the building blocks of an open and decentralized cloud infrastructure: reproducible, relocatable and shareable. They can be started, stopped, backed up, restored, migrated, cloned and forked.
When I first started thinking my initial assumption was that it was a fairly obvious idea and that I just needed to find the people and initiatives working to make this a reality.
After a fair bit of research and reflection it became clear that: One, there isn’t much out there; Two, nailing down a definition of “open cloud services” that is actually useful is surprisingly hard; Three, building one is even harder and lacks many of the incentives that drives most open source projects. This last point is probably why the ideas below have languished in relative obscurity.
The Open Knowledge Foundation defines an “open software service” as:
- Whose data is open as defined by the Open Definition with the exception that where the data is personal in nature the data need only be made available to the user (i.e. the owner of that account).
- Whose source code is:
- Free/Open Source Software
- Made available to the users of the service.
This is very similar to our definition except it doesn’t consider the hosting aspect. The Open Definition website doesn’t appear to link to this page anymore and it is unclear what the status of this is.
The Freedom Defined Wiki has a page for documenting ideas for defining “Free Services”:
“The core idea of the Free Service Definition (FSD) is to protect users’ freedom when they use services (eg gmail, flickr, todocue, mugshot) — to standardize Terms of Service/Privacy Policies so users know how a service will respect their freedom, privacy, and data.”
It doesn’t appear much progress after the initial creation of the page in 2007 and it’s interesting to note that nearly all of the examples of proprietary services cited above have been pretty much disappeared. A fully open cloud service never needs to be shutdown and both its code and content can be archived!
Google touts the open cloud as a reason to choose their cloud platform. This is how they define openness:
“Open is about the power to pick up and move your app. An open cloud is grounded in a belief that being tied to a particular cloud shouldn’t get in the way of achieving your goals.”
Obviously this is a much more limited vision than what we are contemplating here – it is equivalent to the second freedom for open hosting. Nonetheless, this “openness enables faster innovation, tighter security, and offers freedom from vendor lock-in. Google believes openness matters more in the cloud than ever.” And so do we!
Intrigued? Here’s some things you can do to make the Open Cloud a reality:
Give us Feedback Join the community designing this.
Build ensembles There are already thousands of open cloud services out there, especially at level 1. Let’s package them up and make them discoverable.
Join Us! Make this part of your vocation. We’re an early stage startup in San Francisco dedicated to making this a reality. Work with us on project basis (all open source of course!) or join our founding team.