The Developer-Led Landscape
$40 billion generated by products consumed, influenced or purchased by software developers.
Starting in 2009, I began tracking each company whose products were sold to, purchase-influenced by, or consumed by software developers.
I call this the Developer-Led Landscape.
While there is a significant overlap with DevOps, many DevOps landscapes exclude developer tooling (like design IDEs) while including IT Operations not part of a developer's workflow (like network monitoring).
2020 is the first time this has been published.
The appendix details why a developer-led view is needed for our industry.
This work is never finished. If you uncover an error or want to make a contribution, please email firstname.lastname@example.org or open a pull request on the GitHub repo. As an investor, I have access to privileged information provided by companies that we consider for investment. I never include information provided by prospective investments unless their management provides a written (OK, email) consent.
PS. Graphic design is not my forte!
The Landscape — By Category, Segment, ARR, and Growth
ARR, growth rates, and number of companies across 22 segments of the Developer-Led Landscape.
The Developer-Led Landscape
A GitHub repository lists every company and product mapped to categories, segments, and specializations. It also contains the methodology used to define the landscape and collect data.
Developers Are Big Business
Developer-led products account for $40B in annual revenues.
The 2020 global Information Technology industry will reach $5.2 trillion, of which $624B is software, implying developer-led products are 7% of global software spend.
At the time this blog was authored, the median SaaS / Cloud public markets EV / Next 12 Month Revenue ratio is a whopping 15x, and if developer-led businesses are treated similarly they would carry a $0.6 trillion EV.
Developers Are Big(ger) Business
There are four segments (Test Automation, Application Servers, PaaS, and Low Code) where analyst estimates are $54B higher than ours, implying that at nearly $95B the Developer-Led Landscape may be larger than cybersecurity.
Developer Runtimes Generate 2.5x More Than Pre-Production
The combined revenues of application servers, Platform as a Service (PaaS), Low Code, and API as a Product businesses are collectively 2.5x the revenues generated by tools and infrastructure developers purchase to create these software systems.
There are two drivers — one is pricing whereby many pre-production technologies are charged using size of development team (seats) as a proxy while production platforms are charged by the size of the environment. Small groups of developers can deploy massive systems. The other tendency is for vendors selling platforms to provide pre-production tools for free; a reflection of one of the Laws of Tech, “Commoditize Your Complement”.
One interesting correlation that further supports this ratio is the infrastructure consumption driver. It’s been suggested that infrastructure consumed by developers during software delivery is up to 25%, or 1:3, of the total compute globally. With estimates of 20 million professional developers and 80 million bots (i.e., CI, build, and automation systems) writing, compiling, testing, and analyzing code, that’s a significant lift of compute, memory, and I/O. If the cost of developer-led products is driven by their relative compute required, then the 1:3.5 ratio of revenues between Dev Infrastructure : Dev Platforms is close to the 1:3 software delivery : production compute ratio.
Early Segment Leaders Usually Become Dominant Leaders
In the 22 segments tracked, there is usually a single vendor that makes up 15–50% of the segment’s revenues, creating a tail of vendors sharing the remainder.
It pays to be the segment winner, as there is a tendency for developer-led leaders to become bigger, even dominant, leaders as a segment matures.
The total ARR by segment and percent of ARR from the three largest companies in that segment
When summing the revenues of the top 3 companies in a segment, that collection will control up to 97% of a segment’s total revenue, with most segments giving up a majority of their revenues to the top few vendors.
There are some exceptions such as Test Automation and Platform as a Service, but those might be aberrations to how the data was collected since my bottoms-up number (and therefore the top 3 companies for that segment) was smaller than what the consensus analyst number is.
Big Categories Grow In Big Ways — Creating Opportunities for New Entrants
It’s astonishing to see a double digit revenue growth estimate for the developer-led landscape. At 19% growth, these categories drove $6.4B in new revenues over the last year. That’s $500M in new revenues introduced each month.
While incumbents have an advantage to capture the renewal stream (either due to legal obligation from multi-year contracts, expensive switching costs creating inertia, or positive brand affinity), a large portion of those $6.4B in new sales each year come from new opportunities, and generally should be a free for all. Even at a fraction of the size, the growth in greenfield new opportunities is substantial creating incentives and opportunities for new entrants to enter, innovate, and establish sizable footholds.
Developers Love to Roll Their Own
If you’ve got the skills, why not flaunt it? 22 years ago, working for the wonderful Kim Williams at BEA, I grew frustrated with the manual entry spreadsheets we used for tracking a minor portion of our business. Overnight, I built a better option — a piece of software that would make the data entry better for everyone on the team. It fell flat. My colleagues were particularly perplexed why I would spend valuable social time building such a thing. Because I could, and frankly, what was built was better, right?
That dynamic hasn’t (and probably will not) go away. It’s built into the psyche of developers, probably because the creative need to build something was what attracted many developers initially into learning how to program. And it’s not just technologies, but also engineers translating their software construction skills into business construction, transitioning into developer-led entrepreneurs. Dev Tools, Dev Infrastructure, and API as a Product (arguably the categories and segments where developers create things for themselves rather than others) comprise nearly 70% of all developer-led companies while comprising roughly 40% of the revenues.
1 Trillion Programmable Endpoints Drives Need for Lifecycle Automation and Operations to “Shift Left”
We are on a path where every form of digital asset is going to become an Application Programming Interface (API). Many of these APIs are network accessible, becoming programmable endpoints. I’ve speculated that we’ll have more than 1 trillion programmable endpoints by 2035. The growth in programmers and the trend of disaggregating architecture to design systems of scale are the largest accelerants.
Containers, APIs, microservices, and serverless functions are atomic units of architecture modularization
The volume of components to deliver services is exponential requiring new forms of automation to organize, manage, and secure systems comprised of cloud building blocks. In other words, applications are increasingly comprised of so many modules that it’s becoming difficult for humans to reason about those systems, depending upon new forms of automation where machines can do the reasoning.
As a result, operations and security solutions are increasingly “shifting left” into pre-production, and further into the hands of developers which are constructing the modules prior to their orchestration. This need is commensurate with a company’s adoption of containers (and usually cloud), and thus why Dev Infrastructure + Dev Tooling has more companies than Dev Platforms (nearly 50% more if you exclude the long tail of API as a Product vendors). Many of the products contained within the Dev Infrastructure category are thematically aligned, providing solutions specific to cloud, container, or serverless architectures.
Another theme is Infrastructure-as-Code (IaC), which defines both the software and hardware technology stack as building automation, rather than release through manual processes. This pushes infrastructure — along with operations — to the left making infrastructure a part of issue management, CI+CD+Build, Config+GitOps and developer debugging processes.
The Fastest Growing Segments Make Software Delivery Faster and Safer
The six fastest growing segments are each growing greater than 30% year over year. This includes:
Artifact Repository: +45% yoy
RPA for DevOps: +45% yoy
API as a Product: +40% yoy
Low Code: +35% yoy
ChatOps: +35% yoy
Engineering Efficiency: +35% yoy
Artifact Repositories are being driven by a shift in how software is constructed. At the turn of the millennium in 2000, 80% of a new application was custom code, and 20% was sourced from a reusable component, such as what comes from open source, a library, or hosted middleware. How the times have changed., In 2020, 20% of an application is custom code and 80% is sourced from a reusable module.
Increasingly, the job of development is to source and integrate numerous preexisting components into a functioning whole. With the bulk of applications now dependent upon third party modules, organizations need ways to organize those dependencies (Artifact Repositories like Dell Technologies Capital’s investment in JFrog) and to detect, manage, and remediate vulnerabilities that appear in those dependencies. Docker, GitHub, Sonatype, Gitlab, Canonical, AWS, Microsoft, and Google are making recent investments in this segment as well.
Developer-Led Landscape With Segments Growing > 30% Highlighted.
Of special note, the Software Composition Analysis (SCA) specialization in Code & App Security is growing more than 40%, mostly driven by the demand in open source. Application Security Testing as a broader segment is only growing at 20% with a number of large established players (like Veracode, Checkmarx, and Whitehat) that make up the segment’s majority. SCA as a sub-segment is shaking up the budget allocation allocated by CISO’s to different application security vendors given that an increasingly larger number of vulnerabilities are appearing in third party modules. SCA’s rapid growth is being driven by early winners including Snyk, Whitesource, and FOSSA.
Low Code, API as a Product, Engineering Efficiency, and RPA for DevOps make building software systems approachable for broader classes of developer populations. Arguably, they are collectively increasing the available talent pool of engineers available to create software systems by altering the skill sets required. Low Code and APIs are forms of abstractions — making the seemingly hard into something simple. While abstractions tend to remove the power and configurability often needed from underlying systems, the market’s broad scale adoption of abstracted solutions like Low Code and APIs indicate that vendors are finding the ideal balance of simplicity and power.
Engineering Efficiency is a young segment which includes vendors that collect data from across the developer tool chain to create metrics which help teams move faster, such as cycle time — the time from code commit to production. These solutions bring visibility to bottlenecks which may not be intuitive to engineers in the thick of their work, enabling teams to collectively overcome the issues which increase their software release velocity. In other words, it makes developers better by giving them visibility to how the team is moving. With numerous well-funded entrants that have launched within the past few years (e.g. Code Climate, Pinpoint, Jellyfish, Pluralsight Flow, and Waydev), the business of helping devs be continually better is emerging.
RPA for DevOps is also a new segment which includes vendors that are creating automation solutions to eliminate the complexity of managing complex delivery infrastructure. Essentially, these vendors offer an all-in-one DevOps platform simplifying the effort that teams need to go from code to operations. This includes vendors like Atomist, Axiom.ai, CTO.ai, Architect.io, Quali, and StackStorm.
$5M ARR is the Threshold Between Startup and Going Concern
Most segments have the majority of products at or below $5M in ARR. This seems to be the level where it’s possible for VC-backed developer-led investments to become profitable, if necessary, and continue on as a going concern. Companies below the $5M threshold are typically still finding product-market fit.
Total number of companies per segment and percent of those companies whose ARR is less than or equal to $5M
In some cases, segments that have a high percentage of companies with less than $5M ARR are emerging like Engineering Efficiency and Low Code. In other cases, like most in the Dev Tooling category, the large number of small revenue companies reflects fragmented interests which create constraints to building companies large enough to be a going concern.
APIs Are Now the “Universal User Interface” Causing API-Specialization Businesses to Materialize
83% of global Web traffic was through an API at the end of 2018, and it should be approaching 95% by the end of 2020.
With the global expansion of APIs, so has its diversity and complexity. APIs must address challenges with scale from billions of digital assets, data diversity from APIs generating 2.5 quintillion bytes of daily data both at-rest and in-motion, and API contract heterogeneity. It’s no wonder that 75% of IT managers identify an API skill gap in their organization.
This has caused the emergence of lifecycle solutions and businesses dedicated to APIs.
The number of companies, ARR, and % of category, segment totals for API-specific products within the Developer-Led Landscape.
Given the amount of Web traffic flowing through APIs, it’s not surprising that 28% of all Dev Platform revenue is driven to an API specific product offering.
APIs with their structured contracts make it plausible to construct advanced construction and automation solutions that are not possible with GUIs or systems without standardized interfaces. This has created a number of companies providing API IDEs, API testing, and API debugging offerings. The lifecycle revenues allocated to these products is low, but I expect them to grow 50-75% CAGR over the next few years.
It Takes a Mega Vendor to Straddle Pre-Production and Production
You can be a very large vendor (billions in revenue) that spans Dev Tooling and Dev Infrastructure. You can also be a very large vendor that is a Dev Platform.
However, to span all three you need to be a Mega Vendor.
How some of the largest vendors that are tracked in the Developer-Led Landscape span across categories.
If the biggest dollars to capture in the IT budget are in Dev Platforms, it’s long been held that a platform vendor who can sway developer mind share into a philosophy that aligns with how their platform works, then those developers will create more applications that consume that vendor’s Dev Platform. This logic spills over into the largest Dev Platform vendors working to capture that mind share by introducing their own Dev Tooling and Dev Infrastructure.
Microsoft, IBM, AWS, and Google have these kinds of portfolios. Microsoft and IBM have such massive Dev Tooling and Dev Infrastructure investments, that those businesses are each >$1B as stand alone units. While AWS and Google also charge for their pre-production services, they are not meaningful to their overall revenues and they have structures that increasingly make their pre-production offerings free as a way to seed interest in their production-based offerings.
New Developer Abstractions and Paradigm Shifts Precede Billion Dollar Category Transformations
Every so often, seemingly on a 5–10 year cycle, a developer abstraction on top of programming languages, frameworks, infrastructure or platforms materializes. These abstractions introduce >10x productivity enhancements that (generally) attract significant (and fervent) developer adoption.
Developer abstractions are catalysts that cause disruptions which trigger multi-billion dollar category transformation. The transformation, in turn, often introduces new market leaders and accelerates category growth.
An interesting example is the Code IDE segment. In the 1990’s Microsoft, Borland, and IBM dominated the market, probably with 85% of all revenues. In the early 2000’s, IBM open sourced the Eclipse IDE, starting a trend that would cause most Code IDEs to follow suit, decimating (err, commoditizing) most of the for-profit Code IDE vendors, including Borland. At the same time, Jetbrains launched their proprietary Java IDE which introduced “Intellisense”, which was so sensible that it could complete segments or refactor code with near magical qualities. This abstraction proved so useful that Jetbrains became the dominant Java IDE over open source alternatives 15 years later, and collectively the Code IDE segment has benefited to being nearly 2x larger in 2020 than it was in the 1990s. Impressive.
Another example is version control. In the 1990s, Microsoft and IBM had roughly 75% of the market share for team-based version control systems. Version control at that time was centralized, where all changes were coordinated through a server. This was fine for small teams, but was challenging at scale (imagine trying to coordinate a meeting with 100,000 people where only one person can speak at a time). This became cumbersome for the Linux project, and Linus Torvalds conceived of and did the first implementation of git over a weekend in 2005. Git provided an approachable form of distributed version control, where changes could be made by individuals locally, and then later merged together in a coordinated fashion. Turns out that distributed version control was the foundation needed to enable collaborative development. Later in 2008, GitHub launched the “Pull Request” which made it possible for collaborative development to be engaged by anyone. The pent up need for collaborative development caused GitHub to become the market leading version control solution in a few years. Microsoft eventually acquired GitHub for $7.5B, inspired the launch of GitLab (valuation >$2B), and has grown the Version Control market to >$500M.
The abstractions and paradigm shifts that I’m thinking about in 2020:
Programming Languages. Increasingly we are seeing old and new languages that incorporate distributed systems concepts into their syntax. Why think of the network as a bolt-on module which is conceptually hard to program when it can be embedded into the language itself? Error handling and scaffolding coding can be eliminated. There is interesting work being done by Darklang, XTC, Julia, Web Assembly, Elm, Rust, and Ballerina. Will any of these hit mainstream?
Opinionated Frameworks for Stateful Systems. Cloud environments excel at scaling stateless services but challenges occur with stateful applications because database calls to fetch state are slow. There are numerous mechanisms for delivering scalable stateful applications that minimize, avoid, or eliminate the database as the scaling bottleneck.
Reactive Architecture for Building Stateful Microservices. This includes vendors and open source projects for delivering event-driven architectures and stateful serverless. This includes Lightbend Akka, Pivotal Spring, RedHat Vertx, Synadia, AxonIQ, Google KNative, Microsoft DAPR, and a number of serverless companies.
Recently Public Companies are Capturing Market Share Especially in SDLC and Developer Infrastructure
Publicly traded companies have products totaling $29B ARR, which is nearly 75% of Developer-Led Landscape revenues.
Public companies with a Developer-Led Landscape product with >=$100M ARR and the % of revs these products have for a category.
Reputation, security, and economies of scale are a driving force that have allowed publicly traded companies to obtain 95% of Dev Platform revenues, even though they only represent 9% of the 348 companies that make up the category.
This dynamic also plays out in the Software Delivery Lifecycle category where publicly traded companies command 88% of the revenues. It is representative of the immense investment it requires to adequately build solutions that integrate across the entire tool chain along with the tendency for some of the vendors to have achieved rapid scale quickly such as Microsoft Teams and Slack.
The Developer Tooling and Developer Infrastructure categories have their revenues equally split across publicly traded companies and those that are private. This reflects the higher distribution of revenues across a broader set of vendors, and the aforementioned challenges that many platform vendors face making the jump from production into pre-production.
ARR of Developer-Led Landscape Products Owned by Publicly Traded Companies <= 20 Years Old
Interestingly, $10B of product revenues from publicly traded companies are from companies which were founded after 2000 and went public after 2008. Said differently, 25% of all revenues are from companies less than 20 years old, and on average their growth rates outstrip those companies which are older than 20 years. The biggest skew is within SDLC where 67% of revenues are from publicly traded companies less than 20 years old. In other words, the recently crowned kings are taking even more share.
Note: Only includes publicly traded companies still doing business under their brand. So, while GitHub is included in this grouping, Pivotal is not as they are doing business as VMware, which is >20 years old.
Note Note: At the time of writing, a number of companies had just filed their S-1 to go public including Asana and JFrog. These companies are included as public companies in the landscape.
Substantial Application Server Businesses Emerge (Category Creation) Around Programming Paradigms
Programming model disruptions require application server runtimes to execute them. Businesses supporting application runtimes (i.e., an application server or a PaaS) emerge from these disruptions creating large, long-lived software companies.
Tuxedo. The programming trend was C/C++ transaction processing in the 1980s. It was eventually acquired by BEA when it was $200M in revenues. It’s still an active product generating renewal streams within Oracle.
BEA. The programming trend was JavaEE in the 1990s. It was eventually acquired by Oracle when it was $1.2B in revenues.
Software AG. The programming trend was 4GL for integration in the 1980s. Integration has gone through many transformations since that time, but Software AG is leading the charge on all of those transformations and remains a large going concern with $900M in revenues.
Tibco. The programming trend was real-time asynchronous communications in the 1990s. We now call this event-driven architecture, but it was the more primitive message bus back then. Tibco today is a large going concern with >$2B in revenues.
Progress Software. The programming trend was XML for data integration in the 1990s and 2000s. Progress Software is a going concern with $450M in revenues.
JBoss. The programming trend was open source JavaEE. They were acquired by RedHat at a significant multiple to their revenues in the early 2000s.
Pivotal. The programming trend was dependency injection as a programming framework catapulting Spring to becoming the dominant Java-based application server. Pivotal was later acquired by VMware.
Mulesoft. The programming trend was Enterprise Service Bus with XML for integration. Mulesoft IPO’d a few short years after forming and was eventually acquired by Salesforce for a 20x multiple when they were at $300M in revenues.
AWS Lambda. The programming trend was functioning as a service combined with per-request cloud pricing. The result is the creation of a new industry around serverless spawning companies specializing in operations, testing, security, development and delivery of serverless applications. No one but AWS knows the true size of AWS Lambda revenues and I don’t want to speculate publicly, but it’s significant and growing significantly.
Interesting detail — for the first time in 5 decades, we have seen the emergence of an infrastructure shift ahead of the programming paradigm with the emergence of containers and Kubernetes. It’s arguably a massive market, but there hasn’t yet been a collective programming paradigm that developers adopt to create a certain class of applications which then drove the invention of specialized infrastructure to optimize application execution. Prior to this occurrence, it was the emergence of transaction processing, client-server, 3-tier architectures, J2EE + .NET, SOA + Web Services which emerged in advance of application servers and infrastructure to run them. I’m a firm believer that Reactive Architecture is the best option for stateful microservices and serverless (based upon Reactive Architecture) is the best option for cloud functions.
Private Companies With Developer-Led Products Have Raised a Staggering $50B in Venture Capital … Though Deliver Questionable Capital Efficiency
Would you spend $50 to make $11? It depends - as the EV of revenue in developer-led businesses ranges from 4x-100x (yes, that is correct, some of these vendors have raised at those eye boggling numbers).
ARR and VC raised for private companies which publish a product listed in the Developer-Led Landscape (VC raised amounts from Pitchbook).
A world class SaaS company would generate $1 of ARR for every dollar provided by an investor. Companies that raise $3 to generate $1 are considered good. If a SaaS company’s ratio is below that, well, it’s questionable and dependent upon how fast the company is growing and their gross margins.
In aggregate, all of the private companies in the landscape have $10.8B in ARR for their developer-led products and the companies that publish those products have raised $49.5B in venture capital, implying a ratio generating $1 ARR for $5 of VC.
On the surface, this is seemingly less efficient than what is typically seen in the large (and fairly well understood) SaaS category. However, we’ve seen premium developer-related businesses demand up to $30 EV for each dollar of sales (Atlassian, circa August 2020), creating interesting ROI multiples for investors.
Note - ARR is our estimate of product ARR, not company ARR. A company which has products outside the developer-led landscape does not have any VC money raised by their company pro-rated to the proportion of total business driven by their developer-related businesses. It’s possible (and likely) that many of the companies represented have products generating additional revenue not captured in this study. This implies that the real ratio is somewhere better than the $1 : $5 estimate.
Prediction: Software Supply Chain Industrialization Will Propel the Industry Towards Autonomous Software Development
In the next 10-20 years, I believe we will see a massive disruption in the Developer-Led Landscape driven by the emergence of Autonomous Software Development.
I call this the Third Wave of Software Supply Chain Industrialization. We are currently in the second wave: “Agile + DevOps + Developers”.
Industrialization of software development is driven by the micro-modularization of connected systems and time-to-feedback for changes.
Nearly $15B in software construction and testing jobs and up to $5.2B in Developer Tooling and Infrastructure product revenues are potentially up for grabs in what would be the most significant transformation this market has experienced.
I anticipate there will be at least one new, dominant, $1B revenue vendor that emerges by leading this transformation. I anticipate this vendor will emerge from the Test Automation segment since testing professional services is $30B, largely manual, and objectively-driven resulting in testing being suitable both structurally and economically for machines to deliver these services.
The emergence of Autonomous Development will be driven by two factors:
Complexity of Connected Systems from Micro-Modularization. Systems are becoming increasingly difficult for humans to reason about. If a large scale application is designed with microservices, depends upon open source dependencies, leverages constantly changing third-party APIs, and integrates through asynchronous events, anticipating the impact of a change to the system increases in difficulty with the complexity of the system. At what point will machines be better able than software engineers to reason about the risk and opportunity that a single change would have on a software system?
Time-to-Feedback of Change. Consumer demand for having access to the latest and best software has created pressures for software teams to reduce cycle times and shipping software with continuous delivery, where every change to a code base is potentially shipped to end users. Continuous delivery systems depend upon a progressive approach to moving changes through a delivery pipeline and out into the hands of end users, first to a limited set, and then later to a broader set. The speed of progression between stages is tied to the rate at which feedback (from end users, environments, or other bots) is provided back to the system rolling out the change. Positive feedback increases the chances of advancement and negative feedback increases the chances for rollback. The speed at which a system can react to a change in software is correlated to the effectiveness of the continuous software system. Fundamentally, machines are able to respond to feedback faster than humans, paving the way for humans to eventually be removed from the software release and monitoring process.
As software complexity increases (more APIs, more functions, more microservices, more events), a third wave of software defined by autonomous development will emerge which incorporates instant feedback to allow machines to author software and make changes without human intervention.
3 Potential Catalysts of the Evolution to Autonomous Development.
The Test Automation segment has the broadest early adoption of machine and deep learning technology. 15 vendors in the landscape are shipping products that leverage machine learning to automate test creation and test maintenance, identify intelligent test path execution, authoring end user documentation for APIs, hunting bugs with randomized fuzzing, and engineering chaos. These capabilities require machines to develop a semantic and unified understanding of a system through discovery and reasoning.
While it’s still early, it’s likely that we’ll see tremendous leaps in the potency of these vendors as they figure out how to commercialize and onboard learnings from genetic programming, predictive analytics, BAYOU analysis, and deep learning compilers.
Dell Technologies Capital’s Developer-Led Investments
DTC is a sibling to VMware and Boomi, which are part of the Dell Technologies portfolio. Boomi and VMware have products included in the landscape. VMware recently acquired Pivotal, which also has included products.
Developer-related businesses are one of DTC’s thematic areas of investment and we would like to increase our exposure in this category.
We would like to talk to more entrepreneurs — feel free to reach out. We invest roughly $150M / year in companies that are at any stage of financing. We are financially-driven investors with Dell Technologies as our sole limited partner, leveraging our enterprise expertise to help companies build faster. We usually lead investments, especially in the Seed through Series C phase of financing. We often become fiduciaries and work hard to facilitate the growth of the companies we support. Our investment team has deep technical expertise, long operating track records, and global networks that help our companies build better and faster.
My Other Developer-Led Investments
There are many people who influence my thinking on the subject, and in many cases, have also directly contributed to this research. Thank you for the support and thoughtful inputs which worked to make this piece better.
In particular, Diana Kontsevaia deserves incredible recognitionas she has (joyously) spent significant time identifying potential gaps, offering critiques, and analyzing data.
I made my first developer-led investment in 2005.
My interest in supporting Floyd at the time was driven out of friendship and, frankly, geekyness. My career to that point had been tied to developer tools, SDKs, frameworks, and middleware. Programming languages, and the surrounding thing-a-ma-bobs that software engineers used to create software programs were fascinating, usually exposing the hidden depths and power which make computing systems so wonderful.
Up to that point (and probably still!), I was perplexed by the disconnect as to why brilliant technologies were not always market or commercial successes. This curiosity led me down a long winding road into practicing different product management disciplines, starting a developer tools company (to demonstrate geeks can sell million dollar deals), and joining venture capital (to help build markets around phenomenal developer-inspired technologies).
Over the past decade, DevOps has become a mainstream category tracked by analysts, investors, and industry watchers. In 2009, it felt that the business community had awakened to a magical understanding regarding the importance of developers. It was a little ironic to me, as just a few years earlier, developer-oriented companies struggled mightily to gain commercial attention or investment.
DevOps represents the intersection of developer technologies and operations designing to accelerate software delivery, usually targeted at teams that combine disciplines into a single, high velocity, competitor-busting, software creation super muscle. We recently collaborated with Pitchbook to report on the size of DevOps.
However, the DevOps label is stretched and often implied as an abstraction over a range of solutions, some purely for operations. Since many of those products have developer-friendly technical interfaces, they are given a DevOps tag even though they probably do not deliver the value proposition intended by the DevOps convention.
Starting around 2009, I began to track the vendors that were delivering solutions that were consumed by development teams. I also developed an investment thesis to capitalize upon what felt like a limited supply of software engineering talent intersecting with increasing demand for digital services.
This dynamic rewrote the power dynamic within the walls of IT, giving developers the ability to work with technologies selected by their preferences instead of corporate’s and to easily seek out new jobs that catered to their technical proclivities in situations where their desires were unmet.
This thesis — also an investment thesis — has evolved over the past decade.
This dynamic was then met with the cloud, by which servers and software could be leased by usage instead of purchase through expensive capex. When matched with a software engineer’s tendency to create their own software when existing solutions are not ideal matches, this led to a boom of developer-founded startups, building new programming languages, tools, infrastructure, and runtimes. Some of these efforts became hobbies. Others have become publicly traded (behemoth) companies.
Subsequently, many successful technologies and companies admired by engineers, analysts, investors, and employees are developer-led. Between 1999–2012, engineers founded Atlassian, GitHub, GitLab, Pendo, Twilio, Jetbrains, Heroku, Slack, CircleCI, Cloudbees, Hashicorp, and Stripe — a cumulative market cap of >$100B!
Consequentially, the mega success of Zuckerberg, Jobs, Gates, Spiegel, Systrom, Musk, and Dorsey that personify the idea (or is it fallacy?) that exceptional developers are 100x better than the average developer. This has created asymmetric incentives where some technology companies in North America pay 30x compensation for top tier software engineers (as a financial incentive to reduce that same person’s incentive to start their own company).
Over the past two decades, we went from developers shunned as idisyncratic to “Developers As the New Tycoons”.
What are the dynamics that make these developer-led companies successful? How are developer-led businesses structured differently? What are the different business models that work for developer-led businesses? What are the different types of developer-led companies? What are the micro-segments of developer-led businesses, how big are they, and how do they grow? How do these businesses behave differently around the world? For vendors that are building similar products, which ones are better? Is there an objective approach to determining the best developer-led businesses? Who are the biggest investors and acquirers of developer-led businesses?
These questions, among many others, are commonly asked by those new to working in and around developer-led businesses. It’s these questions that I’ve been working to answer with this work.