Skip to main content
Kevin Kho
Founder of KnitKnot.ai
View all authors

Why Gated Communities Eat Themselves

· 6 min read
Kevin Kho
Founder of KnitKnot.ai

I've watched the same story play out enough times that it barely surprises me anymore. A small community forms. It's good — really good. The people inside it share context, trust each other, and produce things none of them could produce alone. Then someone decides it needs to grow.

That's when it starts dying.

The Paradox

Gated communities — private Discord servers, invite-only forums, paid cohorts, closed beta programs, exclusive Slack groups — have a structural problem that no amount of good intentions can fix. The gate is what made the community work, and the gate is also what makes growth impossible without breaking the thing it was built to protect.

The logic for opening up is always reasonable. More people means more ideas, more energy, more connections, more revenue. The community has something valuable, and it feels selfish (or strategically stupid) to keep it locked away. So the gate opens — slowly at first, then faster.

What comes through the gate isn't malicious. It's just uninitiated.

The Density Problem

The core property that makes a small community work isn't shared values or shared interests. It's shared context. Everyone was there for the founding argument. Everyone knows why that one rule exists. Everyone remembers when the group tried the other thing and it didn't work. That shared history is invisible infrastructure — it lets people communicate in shorthand, resolve conflicts quickly, and align on what "good" looks like without spelling it out every time.

When you add new people faster than they can absorb that context, the density of shared understanding drops. Conversations that used to take two sentences now take two paragraphs. Disagreements that would have been resolved by "you know what we mean" turn into extended threads where everyone restates first principles. The community doesn't get worse because the new people are worse. It gets worse because the shared context that made it efficient got diluted past the point of usefulness.

This isn't a people problem. It's a physics problem. You can't compress three years of inside jokes and established norms into an onboarding doc.

The Quality Spiral

Here's where it gets self-reinforcing. As context density drops, the original members — the ones who built the shared understanding in the first place — start disengaging. Not because they're elitist (though some are), but because the experience got worse for them. The conversations they found valuable are harder to find. The signal-to-noise ratio shifted. So they participate less.

Their withdrawal accelerates the dilution. The people who held the cultural memory stop contributing to it. New members arrive into a community that looks the same on the surface but has lost the gravity that held it together. They interact with the shell — the name, the platform, the public-facing content — without ever encountering the substance that made the original group cohesive.

The community's reputation was built on the output of the original group. Now that output slows or stops, but the reputation persists on inertia. New people join expecting the thing they heard about and find something thinner. They either leave disappointed or stay and contribute to the version of the community that exists now — which is, by definition, less than what came before.

The Three Trajectories

I've seen gated communities that try to grow land in one of three places:

The museum. The original members left or went quiet. The community still exists — the Discord is still there, the Substack still posts — but it's curated by people who joined after the interesting part happened. It's a gift shop operating inside a building where the actual work got done years ago. New members wander through, sense that something's missing, and don't come back.

The crowd. The community kept growing and crossed the threshold where individual relationships stopped being load-bearing. It became a brand with an audience instead of a group with members. There's nothing wrong with audiences — I'm not romanticizing smallness for its own sake — but an audience isn't a community, and pretending it is creates confused expectations on both sides. The people who wanted a group feel let down. The people who wanted content get content. Everyone's talking past each other.

The split. The original members recognize what's happening and reform somewhere else, smaller and quieter. The old community becomes the public face. The real community went underground. This works for the people who made the jump. It doesn't work for anyone who was enjoying the old space and didn't get the memo. And it's fragile — the new, smaller group will eventually face the same pressure to grow, because the same logic applies. If the new thing is good, someone will want to scale it.

Why It Keeps Happening

Nobody sets out to ruin their community. The pressure to grow is almost always external. A community attached to a product needs more users. A community attached to a creator needs more subscribers. A community attached to a company needs more pipeline. The community's value gets captured in metrics that don't account for context density, and the optimization target becomes headcount rather than quality of interaction.

Even when the pressure is internal — founders who genuinely want to share something good with more people — the blind spot is the same. The thing that makes the community good is invisible to the people trying to scale it, because shared context doesn't show up in analytics. You can measure members, posts, and active users. You can't measure "how much do these people actually understand each other."

The Uncomfortable Answer

I don't think there's a clever hack for this. Every attempt I've seen to solve the growth-quality tradeoff in communities — tiered access, mentorship programs, extended onboarding, sub-groups within the larger whole — treats the symptom. The underlying dynamic is that context is finite and non-transferable at scale. You can't distill it. You can't compress it. You can't on-ramp people into it fast enough to outrun the dilution.

The communities I've seen stay good over time are the ones that accepted being small. They treated the gate not as a temporary barrier but as a structural feature. They grew slowly enough that new members could be absorbed rather than added. They said no to most people who wanted in, not out of elitism but out of respect for the people already inside.

That's a hard sell. Small means leaving impact on the table. Small means someone who'd genuinely benefit can't get in. Small means you're making a judgment call about who's worth the context investment, and that judgment will sometimes be wrong.

But the alternative isn't "small but with a growth strategy." The alternative is the quality spiral. The museum. The crowd. The split.

Growth isn't always wrong. But for a gated community, growth is always a trade — and the thing you're trading away is the reason anyone wanted in to begin with.

Open Source Isn't Dead, It Just Looks Unrecognizable

· 6 min read
Kevin Kho
Founder of KnitKnot.ai

Last week I was burning five or six dollars a day in API calls just to run a task tracker.

I'd been trying out KiloClaw, a managed OpenClaw offering, for some KnitKnot busy work like lead generation. Useful, but expensive. So I went to bring my own key from z.ai. It wasn't working. Fine, that's the deal with open source. You can usually fix things yourself.

After some debugging I traced it into the upstream OpenClaw repo. The API key wasn't being attached to outgoing requests. Maybe ten lines, plus a test. I opened a PR.

The Kilo team reviewed it. The OpenClaw team, nothing. I checked their queue: over 6,000 open PRs, dozens added that day. My ten lines weren't being ignored, they were just invisible. There's no human-scalable way to tell them apart from the AI-generated drive-bys around them.

Contributing Got Free, Reviewing Didn't

Daniel Stenberg, the creator of curl, has been the loudest voice on this. Curl is in your car, your TV, probably your fridge, and he's been running it since 1998. By mid-2025 only about 5% of bug bounty submissions were genuine vulnerabilities, with around 20% being obvious AI slop. He called it "death by a thousand slops" and a DDoS attack on the maintenance process. In January 2026 he killed the bounty entirely. Node.js tightened their requirements. The Internet Bug Bounty stopped paying out.

A few months after the shutdown, Stenberg said the slop had actually tapered off, but his burden went up anyway, because the AI-assisted reports got good. Plausible. Often correct. Coming in faster than ever. The problem was never that AI writes bad reports. The problem is that AI made contributing nearly free, and review didn't get any cheaper.

If curl can't survive the volume, my invisible PR isn't a story about one ignored fix. It's the same story, smaller.

Cal.com Goes Closed Source

Cal.com just went closed source after five years. The stated reason was security: AI scanners can now systematically read any open codebase looking for vulnerabilities, faster than human maintainers can patch them. They kept a community fork around and closed the production codebase.

I think the security framing is partly true and partly cover. The more pressing problem for a company like Cal.com is that anyone can now point an agent at their repo and build their own calendar system. Not even a competing product, just an internal tool. A scheduling system used to be the kind of thing you bought because building one yourself, even from open source, was more work than it was worth. Now an agent can read the whole repo, infer the architecture, and hand you something deployable in a few days. The friction that kept "use Cal.com" cheaper than "have my agent build me a Cal.com" was load-bearing for the business.

A lot of B2B SaaS sits in the same place. The product is well understood, the surface area is finite, and the moat was mostly that nobody wanted to build it themselves. That calculation is shifting.

Either way, the conclusion lines up. The economics of publishing your source code shifted, and one of the most visible open source companies looked at the new math and walked. Two years ago that would have been heretical. Now it just pencils.

The Code Was Never The Moat

There's a related point that the people building these things have started saying out loud.

Peter Steinberger, who built the viral OpenClaw project, was asked on TBPN how he feels about people copying his code. His answer: "Code is not worth that much anymore. You could just delete that and build it again in months. It's much more the idea and the eyeballs and maybe the brand that actually has value. So let them." He picked MIT. He's considering a foundation, not a company.

Chris Riccomini went further: open source projects are cached agent output. A repo is just a prompt someone else already paid for, materialized as code so you don't have to spend the time and tokens generating it yourself. Sometimes the repo is literally a prompt, like StrongDM's Attractor, which ships as a README that points a coding agent at it.

If the code is just cached output of a prompt anyone can re-run, then forking isn't betrayal, it's caching with edits. That used to be a nuclear option. Now it's Tuesday.

Cal.com and Peter looked at the same landscape and reached opposite conclusions. Peter's project is ideas; copying the code doesn't get you the thing. Cal.com is the product; the code more or less is the moat. Same landscape, different exposure.

Where I Landed

I gave up on the PR, and on OpenClaw entirely. Too many tokens, too bloated, and clearly nobody on the receiving end of my ten lines. If I can't get a critical bugfix in, the open source pitch stops working. I went with Zo Computer. Closed source, scoped, opinionated, and a direct line to someone who'll actually answer me. Open source in this space tends toward bloat or staleness anyway. Design by committee meets the pace of AI tooling, and a small closed tool with a real support channel sidesteps the whole tension.

I'll caveat all of this. I maintained Fugue for a few years, and at Prefect some of the most fun I had was encouraging people in the community to open a PR and feed it back. I met a lot of cool people that way. That part of open source is kinda gone now. I don't think you're hopping on the phone with maintainers anymore, and the thing it costs is the random connections that come from working on something with strangers who care. I don't know what replaces that. Discords, maybe. It's not the same.

What it looks like now is some mix of Peter's version (build in the open because it's fun, MIT it, don't owe anyone a governance process), Cal.com's version (open as a launchpad, close when the math changes), and Attractor's version (the repo is the prompt, the code is something you regenerate locally). All of them look unrecognizable next to open source from two or three years ago. I'm not going to pretend I prefer any of them. I closed the tab on my PR and moved on.