Week of 2021-08-09
Open-endedness and bedrock
I’ve been inspired and captivated by Gordon Brander’s exploration of open-ended systems, and was reminded of a concept that we developed a while back when working on the Web Platform: the bedrock. My old colleague and friend Alex Russel and I wrote and talked a bit about it back then, and it still seems useful in considering open-endedness.
Generally, the way I want to frame bedrock is as an impenetrable barrier, the boundary at the developer surface of a platform. It acts as the attenuator of capabilities: some are exposed to the developers (the consumers of the platform) and others are hidden beneath. In this sense, bedrock is a tool, whether intentional or not. When intentional, it is usually the means of preserving some value that becomes lost if fully exposed to developers, like the Web security model. When unintentional, it’s just where we decided to settle. For example, if I wanted to build my own developer surface that sits on top of multiple other platforms (see any cross-platform UI toolkit or -- yes, the Web platform itself), the bedrock will likely be defined for me as the lowest common denominator of capabilities across these platforms -- rather than something I intentionally choose.
Through this lens, the open-endedness of a system can be viewed as a degree to which the bedrock is used as the attenuation tool. When attenuation is minimal, both developers of the platform and consumers are likely working above the bedrock. As I write it, I reminisce of the early days of Firefox. Being written mostly in Javascript and easy to hack, tools like Greasemonkey sprouted from that fertile ground, with their own vibrant ecosystems. Sadly, the loss of value in the form of security vulnerabilities showed up pretty early and with that, the push to move some capabilities under the bedrock.
When the attenuation is high, the bedrock becomes a more pronounced developer boundary: on one side are the developers of the platform, and on the other are its consumers. Platform developers rarely venture outside of the bedrock and platform consumers treat the stuff beneath the bedrock as a mythical “thing that happens.” Ecosystems around platforms with high bedrock attenuation can still be thriving and produce beautiful outcomes, but their generative potential is limited by the attenuation. For example, there are tons of dazzling Chrome themes out there, yet the bedrock attenuation is so high (API is “supply pictures and colors”) that it’s unlikely that something entirely different can emerge on top of it.
Platforms that want to offer a more generative environment will tend to want to move capabilities in the other direction across the bedrock line, exposing more of them to the consumers of the developer surface. One thing to look out for here is whether the platform developers are coming along with these capabilities: do they mingle with the surface consumers, building on top of the same bits? If so, that would be a strong indicator that the bedrock attenuation is diminishing.
🔗 https://glazkov.com/2021/08/13/open-endedness-and-bedrock/
Growth, control, and tricycles
Riffing on Alex Komoroske’s excellent set of cards on compounding loops, there’s something really interesting about the relationship between compounding loops and properties of a theory of change. A compounding loop makes an excellent motor: every cycle produces a bit more value. At the same time, a rudder tends to dampen a compounding loop: just like with any OODA loop, we will need to zig and zag, introducing variability into the compounding process. And as Accounting 101 teaches us, variability diminishes compounding returns.
If my theory of change relies on the same compounding loop to serve both as a motor and a rudder, I will start experiencing a weird tension that I call the growth/control tension.
This tension arises from the two opposing forces. There’s the force of growth that comes from my wish for the compounding loop to continue acting as the motor in my theory of change. There’s also the force of control, which is an embodiment of my wish to use it as the rudder. This might be a really terrible analogy, but it’s kind of like riding one of those front-wheel pedal tricycles: choose between going fast and steering as little as possible, or turning and breakingthe pedaling rhythm -- can’t do both. In a single-compounding loop theory of change, trying to control impacts growth and focusing on growth means losing some control.
Developer ecosystems are very commonly subject to this tension. To get more developers (growth), I want to listen to their needs and ship stuff that satisfies them. To move an ecosystem in a certain direction (control), I want to change what developers do, which means that some of them won’t like it. If I don’t recognize the control/growth tension, I might end up see-sawing from one extreme to the other, or worse yet, find myself paralyzed by indecision: do I take the developer sentiment hit, or do I stay in the past? I have done both, and these aren’t on my list of happy places.
If you’re lucky, you can diversify: there is another low-correlation compounding loop in the ecosystem that you can lean onto, to separate your motor and rudder from each other. Otherwise, you are stuck riding the tricycle, dynamically resolving the growth/control tension. It’s not so bad, but it does take a lot of practice.