Own the Category or Rewrite the Rules
Choosing the right positioning strategy for commercial open-source companies
Every commercial open-source founder hits the same fork, usually before they’ve sold anything. Do you sell your product as a better version of something buyers already budget for? Or do you try to name and own a category that doesn’t exist yet?
For COSS companies the fork is nastier than for most startups. Your open-source project might already be changing how developers work, but the commercial tier still gets sold to an enterprise buyer who maps every dollar to a category their CFO recognizes. The choice shapes your marketing story, who you get compared to, and how much venture money you’ll burn before any of it pays off.
Three paths. Two obvious ones and a third that’s usually the right answer.
Option 1: Position in an existing category
The common path, and the safer one. You frame your product as a much better option inside a category enterprises already understand.
The upside is money that’s already allocated. You don’t spend millions teaching a CISO why they need a database, an identity provider, or an observability tool. They know. You just have to convince them yours is the one to buy. For a startup running on a seed round, that’s faster and cheaper.
In COSS, being open source is usually the wedge. Customers are already shopping; they’re just sick of the incumbents.
GitLab is the clean example. When they showed up, “source code management and CI/CD” already belonged to GitHub and Jenkins. GitLab didn’t coin a term. They planted themselves in the existing category and differentiated hard: one application for the whole DevOps lifecycle, open-core, easy to self-host. Companies already knew they needed CI/CD. GitLab argued that unified and open beat fragmented and proprietary, and let the incumbents keep the fragments.
The move is to turn your open-source strengths into the buyer’s selection criteria. So name what actually makes you better than the closed incumbents:
No vendor lock-in.
A developer experience that’s 10x, not 10% better.
Air-gapped deployment, for the customers nobody else will serve.
Usage-based pricing that undercuts per-seat licensing.
The cost of this path is noise. You’ll answer “why not just use Datadog, Oracle, Okta?” in every pitch, forever. One tactic that works: publish the buyer’s guide or the architecture whitepaper yourself, and write your differentiators in as the must-have criteria. You get to define what “good” looks like, which quietly files the closed-source players under “missing features.”
Option 2: Create a new category
Bolder, riskier, and if it lands, enormous. Category creation means you sell something new: a solution to a problem nobody was framing that way yet, not a better X.
Win, and you define the category, become the “category king,” and raise at valuations that don’t make sense on revenue alone. Open source is built for this. You can hand a new paradigm to millions of developers for free and set the technical standard years before any enterprise writes a check.
Confluent is the case people cite. They commercialized Apache Kafka and stood up the category people now call “event streaming,” or “data in motion.” Before Kafka, the enterprise ran batch jobs and message queues. Confluent and the Kafka community sold a different architecture altogether: data as a live, continuous stream. They sold a vision of a real-time, event-driven company, and Kafka was how you got there.
HashiCorp did the same with Terraform, championing “Infrastructure as Code” as a whole way of working. It spun up a new job title (the modern platform engineer) and a software market to feed it.
Category creators go hunting for a higher-level problem the existing buckets don’t touch. The product is almost secondary. What you’re really selling is a new way to build.
The downsides of category creation in COSS
The bill is brutal, and it comes early. Enterprises have no line item for “data in motion” or “infrastructure as code” at the start, because they don’t yet believe they have the problem.
So you pour years and cash into thought leadership, DevRel, and community, just to explain what the paradigm is before you ever get to why they should pay you specifically. A chunk of that goes to convincing Gartner and Forrester to name the category on their maps, because until an analyst blesses it, half your buyers can’t get budget approved.
Then there’s the free-rider trap. Spend millions teaching the market, ship code that’s too permissive, and AWS or GCP can host your project, absorb the demand you manufactured, and hand you nothing. (Ask anyone who watched a hyperscaler roll out a managed version of their OSS the same quarter as a good launch.)
Attempt this only if you actually have a breakthrough architecture, and only if fighting inside an established category would badly underprice you. If your project is Postgres but 10% faster, don’t go invent “hyper-relational data stores.” It falls flat. You’ll waste every conversation explaining what the thing is instead of why your managed cloud beats RDS. Save category creation for a genuinely new problem, backed by enough funding to play a ten-year game.
Option 3: Re-segmentation, the COSS sweet spot
For most commercial open-source startups, the best move is neither. You don’t conjure a category from nothing, and you don’t line up shoulder to shoulder with the proprietary incumbents on their turf. You re-segment: take an existing category and reframe it around a use case, a deployment model, or an audience the incumbent serves badly.
Supabase is the textbook case. No new category. They called themselves “the open-source Firebase alternative.” Backend-as-a-Service was already a thing everyone understood, dominated by Google’s proprietary Firebase. Supabase kept the category’s built-in demand (”we know what Firebase is and why we want it”) and claimed the whole open-source, Postgres-under-the-hood corner of it as theirs.
Re-segmentation lets you spend the incumbent’s budget while keeping a story that’s unmistakably yours. dbt Labs did it to data transformation. ETL had been around for decades; dbt didn’t invent it. They reframed it around software engineering habits, version control and testing applied to SQL, and named the result “analytics engineering.” A twist on an old idea that landed hard with modern data teams, because it described work they were already trying to do.
How to actually decide
It comes down to three things: your architecture, your community traction, and how much runway you have.
Go with Option 1 (differentiation) if:
The market is mature, the enterprise problem is already well defined, budgets exist, and you hold a real COSS edge, lower total cost of ownership, no lock-in, air-gapped deployment. Lean on why your open core beats the legacy proprietary players, and go after the segment they can’t be bothered to serve.
Go with Option 2 (category creation) if:
You genuinely have a new architectural paradigm, the way Docker had containers or Kafka had streaming. Quick test: if you keep explaining your product with “it’s sort of a database, but it also acts like a message broker, and honestly nothing out there does both,” you might have a real category on your hands. Just make sure you have the capital and the DevRel stamina for years of evangelism before the money shows up.
Go with Option 3 (re-segmentation) if:
You want both. The search volume and budget of an established category, plus a win condition that’s a fundamentally different open-source take on it. “We’re an API gateway, but built Kubernetes-native from the ground up.” That kind of thing.
Best practices for executing your choice
If you decide to create a category:
Be the loudest, clearest voice in it. Define the problem in big terms and build a movement, not a product page. In COSS this is as much about pushing a technical philosophy as selling a managed service. Find the higher-level need developers actually care about and make your project the standard-bearer: write the definitive book, run the flagship conference, get engineers to list your paradigm on their LinkedIn.
If you position in an existing category (or re-segment):
Map the proprietary competitors cold, then turn your open-source nature into a weapon against them. Build a plain matrix of the buying criteria enterprises weigh (security, scalability, ease of use) and slip in at least one new criterion that only you win. “Extensibility via open code,” say, or “deployment portability.”
Don’t be shy about naming names. Your account executives should have a sharp “unlike Datadog, we…” or “unlike Snowflake, we…” loaded for every incumbent. Set the rules of the category, or you get filed under “cheap open-source clone.” That label is very hard to peel off.
There’s no universal right answer
There’s no universal right answer here; it depends entirely on your context. What isn’t optional is consistency. Pick the story and hammer it in every channel where developers actually hang out: Hacker News, your README, the analyst briefing. If you’re creating a category, repeat the new term until the market says it back to you. If you’re fighting inside an existing one, keep pounding on why open and transparent beats expensive and closed.
Pick that story early, while the open-source momentum is still building. The market hands its own label to anything that hesitates, and the default label is not a flattering one.