I just watched the entirety of this PyCon keynote [1] by Russell Keith-Magee @freakboy3742. Python is 28 years old, and the context is — how does it stay relevant for the next 10 years? How does it plan to do things, to remain relevant? And what “black swan” events does Python need to be prepared for?

The essential topic is, Python has been around for 28 years; how does it make sure it stays around for 10 more years? Covers “black swan” events, open source community norms, WASM, volunteerism vs. funding experts, contributor burn out, and more.

Take Aways for Ethereum

A lot of this is familiar to be me because I have a long history with open source projects. But, that’s history: one big point is that we need to be thinking about — and planning for! — the future of collaborative projects. From my recent involvement with the Ethereum project [2], I’ve been thinking a lot about the topics covered.

I feel like Ethereum and its component parts (I’ve started calling this the “Ethereum Stack”, more on this in a bit) are just on the way towards becoming more traditional open source projects, from its relatively centralized roots.

Alexey’s article about Eth1x highlights this shift well: a shift in who works on research and implementation, and a shift in how the process is changing and needs to continue to evolve.

Now, instead of waiting for some developers in well-established implementation teams to get interested in a proposal, it is possible to form a working group and start working on it. Of course, it is still not trivial, because it requires finding people who want to do the work, people who want to pay for it, etc. But at least it hopefully gives us a nice separation of duties, and a more scalable process.

Alexey Akhunov

In other open source communities, a foundation or other entities comes after growth of the community. We’re in the midst of seeing the Ethereum Foundation actively divest itself of core responsibilities.

Oh, and if you don’t know Python, python2 and python3, which after 10 years still co-exist, are also useful to look at for thoughts on ETH2.

If I could, I would want to get up on stage at DevCon5 and essentially give the exact same talk, applied to Ethereum.

Here are specific areas of the talk, applied to Ethereum:

Becoming Open Source

Ethereum is still learning what it means to be an open source project; we need to spread a culture of getting involved, contributions that go beyond code, and iteratively making things better.

What does this mean? It means turning “this sucks” into actionable items, that get assigned / have ownership taken, and that get reviewed weekly and monthly.

Every day, we make things suck less. It may not sound like the best rallying cry, but trust me when I say that this appeals to engineering and “do-er” mindsets, and that compounding effort pays off. #WeighingWei

I am asking non-code contributors to learn basic open source code repository norms (issues & PRs), asking developers who may not have organic open source experience outside of Ethereum to welcome new contributors (#goodFirstIssue, bettering CONTRIBUTING documentation, resources dedicated to bringing on new code contributors), and all of us to learn how to collaborate better.

Open Source Licensing & Funding isn’t a Solved Problem

Open source licensing and funding is at a cross roads, so along with learning from other open source projects and norms, Ethereum has an opportunity to lead in experiments in these areas.

Open source licensing in Ethereum has not been a strategic consideration. There is a mess of different licensing, and many of the licenses used slow down adoption by commercial companies and enterprise. Part of the discussion around open source licensing in the broader world is as an opportunity to generate revenue, and to reinforce contributions to the commons.

Funding innovations are popping up left and right in Ethereum, but I would say that only Gitcoin and Gitcoin Grants are firmly rooted in an open source project tradition. Meaning: I think other efforts need to understand how to incorporate open source awareness into their thinking.

Embrace the Ethereum Stack

I’ve started to think about Ethereum as the “Ethereum Stack” — the EVM, JSON-RPC middleware, the devp2p networking layer, the Solidity smart contract language, the EIPs that set specifications, the client software that powers nodes — all of these are in many cases open source projects of their own, coordinating and collaborating together, and also getting remixed in different chains, sidechains, and private enterprise contexts.

This is a strength if we can make a tent that is bigger than main-net Ethereum. While still leaning into Ethereum public main-net as a global umbrella that the entire stack can benefit from and link into.

The Ethereum community’s “specification first” approach to building software and supporting multiple client implementations is potentially a core strength here.

We’ve been gathering EVM-related news (I’m realizing that EVM is another analog for Ethereum Stack) on the RUN EVM site. And yet, I was still surprised to see ThoughtWorks Radar highlight “EVM beyond Ethereum”; it’s in their “Trial” category, one before “Adopt” recommendation.

EVM beyond Ethereum in the "Trial" area of ThoughtWorks Radar Platform category

Ethereum’s Black Swans

What disruptions and major shifts in the broader technology industry might affect Ethereum? Even while thinking about distributed ledger technology and related decentralized web tech as a disruption itself, we need to look at how the Ethereum stack fits into other changes.


The community is already working on improving the EVM and making the transition to WASM [3], which is mentioned in the video.

Solidity, as a major programming language in the ecosystem, in part “competes” with Python. On the other hand, enabling the Python developer community to write Ethereum compatible smart contracts is a huge win for our community. This is why I want to see LLVM to EVM work today [4], which lets us start recruiting other language developers today, and sets us up for support in WASM as well (that is, it’s not duplication, it’s forward compatible work, as WASM relies on LLVM for other language compatibility as well).

Mobile as a Programming Environment

Personally, I have been jumping up and down over mobile support, not just for Ethereum powered applications, but also for writing / launching apps. I see the same “make Ethereum programming work from your phone” opportunity and threat highlighted by Russell.

Since Ethereum chains run continuously as a global “backend” — I see this as an opportunity! Front end apps written in JavaScript, CSS, and HTML can get written & deployed from mobile devices today — with Ethereum blockchains providing a shared backend. This is connected to the “hostless” theme that we are following at FISSION.

What should we work on?

The entire video has lessons, so I really encourage anyone interested in open source, software communities, and contributor culture to watch the whole thing.

Here are my top two picks on base level strengths that I think the Ethereum community can work on:

  1. Become experts at commons based peer production, from non-code collaboration, to funding, to open source licensing. Celebrate experiments and new entrants, while also Getting Shit Done.
  2. Work on building strong maintainers and communities around all components of the Ethereum Stack, and look for adoption of the stack everywhere.

FISSION’s mission is to bring decentralized web technologies to the wider development community by solving real problems today & exploring fundamental shifts in the way we host, deploy, and run software for humans. I look forward to completing this mission alongside the growth of the Ethereum community.

Sign up if you want to get involved as an alpha tester »

Further Reading

I haven’t read Elisabeth Ostrom’s 1990 book, “Governing the Commons: The Evolution of Institutions for Collective Action“. It was mentioned in the keynote, and has been brought up multiple times. I’m putting it on my reading list. Everybody has homework!

Here’s a link to a PDF hash on IPFS

On the recommendation of Trent McConaghy @trentmc0, I recently bought Pieter Hintjen’s Social Architecture. I know Brooke @expede is ahead of me in reading it, and I also sent a copy to Trent @trent_vanepps.

Aside from the Github link to Social Architecture, it is available on Amazon, and here are PDF and ePub IPFS hashes.

[1] This keynote was given at PyCon 2019, which is the Python communities largest annual gathering.

[2] I wrote a post about Ethereum Governance and covered my own entry and participation in the community.

[3] Our team leads the EVM Evolution Working Group. Because it likely has to be said, this does not mean we don’t like WASM! Forward compatibility is our goal, we’re not tied to the current spec of the EVM, but rather want to evolve it today, and help with the WASM transition. I joke (but am actually serious!) that our RUN EVM event and rallying cry stands for “Run Excellent Virtual Machines”.

[4] I recently found out that the ETC Labs team is working on an LLVM to EVM project — Ethereum Stack FTW!