Three Laws of the Business Side of Developer Tools

Developer tools are some of the most interesting, inspiring and satisfying jobs in the industry. In what other job can you create such fundamental, useful, elegant, powerful tools, meet customers, see your tools get used, see the huge difference they make to productivity?

However, developer tools often exist in a business context. This can be confusing for technical people who love technical things. This note is primarily written for technical people and students who may be exposed to the business side of developer tools, through engineering jobs or products.

Below I give three “laws” I feel people working in developer tools should know. The opinions are my own, though I’ve heard many people express variations of them over the years. There are exceptions, they are not 100% universally applicable, I discuss that below. And I also discuss how, in the era of AI, there are fascinating new business models emerging.

When I say “developer tools” here I mainly mean coding tools – IDEs, compilers, languages and new things close to those. I explicitly don’t mean security tools, databases, operating systems, or AI inference delivery, which I regard as different categories.

Still, if you’re out for a drink with me, these “laws” will crop up pretty soon. They’ve been my landscape map for many years. So I’m putting them down so I can refer to them, and discuss how they are both relevant and changing in the era of AI. Enjoy!

——

The First Law of Developer Tools – The Law of Not Much Money in Their Own Right.

There is, generally speaking, not so much long term profit in dev tools in their own right. This is a hard lesson for many who try to make standalone businesses from dev tools. Unlike, say, machine tools – a sector driving a significant portion of the German economy – these incredible productivity enhancing developer tools are only rarely a major business in their own right!

There are exceptions to this, and I list some categories further below. And don’t get me wrong – some incredible people work very hard to make a long term business from developer tools alone, as a product, unattached to any platform or other business dynamic, over the long term. Full credit to these people! It is hard work, you have to find a niche. To these people: many people reap the benefit of your work without paying you enough considering the value you bring. Up your prices. You are amazing.

Even more people contribute to OSS developer tools. Again, this is amazing, done mostly by people creating, maintaining and contributing to tools they use themselves. This post is not about OSS, which is such a unique and important cooperative social dynamic in the era of capitalism that it should be celebrated widely, and every contributor recognised. OSS is the norm in most parts of developer tools.

The relatively small scale of the developer tools sector is largely because of the dynamics and economics of OSS – if a developer tool is highly successful, an OSS version of it will be likely be made and popularised, squeezing the growth path of commercial developer tools offered in their own right. These OSS tools are often maintained or sponsored by platform companies. Anyone planning a new developer tool company should be deeply aware of these dynamics.

The Second Law of Developer Tools – The Inevitability of Platform Alignment, Consulting or OSS.

Why are there so many jobs in developer tools? This is because most developer tools at commercial companies are platform-aligned. Alternatively they may support some other business process like consulting.

The centrality of platforms in the dynamics and history of programming and dev tools is often missed. Here are some examples of amazing dev tools that align with platforms:

• .NET – Azure
• Go – GCP
• Claude – Anthropic

There are thousands of examples in history. Indeed the history of dev tools, including programming languages, is almost 100% aligned with the history of platforms.

There’s big money in platforms (including hardware, or foundation models) which these dev tools support, whose usage and adoption they drive. Most the money in dev tools ultimately comes from the platforms, not the tools themselves.

Further, platform companies employ a LOT of people in dev tools. There are many amazing jobs at these companies in dev tools, and they can pay very well and be crucial and highly respected. But when you take these jobs, it is wise to be aware of the business context – these companies ultimately do this because of their platforms. That’s fine, just please be aware why they’re doing it. It will make many things simpler and clearer in your working life.

The significance of the platform dynamic means that, on the whole, the destiny of most developer tools is either

(1) to end up at a platform-aligned company, supporting the growth of that platform, or

(2) to support a consulting company, or

(3) to be a relatively small business, delivering a niche professional tool to businesses, or

(4) to be community-based OSS, or

(5) to go the way of all things.

That’s just the way things shake out, most of the time. These destinies involve very different end games. If you know your destiny, you can make better decisions.

The Third Law of Developer Tools – The Law of Trajectory

Any good developer tool that makes significant money or attracts significant investment for a while will either (1) be crowded out by OSS clones or (2) be acquired by a platform model company or (3) be made OSS or (4) be squeezed. This is the dynamic version of the First and Second Laws. It is not universally true, but is true to first approximation.

Recap

To recap: the first and most basic principle of the dev tools industry is that, generally speaking, there’s not much direct profit in it considering its importance to the world economy. There is often investment, startups, small companies, but finding long-term direct profit streams that sustain is a challenge. And even where there is large revenue it may be sold-at-cost within a larger platform business context.

The second basic principle is that dev tools only make sense long term if they’re OSS, or are aligned with a platform, or somehow make significant defensible revenue that can’t be undermined through OSS.

The third law is about how this can take some time to play out. The demise of the exceptions to the Second Law (eg Borland in 1990s) are the proof of ultimate truth of the Second Law.

Exceptions to the Laws

There are exceptions. First, some dev ecosystems (.NET, Java, Python) are vast and support a range of small dev tool companies aligned with those ecosystems. These are usually (though not always) also aligned with the underlying platforms they serve. There are also a couple of strong dev tool companies that span multiple ecosystems and build incredible dev tools across those ecosystems. Full credit to these exceptions.

Secondly, there are also exceptions where some dev tools occupy a position in the market where they can extract enough rent (subscriptions) , and grow enough users, to continue their development long term. Commercial numerical libraries, for example. Some performance or testing tools are similar. Sometimes this happens at reasonable scale, and again they’re usually attached to one or more major ecosystems.

Thirdly, many dev tools exist as OSS with an associated consulting business. These are important business models for many people. The money is in the consulting, not the dev tool. Understand it and respect it. It’s a good gig.

A New Exception – The Engine Room

These dynamics may be changing in the era of AI. Today, new developer tools can be created quickly using AI assistance. Will that reduce costs to allow more developer tool businesses to thrive? Will it make creating and sustaining OSS tools even easier? Will AI powered developer tools, which incur costs, somehow be different and escape these dynamics? All this is still to be seen.

A fascinating new dev-adjacent business model is emerging: there are now AI code generation and improvement tool chains that are deliberately kept entirely internal, usually to support an external requirements consulting business.

These tools are so powerful, so core to the delivery of the (relatively simple)  consulting business that they are fully internally stable – they are the “engine room” of the consulting company, whose external product is to assist customers along the path from requirements to deployed software.

This “engine room” model is not yet fully appreciated in the era of AI coding, but I believe will be critical to the future. Arguably these are not dev tools at all, because there are no developers using the tool, except the operators of the engine room.

Using the Laws – Your Job

If you’re working in dev tools in a platform company, the ultimate reason you have a job at all is platform pull through. Your job, or your team’s job, is to make tools that make it easier to develop using the platform, or which open new applications of the platform for developers, or attract more developers to the platform, or allow your platform to interoperate with others, or to enable your company’s development of the platform. These are long term plays over 5 or 10 years. It’s often very difficult to measure platform pull through. This requires good VPs and good managers who understand that developer tools are a critical part of a platform ecosystem, a bigger picture. Attempting to squeeze excessive direct revenue from developer tools is missing the point and will likely backfire.

If you’re at a platform company, and you’re working on a tool which is misaligned with the company’s platform, you should expect trouble in your working life. At some point, someone will ask “why are we spending resources on this?”. This can be particularly difficult at times of change.  Platforms are not static – they change and shift over time. This means the bedrock on which your developer tools job sits can shift. To give one example, Azure shifted to a Linux focus around 2014. This had major implications for its associated primary developer tools. Again this requires steady, long term vision from leadership, product and engineering. Such steadiness can be lacking in profit-driven companies with 1-year review cycles, or brash inexperienced managers. These dynamics can also be upsetting to the technically minded, idealistic engineers and researchers attracted to do developer tools at all.

Using the Laws – The Crystal Ball

If you are assessing a new proposed commercial dev tool from a company, pause and ask yourself

(1) Is it platform aligned? Is there some platform at that company that this tool aligns with. Is the tool intrinsic to the growth of the platform?

(2) If not, or if the company is a startup with no platform at all, then is there something very  special about this dev tool that will allow it to occupy a secure, defensible position in the market where it can extract ongoing rent long term? What is the size of that rent, long term. Is the company making the tool interested in revenue of that size?

(3) If not, is it reasonable to assume an OSS version of this functionality will come along sooner or later? One that will undermine this tool? Is there some special reason that this tool will be immune from this dynamic once it becomes successful? What stops a grad student from making an OSS version of the same thing?

With these basic laws, and basic questions, you can crystal ball most of the future of most dev tools most the time. Give it a go.