ETHPrize - An Introduction

For a number of months, various Ethereum community members have been interviewing the best developers they know. There has been a lot of duplicated work in the ecosystem with teams using a mishmash of testing tools, development environments and deployment pipelines. What we heard was a lot of frustration around getting complex Dapps built.

We realised that what we were learning from the interviews was incredibly valuable and needed to be shared. So, our crew of Open Source warriors decided to dive deep — to create a clear picture of what the biggest frustrations are for people #buidling.

With this information, we created ETHPrize to identify the most important developer tooling and infrastructure needs of the ecosystem. But identification wasn’t enough…

We also want to use this information to incentivise the best developers to work on tools we all need, rather than the next big sale.

Robbie Bent and Sina Habibian from Truebit, myself from Status, Josh Stark and some friends from L4, the ECF, Web3 and the Ethereum Foundation have interviewed nearly 80 people. The people we have talked to are working on everything from core protocols, to the EVM, to various different languages, security, verification and best practices, decentralised exchanges, decentralised apps, games, kitties, and everything in between. We are aiming for at least 120 over the next few months, and there seems to be no upper bound to the growing developer community.

We sift through all the feedback we gather, identify the most relevant bounties to fund and help put together teams of people we know can fix the most common issues or create the required tools.

The first two bounties — worth $250,000 each— are currently live and being worked on by well-known teams:

ETHPM — a package manager for all your smart contracts. Led by Piper Merriam and the team from Truffle. The Embark people are also helping.
An Open Source Block Explorer. Led by the team at POA, organised by Griff Green and friends.

Oh yeah, the site where both of those bounties are detailed and where the full report will live was also built with bounties. It’s just bounties all the way down, folks.

Part of the goal or intention behind choosing to use decentralised technologies is that they offer us new and innovative ways to organise without requiring intermediaries to handle the trust overhead. ETHPrize is just another in a growing community of experiments trying to figure out the best, easiest, and most sustainable ways of funding open source development and documentation.

Put differently, we are figuring out by iteration how best to curate and organise digital knowledge and resources in general, which is why people get so excited about the possible futures we can build with decentralised tools.

Next Steps?

We have split up all the interviews from a Master Doc to rule all master docs and will be sending them out to each developer before putting them into markdown files in a public GitHub repo.

We will then put up bounties for everything from the design of the report; to building the site itself; to analysing the data and building some cool NLP-backed goodies like word clouds and other visuals for the report to make it easy to see at a glance the most important information.

What’s great is that the people we have already interviewed can then just send in a pull request whenever they want to update the information about their biggest pain points using Ethereum, and what they think ought to be worked on by the wider community. This will allow the community to identify bounties and tools on an ongoing basis that will help us all ship awesome, production-ready things that can change the world and stuff.

Rob, Sina, Mitch Kosowski, Parker Place and whoever else wants to help can then focus on sitting down with all the other emerging talent in the space (and with all of the rest of the awesome people we are yet to get to) in order to expand the data set and get an even clearer picture of where the most common frustrations are and what can be done to fix them effectively and for everyone.

Key Learnings

We are still working through these with the whole team in order to identify the next round of great bounties we think people can realistically work on and deliver, but I can discuss some of my personal take aways here.

Documentation sucks. It is fragmented. It is out of date. It is not well versioned, not well maintained, not easy to find. A lot of the best tools are not widely known and do not have the mind share amongst new developers that they perhaps should.
We need #docunomads real bad, people! Forget crypto, just go from team to team and help them write well about what the hell they’re up to.
We should also have an annual #NaNoWriMo week for Ethereum, which I think Lane Rettig has already proposed.
We need a better debugger for Solidity. Something where you can set break points in Solidity easily (or at least log things more effectively), step through opcodes more easily, visualise the stack clearly, and change variables between tests without having to redo everything. Smarter compiling of contracts and the ability to test only a subset of things easily without long waits would also be great.
Getting reliable data from the chain without relying on centralised and proprietary APIs is wayyyyy harder than it should be and we need to sort that out ASAP before Layer 1 scaling solutions like sharding are implemented, because it then becomes an even more multi-dimensional problem than it currently is. Lots of people are working on this, thankfully.
Better error codes for pretty much everything. Developers are very sad about the errors they get back and how hard they make it to debug code.
We need better open tools to deploy easily our own nodes, networks and infrastructure. Some kind of image(s) that runs our client of preference with all the best practices and everything else we need to get set up easily.
On that note, work is required on testing tools (fuzzing comes up a lot) and the JS EVM in particular so that conditions between it and the live networks are more similar.
An A-IDE (actually-integrated) that can be run locally, with all the bells and whistles we need to develop and test contracts easily. AI-DEs are also welcome…
We’ve got to stop depending on tools like MetaMask and Etherscan (as good as they are) if we want to build a resilient and decentralised ecosystem. More signing tools and tutorials around how to implement them are needed so that devs don’t just default to using injected web3, which is likely to be deprecated soonish anyway.
Everything is just a signature anyway ;)
Seriously though, we need technical writers to help with documentation. I cannot stress this enough — it has been mentioned in basically every interview we have done so far.

One of the best ways to learn more about cryptocurrencies and “the blockchain” is by writing some of the documentation for a project or person you really like or admire. And there is a desperate need for it, so get involved!

A great way for teams around the world to think about how best to address this feedback is to make documentation 1) more central to the design of your product or service and 2) more fun to produce.

Solidity readthedocs and the Truffle docs are often quoted as good examples.

Swarm.city excel at the fun part, writing their user stories as TV episodes before turning them into formal specs. Get creative; you’ll attract the sorts of writers inspired to learn what is necessary to write authoritatively about your project.

I’m particularly excited to see what the Kauri Team can do on this front.

ETHPrize is a grass roots, community-led initiative. Hop in and help us out if meeting all the coolest kids in Ethereum and diving deep into what they actually do and HOW they do it everyday is something that would interest you.

The community has always been Ethereum’s single greatest advantage, and it is seeing initiatives like this, which just kinda self-organise, that I find to be truly inspirational.

It really brings it home to me that:

open source communities of knowledge, practice and reputation
incentivised by abundant, but unique, digital tokens
constantly iterating to find better practices

are the future of work that we are all headed towards.

I think that taking part actively, and helping to rig some of the ropes as we figure out what tries to tie them to so that we can all swing safely in the merkle forests, is a defining feature of the sort of mindset that will define ‘success’ in and for these nascent networks.

If this has you all inspired, please share it with a developer you know/love/grudgingly care for and think should be working on better tooling.