sgo.to

Ceilings and Foundations

Sam Goto

Over the last four years I've participated in a recurring discussion related to the development of third party platforms and ecosystems at Google.

To me, the analogy from Tim Bernes-Lee is the one that captures the tension between forces most precisely.

There is a very important difference in attitude between a foundation technology and — well — let's call it a ceiling technology. A foundation technology is designed to enable innovation, to be the base which will support other even more powerful things to come. A ceiling technology is not. [...] Ceiling technologies are the end of the road for innovation. [...] When you want to make a foundation technology, you need to look ahead. You need to put aside the short term return on investment questions and look at the long term.

In software, strong structural foundations are poured such that new use cases can be built on top of them without any further recompilation: new unanticipated use cases pop up without coordination with or permission of the foundation.

Ceilings, on the other hand, form an opinion of what should and should not exist from a use case perspective. Because they are not extensible, they anticipate and prescribe a limit of what's allowed, having to be recompiled/reconstructed everytime a new vertical needs to be enabled. They pull the accountability of the user experience to themselves, often developing an editorial judgement at the application domain level.

The best examples of foundations we have today are the Web, the Internet and POSIX. For example, URL/HTTP/HTML is use case agnostic, i.e. they don't form any domain-specific opinion, and enabled a myriad of applications to be built from almost any domain of human discourse. For example, they enabled gmail.com, facebook.com, amazon.com to be created without any coordination / recompilation of browsers and protocols. The same is true for TCP/IP and system calls.

Platforms distill what are the most basic principles (e.g. security, privacy, isolation, affordances) and low level primitives (e.g. data types, programming environments, interfaces, etc) that it absolutely needs to expose and delegate everything else to userland.

The challenges of being opinionated

The biggest challenge of being opinionated is that it sets an invisible asymptote: a ceiling that your growth curve bumps its head against everytime it needs to add a new use case. You can form another opinion and raise your ceiling (which, by the way, requires a recompilation of your binary), but you just postponed the problem to a later day. Most importantly, by being on the critical path discovering new use cases for your platform, you have become the choke point of innovation: your platform can only innovate as fast as your organizational boundaries allow.

As an example, a ceiling in parenting/managing are attitudes like "my kids will be doctors" or "my kids will go to school X" or "my kids will marry and give me grandchildren".

An example of a ceiling in software are attitudes like "my conversational assistant will make online restaurant reservations" or "my API will be a declarative app caching API".

In managing, parenting and architecting platforms, the worst that can happen when you demand something is that they obey you rather than surprise you, exceeding your original expectations with something you never anticipated.

Attitudes towards foundations

In many ways, building foundations sometimes requires an attitude/mindset change. Much like parenting and managing, it requires hard work finding the right horizontal priciples/culture to aspire to (e.g. "my kids should be happy"), the isolation mechanisms (e.g. "each kid will have their own bed with their own stickers"), the security baseline (e.g. "no guns in the house") and the communication protocols (e.g. "you can call me if you run into trouble").

In software, here are some useful tactics:

Principles

Operating Systems launch, switch and notify. Start here and derive your security, privacy, sandboxing and communication rules of engagement.

Extensibility

Think hard about how low level you can get (without compromising security) and delegate everything else (e.g. ergonomics) to userland. Know really well the layering of your system and enable as much modularity as possible.

Accountability

Make sure that your platform has a clear accountability line back to the app developer. The answer to "whose customer is this?" should always be the app developer. For example, nobody blames HTTP/HTML/URL or calls Tim Berners-Lee when amazon.com doesn't deliver your packages.

Composition

Be careful while introducing ranking or triggering apps into your product because that can set a ceiling. Both recommendations (i.e. offer as a suggestion - "harvard is pretty cool" - rather than a prescription - "everybody in our family goes to harvard") as well as user-based composition (e.g. a feed reader) can mitigate that.

Isomorphic Dichotomies

I believe these discussions are related (if not the same) to the one I'm having here: