For most of 2017, the cryptocurrency markets seemed to be obsessed by the discounted future utility value of tokens (in other words, their speculative value). But it’s time to go #BTTF2018 — back to (building) the future! The long-term success of token economies and the protocols they are built around is led by fundamentals, and ultimately adoption. How useful is the protocol, to how many end users? This question is fundamental to our vision of the Convergence Economy.
There are several factors that we consider critical for protocol success, including world-class cryptoeconomics, governance, and community management. But leaving those aside, who is going to build it all? One of the scarcest resources in the decentralisation space: developers, developers, developers.
Steve Ballmer, the former Microsoft CEO, knew very well that to make Windows successful, he needed developers to build on Windows
Building blocks
A tokenised protocol is, in its essence, a building block that can serve to create useful things. It needs others to build on top in order to become really useful. Core protocol developers build the building block itself, and other developers can use that building block to build apps that are useful to end users. If you’re building a tokenised protocol, your immediate users are developers building on that protocol.
This applies to low-level, general-purpose protocols like Ethereum or IOTA, but also to higher level protocols like Augur, district0x or OmiseGO. In many cases the core team builds both the protocol and one or more initial applications, but considering these are open systems, anyone can build on them. And for them to be widely successful and sustainable, many people should.
There is something quite similar and something radically different between tokenised protocols and, say, Microsoft Windows (a proprietary operating system for computers, you know, those bulky machines that came before smartphones) or Oracle’s MySQL (an open source database management system).
Windows and MySQL both are building blocks as well. The owner of the building block thrives when people use it, assuming there is a valid business model in place. The business model around Windows has long been selling lots of licenses to use it. People want to pay for Windows — directly or indirectly when they buy new equipment — if the most and best applications are available on Windows. In the cloud age, Microsoft has successfully taken those developers to Azure, establishing itself as the global number two public cloud provider and steadily catching up with Amazon’s lead.
The business model around MySQL is different. The software is open source and free to use, but there are more advanced versions with features like database encryption and high availability for which enterprises gladly pay, as well as paid consultancy services. If some percentage of use cases require these services, then Oracle makes money when more and more people build their applications and businesses using MySQL. Once again: developers, developers, developers.
So what about tokenised protocols? A tokenised protocol with more, better, useful applications ultimately makes it more attractive for more consumers to use it. And more people using it makes the protocol more valuable. But who’s the beneficial owner and where’s the business model? That’s where tokenised protocols are radically different. The value of a tokenised protocol is captured in the native tokens rather than the valuation of an organisation. It’s not a share of an “Ethereum Ltd” that is valuable; it’s the Ether token. Generally there is some form of revenue model to participants in the protocol, for example Ethereum miners receiving block rewards and transaction fees, but not to a single organisation.
If attracting great developers into their orbit is so critical for a tokenised protocol to thrive, that seems a pretty important thing for protocol builders to focus on. So let’s look at some things they can do to help achieve that.
How can tokenised protocols attract great developers?
Let’s consider three rockstar developers: Jane, Calvin and Boris. Jane is an independent full stack developer. She likes to build apps using TypeScript, with an Angular frontend and Node JS on the backend. Calvin is a data scientist at BigCorp LLC, a large insurance enterprise. His preferred language is Python, and he uses many data science libraries from the Python ecosystem. Boris is an experienced distributed systems engineer and blockchain developer. He’s built enterprise-grade infrastructure for financial applications, committed code to the Bitcoin codebase and is eager to work on high-quality projects for a more decentralised web. C++ is his language of choice.
Jane, Calvin, Boris and other developers like them have a wealth of projects to choose from to dedicate their time to. Why would they come to a new tokenised protocol?
Great technical foundation
There is no way around it — the most important factor for long-term success is a solid technical foundation. You might be able to wing it for a short while (though Satoshi Nakamoto is generally regarded as a good coder, early versions of the Bitcoin codebase had somewhat hacky aspects to them). But if your tech is bad, you’re very unlikely to attract the highly talented developers you need to make your project shine. Calvin gets frustrated if he runs into weird issues all the time, and Boris will stay far away from mediocre engineering practices.
It is for this reason we invested in projects like Ocean Protocol, whose founders BigchainDB have been demonstrably producing high-quality code for a long period, and Sovrin, whose code is governed in the Hyperledger Indy project as part of the Linux Foundation.
Great APIs that don’t break all the time
For most aspiring application builders, the API is the first thing they see, and for many the _only_ thing they ever see. So better make sure that your APIs and libraries are clean, understandable and well-documented — and uniform on multiple platforms so that Jane, Calvin and Boris understand each other even though they’re using different programming languages.
A specific point of attention here is the balance between rapid development of the core technology and offering a stable interface to developers. If Jane has to change her code after every new weekly release because there has been a breaking change to the API, she’s less likely to hang around and build great apps. While there is a need for protocols to develop rapidly, and breaking changes through progressing insight can’t be entirely avoided, don’t underestimate the value of a stable interface and attention for backward compatibility. Microsoft again is a great example here while Google is notorious for launching shiny new API products only to discontinue or radically change them shortly after without much notice — leaving developers building on them in the cold.
Great tools
Great developers need great tools to build great things. From syntax highlighting to inline debugging to formal verifiers to realtime unit test execution, decades of computer science have delivered us a wealth of tools to make software development more productive and enjoyable. Are you building something radically new in your protocol, for example, a new programming language for smart contracts? Then existing tools likely won’t support those very well out of the box, and your team will have to create new tools or customise existing toolchains to work well with your new platform.
As an example, for the Ethereum project, there is now a reasonably well-working IDE to develop and analyse smart contract code (albeit not integrated with existing tools that developers know and love), syntax highlighting for the Solidity smart contract language in most major IDEs and multiple mature development frameworks. But this was not achieved until Ethereum was several old. Better tool support earlier in the project can help attracting developers faster.
So which toolchain should protocol builders focus on? It depends. Many developers are wedded to their tools. They’ve internalised the keyboard shortcuts, and the user interface is deeply ingrained in their workflow. Jane loves Visual Studio Code with its rich ecosystem of extensions. Calvin prefers Eclipse. Boris swears by old-school Emacs. As a team building a protocol, your resources are limited, and you can’t deliver a pristine development experience on every developer’s favourite tool right from the start. Choose wisely which developer community you want to target first, and make sure their favourite tools work smoothly with your building blocks.
Great code examples
As the old saying goes, a great working code example says more than a thousand lines of documentation. Oh, and do make sure that Calvin can run it with just a handful of shell commands. He’ll be up and running in no time.
Great education
With an abundance of Massive Open Online Courses (MOOCs) available, in many cases affordable or even for free, it’s never been easier to learn something new. In blockchain land, however, good educational materials are still thinly spread. A good effort to improve this is RSK Educate from the Rootstock project, who are building free blockchain course materials for everyone to learn and teach.
But how about better than free? Developers could earn tokens for completing a developer course to get them up and running rather than paying for it. If protocols thrive when more developers adopt them, it makes sense that developers would not have to pay for the privilege, rather the other way around.
Great onboarding
Related to education, there’s onboarding. For protocols that introduce a new programming language or paradigm, every developer will have to go through at least some learning curve to get going. Besides new computing concepts, there are new languages like Solidity and Serpent (Ethereum), Rholang(RChain) and Michelson (Tezos). To allow smooth onboarding of new developers, protocol builders do well to provide specific onboarding tracks for developer profiles like Jane, Calvin and Boris.
Another approach is to bring the platform to the skills of the developers rather than the other way around. This is the path followed by the likes of NEO, where developers can build smart contracts in existing programming languages like C#, Python and Java. In EOS, smart contracts are based on Web Assembly, which is a new paradigm but supports existing languages like C++ and has broader support than EOS alone. Qtum started out with the Ethereum VM, but is now developing to support the Intel x86 VM which will enable most existing programming languages to be used for smart contracts on the Qtum blockchain.
Grants, funds and bounties
Ultimately any developer needs a roof over her head and some food on the table. And while some of the people in the crypto ecosystem have become financially independent through the gigantic price appreciation in cryptocurrencies, most of us need a steady income to pay the bills. Therefore crypto projects do well to have a grant program in place.
Examples include the Blockstack Fund, IOTA Ecosystem Fund and the shockingly large, yet to be officially announced $1B EOS fund. Especially interesting from a funding perspective is the recently announced Ethereum Community Fund. Here’s a tokenised protocol (Ethereum) which spawned projects building tokens on top of it (OmiseGo, Cosmos, Golem, Maker, and Raiden) who have now jointly created a fund to further the development of the base protocol (Ethereum). This has Community Token Economy written all over it.
To get specific tasks done within a tokenised project, a bounty program is indispensable. Bounties are generally awarded for smaller tasks, and are therefore very suitable to attract new developers. A bounty to solve a specific hard distributed computing problem might attract Boris’s attention. And when he’s done fixing it and has received some tokens as the bounty, maybe he’s enthused and goes on to build something awesome on top of the protocol.
Great events and hackathons
A lot of development in the decentralisation space happens online, with teams coordinating their development using tools like GitHub, Slack and Trello. Great! But nothing beats working together in-person on a focused effort, at least every so often. Hackathons are a great working form to get people together and build things in a highly energetic manner. In a well-executed hackathon, the open character of tokenised protocols really shines.
Why do I say “well-executed”? Because while the hackathon concept seems simple, there’s a lot of variance in quality. Simply adding developers + laptops + sponsored pizza and beer together might guarantee a fun weekend, but doesn’t necessarily lead to great immediate results, structural working relationships or foundations for long-term projects building on the protocol. The real work to get great results out of a hackathon is done before and after the event itself.
Before the hackathon, there’s a need for protocol core teams to get their product “hackathon ready”. This includes all of the earlier points. New developers should be able to get started quickly, have documentation to fall back to, and not run into blocking issues every few moments. Hackathons are an amazing opportunity to get lots done in a very short timespan, but far too often participants spend half of the time getting the basics running and the other half fixing issues.
Then after the hackathon, the challenge is not to let it end there. Let’s imagine that Jane, Calvin and Boris team up in a hackathon and build an amazing prototype for an app. Maybe they’ll even win a prize. But what happens next? If they want to take their project to the next level, they need long-term funding, and support from the core team. They need corporate or government partners as launching customers; Blockchaingers is a great example of a blockchain hackathon where such parties are deeply involved in the hackathon and beyond. Or maybe Boris would like to contribute further work to the core protocol or even join the core team permanently. To maximise his contribution, he needs to have a clear path to contribute code and active communication from the core team. Developer Relations is perhaps the most undervalued function in a tokenised protocol founding team.
Conclusion
Tokenised protocols need great developers to be successful. In this post, we’ve explored a number of things that founding teams can do to attract developers to their project. The vast majority of software engineering talent is not working on decentralised protocols yet. Let’s do what’s needed to get them on board and get back to (building) the future!
As part of this, we are establishing a Convergence developer community and event programme, bringing protocol teams and developers together in technology-focused event formats.
If you have a proven track record in organising developer-focused events, or are interested in taking part in them, reach out to us at developers@outlierventures.io.
Thanks to Matt Law, Lawrence Lundy, Eden Dhaliwal, Greg Murphy, Jamie Burke and the rest of the team at Outlier Ventures for your valuable input.
Photo credits: Hack Capital and Alex Kotliarskyi on Unsplash
