Skip to content

Instantly share code, notes, and snippets.

@julien51
Last active May 31, 2019 10:23
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save julien51/c7dbc86cda96828b210d7e914bceefe5 to your computer and use it in GitHub Desktop.
Save julien51/c7dbc86cda96828b210d7e914bceefe5 to your computer and use it in GitHub Desktop.
layout title date
post
Open Source, what is next?
2019-05-20 05:07:51 -0700

Or, an attempt at convincing my friends who care about open source software that blockchain and smart contracts are the future of our work.

10 years ago, I was starting my previous company, Superfeedr. For those but familiar with it, it's a service which provides a push API for RSS and Atom feeds. The basic premise was that many applications were all polling the same feeds over and over again, making something inefficient (polling) exponentially worse, and that a single service could do that and then ping everyone else.

From that day and until today, a lot of people asked why we did not release the code we wrote as open source. My answer has always been the same: it would be wasteful and defeat the purpose. That code was meant to be run once only. Of course I knew that releasing that code in an open way would also enable people to contribute, identify bugs, make tests, write docs... It would also bring transparency which would maybe enable more organizations to "trust" that Superfeedr was doing the right thing...

Superfeedr is arguably not an exception. Given that search engines tend to get better (maybe even exponentially better) with the number of users, as they are able to leverage more signals to filter and rank documents, one could consider that we, users, are actually better off with a single search engine... similarly, the social graph is hard enough to maintain that having a single massive one may actually make sense. These facts also explain why both Google and Facebook have grown into the monopolies that they are today.

The web or email are actually not different either. Back in the early internet days, AOL had its own versions of both: inside of them, people could only visit AOL hosted "sites" or only message other AOL members. That limitation made both of them irrelevant quickly: there could be only a single web, and we're better off like this.

What does this have to do with Open Source Software? Everything. Google, Facebook, Superfeedr and most web sites or applications were built using Open Source Software, and many of them are actually still relying on Open Source Software to "execute" that code both on the server and the client (for example, all web browsers have their core inside open source projects).

In a "disconnected" world, open source code makes sense, but in a connected world, the idea that we are all running the same code over and over again, maybe even on the same set of inputs seems incredibly wasteful. At the same time, if we're to decide that we should have a single search engine, a single social network, who is going to operate them? who is going to be in charge? or even, ... can there be anyone in charge?

The most recent debates about breaking up Facebook are obviously spot on: the social network has an oversized impact on our individual and collective lives, and its founder and CEO de-facto control of it means that a critical shared infrastructure is effectively controlled by him. Google, Amazon, Apple are not that different. They are contesting nation states with incentives which are not necessarily aligned with the majority's interests.

This does not have to be this way. We could run globally shared infrastructures in a way which does not require gatekeepers, or single points of failure. For example, IPFS is fully permissionless and acts as a shared infrastructure for file storage. Its hashing mechanism means that the same file can be accessed by anyone who needs it, without requiring them to make a copy of it.

Smart contracts are another way to achieve the ambitious goal of not only writing code in the open but also executing it that way. If Superfeedr could have been a smart contract, then it would be shared infrastructure where everyone uses the running code, pays for the resources this code consumes and maybe even participates in the governance which determines improvments, upgrades and changes performed to the code.

At their core, smart contracts are just "programs" running on a shared computer (called a virtual machine or VM). As this is shared, the constraints imposed to what the programs can do are very strict. It would not be acceptable to have the whole computer "wait" for one program. The consequence is that, at least for now, the type of programs which can be run on these shared computers is fairly limited to what we can describe as "protocols".

The most well known example is ledgers which keep track of users' ownership of currencies (see Bitcoin), but there exists other ones: financial tools which guarantee the price stability of some assets, very simple games, or even access control lists (hello Unlock!), but I deeply believe that these smart contracts could be used to run many many programes beyond the ones we used today, and improvments in performance of these VMs allow us to imagine a point where they can actually be used to run growingly complex applications.

I believe that these smart contracts could be the "future" of open source software, where not only the source code is shared in a decentralized way, but the actual execution environment is also shared in the same way.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment