With development of blockchain applications now booming there are many interesting things happening and a lot of reasons to be excited for 2018. Unfortunately, there are a lot of reasons to be pessimistic too. Many are approaching application development in the same ways they always have, which in an open global system runs at odds with the design and ethos of the very ground they're walking on.
Creating an open-source platform designed to work as part of a globally integrated system is a very different process than building a product or enterprise platform to be monetized through licensing and sales. In this article, I'll attempt to explain why this is the case and give some tangible rules to guide you on your journey to creating the next killer blockchain app. I'll focus on Ethereum, but the same ideas apply to any public global system.
Even more so than in traditional open source environments, the Ethereum ecosystem functions best as a web of integrated applications. Since it is a global singleton and all applications have direct access to all other applications' data, drawing in information from related platforms is easier than it has ever been before. Mashups and reinterpretations of existing systems will be commonplace, and developers should expect that data from systems they build will be surfaced and utilised in other ways. There is a strong benefit to experimentation, and this should be viewed as healthy not only for Ethereum applications but for the world as a whole.
Platforms should easily interoperate
A key directive is to aim to maximise the potential for interoperability between any platform and the rest of the ecosystem. Open-source contracts and easily digestible documentation ensure that anyone creating value-adding platforms of their own is more readily able to tie them into yours, thus increasing the utility value of your own systems at no extra cost.
Another way of achieving this is by way of protocol development. Standardising the smart contract layer on which your platform runs, and thus encouraging others to build systems which fit the same standard, results in a plethora of complementary platforms being built to mirror your own. Though this directly subverts market dominance, the tradeoff is a richer network of complementary systems which are able to participate with your own. A great example of this is the ERC20 token standard, which has spawned a vast array of token implementations, as well as supporting services such as exchanges and market makers which add value to every token deployed. More implementations against a protocol = more incentive for others to build supporting infrastructure = more value added to existing implementations. It's a virtuous cycle of collaborative wealth generation.
In the end, network effects are what give any system lasting value. Platforms which are easily integrated and remixed elsewhere will be the ones which win out. A smart contract layer which only works in the context of a single platform is likely to lose momentum in the face of those which embrace other systems readily.
Platforms should offer specific targeted functionality
A natural impulse when building an application may be to iterate and add new features as it matures. However, when doing this one should carefully consider the core purpose of the platform and whether the new features are relevant to its existing functionality. Rather than attempting to own a suite of features under a single platform umbrella, it is often advisable to build separate targeted applications. This is especially true when new features target a usergroup not already serviced by the app— a dead giveaway that you are dealing with two separate (integrated) platforms with distinct purposes.
Again, this comes down to the difference between a platform and an ecosystem. Building an unrelated feature into a platform application results in that feature only being useful in the context of your own platform. If it were spun out as a separate app its functionality would be able to be leveraged by other systems similar to your own— thus creating much greater value, utility and impact. Indeed, this is the way Ethereum was expected to function from the start. Early versions of the Mist browser featured a sidebar where users were intended to bookmark multiple dapps to perform separate, discrete but interconnected functions.
Attempting to deliver too many features can also undermine the quality of an application. To state the unix design philosophy, "do one thing and do it well". When an application tries to offer too many features it can often become cumbersome and brittle over time. Simple, clean UX devolves into a cluttered mess of features. Apps should be pleasant and simple to use, not monolithic and complex.
Platforms should create value, not own it
For a platform to last, it should be built in a way that feels 'fair' to its users. Given the open nature of the blockchain and presence of disassemblers etc in the space, it is all too easy for others to fork a codebase and deploy a different version of your application with an altered economic model. Ensuring a good rapport with your users and including governance functionality to empower them in the way the platform is run is paramount. Loyal communities who build on top of open source are worth their weight in gold— just look at the market valuations of some prevalent free software companies such as Automattic ($1.16B), MongoDB ($1.6B) and Docker ($1B).
Ideally, platforms should take no fees and be free to use. However, computation still costs gas to run. User-pays, donationware (like Wikipedia) and payments which align with network participants' incentives in multi-sided marketplaces are all models worth considering. In many cases, the wealth generated from a platform may not come from operation of the platform itself, but rather from a "first mover" advantage in being one of the first service providers to utilise it.
In summary
- Start a process, don't attempt to create a final solution
- Build ecosystems, not apps
- Prioritise protocols, build platforms on top
- Let users own the value, don't try to lease it to them
- Communicate openly and transparently with your userbase
That's enough open-source evangelism for one day. Go build some cool stuff!