Market Engineering

"In proprietary SaaS, you hunt for customers. In COSS, you hunt for usage."

The fundamental error most COSS founders make is defining their market like a SaaS company. They buy lists of "VPs of Engineering" from ZoomInfo, hire SDRs to spam them with cold emails, and pitch a "solution" to a problem the buyer doesn't know they have.

This is a waste of capital. It is an attempt to push a boulder up a hill when you have a river flowing downhill right next to you.

In Commercial Open Source, your market is not defined by who might buy; it is defined by who is already using your code. Your software has already penetrated the market permissionlessly. It is running on servers you don't own, solving problems for users you haven't met.

Your Go-To-Market strategy does not begin with a marketing campaign. It begins with a Forensic Investigation of your install base.

Redefining TAM: From Logos to Workloads

Traditional VC decks calculate TAM (Total Addressable Market) based on "Total IT Spend" or "Number of Companies." You see slides that say: "There are 50,000 mid-market companies in the US. If 10% buy our software at $10k/year, our TAM is $50M."

This logic is flawed for COSS because it assumes the Customer Logo is the unit of value. In modern infrastructure, the unit of value is the Workload.

The New Metric: Total Addressable Workloads (TAW)

Stop counting companies. Start counting Compute.

In the cloud-native era, a single "customer" (like Uber, Netflix, or a massive fintech) might represent 10,000x the usage of a mid-sized bank. If you price by "seat" or "company," you leave 90% of the value on the table. If you price by "workload" (node, core, cluster, GB of ingest), your TAM expands exponentially with the customer's infrastructure.

SaaS TAM Thinking:

• "We sell to Banks."

• "There are 5,000 banks."

• "Average deal size is $50k."

• TAM: $250M (Capped by logos).

COSS TAW Thinking:

• "We sell to Kubernetes Clusters running high-frequency transaction logs."

• "There are 5 million CPU cores dedicated to this workload globally."

• "We capture $0.01 per core hour."

• TAW: $400M+ (Uncapped by infrastructure growth).

The "Shelfware" Antidote

Proprietary software often ends up as "shelfware"—sold but not used. COSS is the opposite: it is often "shadow-ware"—used heavily but not bought.

Your market definition process is not about finding people to sell to; it is about finding the shadow-ware that is already running in production and flipping it to commercial.

The COSS TAM Formula: Use your own telemetry (see Chapter 1: The Telemetry Mandate) to build a bottom-up model.

1. Estimate the Open Source Footprint:

• Take your total monthly downloads.

• Apply a Replacement Rate (e.g., 1 active node per 50 downloads, accounting for CI/CD noise).

• Result: Estimated Active Nodes globally.

• Apply the "Enterprise Ratio":

• Historically, only a fraction of open source users will ever convert to paid. This is the "Golden Ratio" of COSS.

• Benchmark: 3-5% of active open source users convert to paid in a healthy model. (If you target 100%, you are delusional. If you target 0.1%, you are a charity.)

• Calculate the Workload Value:

• (Active Nodes × Enterprise Ratio) × (Price per Node).

This number is your real TAM. It is dynamic. It grows every time a developer runs docker pull.

The "Shadow ICP": Defining the Dark Matter User

In traditional enterprise sales, you target the Economic Buyer (The CIO, the VP of Engineering). You map out the org chart, identify the budget holder, and try to get a meeting.

In COSS, the Economic Buyer often doesn't know you exist until the contract hits their desk. If you try to sell to them too early, they will reject you because they have no context.

Your true Ideal Customer Profile (ICP) starts with the Dark Matter User.

The Anatomy of the Dark Matter User

This is the Senior DevOps Engineer at a Fortune 500 company who docker pull'd your image three months ago.

• They do not fill out forms. They use ad-blockers and fake email addresses to get your whitepapers.

• They do not attend webinars. They learn by reading your documentation and source code.

• They do not want to talk to sales. They view salespeople as "friction" preventing them from solving a technical problem.

Yet, this person is the single most important asset in your sales cycle. They are the Internal Champion who has already deployed your software.

The "Trojan Horse" Profile

Your ICP isn't just "Company X." It is a specific technographic state within Company X. You are looking for a specific set of behaviors that signal Production Dependence.

Target Signal 1: The "Silent Scaling" Telemetry shows a user ID that started with 3 nodes (laptop/dev) and suddenly jumped to 50 nodes (production cluster).

• Meaning: They have moved from "playing" to "relying." They are now at risk if the software breaks.

Target Signal 2: The "Corporate Contributor" You see a Pull Request (PR) or an Issue filed from a corporate email domain (e.g., @jpmorgan.com).

• Meaning: This is not a hobbyist. They are fixing bugs on company time. This signals that the software is critical enough to warrant engineering investment.

Target Signal 3: The "Monday Morning Spike" Usage patterns that align strictly with business hours (9-5 M-F) and drop to zero on weekends.

• Meaning: This is a business workload, not a side project.

Strategic Pivot: Stop marketing to "Decision Makers." Market to "Practitioners with Problems."

• Your goal is not to sell the software to the Dark Matter User. Your goal is to arm them to sell it to their boss.

• Give them the ammunition: ROI calculators, "Security Architecture" whitepapers, and "Migration Guides" that they can forward to the VP of Engineering when the question of "Is this safe?" comes up.

Segmentation by Open Source Maturity

Demographic segmentation (Revenue, Employee Count, Vertical) is a blunt instrument. A $10B revenue retailer might have a tiny, unsophisticated engineering team, while a $50M revenue fintech startup might have a massive, complex infrastructure.

In COSS, you must segment by Open Source Maturity. This determines willingness to pay.

We classify the market into three distinct psychographic segments. You must treat them differently.

Segment A: The Builders (Low Conversion Probability)

These are the tech giants and elite engineering organizations (e.g., Meta, Google, Netflix, proprietary trading firms).

• Technographic Profile: They have armies of engineers. They contribute heavily to open source (Linux, Kubernetes). They run massive scale.

• Behavior: They download your code, read the source, fork it, and fix bugs themselves. They often build internal tools that are better than your commercial offering.

• Commercial Potential: Low. They prefer "Build" over "Buy." They view paying for software as a failure of engineering. They do not need your support because they likely know your code better than your junior engineers do.

• Strategy: Treat them as R&D Partners, not customers. Accept their PRs, feature them in case studies ("Used by Netflix"), and invite them to your Customer Advisory Board. Their logo gives you Social Proof, not revenue. Do not burn sales cycles trying to sell them a standard license.

Segment B: The Consumers (High Conversion Probability)

These are mainstream enterprises (Banks, Insurance, Retail, Healthcare, Logistics). They have money, but they lack engineering "depth."

• Technographic Profile: They use open source, but they treat it like a vendor product. They have strict compliance requirements (SOC2, HIPAA). They are terrified of "abandonware."

• Behavior: They download the software, but they get stuck on Day 2 operations (upgrades, scaling, security patching). They do not have 50 engineers to maintain a fork.

• Commercial Potential: High. They buy Insurance (Support, SLAs, Indemnification) and Governance (SSO, Audit Logs).

• Strategy: Sell them Risk Mitigation. Your pitch is: "You can use the free version, but who maintains it when your lead engineer quits? We do."

Segment C: The SMB / Hobbyist (Zero Conversion Probability)

These are early-stage startups, students, and indie hackers.

• Technographic Profile: Small scale. Low budget. High tolerance for risk.

• Behavior: They complain loudly in Discord about missing features in the free tier. They want "Enterprise" features (like SSO) for free.

• Commercial Potential: Zero. They will never pay you $50k/year.

• Strategy: Automate or Ignore. Do not let your sales team talk to them. Direct them to community forums. They are valuable for "noise" and top-of-funnel buzz, but they are a drain on CAC if you engage manually.

The COSSA Rule of Segmentation: Focus your direct sales efforts entirely on Segment B (The Consumers). Let Segment A build your product credibility. Let Segment C build your marketing buzz. But only Segment B pays the bills.

The "Beachhead" Strategy: Winning the "Sloppy Middle"

In Crossing the Chasm, Geoffrey Moore talks about the gap between Visionaries and Pragmatists. In COSS, the dynamic is slightly different.

You don't start with the "Visionaries" (Segment A), because they will just use the free code forever. You don't start with the "Laggards" (who only buy from IBM or Oracle).

You start with the "Pragmatists in Pain." These are the Segment B companies that are technically competent enough to adopt open source, but operationally stretched enough that they cannot maintain it.

Identifying the Beachhead

The ideal beachhead customer has three traits:

1. High Criticality: Your software is in the "Critical Path" of their revenue (e.g., the database for their checkout system). If it goes down, they lose money.

2. Low Resource: Their engineering team is underwater. They have a roadmap of product features they need to ship, and maintaining your open source project is a distraction.

3. Regulatory Pressure: They are in a regulated industry (Fintech, Healthtech) where "community support" is not an acceptable answer for an auditor.

The "Build vs. Buy" Wedge

Your sales pitch to this beachhead is not about "features." It is about Engineering Arbitrage.

The Pitch: "Mr. CIO, your team is currently spending 20 hours a month maintaining our open source database—patching, backing up, and troubleshooting. That is 240 hours a year of your most expensive engineers' time. That costs you roughly $150,000/year in fully loaded OpEx. Our Enterprise Cloud license is $50,000. We are selling you cheap engineering time so your team can go back to building your product."

This argument works because it aligns with the CIO's goal: Developer Velocity. You are not selling software; you are selling the removal of toil.

Operationalizing Market Definition

How do you turn this philosophy into a list of names for your sales team? You build a Technographic Intelligence Engine.

Step 1: Instrument the Signals

(See Chapter 1: The Telemetry Mandate). Ensure you have Scarf, LFX, and product telemetry flowing into a central data warehouse.

Step 2: Enrichment and Mapping

Take the raw IP addresses and domains from your telemetry and run them through enrichment tools (Clearbit, ZoomInfo). Map them to:

• Company Name

• Industry / Vertical

• Employee Count

• Technographic Stack (e.g., "Do they use Kubernetes? AWS? Datadog?")

Step 3: Scoring the "Open Source Maturity"

Look at their GitHub presence. Does this company have an Open Source Program Office (OSPO)? Do their engineers contribute to CNCF projects?

• High contributions = Segment A (Builder). Deprioritize for sales.

• Low contributions but high usage = Segment B (Consumer). High Priority Target.

Step 4: The "Surge" Alert

Create a dashboard that alerts Sales when a specific account crosses a "Production Threshold."

• Alert: "Account Home Depot just spun up their 50th node. Usage has been consistent for 90 days. No support contract exists."

• Action: This is a Qualified Lead. Not because they filled out a form, but because the physics of their usage proves they have a problem you can solve.

Summary Checklist

Before you hire a VP of Sales or launch a demand gen campaign, you must be able to answer these three questions with data, not guesses:

1. Can we see the Dark Matter? Do we have the telemetry to identify which Fortune 500s are using the free tier right now?

2. Do we know the Unit of Value? Are we pricing by "seats" (incorrect) or by "workloads" (correct)? Have we modeled the TAW based on compute?

3. Have we filtered the Builders? Does our sales team know not to call Google or Meta, and instead focus on the "Pragmatists in Pain" (Banks, Retailers, Healthcare)?

Strategic Directive: Market definition in COSS is not creative writing; it is data science. Stop imagining who your customer is. Look at the logs. They are already there.