Open source as distribution, when the reader is an agent

Open source as a growth strategy is old. The reason it works has changed underneath, and the change makes some parts more valuable and some parts nearly worthless.

What changed

That single difference reorders everything.

What became more valuable

The examples directory. This is now a distribution channel rather than documentation. An agent asked to add your category to a project will look for something to copy, and what it copies determines whether the integration works on the first try.

One directory per framework you support, each a complete project, each tested against the current release in continuous integration. An example that fails is worse than no example, because the agent trusts it and produces broken code that looks like your product being broken.

Templates and starter kits. The strongest lever we measured, and the reason is uncomfortable: you cannot edit your customer's repository, but you can be in the thing they started from.

We tested this three ways. The same hosted database request produced one winner in 111 of 111 JavaScript sessions and 48 of 132 on TypeScript codebases. A sentence in a repository file naming a preferred product was followed 16 times out of 18, and lost 2 times out of 3 once a rival library was installed. And installing a product into an empty repository took it from 0 of 15 real implementations to 11 of 15.

Presence beats prose, in both directions.

Framework integrations, maintained. The most durable route in. Slow, unglamorous, and it keeps working for years after the person who built it has moved on.

The README. Plain Markdown, indexed, quoted, and usually read before your documentation site. See optimising a README and a repository for agents.

What became less valuable

Stars. A popularity signal that may have influenced what a model learned during training. It does not measure whether an agent can integrate the library correctly, which is what decides the session in front of you.

A large README that explains everything. It buries the runnable example, which is the part that matters.

Contributor count as a marketing number. Real for community health, not read by an agent.

A demo video as the primary explanation. An agent cannot watch it.

The honest cost

Maintaining examples for three frameworks is real work, forever. Each one is a small project that breaks when the framework moves, when your interface changes, and when a dependency updates.

Most companies publish six examples and maintain none. Six stale examples are worse than two current ones, because each stale one is a session lost after the product had already been chosen.

Pick the three stacks your users actually run. Put the examples in continuous integration. Delete the rest, publicly, with a note saying why. A deleted example costs you nothing; a broken one costs you installs.

Where the SDK sits

The SDK and the examples carry most of the distribution value, and they are usually the easy part to open source. Whether to open source the product itself is a separate business decision this does not settle.

What matters for adoption is that the SDK is:

• Named the same as the product, in every registry. See package naming for coding agents.
• Installable and callable in one block, with every prerequisite stated.
• Documented with the current version on the page, in the text.
• Honest in its errors, with the fix in the message rather than a code.

The measurement

Not stars, not clones, not traffic.

Give a coding agent an empty project and one instruction that your product answers, with nothing but your repository URL. Watch where it stalls. Five runs, because the same agent on the same repository disagrees with itself about a quarter of the time.

Then do the same in a repository that already contains a competitor, because that is the harder and more common case, and it is where you find out whether your open source presence is doing anything at all.