The developer-driven economic stack

Sometime around 2008 or 2009, I was dabbling in Ruby on Rails development in my spare time as a distraction from my front end contracting work. Someone suggested I take a look at Heroku, a new(ish) tool for hosting and deploying Rack-based apps (like Rails).

I was sucked in. Heroku made it really easy to deploy toy apps into a production environment, and it was free. For a front-end dev with extremely limited system administration chops, this was indistinguishable from magic. In the following months I shipped a procession of terrible side projects.

None of those projects were good; nor was I motivated to try to get people to use them. But the point was that Heroku had dismantled some large barriers to entry for people like me who get nervous about hardware, servers, configuration, databases and so on. The Platform-as-a-service (PaaS) market was born*.

The stratospheric rise of the PaaS market reflects a wider phenomenon: recognising and fostering the decision-making power of hands-on developers.

The developer-driven economy is nothing new of course. Venture capitalists love to chat about the importance of understanding the developer market and using developers as an entry point to very big markets.

What’s newer is that developer tools with a front-end focus are now getting in on the act too. If you think frameworks like React and Angular are just mature open source projects, you need to take a look at how they’re marketed, and how much money Facebook and Google are willing to spend on these projects. They’re not just after mindshare. There’s a long-term strategy behind sponsoring open source projects internally in this way. Tobie Langel writes frequently about the strategic benefits of this on his mailing list.

And then there are modern serverless PaaS platforms like Zeit’s Now, aimed squarely at full-stack and front-end developers, and built with their own open source software. You can expect Zeit and similar companies to become increasingly influential in the next few years.

While using a suite of AWS, Google Cloud or Microsoft Azure services is becoming the new default for enterprise applications, there is a place for highly-targeted tools at the next level up the stack for smaller organisations. While you lose some flexibility, there are big gains to be made in paying slightly more for a set of well-developed abstractions that allow smaller teams to move more quickly and with fewer specialists.

The same could be said for the big front-end frameworks. They are very deliberately developer-friendly abstractions, sometimes at the cost of raw performance or deep control. Their popularity demonstrates that teams are willing to make these kinds of economic trade-off.

For me, the web platform itself needs to take the developer-driven economy into account. Using some web platform APIs directly often feels similar to using AWS services directly. That’s why there are popularly libraries for abstracting common use cases, e.g. offline caching using service workers (Workbox), or managing DOM updates efficiently (ReactDOM, Svelte, Elm, etc, etc).

Sometimes cowpaths are paved of course. ES6 was partly a cowpath-paving exercise. But so are the Fetch API, portals and various DOM methods (because of jQuery). The demand for these was created by developers.

These paved cowpaths also end up creating further opportunities for developers to build on top of the platform, of course. WebAssembly will no doubt feed much of this innovation over the next few years. It’s going to be fun to watch.

All of this rambling is to say: keep in mind the layers of the stack at which you are operating as a team, and how your chosen tools fit into this picture. Choosing a framework, a PaaS service or even a smaller library is both an economic and socio-technical decision that impacts the value chain in your organisation. No pressure then!

All the best,

– Jim

P.S. To be fair, Heroku was not the first PaaS. That’s credited to Fotango’s Zimki. I recommend reading Simon Wardley’s account of it’s creation, part of his online book on Wardley Mapping. Wardley mapping can really help to understand how value is realised through a value-chain, and how you might make strategic changes to it (similar to the ‘stack’ I’ve been waffling about above).