Developer Platform

tl;dr: “What’s the difference between a platform and an ecosystem?” This simple question resulted in an ecosystem strategy to connect sub-ecosystems that work on the Web. What if we lean in and deeply connect our tools, services, frameworks, and platforms….. and align on the right incentives for a healthy web?

I work in a product area of Google that is called Platforms and Ecosystems, and I sometimes reflect on the question “what’s the difference between a platform and an ecosystem?”

There are many, but I have found myself diving into the differences in complexity of a rich ecosystem.

With platforms we often think in layers, each layer building on each other, and the interfaces mostly being at the boundaries. This is a nice abstraction when done right, as it isn’t leaking all over the place.

An ecosystem often forms on top of a platform, or if it gets connected enough, you get combinations. Sub-ecosystems form that have their own fractal view of the world, and they may connect with multiple technical platforms (e.g. the React ecosystem touching Web, iOS, Android, Desktop, ….).

The Web is complex enough that it is one of the canonical examples of an ecosystem that has many sub-ecosystems. You can even slice “the web” itself into pieces including the technical client platform that is embedded in almost every native platform there is (WebView anyone?) as well as the connected open Web, where many technical stacks are available to run as well.

A week ago, I had the pleasure of spending some time with representatives from major global CMSes, and they are a fantastic example of sub-ecosystems.

We spoke of ecosystem loops, and how an ecosystem has so many more connection points that are not restricted to layers, and are multi-directional.

These connection points, when strong, can enable a healthy web ecosystem. This realization has changed the way that we work, thinking about we can truly enable healthy connections.

Foundationally, we obviously want to build web platform APIs that work for as many ecosystems as possible, whilst also push the web. We also work to build clear guidance on web.dev that helps developers understand what is possible on the web across key pillars and principles. We want to deliver new and better tools that help you create, debug, and deliver actionable insights to you (e.g. DevTools, Lighthouse, CrUX).

Speak the right language

Lighthouse Stack Packs can speak your language

One of the problems we see, is that there is often an impedance mismatch between the layer of abstraction that a developer uses (e.g. using a particular framework, set of libraries, or backend infra) and the feedback that tools and services surface.

We are on a journey across our portfolio to fix this, and the best example is probably Lighthouse:

Lighthouse plugins allow you to build on the platform to offer your own audits and rulesets, enabling you to enforce you own criteria or requirements. For example, a framework may have important linting tests, or an ecommerce platform may have retail oriented audits.
Lighthouse Stackpacks bring an understanding of the ecosystem into the existing core rules. Don’t give generic guidance on next generation images when you could give custom guidance for particular plugins or point the developer to a setting in the admin console.

Elsewhere we are thinking of similar evolutions:

web.dev offers framework specific guidance, but what if the base guidance changed based on your needs?
There are many Chrome extensions for developers which extend DevTools, but what if there was a strong plugin API where knowledge can be brought to the core tools?

I am excited to work with the ecosystem to enable this kind of intelligence for our collective developers.

Show me the incentives!

We can make life much better for developers, but we have also learned that this isn’t enough to fully elevate the web together.

We want to see the flywheel moving nicely on the above ecosystem loops, with users engaging with high quality content from developers and their sites and platforms.

As platforms, how do we enable this outcome? It’s hard, but we have learned a lot from the work that the ecosystem did to move to HTTPS.

Moar TLS!

It may be hard to think back to the days when HTTPS wasn’t the norm, and only 30% of traffic was secured. How could we make it the vast majority? I remember hearing thought such as: “it can’t be done!”, “people just don’t actually care enough!”, “it’s too hard!”

In retrospect, it’s interesting to reflect on the parts and pieces that I think collectively drove things forward:

#1 Knowledge and Insights
There was a lot of content on *why* this is important, and *how* to do it. I remember it being really quite hard to do, and also waking up in a sweat on a couple of occasions with my brain racing: “did my certificate expire?“

#2 Tooling
The ecosystem jumped in to help make it MUCH easier. LetsEncrypt changed the game, and servers and hosts jumped in too.

#3 Demand
Now it’s easier, and it’s the right thing to do, but companies have huge backlogs. How do we make “the right thing to do” blindingly aligned to users and the company?

We need the right incentives, and this was the final puzzle piece. How do we reward developers that do the right thing? Some examples here are:

Browser UI surfacing quality: At first browsers changed their UI to highlight the good (e.g. showcase “secure”), and then…. over time…. deliberately…. switch to the point where the default is secure and we highlight the insecure
HTTPS required for API usage: WIth Service Workers, and powerful capabilities such as those being worked on via Project Fugu we need to make sure that we aren’t setting users up for attacks. This keeps our users secure, and also incentivizes developers to move to HTTPS to gain access to said APIs.
Acquisition: highly quality content is better for our users, so we want to make sure that Google Search is driving engagement to that content. When HTTP was added as a ranking factor we noticed an increase in adoption.
It has been great to see the sum of the parts add up to the great adoption of HTTPS and we continue to push.

Moar Incentives!

How do we learn from HTTPS and bring this to the other areas of quality such as performance?

We will make sure that:

We will be clear about the metrics that we think represent quality
We will surface data and insights for developers and decision makers across our suite of products, and accessible for third party tooling solutions
We are very deliberate in carrots and sticks so everyone has time to plan
We will work with the sub-ecosystems so we can align on everything above so we row in the same direction. For example, if you are an established CMS provider, it isn’t solely important to track how many themes and plugins you have in your marketplace, but also note the quality of the output and how you can use said marketplace to share the same incentives (surfacing the right metrics etc).

How can we build connections that will strengthen us all? Do you see anything we should be doing? I am all ears.

“We are a platform company” — VC pitch

Whenever I hear this utterance I get curious to understand what this person thinks that means. Sometimes it ends up being related to wanting to be a platform company, but that is besides the point. If you really do end up being a platform company, then one key aspect of a great one is patience.

If you are fortunate enough to grow a business that has success, you now have producers and consumers working with you (I will switch to developers and users because I think about developer platforms :). Congrats! Just one small thing though….. it may start to feel like you are driving a boat vs. racing a Ferrari, and you need to account for that.

Hopefully you got into this situation carefully and have plans for keeping momentum and moving the ecosystem.

I once got stuck in a boat off of the Florida Keys. Everyone had forgotten that it was a full moon, and the tide came out quickly. This meant that we had a boat sitting on shale, and we had to slowly push it as fast as we could to catch up to the water.

The tides are always moving in your business too, and you need to make sure that you have a way to keep moving ahead of them. You could also argue that your role as a platform is to be the ocean, and thus you need to keep the tide moving, nudging the boats in the right direction.

To do this nudging correctly you need to be able to:

Communicate the vision of the platform

Where are you going? Why?

Keep the vision updated and get into the rhythm of “we are going over there!”, “remember when we said we were going over there? that time is coming!”, “we have made the change so you can go there, but haven’t broken you yet, but really…. time is running out!”, “ok, it’s really painful for you to not have made this change…. the warning signs are flashing”, “done.”

Have a connection to developers

How well connected are you to your developers. If you have an important message to get out to them, how many of them get it? Far too often a platform is shooting out UDP messages that get missed, and developers don’t even have the information to do the right thing for them and our users.

This can be really tricky. We have many ways to communicate, and most of them are lossy in some way, or don’t reach the right people on the other end. You can broadcast to email, or you can put messages in consoles, but do they reach a general “admin” account?

Knowing that you have a lossy protocol is important, and puts the burden on you to re-try across the board, and capture when there has been real action. There are plenty of basics to get right such as having the same messages reach the various touch points. E.g. can the central console messages reach developers in the tooling that they live in each and every day? Do the various tools even get the same message across? Often the answer is…. sub-optimal.

Have a connection to users

Do you have good control over the platform that the user actually has? Can you update it and secure it? Just as the connection to developers is key, so is this.

By moving the developers you keep upgrading the experience for users.

By moving the users you give reason for developers to prioritize.

By moving them both, everyone progresses, hopefully leading to much success for all

The patience part

Once you have a plan on how to keep momentum, you still need to acknowledge that you will probably have to be patient. Your platform priorities may not always totally align with those of developers and users.

With both, there are incremental updates which can work nicely (smaller changes) unless they are too small to prioritize.

With larger efforts you are reaching a new level, and you may find yourself running into a natural cycle. E.g. it’s been a few years and there is enough value to be had that the product team is ready to rewrite a large part of the system, giving them a chance to jump to the next level.

Now, building the next generation of primitives (and tools and ….) takes a long time.

A great example of this is the recent upgrade of web primitives. Alex Russell gave a talk on the multi-year journey, which is a great example of looking to the future and plotting all of the dots that will get you to a new location whilst bringing incremental value along the way.

It is fascinating to think back to some of the individual items and how the community has gone from “nah we don’t need that” to “man, it is so much more fun to build on the Web now with these primitives!” — I am looking at your ES2015!.

The larger you get as a platform, the more wrinkles you get, and you run into Hyrum’s Law:

“With a sufficient number of users of an API, it does not matter what you promise in the contract, all observable behaviors of your system will be depended on by somebody.” — Hyrum

This is where you can run into the feeling of momentum slowing, but you have to press on.

Sometimes this slowness is partially an issue of perception. When you are small you can see big movements in percentage terms, and you get excited (and ignore the small base). When larger the percentages can feel smaller, but the absolute change can be massive. A momentum change for a huge mass is a huge change, but it may not feel it, and there is always so much that you want to do.

We see perception issues with new platforms too. We humans are awful eye witnesses, and we are dreadful and remembering time periods. When a new computing model pops up, we forgot how long the last one took to really take and we want instant success. We see how obvious it is “we knew this would happen, because Star Trek!” and rush. Instead we need to remember that it takes time to truly bake in something new, and instead of rushing for “fake” adoption we need to nail use cases that add true value and build from there.

We also like to simplify and think in linear terms. Platform A begets Platform B begets Platform C. In reality platforms often evolve and, importantly, work together. This means that new paradigms are often accessories and amplifiers of current platforms….. and that is OK! Having and vs. or isn’t a bad thing.

Have the vision, have communication in place, measure the right thing, and be patient.

The difference between Platforms and Ecosystems