The Problem
Two years in, our open-source observability collector had 30,000 GitHub stars, an active Discord with 2,400 members, and an annual conference talk that sold out every year.
We had four paying customers. Combined ARR was $112,000.
The community loved us. The community also did not pay us. We'd built our cloud product as a hosted version of the OSS — same UI, same features, "managed for you." It turned out the kind of engineers who ran our OSS were exactly the kind of engineers who could keep running the OSS themselves.
We were watching our runway shrink while every "growth" metric outside revenue went up and to the right.
The Journey
Beacon started as a side project to scratch an itch — the OpenTelemetry collector at my old job had been a bottomless source of pain, and I thought I could do it better. I open-sourced the prototype on a Saturday. By Monday it had 1,200 stars.
Within three months I'd quit my job, my cofounder Mateus had joined from another infra team, and we'd raised a $4M seed. The deck was OSS-flywheel. Get a million users on the free tier, convert 1% to paid, scale.
The flywheel half-worked. Stars compounded. Adoption climbed. But conversion-to-paid was 0.013%, not 1%. The hosted version was a worse version of the open-source version, because the OSS had grown faster than the cloud product could keep up with.
We were running a free distribution channel for our own free product.
The Struggles
Mateus and I avoided talking about revenue for almost a quarter. Every time it came up, one of us would deflect with a community metric. "We hit 25,000 stars this month." "Our PR throughput is the highest it's ever been."
The quiet truth was that we'd built two products: an OSS that was world-class, and a cloud product that was a thin paint job over it. Anyone serious enough to buy the cloud product was serious enough to self-host.
The wake-up call was a Discord message from a director of platform engineering at a Fortune 200 company. He said, very politely: "We love Beacon. We've been running it in production for fourteen months. We've never paid you because there's no reason to. What would actually make us pay?"
We spent a week reading every Discord transcript from our top-100 deployments. We found the answer in the noise.
The Breakthrough
The thing every serious deployment struggled with wasn't running the collector — it was correlating data across teams. Different services, different owners, different naming conventions. The OSS handled the collection beautifully and then dropped you into a dashboard you had to wire up yourself.
We spent eight weeks building a service-graph and routing layer that lived only in the cloud product, never in the OSS. It was the first feature we ever shipped that the community could not have built themselves over a weekend.
We priced it at $1,200 per service per year. It launched on a Wednesday. By Friday we'd booked $44,000 in new ARR — more than we'd booked in the first nine months of the cloud product combined.
Within six months we'd added eighteen mid-market customers and our Fortune 200 director had signed a $260,000 multi-year contract. The OSS kept growing — past 50,000 stars — and now it served as a pre-qualifier for the buyers we actually wanted.
The Lessons
- 1OSS distribution is not an OSS business.
Stars are top-of-funnel. They have to convert into something a company will pay for, and that something almost certainly cannot live in the open repo.
- 2Don't compete with your own free product.
A "managed" version of OSS rarely creates buying urgency. Build something the community could not realistically build for itself in a week.
- 3Read your Discord like it's a research lab.
Our breakthrough was hiding in plain sight in transcripts we'd never sat down to read systematically.
- 4A polite paying customer asking "what would make us pay" is the most valuable signal in the world.
Treat it like an inbound research grant.
- 5Pricing per service / per workload tracks customer value.
Per-seat broke for us; per-service mapped exactly to the pain we were fixing.
