How to Create a Lasting Developer Platform

OK, it's been a few weeks since I promised a follow up to my last post on first principles for developer platforms. Let's just say life got in the way, but its time to fulfill my promise and tell you about my simple (to say, not to execute) formula for creating a lasting developer platform.

Before I get to the details, however, let me just point out that the definition of developer platform has evolved over the history of personal computing. In the early 1980s, MS-DOS was an important developer platform. Probably the most successful developer platform in history was also an OS, namely Windows versions in the 1990s and early 2000s. PowerBuilder was a wildly successful platform for client-server applications until it failed to adapt fast enough to multi-tier application trends.

Modern developer platforms include DevOps centric build-and-deploy platforms like RedHat OpenShift and VMware Tanzu Application Platform (TAP) (plus a myriad of SaaS options), DIY alternatives using the phenomenal plethora of OSS options out there today, and even the major cloud provider services for DevOps automation, application architecture options (such as "serverless"), and operations optimization.

The point is that the term "developer platform" just means whatever developers use to automate the tasks that have the most toil and risk, or enable architecture options that further optimize productivity, cost, and customer outcomes. But I argue that regardless of the "type" of platform we are talking about, the rules below hold true.

Modularity

Build a box of parts…

The long term success of your platform begins with adaptability to changing market and technology conditions. That, in turn, requires the ability to adopt new technologies and (if necessary) jettison older, no longer viable options. The only way to do that is to build your platform so that pieces and parts can integrated, updated, and removed independent of the rest of the platform. In other words, platforms should be thought of as highly integrated collections of modules.

You can see this philosophy in play today in both the major OSS-based platforms (like OpenShift and TAP), as well as the way the major cloud providers are handling developer automation. In the former case, the vendors are wrapping OSS components with integration interfaces that allow them to work together, and providing user interfaces and APIs to control the end-to-end product (rather than each OSS component individually). In the latter case, the providers are creating services with built-in integration to other services that can work together to meet a developer need. In both cases, the result is a modular system that can be changed and expanded relatively easily.

The lure of modularity for software vendors is great. It enables independent teams to release on their own schedule (or at least merge with main on their own schedule). It allows product, design and architecture teams to evolve their individual visions "ahead" of the current state of development with some assurance that the vision can be executed. But modularity is not the end game. Customers generally hate buying a "box of parts" that they have to assemble to meet their needs. Which leads us to the next rule…

Opinions

…but sell solutions…

Customers have problems that hinder their ideal vision of their businesses. They may or may not be able to articulate these problems—and if not, this is an ideal opportunity for solution architects or field CTOs to add value for the customer—but nonetheless they have them. The successful software vendor does not sell a kit that leaves the hard work of solving the problem to the customer, but rather sells a starting point that solves the problem generally, but allows the customer to evolve from their to the specific solution that works for them.

But the list of problems that need solutions is vast (more on that in the next section). It is up to vendor product management to identify general solutions that result in the most customers spending what is needed to solve their problems.

Developer platforms are an especially difficult product space to get this right. Developer tools are unique in that the end user (who may or may not be the one with the budget) can simply say "if I don't like what my employer gives me, I can build my own". And, believe me, there are many developers out there looking for any excuse to "build their own" developer tools.

This leads to the challenge for the vendor of getting both the solution generalization and the associated developer experience right. This goes back to what I discussed in the last post I did: developers will gladly adopt software that reduces toil, reduces risk, AND solves their use cases. This, then, has to be the mission of every platform team.

Ecosystem

…and enable others to build the solutions you can't.

The biggest mistake that I see platform companies make is that they think they can own all the profit for the impact their platform has on their customer's business outcomes. This might be true if they were willing to staff their engineering and field technology teams with as many Human Resources (and AI support systems) as needed to cover every use case their customers introduce.

But any smart business won't do that, in part because organizations don't scale efficiently like that, and in part because they would need the resources in place and trained before they encountered a new use case. It's just not efficient.

However, the market as a whole can be efficient, which is why the most consistently good strategy to deal with a large variety of needs is to engineer to enable other organizations to make money from the platform. Give partners, startups, even independent developers the ability to create, integrate, measure, and charge for software customizations or add-ons that solve problems you never thought of, can't staff, or both.

The health of an ecosystem is driven by this mutual benefit: third parties make your platform more applicable to more customers, and you—the platform vendor—always sell your product when the third party sells theirs.

The ecosystem market is a flywheel: the more successful third parties are at profiting from your platform, the more third parties become interested in building solutions for your platform. While some of these efforts will fail to build enough profit for their creators, others will—and a select few may be successful beyond what anybody anticipated.

As an example, let's once again look at what happened in the Microsoft Windows ecosystem. Thousands and thousands of developer, software companies, and others saw opportunities to build software to solve real problems that people would pay for. Windows not only made it easy to write such software without worrying about disk access and other mundane hardware tasks, but also made it easy to install any software that used the Windows APIs. Once packaging and licensing were figured out for a given product, it was easy for consumers and businesses to acquire, install, and use software from the ecosystem.

All of this made Microsoft one of the largest and most valuable companies in the world. Even today, with cloud computing and SaaS offerings gaining importance, the Windows ecosystem is strong. And Windows keeps selling. (Although Apple's closed ecosystem has certainly gained ground.)

Putting it all together

The key thing about these three properties is that they create long lasting developer platforms. Platforms that can adapt to changing needs, new technologies, and even new developer methodologies. Nothing can completely protect a platform from obsolescence, but if you are going to invest the money to build a platform, for goodness sakes make sure it lasts.

I always used to close posts with the statement "I write to learn", so let me reboot that tradition here. Let me know what you think. What do you disagree with? Which of these things do you implement yourself, or do you wish your platform vendor understood? I look forward to reading your thoughts.