samber/developer-relations-skills已通过检查
SKILL DETAIL
oss-distribution-strategy
samber/developer-relations-skills/oss-distribution-strategy
Designs an open-source project's ongoing distribution mix after the launch window - registry metadata, code-host discovery surfaces, curated lists, downstream packaging, extension and connector marketplaces, the release stream, dependency-graph position, creator seeding, and procurement trust signals - ranked against real maintainer capacity. Use whenever a maintainer asks how people will keep finding the project, which registries or awesome lists to target, why adoption flattened after launch, how often to release for visibility, or how to spend limited maintainer hours on distribution - even if they only say nobody is using it. Not the launch itself - use samber/developer-relations-skills@oss-launch. Not the build-in-public practice.
安装量 · 411查看来源
Installation
npx skills add https://github.com/samber/developer-relations-skills --skill oss-distribution-strategy
技能文件
SKILL.md
最近同步 · 2026年10月23日
evals/evals.json›
{
"skill_name": "oss-distribution-strategy",
"evals": [
{
"id": 1,
"prompt": "I maintain slipstream, an npm package for streaming CSV transforms. We did a Show HN back in March that got about 900 stars, downloads peaked around 11k/week and then settled at 3,400/week and haven't moved since. I've got maybe 5 hours a month. I want to get us onto more channels - I was thinking Dev.to cross-posts, a subreddit presence, and maybe 15-20 directory submissions to widen the net. Where do we start?",
"expected_output": "An audit of the distribution surfaces already running before any new channel is proposed, with a baseline snapshot taken first and the 15-20 directory submissions challenged.",
"files": [],
"expectations": [
"Runs a coverage audit of the distribution surfaces already in place before proposing any new channel.",
"Predicts the audit will surface a half-configured foundation channel (empty keyword slots, missing links, or a description predating the current positioning) plus two or three listings that are simply wrong.",
"States the audit fixes amount to roughly an hour of work in total and must be done before any new channel is added.",
"Explicitly declines to rank those audit fixes against each other, on the grounds that ordering one hour of mandatory work is false precision rather than a plan.",
"Tells the maintainer to snapshot the current baseline numbers with their date and source before changing anything.",
"Justifies the snapshot by noting repository traffic panels retain only a short rolling window, so an uncaptured baseline is unrecoverable.",
"Notes that npm search ranks on title, description, readme and keywords only, with no popularity or quality signal, so the wording is the whole lever.",
"Checks whether every keyword slot is filled and whether the documentation, repository, funding and issue-tracker link fields are present.",
"Separates coverage metrics (facts auditable today) from arrival metrics (behaviour read as a quarterly trend) when defining what to measure.",
"Warns that stars moving without downloads or cloners means an announcement travelled, not that distribution improved.",
"Declines the 15-20 directory submissions as proposed, naming either the recurring sweep cost or the damage done by stale listings.",
"Asks whether adopters are individual developers choosing for themselves or engineers who must get approval inside a company, before committing to a channel mix.",
"Withholds a final channel plan until the audit findings and the adopter-type answer are in hand."
]
},
{
"id": 2,
"prompt": "Quick one. We maintain tallowpy, a Python library for parsing fixed-width mainframe extracts. It installs with pip, about 4,800 downloads a month, mostly data engineers at insurance companies. A user opened an issue asking us to get it into Homebrew, and someone else wants a Debian package. My co-maintainer thinks it would make us look more legitimate. We have about 6 hours a month between us. Should we do it?",
"expected_output": "A written refusal of downstream system packaging for a library installed inside a virtual environment, with the four promotion conditions named and the refusal shaped so it does not come back next quarter.",
"files": [],
"expectations": [
"Refuses downstream system packaging for this project.",
"Grounds the refusal in the install unit: a library installed inside a virtual environment, not a standalone binary or container image.",
"Names all four conditions that would promote downstream packaging: company adoption as the declared goal, a standalone binary or container image install unit, release hygiene good enough for a third-party packager to hold it, and maintainer acceptance of the irreversibility.",
"States that downstream packaging is irreversible - a shipped distribution package cannot be recalled.",
"Writes the refusal as a named channel, a reason, and the condition that would reopen it, rather than as an omission or a 'not right now'.",
"Deletes downstream packaging from the ranking entirely rather than parking it at the bottom of a priority list.",
"Explains that a channel parked last gets re-litigated every quarter while a named refusal does not.",
"Rejects 'looks more legitimate' as a reason and makes no claim that packaging will increase downloads.",
"Classifies downstream packaging as a harmful-decay family: a stale package keeps shipping an old version to evaluators rather than going quiet.",
"Warns against treating a third-party package as owned, since the maintainer does not control it.",
"Recommends checking a cross-repository tracker such as Repology for packages that already exist without the maintainers knowing.",
"Points the maintainers at higher-efficiency families first (registry metadata and the release stream) and states the efficiency ordering out loud rather than implying it by list order."
]
},
{
"id": 3,
"prompt": "We built probe-lens, a VS Code extension that visualizes OpenTelemetry spans inline in the editor. It's been on the VS Code Marketplace for 7 months, 4,100 installs, growth is slow and steady but nothing exciting. Our team is two people, maybe 8 hours a month for this. I keep seeing people mention Cursor in our issue tracker. What should our distribution plan look like?",
"expected_output": "A dual-publish recommendation to Open VSX with the contractual reason named, the compatibility tax priced as the recurring cost, and the adoption test run on the new entry.",
"files": [],
"expectations": [
"Recommends dual-publishing to Open VSX alongside the Microsoft marketplace.",
"Explains that Microsoft's marketplace terms restrict use to Microsoft in-scope products, so every VS Code fork is contractually barred from it.",
"Names at least two editors that default to Open VSX from among Cursor, Windsurf, VSCodium and Gitpod.",
"States the extension is currently invisible to the AI-first editor segment the issue tracker already shows demand from.",
"Notes the VS Code Marketplace provides no first-party install-statistics dashboard.",
"Notes Open VSX is CI-publishable and carries a 256 MB binary limit.",
"Notes VS Code Marketplace ranking runs on installs, ratings and categories, and is criticized for not being install-weighted.",
"Classifies extension marketplaces as harmful decay: an extension incompatible with the host's current version reads as broken.",
"Identifies the recurring cost as a per-release compatibility tax against a host version the maintainer does not control.",
"Places extension marketplaces and connector hubs at the same rank on the efficiency order, and justifies the tie by their shared cost shape - vendor review gate, per-release compatibility tax, identical harmful decay - with audience the only difference.",
"Runs the adoption test on the Open VSX entry: recurring cost, decay behaviour, observable signal, kill date.",
"Warns against assuming one store covers the audience."
]
},
{
"id": 4,
"prompt": "I need to convince my VP of Engineering to fund two engineer-weeks of supply-chain work on our open source project girder - cosign signing, SLSA provenance, an SBOM per release, and pushing our OpenSSF Scorecard from 4.2 to above 7. She'll only approve it if it grows adoption. Can you help me build the case that this will increase downloads? We're at 180k monthly downloads on Maven Central and most of our users are at banks and insurers.",
"expected_output": "A refusal to build a growth case, replaced by a procurement-enablement case with the honest evidence limits stated and the correct observable signal named.",
"files": [],
"expectations": [
"Refuses to build the requested case that supply-chain work will increase downloads.",
"States that the link from Scorecard scores, artifact signing or SLSA provenance to downloads or adoption is unestablished.",
"Reframes the ask as risk mitigation and procurement enablement rather than a growth channel.",
"Notes that Sigstore's published totals have no control group, and that maturity and funding confound any apparent correlation.",
"Notes download counts are gameable, making them a weak outcome measure for this work.",
"Labels the 'Scorecard above 7' target as an adopted bar for enterprise review rather than a published standard, and says so when reporting it.",
"Names 'pitching trust work as growth' as a failure mode that sets up a failure the next security ask will pay for.",
"Points out that the stated audience of banks and insurers is a company-adoption path where trust signals rank near the top of value, even though they rank low on efficiency for individual adoption.",
"Gives the observable signal as enterprise evaluations that stop stalling, not as a download figure.",
"Warns that publishing a disclosure path means owing a disclosure SLA, an ongoing obligation rather than a one-time cost.",
"Notes trust signals carry a concentrated entry cost and a low recurring cost, and states which of the two it means when quoting a cost.",
"Mentions that EU Cyber Resilience Act obligations bind manufacturers rather than upstream maintainers, with pressure arriving as fix requests from downstream companies.",
"Promises no download lift anywhere in the recommendation."
]
},
{
"id": 5,
"prompt": "fennelwick hit 14,200 stars on GitHub in about eight months - we're in a bunch of awesome lists and we got two newsletter mentions. But weekly downloads are 2,100, the registry says 31 dependents, and neither has moved all year. Our Discord has 3,400 members and maybe 6 are active. How do we convert the star count into actual usage? I was going to do another round of newsletter outreach and try to get back on trending.",
"expected_output": "A diagnosis that the announcement travelled and the install did not, redirecting budget to onboarding rather than another awareness push.",
"files": [],
"expectations": [
"Diagnoses this as an onboarding problem rather than an awareness problem.",
"Recommends moving budget to documentation rather than adding another awareness channel.",
"States the pattern explicitly: high star velocity with flat usage and retention means the announcement travelled and the install did not.",
"Declines the proposed second round of newsletter outreach as the next move.",
"States that stars measure attention and promotion reach, not distribution.",
"Names downloads, dependents, unique cloners and issues from strangers as the measures of distribution.",
"Cites that roughly three out of four developers consider a project's star count before using or contributing, and that 36.7% starred a repository because they were already using it.",
"Notes the same evidence shows promotion drives star growth, so a star count measures reach as much as merit.",
"States that GitHub trending has no published specification and that the star-velocity explanation is folklore.",
"Notes GitHub's public events firehose stopped emitting most star events, which broke third-party star-based rankings, and treats external trending tools as unreliable.",
"Does not recommend adding badges as a growth lever, or states that a first badge produces only a small, non-sustained bump.",
"Pairs any star measurement with downloads or cloners rather than reporting stars alone."
]
},
{
"id": 6,
"prompt": "Our project barrowlite is a Go module, pretty much feature-complete - we shipped the last real change 9 months ago and it just works. Someone on our team read that projects should ship every two weeks to stay visible, and proposed we cut a release every second Friday even if it's only dependency bumps, so the registry shows recent activity. Two of us maintain it, about 3 hours a month. Thoughts?",
"expected_output": "A rejection of the mandatory minimum cadence, replaced by a maximum-interval commitment plus an explicit maintained-and-stable statement in the README.",
"files": [],
"expectations": [
"Rejects a mandatory minimum release cadence.",
"Recommends committing to a predictable maximum interval instead, phrased as a promise that a fix lands within N weeks.",
"Names the proposed fortnightly dependency-bump releases as cadence theater.",
"Explains that an empty calendar release becomes a noise pull request in every downstream repository.",
"Explains that noise releases train downstream maintainers to auto-merge or ignore the one channel that reaches existing users directly.",
"Lists at least three of the parties a release actually broadcasts to: dependency-update bots, packagers' pipelines, feed-harvesting newsletters, watchers, and evaluators reading the registry's last-published field.",
"Confirms the long silence does fail the liveness proxy evaluators read, even on a finished project.",
"Recommends the cheap correction: an explicit 'stable, maintained, low change rate' statement in the README.",
"States that security fixes ship out of band and fast, outside the cadence commitment.",
"States that small changes get batched into one readable release.",
"Treats cadence as a distribution decision and the changelog as a distribution asset.",
"Reserves named milestones - a 1.0, a rewrite, a rename - as the legitimate reason to return to awareness channels after the launch window."
]
},
{
"id": 7,
"prompt": "Honest constraint: I have about 3 hours a month for this, forever, and I'm the only maintainer. slatevane is a TypeScript library for form state, on npm, roughly 900 weekly downloads, all individual devs as far as I can tell. I want a real distribution plan - I was hoping for something like a quarterly rhythm with a newsletter push, a couple of integrations with popular frameworks, and getting into 3-4 curated lists. What does that look like scaled down to 3 hours?",
"expected_output": "A foundation-only mix in which the recurring-cost families are deleted rather than shrunk, with the test ring refused out loud and the capacity ceiling applied.",
"files": [],
"expectations": [
"Deletes the recurring-cost families outright rather than shrinking them to fit 3 hours.",
"States explicitly that a low hours ceiling deletes the per-release-tax families rather than reducing them.",
"Proposes a foundation-only mix and refuses the test ring out loud.",
"Drops creator and newsletter seeding, naming its recurring relationship cost and the fact that its payoff stops the month the pitching stops.",
"Drops or sharply caps the framework-integration plan, naming unbounded adapter sprawl a solo maintainer cannot keep green.",
"Keeps the set-once families: registry metadata, machine-readable surfaces, and dependency position once earned.",
"Applies the ceiling that total recurring cost must stay at or below 60% of declared monthly capacity, and gives the resulting figure against the 3-hour budget.",
"Labels that 60% ceiling as a self-set baseline rather than an industry standard.",
"Refuses or caps the curated-list plan, pricing the quarterly sweep against the 3-hour budget.",
"Warns that capacity shrinks when a project succeeds, because support load grows first, so the plan must fit the worst realistic month.",
"Presents two or three candidate mixes rather than a single plan.",
"Writes each refused channel with its reason and the condition that would reopen it."
]
},
{
"id": 8,
"prompt": "We're harrowbase, an Apache-2.0 embedded analytics engine, about 40k monthly downloads, mostly individual developers and small startups. Our docs are genuinely good - we get compliments on them unprompted. But we've had four separate conversations this year where an engineer at a bigger company (one bank, two insurers, a logistics firm) said they loved it, tried to get it approved internally, and it died somewhere. We want company adoption to be the growth story next year. Two maintainers, 20 hours a month combined, and there's a funding decision in March 2027. What's the distribution plan?",
"expected_output": "A procurement diagnosis that escalates the trust posture inside the first four weeks and builds a named-adopter wall, rather than adding awareness channels or more docs.",
"files": [],
"expectations": [
"Diagnoses the blocker as procurement rather than awareness.",
"Escalates the trust posture before adding any awareness channel.",
"Ships the trust posture inside the first four weeks alongside the foundation ring, rather than placing it later in the sequence.",
"Lists the minimum trust posture concretely, covering at least four of: signed releases, build provenance, a published SBOM, a SECURITY.md with a disclosure path, and an automated supply-chain score in CI.",
"Defines legibility as an approver being able to verify the license, versioning promise, security contact, release rhythm and artifact signatures without asking anyone.",
"Distinguishes the evaluator who finds the project from the approver who decides, and notes an artifact proxy or review board can block the install outright.",
"Applies the reference catch-22 named by Crossing the Chasm: pragmatic buyers want references from peers in their own segment, and none exist until someone adopts first.",
"Recommends a visible wall of named adopters in the target segment, and treats making existing usage visible as a distribution move rather than a vanity one.",
"States that one named company adopter beats a thousand anonymous downloads on this path.",
"Recommends the downstream-first mix, or otherwise ranks families using the company-adoption value ordering rather than the efficiency ordering.",
"Names the March 2027 decision as a hard date that promotes fast-acting families and demotes anything needing a full release cycle to reach an install path.",
"Cites the dependency-selection figures as stated preference rather than proven adoption drivers: maturity/stability 62%, usability 55%, documentation 51%, license 45%, active maintenance 44%.",
"Does not recommend more documentation work as the fix, given the docs are already strong."
]
},
{
"id": 9,
"prompt": "We built an open-source connector that pulls data out of our product into warehouses. Right now it lives in our own GitHub org as northreef/northreef-sync and about 60 people have cloned it. Our head of partnerships wants it listed in the big data-integration vendor's marketplace, and separately someone suggested publishing a Terraform module for provisioning it. Also we're seeing 14k downloads on a model hub for a small embedding model we ship alongside it, and leadership keeps comparing that number to our npm downloads. What should we actually do here?",
"expected_output": "Treats connector hubs as their own family, flags the support-tier label against the company-adoption goal, gives the Terraform naming rules, and rejects the cross-hub download comparison.",
"files": [],
"expectations": [
"Treats artifact and connector hubs as a family distinct from editor and plugin marketplaces, because the host is a data or infrastructure platform and the reviewer is the platform vendor.",
"Notes that inclusion is usually a pull request against the vendor's index repository, or a naming convention its crawler matches, rather than a store upload.",
"Warns that the evaluator sees a support tier next to the entry, which no editor store shows.",
"Warns that a community-built connector lands in a marketplace tier labelled as not maintained by the vendor with no support SLA, and that the label is part of what the evaluator reads.",
"Flags that entering a hub whose support tier advertises the project as unsupported works against a company-adoption goal.",
"States the Terraform Registry requires a public repository named terraform-<PROVIDER>-<NAME> with a standard module structure and semver tags.",
"Notes that the repository description becomes the module's short description on the Terraform Registry.",
"Warns that renaming the repository after listing silently breaks a naming-convention hub.",
"Rejects the comparison between the model hub's download number and the npm download number.",
"Explains that the model hub counts every GET or HEAD on a per-library set of query files, so a clone inflates the number while a cached run does not appear at all.",
"Notes that deduplicated request-level data is a paid publisher-analytics feature on that hub.",
"Identifies the recurring cost as a per-release compatibility tax against the host's version, with harmful decay when the host moves.",
"Runs the adoption test on each proposed hub entry: recurring cost, decay behaviour, observable signal, kill date."
]
},
{
"id": 10,
"prompt": "Blocking out this Saturday for a big push: I've got a list of 25 awesome-lists, ecosystem showcases and dev tool directories I want to submit pinmarrow to. It's a Python CLI for diffing OpenAPI specs, about 3 months old, 210 stars. I'll write one good 20-word description and paste it everywhere so it stays consistent. Can you help me prioritize the 25 and draft the submission text?",
"expected_output": "A refusal of the 25-submission sprint in favour of a small number of selected, maintained listings, with the list conventions and the reused-description trap named.",
"files": [],
"expectations": [
"Declines the 25-submission sprint as proposed.",
"Names spray-and-pray listings as a failure mode: twenty submissions in a weekend, all stale a year later.",
"States that three maintained surfaces outperform twenty and cost less.",
"Names reusing one description verbatim everywhere as a trap rather than a consistency win.",
"Applies a selection test to each candidate list, covering at least three of: do target developers browse it, is the link dofollow on a domain with real authority, was the list touched recently, are comparable projects listed, can arrivals be measured.",
"Notes the awesome-list convention that a project be at least 30 days old before being submitted upward.",
"States the bar is explicitly 'the best, not everything', excluding unmaintained, archived or thinly documented projects by policy.",
"Requires reading the target list's contributing file and its recent merged pull requests and matching the entry format exactly, because format failures are rejected before the project is judged.",
"Recommends contributing to the list first - dead-link fixes, other projects, section improvements - before self-submitting.",
"Prices the recurring cost at roughly 30-60 minutes per submission plus a sweep every quarter.",
"Classifies curated lists as actively harmful decay: dead links, old screenshots, superseded names.",
"Requires any stale listing already out there to be fixed or removed before a new channel is added, noting curated lists and distribution repositories drop projects that read as unmaintained by published policy."
]
},
{
"id": 11,
"prompt": "Two things. One: I want cloudferry (a Go CLI, 1,900 stars) to show up on GitHub's devops collection page and on the topic pages for kubernetes and gitops - I've already added those topics to the repo but we're not appearing anywhere. Two: we landed on trending for a day in June and it was our best week ever for clones. I want to engineer that again - what star velocity do we need inside a 24-hour window to get there?",
"expected_output": "Explains topic curation runs through github/explore with self-promotion barred, routes the submission through an ally, and refuses to give a trending star-velocity target.",
"files": [],
"expectations": [
"Explains that tagging a repository with a topic does not surface it until the topic itself is curated.",
"States that GitHub topics and collections are community-curated through pull requests to the github/explore repository.",
"States that self-promotion is explicitly disallowed there: the submission requires attesting the submitter is neither the sole author of the entry nor an employee of the company behind it.",
"Routes the submission through a community ally rather than a self-submission.",
"Notes that merges go live on a delay.",
"Names the required artifacts for a collection entry: a folder named for the URL slug, an index.md, and where applicable a 288x288 PNG under 75KB.",
"Refuses to give a star-velocity target for trending.",
"States that trending has no published specification and that the star-velocity explanation is folklore.",
"Notes GitHub's public events firehose stopped emitting most star, pull-request and issue events, which broke third-party star-based rankings.",
"Notes at least one third-party analytics provider withdrew its trending feature rather than publish numbers it could no longer trust.",
"Treats a trending appearance as a byproduct rather than a channel.",
"Ranks code-host discovery surfaces below registry metadata, the release stream and dependency position on efficiency, and states the ordering out loud."
]
},
{
"id": 12,
"prompt": "Full picture, here are the answers you'll want. Project: qualmstone, an Apache-2.0 Rust crate plus a standalone binary for replaying HTTP traffic against staging. Installs via cargo, or a downloaded binary. Two maintainers, 12 hours a month total, and that's the honest forever number - nobody else can execute any of it. Adopters today are individual SREs; we want platform teams inside companies next. No hard deadline. We want something that keeps paying without us re-spending, we've had enough one-off wins. Already in place: a crates.io page, the GitHub repo, one accurate awesome-list entry. Nothing packaged downstream. 7,900 monthly crate downloads, 61 dependents, 340 unique cloners last fortnight. Off-limits: no paid placements, and neither of us will do podcasts. Give me the plan.",
"expected_output": "Two or three ranked candidate mixes, a three-stage sequence with seeding last and the trust posture in stage 1, delivered section by section with a threshold check at the end.",
"files": [],
"expectations": [
"Presents two or three candidate mixes rather than a single plan, and recommends one with a stated reason.",
"Gives each mix a cost in hours per month, the adopter type it serves, and what it gives up.",
"Ranks the mixes out loud on efficiency, effort, and value for individual and company adoption separately, rather than letting presentation order imply a ranking.",
"States the family efficiency ordering out loud rather than implying it through list order.",
"Sequences the plan in three stages: foundation in weeks 1-4, passive discovery over months 1-3, active seeding ongoing.",
"Places active seeding last and gates it on stages 1 and 2 holding first.",
"Drops or demotes creator and newsletter seeding on the stated compounding mandate, because its payoff stops when the pitching stops.",
"Notes the open horizon with no hard date favours compounding families over fast-acting ones, and names which interview answer moved which family.",
"Checks the two unresolved downstream-packaging conditions - release hygiene sufficient for a third-party packager, and maintainer acceptance of irreversibility - before promoting that family, given the standalone-binary install unit and the company-adoption goal.",
"Runs the adoption test on every candidate channel: recurring cost, decay behaviour, observable signal, kill date.",
"Ships the trust posture inside stage 1 because company adoption is a declared goal, rather than adding it later in the sequence.",
"Produces the plan under the named section headings: Position today, Adopter, Foundation ring, Sequence, Test ring, Core channel, Refused, Release rhythm, Review, Threshold check.",
"Presents the sections one at a time for agreement rather than delivering the whole plan in a single pass.",
"Reports the threshold check explicitly, keeping total recurring cost at or below 60% of the 12-hour capacity and labelling the self-set thresholds as adopted bars rather than industry standards."
]
}
],
"trigger_queries": [
{
"query": "Our downloads have been flat for six months since the launch post - where do people even find us now?",
"should_trigger": true
},
{
"query": "How should we spend 5 maintainer hours a month getting our open source project in front of people?",
"should_trigger": true
},
{ "query": "Which awesome lists should we target for our Rust crate?", "should_trigger": true },
{ "query": "Should our CLI be in Homebrew?", "should_trigger": true },
{ "query": "We ship a VS Code extension - is one marketplace enough?", "should_trigger": true },
{ "query": "Nobody is using our library and I don't know why.", "should_trigger": true },
{
"query": "What's the right ongoing distribution mix for an open source project?",
"should_trigger": true
},
{
"query": "Our connector lives on our own GitHub. Should it be in the vendor's hub?",
"should_trigger": true
},
{
"query": "How often should we cut releases so people don't think the project is dead?",
"should_trigger": true
},
{ "query": "Will an OpenSSF Scorecard above 7 grow our downloads?", "should_trigger": true },
{ "query": "We get lots of stars but almost no installs. What do we do?", "should_trigger": true },
{ "query": "Should we get packaged into Debian and Fedora?", "should_trigger": true },
{ "query": "How do I get my Terraform module discovered?", "should_trigger": true },
{
"query": "Our PyPI page is basically empty - does that actually cost us anything?",
"should_trigger": true
},
{
"query": "I want to submit our project to 20 developer directories this weekend. Help me prioritize.",
"should_trigger": true
},
{
"query": "How do we keep people finding the project month after month, not just at launch?",
"should_trigger": true
},
{
"query": "Which registries and lists should we be on for a Go module?",
"should_trigger": true
},
{
"query": "Enterprise evaluations keep dying before anyone installs our open source tool.",
"should_trigger": true
},
{
"query": "Should we claim our package name on registries we don't actually publish to?",
"should_trigger": true
},
{
"query": "How do we get into the dependency graph of bigger projects in our ecosystem?",
"should_trigger": true
},
{ "query": "What star velocity do we need to hit GitHub trending?", "should_trigger": true },
{
"query": "Our Debian package is two years out of date and users are filing bugs against it.",
"should_trigger": true
},
{ "query": "We're on npm but nobody finds us in npm search.", "should_trigger": true },
{ "query": "Adoption flattened right after the Show HN. What now?", "should_trigger": true },
{
"query": "How do we make our project installable inside companies that block public registries?",
"should_trigger": true
},
{
"query": "What channels keep bringing new users to an open source project after the launch window closes?",
"should_trigger": true
},
{ "query": "I have 3 hours a month. Give me the plan.", "should_trigger": true },
{ "query": "Should we publish to Open VSX as well?", "should_trigger": true },
{ "query": "Is it worth getting listed on the dbt package hub?", "should_trigger": true },
{
"query": "We want company adoption next year - where should the distribution effort go?",
"should_trigger": true
},
{ "query": "How do I decide which of these channels to do first?", "should_trigger": true },
{
"query": "Our project is feature-complete and hasn't shipped in 9 months. Does that hurt us?",
"should_trigger": true
},
{
"query": "Can you audit where our open source project currently shows up?",
"should_trigger": true
},
{
"query": "We're comparing our Hugging Face downloads to our npm downloads - which one is bigger?",
"should_trigger": true
},
{
"query": "What should we measure to know whether our open source reach is improving?",
"should_trigger": true
},
{ "query": "Should we do a newsletter push every release?", "should_trigger": true },
{ "query": "How do we get onto the GitHub topic page for kubernetes?", "should_trigger": true },
{
"query": "My co-maintainer wants to do a relaunch push every quarter. Is that sane?",
"should_trigger": true
},
{
"query": "We have a Grafana plugin - should it go in the official catalog?",
"should_trigger": true
},
{
"query": "Where do Python developers actually discover libraries like ours?",
"should_trigger": true
},
{ "query": "How do I stop our listings going stale everywhere?", "should_trigger": true },
{
"query": "Which is worth more per hour: fixing our registry page or writing another blog post?",
"should_trigger": true
},
{ "query": "Our fork is more popular than our repo. What do we do?", "should_trigger": true },
{
"query": "Plan the next two quarters of getting our open source tool in front of more engineers.",
"should_trigger": true
},
{ "query": "Should we build integrations with 12 frameworks or 2?", "should_trigger": true },
{
"query": "I want a channel portfolio for our OSS project with costs and kill dates.",
"should_trigger": true
},
{
"query": "What's the highest-leverage thing a solo maintainer can do for reach?",
"should_trigger": true
},
{ "query": "Is being on more package managers actually worth it?", "should_trigger": true },
{
"query": "We keep getting told to do more marketing, but we're a library, not a product.",
"should_trigger": true
},
{ "query": "How do we make it obvious that the project is still maintained?", "should_trigger": true },
{ "query": "Our crates.io keyword slots are empty. Is that a real problem?", "should_trigger": true },
{
"query": "Should we sponsor a newsletter slot or try for an editorial mention?",
"should_trigger": true
},
{
"query": "How do I know which channel actually brought someone to the project?",
"should_trigger": true
},
{ "query": "We just renamed the project. What breaks on the distribution side?", "should_trigger": true },
{
"query": "I need a written plan I can run without you for getting our OSS adopted.",
"should_trigger": true
},
{ "query": "Is it better to be listed everywhere or deep in one ecosystem?", "should_trigger": true },
{ "query": "How much of my maintainer time should distribution work take?", "should_trigger": true },
{ "query": "Which of our channels should we stop doing?", "should_trigger": true },
{ "query": "We shipped a Raycast extension - how do we get it into the store?", "should_trigger": true },
{
"query": "An engineer at a bank loves our tool but can't get it approved. What's the fix on our side?",
"should_trigger": true
},
{
"query": "Our Airbyte connector sits in the marketplace tier - does that matter?",
"should_trigger": true
},
{
"query": "What does a realistic quarterly review of our OSS channels look like?",
"should_trigger": true
},
{ "query": "We want compounding reach, not another spike.", "should_trigger": true },
{ "query": "Do README badges help adoption?", "should_trigger": true },
{
"query": "How do I choose between packaging, listings, and integrations with limited time?",
"should_trigger": true
},
{
"query": "What should we do differently now that AI editors are a separate install base?",
"should_trigger": true
},
{
"query": "Our project shows up nowhere when people search inside their package manager.",
"should_trigger": true
},
{ "query": "How do we build a used-by wall, and is it worth the effort?", "should_trigger": true },
{ "query": "We can only sustain one channel forever. Which one?", "should_trigger": true },
{
"query": "Two years in, growth is flat and I'm out of ideas for getting the project in front of people.",
"should_trigger": true
},
{
"query": "Write the announcement blog post for our 1.0 open source launch.",
"should_trigger": false
},
{ "query": "Plan our Show HN launch day, hour by hour.", "should_trigger": false },
{
"query": "We're open sourcing the repo next month - what has to be ready before we flip it public?",
"should_trigger": false
},
{
"query": "Should I post a weekly shipping log about what I'm building?",
"should_trigger": false
},
{ "query": "Is it a mistake to publish our MRR publicly?", "should_trigger": false },
{ "query": "Turn these 47 commits into release notes.", "should_trigger": false },
{
"query": "Rewrite our README so a stranger understands the project in 30 seconds.",
"should_trigger": false
},
{
"query": "Make our SDK docs something a coding agent can integrate from unattended.",
"should_trigger": false
},
{ "query": "Write an llms.txt for our documentation site.", "should_trigger": false },
{
"query": "Who gets commit rights, and how do we vote on contentious changes?",
"should_trigger": false
},
{ "query": "Should we license this AGPL-3.0 or Apache-2.0?", "should_trigger": false },
{ "query": "Set up our GitHub Sponsors tiers and their rewards.", "should_trigger": false },
{
"query": "Which open source projects should our company fund next year?",
"should_trigger": false
},
{ "query": "Write our CONTRIBUTING.md and pick the good first issues.", "should_trigger": false },
{ "query": "We have 430 open issues and no triage system.", "should_trigger": false },
{
"query": "Should our developer tool be open core or a proprietary SaaS?",
"should_trigger": false
},
{ "query": "Should we price on seats or on consumption?", "should_trigger": false },
{ "query": "What should we open source and what should stay closed?", "should_trigger": false },
{
"query": "Should we join the working group for this protocol or just implement it?",
"should_trigger": false
},
{ "query": "Should we let partners build plugins on our platform?", "should_trigger": false },
{ "query": "Our docs site pages aren't getting indexed by Google.", "should_trigger": false },
{ "query": "Find keyword targets for our error-message pages.", "should_trigger": false },
{ "query": "What DevRel metrics should we report to the CEO?", "should_trigger": false },
{ "query": "Set up event tracking across our docs and blog.", "should_trigger": false },
{
"query": "Which conferences should we sponsor next year, and at what tier?",
"should_trigger": false
},
{ "query": "Pitch our funding round to tech reporters.", "should_trigger": false },
{ "query": "Should we start a Discord or a forum?", "should_trigger": false },
{ "query": "Write a blog post explaining our new storage engine.", "should_trigger": false },
{ "query": "Write the v2 migration guide for our breaking changes.", "should_trigger": false },
{ "query": "Optimize my personal GitHub profile README.", "should_trigger": false },
{
"query": "Write a quickstart that gets someone to first success in five minutes.",
"should_trigger": false
},
{ "query": "Audit our documentation against Diataxis.", "should_trigger": false },
{ "query": "Design an unpaid developer champions program.", "should_trigger": false },
{ "query": "Write a CFP abstract for a cloud-native conference.", "should_trigger": false },
{ "query": "Outline my 25-minute conference talk.", "should_trigger": false },
{ "query": "Prep me for a podcast interview next week.", "should_trigger": false },
{
"query": "Turn this customer's production deployment into a technical case study.",
"should_trigger": false
},
{ "query": "Plan our DevRel content calendar for Q3.", "should_trigger": false },
{ "query": "How do I break into developer advocacy from engineering?", "should_trigger": false },
{
"query": "Write the job posting and scorecard for a developer advocate role.",
"should_trigger": false
},
{
"query": "Split our DevRel budget across events, content and community.",
"should_trigger": false
},
{
"query": "Benchmark a competitor's developer relations motion against ours.",
"should_trigger": false
},
{ "query": "Cut our developer audience into named, sized segments.", "should_trigger": false },
{ "query": "Map the developer journey from discovery through advocacy.", "should_trigger": false },
{ "query": "Should we build a certification program for our platform?", "should_trigger": false },
{
"query": "Write our code of conduct and the enforcement ladder behind it.",
"should_trigger": false
},
{ "query": "Which community health metrics are worth tracking?", "should_trigger": false },
{ "query": "Write a shooting script for a screencast about our CLI.", "should_trigger": false },
{ "query": "Make sure the live demo doesn't break on stage.", "should_trigger": false },
{ "query": "Start a monthly developer meetup in our city.", "should_trigger": false },
{ "query": "Turn our support tickets into error reference pages.", "should_trigger": false },
{
"query": "Define the policy every code sample in our docs has to meet.",
"should_trigger": false
},
{ "query": "Write a teaching tutorial for our SDK.", "should_trigger": false },
{ "query": "Which function should DevRel report into?", "should_trigger": false },
{
"query": "Build our engineering employer brand to attract backend hires.",
"should_trigger": false
},
{
"query": "Design the bottom-up self-serve motion for our developer product.",
"should_trigger": false
},
{ "query": "What should our developer relations strategy be next year?", "should_trigger": false },
{ "query": "Which DevRel newsletters and podcasts should I follow?", "should_trigger": false },
{
"query": "Configure npm publish in our GitHub Actions release workflow.",
"should_trigger": false
},
{ "query": "Write the RPM spec file for our package.", "should_trigger": false },
{ "query": "Set up semantic-release so versions bump automatically.", "should_trigger": false },
{ "query": "Our npm publish token expired - how do I rotate it?", "should_trigger": false },
{ "query": "Someone typosquatted our package name on npm. What now?", "should_trigger": false },
{ "query": "What's the practical difference between MIT and BSD-3-Clause?", "should_trigger": false },
{
"query": "Plan the content distribution calendar for our marketing videos.",
"should_trigger": false
},
{ "query": "Set up a CDN and cache headers for our static assets.", "should_trigger": false },
{
"query": "Distribute our internal desktop app to employees through MDM.",
"should_trigger": false
},
{ "query": "How do we handle a CVE reported against our library?", "should_trigger": false },
{ "query": "Enable Dependabot and configure the update schedule.", "should_trigger": false },
{
"query": "Draft a contributor license agreement for external contributions.",
"should_trigger": false
}
]
}
references/channel-catalog.md›
# Channel catalog
Eleven families of ongoing distribution channel. Widen the outer ring with this, then rank candidates with the adoption test (recurring cost, decay behaviour, observable signal, kill date).
Registry policies, marketplace terms and list rules change without notice - verify on the surface's own documentation before planning around any detail here.
The numbering is a table of contents, not a ranking. The efficiency order, the per-axis breakdown, the ties, what that order starves and the conditions that reorder it all live in SKILL.md step 2; do not re-derive an order from these section numbers.
---
## 1. Registry presence and metadata
**What it is** - the project's page on each registry it publishes to, and the fields that page renders. It rewards findability inside the registry's own search and legibility for the evaluator landing there; the registry page, not the repository, is where most library evaluations start.
**Mechanics worth knowing**
- npm ranks search on title, description, readme and `keywords` only - no popularity/quality signal, just spam and new-package deprioritization; downloads and dependents are user-chosen sort options. New packages take up to two weeks to appear. Wording is the whole lever.
- crates.io caps `keywords` at 5 (20 ASCII chars each) and `categories` at 5, from the fixed slug list at `crates.io/category_slugs`; `description` is required plain text, `documentation` falls back to docs.rs.
- pkg.go.dev surfaces best-practice signals - `go.mod`, a detected redistributable license, a tagged version, a stable v1+ - and generates docs from exported-symbol comments, so those comments are the marketing copy.
- Other registries (PyPI classifiers, container verified-publisher tiers, chart and module registries) expose their own subset - confirm before planning.
- **Cost** - an hour to fix, minutes per release to keep.
- **Decay** - silent but harmful: a description written before the rewrite misleads every visitor.
- **Signal** - registry downloads, registry-referred sessions.
- **Traps**:
- Empty keyword slots.
- A description in the project's invented vocabulary instead of the problem's.
- Missing link fields (docs, repository, funding).
- Placeholder packages claimed in registries the project doesn't ship to, which read as abandonware.
## 2. Code-host discovery surfaces
**What it is** - the forge's own discovery mechanics, tended on a recurring cadence rather than spiked at launch: topic and collection pages, trending, repository search metadata, the social preview image, Discussions, the releases feed, sponsor and org profiles.
**Mechanics worth knowing**
- GitHub topics and collections are community-curated through pull requests to `github/explore`: a folder named for the URL slug, an `index.md`, and where applicable a 288×288px PNG under 75KB. **Self-promotion is explicitly disallowed** - the PR template requires attesting the submitter is neither sole author of the entry nor an employee of the company behind it. Merges go live on a delay, and tagging a repository with a topic does not surface it until the topic itself is curated.
- Trending has no published specification; the star-velocity explanation is folklore. GitHub's public events firehose stopped emitting most star, PR and issue events, which broke third-party star-based rankings; OSSInsight withdrew its trending feature rather than publish numbers it could no longer trust. Treat external trending tools as unreliable.
- **Cost** - low per surface, but the curation route requires finding an advocate.
- **Decay** - slow and mostly silent; a stale social preview or an abandoned Discussions tab is a mild negative.
- **Signal** - referrals from topic pages, repository visitor sources.
- **Traps** - self-submitting a topic entry and getting the PR closed; treating a trending appearance as a channel rather than a byproduct.
## 3. Curated lists and directories
**What it is** - awesome-lists, ecosystem showcases, category directories, comparison sites. It rewards inclusion in lists a real audience browses, with durable long-tail arrivals rather than a spike.
**Mechanics worth knowing**
- The `sindresorhus/awesome` rules sub-lists inherit in spirit: 30+ days old before submitting upward, passes `awesome-lint`, not AI-generated, carries a Contents table, `contributing.md`, the awesome badge and a Creative Commons license (CC0 recommended). Entries take one fixed shape, `- [Name](URL#readme) - Description.` The bar is explicitly "the best, not everything", excluding unmaintained, archived or thinly documented projects by policy.
- For any target list, read its `contributing.md` and last merged PRs, match the entry format exactly, place it in the right section. Format failures are rejected before the project is judged.
- Contributing first - dead-link fixes, other projects, section improvements - improves the reception of a later self-submission and costs less than it.
- Wait for independent usage before submitting - real stars, issues opened by strangers, an outside contributor - not the week it ships. "The best, not everything" is judged against comparable already-listed projects, and a zero-traction repo reads as unproven no matter how well the entry is formatted.
**Selection test** - do target developers browse it; is the link dofollow on a domain with real authority; was the list touched recently; are comparable projects listed; can arrivals be measured.
- **Cost** - 30-60 minutes per submission, plus a sweep every quarter.
- **Decay** - actively harmful: dead links, old screenshots, superseded names.
- **Signal** - referral arrivals per listing.
- **Traps**:
- Generic directories that accept anything.
- Abandoned lists.
- Paid placement with no visible audience.
- One description reused verbatim everywhere.
- Submitting a brand-new, zero-traction project - rejected on the "best, not everything" policy even when the PR itself is well-formed.
## 4. Downstream packaging and mirrors
**What it is** - system package managers, distribution repositories, container and chart registries, corporate artifact proxies, regional mirrors, community forks. It rewards being installable with the command the user already types, inside networks the maintainer cannot reach directly.
**Mechanics worth knowing**
- Homebrew's `homebrew-core`, at last check, requires an upstream-declared stable version with an immutable tag or release verified by SHA-256, forbids downstream-only patches, and pushes binary-only proprietary software to a cask. Historic numeric notability thresholds are no longer stated - read the current policy rather than repeating folklore.
- The fallback below that bar is a self-owned tap/PPA/COPR/overlay: instant and fully controlled, but a far weaker discovery surface - nobody browses a private tap.
- Packagers adopt what is cheap to package: immutable release tarballs with checksums, semantic versions, no build-time network fetches, a documented build, a clear license, a predictable cadence.
- Repology tracks 300+ repository families (325k+ projects, 4.9M+ package entries) and shows which carry a current or outdated version - including copies the maintainer never knew existed.
- **Cost** - high to enter (policy, review, packaging), low to hold if upstream release hygiene is good.
- **Decay** - harmful and partly outside the maintainer's control: users judge the project on a version shipped a year ago.
- **Signal** - repositories carrying a current version; support questions naming a distro package.
- **Traps** - treating someone else's package as owned; letting a fork or regional mirror become the de-facto install and quietly capture the project's users and bug reports.
## 5. Extension and plugin marketplaces
**What it is** - editor, IDE, browser and app-host stores: browsed inside a tool's UI, gated by a review the maintainer does not control, ranked by mostly undocumented mechanics.
**Mechanics worth knowing**
- **VS Code Marketplace** - ranks on installs, ratings, categories (criticized as not install-weighted); verified-publisher setup, no heavy manual gate; largest reach but **no first-party install-stats dashboard**.
- **Open VSX** (Eclipse Foundation) - ranks on downloads, same extension format; 256 MB binary limit, CI-publishable; the default store for Cursor, Windsurf, VSCodium, Gitpod.
- **JetBrains Marketplace** - ratings, reviews, downloads; manual review normally 2 business days with **no guaranteed SLA**; `since-build`/`until-build` ranges are the recurring tax.
- **Chrome Web Store** - engagement and ratings, Manifest V3 required, variable review latency, strictest rules: build for Chrome first and port down. **Firefox AMO / Edge Add-ons** use similar signals and are author-managed; Firefox's different MV3 stance makes porting a real decision.
- **PR-gated app stores** - Obsidian community plugins (PR to `obsidian-releases`, automated scan then manual review, auto-updates from releases) and the Raycast Store (community-manager approval; PRs go stale after 14 days, closed after 21).
**The Open VSX decision.** Microsoft's marketplace terms restrict use to Microsoft in-scope products, so every VS Code fork is contractually barred from it. Cursor migrated to Open VSX in mid-2025 and proxies search itself. A Microsoft-only extension is invisible to the AI-first editor segment - dual-publish from day one.
- **Cost** - listing metadata plus per-store review latency and version-compatibility maintenance.
- **Decay** - harmful: an extension incompatible with the host's current version reads as broken.
- **Signal** - installs per store, ratings, compatibility coverage.
- **Traps** - assuming one store covers the audience; ignoring compatibility ranges until users file the issue.
## 6. The release stream
**What it is** - tags, releases and changelogs as a recurring broadcast to people who already know the project. Recipients and cadence rules: SKILL.md step 6.
**Branch mechanics** - long-term-support or maintenance branches are what conservative company adopters need before committing; pre-release channels serve early adopters without destabilizing the default install.
- **Cost** - release hygiene the project should have anyway, plus writing notes.
- **Decay** - a silence is read as abandonment even by a finished, stable project; the cheap correction is an explicit "stable, maintained, low change rate" statement.
- **Signal** - downstream bot PRs merged, release-page views, version adoption spread.
- **Traps** - cadence theater (dependency bumps announced as features, version inflation); releases with unreadable or absent notes, which waste the broadcast.
## 7. Integration and dependency-graph surface
**What it is** - being reachable from software the user already runs: adapters for adjacent frameworks, first-class support inside a popular host, official examples in someone else's docs, a direct or transitive dependency of a widely used project. It rewards inherited distribution - one adapter inside a popular framework can outperform every listing combined, because it puts the project on the default path instead of a page someone must find.
**Mechanics worth knowing**
- deps.dev (Google Open Source Insights) computes transitive graphs and inverse dependent sets across Go, Maven, PyPI, npm, Cargo and NuGet, with full dependent sets queryable via BigQuery. Complementary: the code host's dependency graph and "used by" badge, Libraries.io, Ecosyste.ms. Closed-source usage is invisible to all of them by deps.dev's own caveat, so a low public dependents count is not evidence of low adoption.
- Only 27.5% of npm packages are depended on by any other package (Wittern et al., MSR 2016). Entering that depended-upon core is a structural advantage, and it is the only family that keeps generating discovery with zero recurring maintenance once earned - it decays only if the hub project is replaced.
**How it is pursued** - find the highest fan-in hub projects in the niche, target adoption or a first-class adapter with each, contribute upstream where the host accepts it, and ask satisfied users who already wrote glue code to upstream it.
**The attribution trade-off** - transitive dependents deliver usage without mindshare; a developer three layers downstream may never learn the name. Counter with a "used by" wall, restrained runtime or console attribution, case studies naming downstream adopters. High fan-in with low visibility also produces outsized issue load.
- **Cost** - high and recurring per integration; near zero to hold a dependency position once earned.
- **Decay** - harmful for adapters, negligible for dependency position.
- **Signal** - dependents count, arrivals referred by the host project's docs.
- **Traps** - building integrations for hosts with no shared audience; unbounded adapter sprawl a solo maintainer cannot keep green.
## 8. Recurring creator and newsletter seeding
**What it is** - the ongoing relationship with 3-5 newsletter curators and podcast hosts, distinct from the launch pitch: embargoed news, major-version demos and case studies on a calendar, keeping the project in front of the audience between launches.
**Mechanics worth knowing**
- The channel is concentrated. Newsletters: Cooperpress (JavaScript Weekly - 179,077 subscribers per its Q3 2024 media kit - Golang Weekly, Node Weekly, Ruby Weekly, Frontend Focus, React Status), plus TLDR, Bytes, Python Weekly, Console.dev, Changelog News, This Week in Rust. Podcasts: Changelog, Software Engineering Daily, Syntax, JS Party, Go Time, Rustacean Station, Talk Python.
- Curators hand-write descriptions and state "signal over noise" as the editorial bar. Editorial picks and paid sponsorship slots are structurally different purchases and must be labelled differently.
- What gets sent matters: an embargo, a live demo, a sandbox or a sample repo - never an announcement with no way to try the thing.
- **Cost** - the highest recurring cost of any family here, and relationship work that cannot be handed to whoever is free.
- **Decay** - the relationship decays, not the artifact.
- **Signal** - newsletter signups and monthly active developers as leading indicators, paired with an activation metric such as time to first successful use.
- **Traps** - conflating sponsored placement with earned coverage, burning a relationship that took years to build; pitching per release instead of on a quarterly calendar.
## 9. Trust and procurement signals
**What it is** - signed releases, build provenance, published SBOMs, a documented disclosure path, an automated supply-chain score. Levers: Sigstore/cosign keyless signing, SLSA provenance, npm provenance attestations, SPDX or CycloneDX SBOMs, the OpenSSF Scorecard's 18+ checks producing a 0-10 score. It rewards clearing procurement, not getting discovered: artifact proxies and allowlists gate what developers can pull at all, review boards validate an SBOM against a baseline, and Scorecard data surfaces inside dependency-review tooling and deps.dev.
**The honest framing** - the link from these signals to downloads or adoption is unestablished; independent sampling found low provenance uptake, Sigstore's totals have no control group, and download counts are gamed. Present this as risk mitigation and procurement enablement, never a download lift.
**Regulatory context** - EU CRA reporting obligations begin September 2026, SBOM technical documentation is enforceable from December 2027, both binding manufacturers rather than upstream maintainers. Expect pressure as fix requests from downstream companies, not direct liability.
- **Cost** - a concentrated one-time setup, then a monthly score check and a per-release SBOM.
- **Decay** - a lapsed signing pipeline fails builds downstream, so it is harmful.
- **Signal** - score above 7 with green attestations; enterprise evaluations that stop stalling.
- **Traps** - treating it as a growth channel; taking on certification-shaped obligations a volunteer project cannot sustain. Funding predicts posture more than intent: paid maintainers publish signed releases with provenance at 50% vs 28% for unpaid ones (Tidelift 2024).
## 10. Machine and agent-readable surfaces
**What it is** - the project as consumed by search engines, answer engines and coding agents rather than a browsing human: structured docs, machine-readable indexes and specs, canonical error strings, accurate metadata everywhere the ecosystem is scraped. It rewards recommendation by the tools developers now ask first - a project whose docs an agent can parse, with an unambiguous install path, gets suggested with correct code; one understandable only by reading a blog post does not.
- **Cost** - mostly documentation work already justified on its own.
- **Decay** - slow.
- **Signal** - arrivals from answer engines where distinguishable; correctness of the code snippets tools produce when asked about the project.
- **Traps** - treating this as a keyword game. The underlying work is unambiguous naming, complete runnable examples and versioned docs, covered by this collection's documentation skills - decide here that the family is in scope, execute it there.
## 11. Artifact and connector hubs
**What it is** - hubs where the unit of distribution is an artifact or connector inside someone else's product: model and dataset hubs, data-connector marketplaces, infrastructure module registries, observability plugin catalogs, automation-node directories, rule and policy registries.
**Why it is not family 5** - the host is a data or infrastructure platform, the reviewer is the platform vendor, and inclusion is usually a PR against the vendor's index repository or a naming convention its crawler matches, not a store upload. The evaluator also sees a support tier next to the entry, which no editor store shows.
**Mechanics worth knowing** (verified against vendor documentation on 2026-08-28; all change without notice)
- **Index-repo hub** (dbt Package Hub) - `dbt-labs/hubcap` runs hourly over the repos in `hub.json`; listing means a PR adding the repo, reviewed by a dbt Labs maintainer. Requires GitHub hosting, `dbt_project.yml` with a `name`, semver release tags (`0.1.0` or `v0.1.0`).
- **Naming-convention hub** (Terraform Registry) - public GitHub repo named `terraform-<PROVIDER>-<NAME>`, standard module structure, semver tags with optional `v` prefix (non-version tags ignored). The **repo description becomes the module's short description**; new versions appear about a minute after a tag push.
- **Tiered-support hub** (Airbyte) - four levels: Airbyte-maintained, Enterprise, Marketplace, Custom. A community connector lands in Marketplace, listed and installable but labelled "not maintained by Airbyte" with no support SLA - and that label is part of what the evaluator reads.
- **License-gated catalog** (Grafana plugins) - public Git repo, mandatory cryptographic signing, license from AGPL-3.0, Apache-2.0, BSD, GPL-3.0, LGPL-3.0 or MIT. Grafana Labs declines forks or duplicates of existing plugins, several plugins bundled as one, environment-specific designs and niche use cases.
**Downloads do not mean here what they mean on a language registry.** Hugging Face counts every `GET`/`HEAD` on a per-library set of query files - `config.json` by default, overridden per library in the open-source `model-libraries.ts` list, plus every `.gguf` file - so a clone inflates the number and a cached pipeline run does not appear. Deduplicated request-level data is a paid publisher-analytics feature. Read each hub's counting documentation before comparing its number to anything.
- **Cost** - a concentrated entry cost (naming, structure, signing, review), then a per-release compatibility tax against the host's version.
- **Decay** - harmful: a connector broken on the host's current version reads as abandoned inside a product the user is paying for.
- **Signal** - installs or pulls per hub, support-tier label, issues from users who name the host product rather than the project.
- **Traps**:
- Entering a hub whose support tier advertises the project as unsupported when the goal was company adoption.
- Renaming a repository after listing, which silently breaks a naming-convention hub.
- Assuming the hub's download number is comparable to a registry's.
references/coverage-audit.md›
# Coverage audit and measurement
Run this before proposing any new channel. It produces the plan's "Position today" section and the baseline every later comparison reads against.
## 1. Inventory: where the project already is
Answer these before judging anything:
- Which registries carry the project, under which names, and who controls those accounts?
- Which repositories package it downstream, at which version? A cross-repository tracker (Repology and equivalents) answers this across hundreds of distribution families, including copies nobody upstream created.
- Which lists, directories and showcases link to it? Search the project name plus the category term, and check competitors' listings - curated lists tend to carry a whole category.
- Which projects depend on it? Registry "dependents" views and ecosystem index services give an order of magnitude.
- Which mirrors, forks or vendored copies exist, and do any have their own audience?
Gather this directly where you can browse or run commands; otherwise ask the maintainer and mark unknowns as unknown rather than assuming zero - an unknown is a finding, meaning the surface is unmonitored.
## 2. Metadata completeness check
For every registry the project publishes to, check field by field and score it as a percentage of fields filled:
- Description - standalone, plain, in the problem's vocabulary, current with the latest positioning.
- Keyword/tag slots - all used, within the registry's limits, matching terms an evaluator would type.
- Categories/classifiers - from the registry's own taxonomy, not invented.
- License - declared and detectable, matching the repository.
- Links - repository, documentation, homepage, issue tracker, funding, changelog.
- Rendered README - first screen readable in the registry's own rendering, no broken images or forge-only markup.
- Version state - latest release visible, no accidental pre-release as the default install.
Anything below 100% here is the cheapest work available and outranks every new channel.
## 3. Stale-listing sweep
For each listing and package, check:
- Does the link resolve?
- Is the description current?
- Is the screenshot recognizable?
- Does the version match?
- Does the name match after any rename?
Fix or request removal, and record the sweep date - that is what makes the next sweep cheap.
A listing that can be neither corrected nor removed is an argument against the channel family, not a sunk cost to defend.
## 4. Arrival sources
Establish where people currently arrive from with whatever the maintainer already has: repository traffic panels (referrers, unique visitors, cloners), registry download series, documentation analytics, tracking parameters on links they control, and "how did you hear about us" answers in issues and discussions.
Two constraints shape this. Repository traffic panels keep only a short rolling window, so an uncaptured baseline is unrecoverable - snapshot before changing anything. And most OSS distribution is unattributable by design: installs come from mirrors, CI caches and proxies. Read direction and magnitude, never precise attribution.
## 5. Metrics that mean something
**Coverage metrics** (facts, auditable today):
- Metadata completeness per registry.
- Repositories on a current vs. outdated version.
- Live vs. stale listings and days since last sweep.
- Days since last release and the longest gap in the last year.
**Arrival metrics** (behaviour, read as quarterly trends):
- Registry downloads by version where available.
- Unique cloners and visitors.
- Dependents count.
- Referral arrivals per channel.
- Inbound issues and discussions from people who clearly are not existing users.
Stars are the loudest and least informative number here. Track them only paired with downloads or cloners: stars moving alone means an announcement travelled, not that distribution improved.
## 6. Baseline snapshot
Write the numbers down with their date and source, in the plan itself, and re-measure on the review cadence rather than continuously - these series are too noisy week over week.
Expect changes on a quarter's horizon: metadata fixes act within weeks, a curated listing accrues slowly, and a downstream package can take a full release cycle to reach anyone's install path.
references/distribution-plan-example.md›
# Worked example and entry patterns
A complete plan for a fictional project, then weak/strong pairs for the entries maintainers most often get wrong. SKILL.md's failure-mode list carries the negative examples.
## 1. Worked plan
From the interview: `queuelite`, a small Python library for durable background jobs on SQLite, published to one language registry. One maintainer, 6 hours a month. Adopters so far are individual developers; the maintainer wants small-team company adoption next. A 1.0 lands the following quarter.
```markdown
# Distribution plan - queuelite
## Position today
- Registry metadata 55%: description predates the async rewrite, 2 of 5 keyword slots
used, no documentation or funding link, classifiers missing.
- Packaged downstream nowhere; no mirrors or forks with an audience.
- 3 listings: 1 accurate, 1 pointing at the pre-rename repo, 1 on a dead directory.
- 14 dependents, all individual projects; no company-owned repository visible.
- Arrivals (last 30 days): 62% direct/registry search, 21% one third-party blog post,
9% the accurate listing, 8% unknown.
- Baseline 2026-08-26: 3,100 monthly downloads, 240 unique cloners, 14 dependents,
last release 71 days ago, longest gap in the last year 94 days.
## Adopter
Both, sequenced. Individual developers stay the volume path, paid for by registry
findability. Company adoption is the growth goal and needs legibility work (versioning
promise, security contact, release rhythm) before any company-facing channel is worth
entering.
## Foundation ring (this month, ~3 hours, then minutes per release)
- Rewrite the registry description in the problem's vocabulary ("background jobs",
"task queue", "SQLite", "no broker"); fill all 5 keyword slots and the classifiers.
- Add documentation, changelog, issue-tracker and funding links.
- Fix the renamed-repository listing; request removal from the dead directory.
- Publish a one-paragraph versioning and support statement in the README, linked from
the registry page - what a company evaluator looks for first.
## Test ring (next quarter, 2 hours a month, ends 2026-12-01)
- T1 - Ecosystem list inclusion: the two curated lists in this language's
background-jobs category, after two unrelated contributions to each.
Signal: referral arrivals per listing > 30/month by the end date - a self-set bar
rather than a published benchmark; derive it from the project's own current numbers,
not from this figure.
- T2 - Framework integration: a documented adapter for the web framework 9 of the 14
dependents already use, offered upstream first.
Signal: adapter installs, plus one dependent that is a company repository.
## Core channel (candidate, decided at the test-ring end date)
Integration surface, if T2 produces adoption the listings do not: this project gets
chosen while solving another problem inside a framework, so the framework's docs are
where that decision happens.
## Refused
- System packaging: a library, not a binary; users install from the language registry
inside a virtualenv. Zero benefit, permanent packaging cost.
- Aggregator relaunch before 1.0: novelty is spent and a repost reads as noise.
- Directory sprint (20+ submissions): at 6 hours a month the sweep alone consumes the
budget, and stale listings damage the company-adoption goal specifically.
- Paid featured placements: no evidence the audience browses those pages.
## Release rhythm
Maximum interval 6 weeks, security fixes out of band within 72 hours; batch small
changes, every release ships notes. 1.0 in Q4 is the one milestone returning to
awareness channels.
## Review
Listing and package sweep quarterly, first 2026-11-15. Metadata re-check at every
minor release. Plan re-decision 2026-12-01, with the power to kill T1, T2 or both.
## Threshold check
Metadata 100% after the foundation ring ✓ · every channel has owner/cost/signal/review
date ✓ · recurring cost 3.5h of 6h capacity (58%) ✓ · no harmful-decay channel without a
sweep date ✓ · stale listings fixed before new channels ✓
```
## 2. Weak vs strong: channel entries
**Weak** - "Submit to awesome lists and developer directories to increase visibility."
Nothing here can be executed, refused or reviewed: no list named, no cost, no signal, no end date, no acknowledgement that each listing must be swept forever.
**Strong** - "Submit to the two curated lists in this language's background-jobs category, after two unrelated contributions to each. ~90 minutes total, 15 minutes per quarterly sweep. Success: >30 referral arrivals/month per listing by 2026-12-01. Below that, remove the entries and drop the family."
Every entry in the worked plan above follows that shape: named surface, cost to enter, cost to hold, signal, and the result that retires it.
Refusals take the same shape.
**Weak** - "We're not doing social media for now": an omission, not a refusal, and it will be proposed again next month.
**Strong** - "Refused: aggregator relaunch before 1.0. Novelty is spent and a repost reads as noise. Reconsider at the 1.0 milestone, where the story genuinely changed."
A refusal earns its place when it names the channel, the reason, and the condition that would reopen it.
references/published-findings.md›
# Published findings on OSS distribution
The studies and policies behind this skill's figures, with what each establishes and what it does not. Cite the limitation alongside the number whenever you use one - a maintainer is spending scarce hours on the advice.
## 1. How developers select dependencies
**Larios Vargas et al., ESEC/FSE 2020** (DOI 10.1145/3368089.3409711) - 16 interviews plus 115 survey respondents, 26 selection factors ranked. Share rating each factor "highly influential": maturity/stability 62%, usability 55%, documentation 51%, license 45%, active maintenance 44%, security 39%, time/budget 39%, risk assessment 38%, performance 32%, popularity 30%, community activeness 30%, well-tested 11%.
The authors themselves call the low security ranking surprising. One interviewee states the gap directly: _"Checking security vulnerabilities is important, but I do not check it up-front."_
- **Establishes** - what practitioners say they weigh.
- **Does not establish** - what drives adoption.
Treat it as an argument for making stability, usability, documentation and license _visible_, not as a ranking of channels.
**Go Developer Survey 2025** (go.dev/blog/survey2025, published 2026-01-21, 5,739 respondents) - "Finding trustworthy Go modules and packages" is the third-most-reported frustration at 26%. Read as evidence that trustworthy-module discoverability is an unmet need addressable through documentation quality and social proof, not through a campaign.
**Stack Overflow Developer Survey 2024** (65,000+ respondents) - technical documentation and Stack Overflow itself are the top learning resources; online resources are cited by 80%+.
## 2. What visible signals actually do
**Borges and Valente, _Journal of Systems and Software_ 2018** (arXiv:1811.07643) - survey of 791 developers. Three out of four consider a project's star count before using or contributing to it; 36.7% starred a repository specifically _because_ they were already using it.
- **Establishes** - stars are a checked social-proof signal and visible usage converts into stars.
- **Does not establish** - that stars cause adoption; the same study documents social-media promotion driving star growth.
**Trockman et al., ICSE 2018** - npm ecosystem study. Repository badges are used by 31.0% of packages; adding a first badge produces only a small, non-sustained popularity bump. Read as evidence against badge-stacking as a growth tactic.
## 3. Dependency-graph structure
**Wittern et al., MSR 2016** - only 27.5% of npm packages are depended upon by any other package; 80%+ of packages have at least one direct dependency.
**Decan, Mens and Grosjean, _Empirical Software Engineering_ 2019** (DOI 10.1007/s10664-017-9589-y) - dependency networks grow super-linearly, so an early position inside a growing hub compounds.
**Kikas et al., MSR 2017** - JavaScript transitive dependencies grew 60% in 2016 alone.
**deps.dev (Google Open Source Insights)** - coverage and its closed-source-invisibility caveat are in `channel_catalog.md` § 7.
## 4. Supply-chain signals and adoption
**No causal link to adoption** - the link from OpenSSF Scorecard scores, artifact signing or SLSA provenance to increased downloads or adoption is unestablished, and nothing here should be presented as proving it.
The Scorecard literature measures something else: Zahan et al., "Do Software Security Practices Yield Fewer Vulnerabilities?" (arXiv:2210.14884, ICSE-SEIP 2023) and "OpenSSF Scorecard: On the Path Toward Ecosystem-wide Automated Security Metrics" (arXiv:2208.03412) study vulnerability reduction and adoption breadth, never download effects.
Sigstore's own figures - 3,800+ projects and 500M+ downloads of provenance-enabled package versions during the April-September 2023 beta - are raw totals with no control group, and maturity and funding confound every apparent correlation. Independent sampling in February 2026 found only 76 of 1,059 npm packages carried provenance. On download counts as a trust signal: ReversingLabs documents download pumping, and the Shai-Hulud npm worm (November 2025) backdoored 796 packages.
**Working rule** - present trust work as risk mitigation and procurement enablement. The Scorecard-above-7 target is a self-set passing posture for enterprise review: a procurement bar, not an adoption forecast.
**Regulatory dates** - EU Cyber Resilience Act reporting obligations begin September 2026; SBOM technical documentation is enforceable from December 2027. Both bind manufacturers, not upstream maintainers. OpenSSF states upstream participation is voluntary and must not shift legal obligation onto project communities; Christopher "CRob" Robinson (OpenSSF) frames the realistic risk as reputational and operational, predicting a wave of fix-request pressure from manufacturers facing penalties.
## 5. Maintainer capacity
**Tidelift maintainer survey 2024** (400+ maintainers) - 60% of maintainers are unpaid, and paid maintainers are 55% more likely to implement critical security and maintenance practices. Paid vs. unpaid adoption rates for four practices:
- Signed releases with published provenance: 50% vs 28%.
- Reproducible builds: 77% vs 47%.
- Two-factor auth: 76% vs 68%.
- Static analysis: 75% vs 59%.
This is the capacity constraint the whole plan is built around - unpaid time is the binding resource, and trust work competes directly with everything else.
## 6. Frameworks this skill builds on
**Bullseye** - Gabriel Weinberg and Justin Mares, _Traction_ (Portfolio, 2015). Nineteen channels brainstormed in an outer ring, tested cheaply in a middle ring, then concentrated on one inner-ring channel. The two adaptations in SKILL.md step 2 - hours as the budget, and a foundation ring for set-once channels - are this skill's, not the authors'.
**Awareness → Activation → Engagement → Retention**, with time to first successful use as the activation metric, is the common DevRel measurement frame; swyx (Shawn Wang) argues the North Star should be monthly active developers, with newsletter signups as an honest proxy (swyx.io/measuring-devrel).
**11th Annual State of Developer Relations Report (2024)**:
- Content marketing remains the most effective outreach tactic.
- SEO/PPC effectiveness dropped to 4.9% from 10% in 2023.
- Teams not measuring at all fell to 7.3% from 9%.
**Crossing the Chasm** - Geoffrey A. Moore (1991; 3rd edition 2014). Imported only for the reference catch-22 in step 4. The rest of its apparatus (beachhead selection, whole product, bowling-pin expansion) is a product go-to-market method, not a distribution-channel method, and is deliberately left out.
## 7. Hub and marketplace policies
The mechanics described in `channel_catalog.md` § 11 come from each vendor's own documentation, which is perishable and can change without notice. Re-read the live page before planning around any detail. Sources, in the order the catalog table lists them: `github.com/dbt-labs/hubcap`, `developer.hashicorp.com/terraform/registry/modules/publish`, `docs.airbyte.com/integrations/connector-support-levels`, `grafana.com/legal/plugins/`, and `huggingface.co/docs/hub/models-download-stats` for the download-counting rules.
## 8. Limits on what to claim
- **No channel-level claim here is causal.** How much of a project's adoption came from which channel stays unmeasured; every claim in this skill is either mechanical (what the surface does) or inferential (what evaluators say they weigh).
- **JetBrains State of Developer Ecosystem** (2025, 24,534 respondents) covers tooling and language adoption - do not cite it for discovery-channel claims.
- **Homebrew's numeric notability thresholds are still live, just relocated.** The 30 forks / 30 watchers / 75 stars rule moved from `Acceptable-Formulae.md` to a separate `Package-Acceptance-Policy.md` page (confirmed via direct fetch of Homebrew/brew's current source, 2026-09), which also adds a rule not previously known: self-submissions by the repository's own owner need 3x the threshold - 90 forks, 90 watchers, or 225 stars. Both metrics apply to the canonical upstream repository only, never a mirror or fork. Cite the current page, not the old one.
- **Three of this skill's five pass thresholds are self-set baselines**, marked as such in `SKILL.md`: defensible construction, not measured benchmarks.
SKILL.md›
---
name: oss-distribution-strategy
description: Designs an open-source project's ongoing distribution mix after the launch window - registry metadata, code-host discovery surfaces, curated lists, downstream packaging, extension and connector marketplaces, the release stream, dependency-graph position, creator seeding, and procurement trust signals - ranked against real maintainer capacity. Use whenever a maintainer asks how people will keep finding the project, which registries or awesome lists to target, why adoption flattened after launch, how often to release for visibility, or how to spend limited maintainer hours on distribution - even if they only say nobody is using it. Not the launch itself - use samber/developer-relations-skills@oss-launch. Not the build-in-public practice.
license: MIT
metadata:
author: Samuel Berthe
version: "1.0.5"
---
# OSS Distribution Strategy
You are an open-source distribution strategist. You decide, with the maintainer, which channels keep bringing new users month after month, which get refused, and what each costs to hold. You produce a channel portfolio, a sequence and a review rhythm - not the posts, packages or pull requests themselves.
The scarce resource is maintainer hours, not money. Almost every channel is free to enter and expensive to keep accurate - and a neglected channel does not go silent; it keeps speaking against the project.
A stale listing, a two-year-old distro package, a description written before the rewrite: each tells the audience it was meant to attract that nobody is home. Hold every recommendation to that test.
**Boundaries.**
- The one-time launch event belongs to `samber/developer-relations-skills@oss-launch`.
- The ongoing transparency practice belongs to `samber/developer-relations-skills@build-in-public`.
- Per-registry publishing execution (credentials, provenance, dist-tags, package shape) belongs to `samber/developer-platform-skills@sdk-package-publishing`.
You decide the mix; they run it.
## Interview
Ask one question at a time, offer multiple-choice options where you can, and stop as soon as you can name the ecosystem, the adopter type and the real capacity.
**Memory: Store a few info about the current task or project context. When memory lives in a file, use `devrel-context.md`; if a different memory system is in use, rely on that instead. Separate task info in different sections. Remove finished tasks. Add a date to a task; no date for general project context. Some interview responses may differ between 2 tasks.**
1. What is the project, and how does someone install or add it today?
2. Which ecosystems does it ship to - one language registry, several, a binary, a container image, an editor or browser extension, a plugin for a host product?
3. Who adopts it: individual developers choosing for themselves, or engineers who must get it approved inside a company? (Both is valid and changes the channel mix.)
4. What does distribution need to produce: users, contributors, sponsors, funnel for a commercial product, hiring signal, standard-setting?
5. How many maintainer-hours per month are genuinely available for distribution work, forever - not in the enthusiastic first month? Who else can execute part of it, and how much of it can be walked back after stopping?
6. Is there a date the result has to land by - a funding decision, a conference, an enterprise deal in procurement, a grant report - or is the horizon open?
7. Is the goal a one-off win to point at, or a compounding position that keeps paying with no further spend? "Both" is a budget split, not an answer.
8. What is already in place - registries, listings, third-party packages, mirrors, integrations, marketplace listings - and what has been tried and produced nothing?
9. What is the current baseline (downloads, unique cloners, dependents, referrer sources) and where is it read?
10. What is off-limits: channels refused on principle, license or employer constraints, regions to reach, competitors' turf?
11. What changes in the next two quarters - a 1.0, a rename, a rewrite, a commercial offering, an enterprise deal in procurement - that the plan should be timed against?
Questions 5, 6 and 7 set the channel ordering in step 2 - ask them before proposing anything:
- A hard date promotes the fast-acting families and demotes anything needing a full release cycle to reach an install path - downstream packaging and dependency position both.
- A compounding mandate reverses that and drops creator seeding, whose payoff stops the month the pitching stops.
- A low hours ceiling deletes the per-release-tax families outright rather than shrinking them.
- No appetite for irreversible commitments deletes downstream packaging, because a shipped distro package cannot be unshipped.
Record the answers. If the harness has persistent memory, store the ecosystem, adopter type, capacity and refused channels there - every later release and sibling skill re-uses them.
## Step 1 - Audit the distribution that already exists
Never plan new channels before measuring the ones already running - follow [references/coverage-audit.md](./references/coverage-audit.md).
Expect two findings from the audit:
- A half-configured foundation channel: empty keyword slots, missing links, a description predating the current positioning.
- Two or three listings that are simply wrong.
Fix those before proposing anything new - about an hour of work, and the decay is already doing damage.
Do not rank these fixes against each other: they are one hour in total and all have to be done, so ordering them is false precision dressed as a plan. Ranking starts in step 2, where the options are genuinely alternatives.
## Step 2 - Brainstorm the channel space before choosing
Enter brainstorming mode explicitly and say so; do not propose a plan yet.
Use the **Bullseye framework** (Gabriel Weinberg and Justin Mares, _Traction_, 2015) - the one established traction method whose shape matches this task - with an extra ring at the front:
- **Foundation ring** - set-once, decay-slowly channels that raise the yield of everything else: registry metadata, the canonical repository surface, the docs entry point, the one or two lists where the category is genuinely browsed. Cheap, compounding, non-optional.
- **Test ring** - 2 to 3 candidate channels as time-boxed experiments with a stated success signal and an end date.
- **Core ring** - the single channel that earns sustained effort once a test proves it.
Two adaptations make Bullseye fit open source, both this skill's, not the authors':
- The budget is hours rather than dollars.
- Several OSS channels are set-once rather than campaign-shaped, which is what the foundation ring exists for.
Widen the outer list with [references/channel-catalog.md](./references/channel-catalog.md): eleven families, each with what it rewards, its cost and its decay profile. Its numbering is a table of contents, not a ranking - the ranking is here.
### Rank the families before proposing a mix
The default order is value returned per maintainer hour. Say it out loud; never let list order imply it.
- **efficiency** - `registry metadata > release stream > dependency position > machine-readable surfaces > curated lists > code-host surfaces > trust signals > extension marketplaces == connector hubs > downstream packaging > creator seeding`
The axes disagree, so read them separately instead of trusting the blend:
- **effort**, recurring hours per month, heaviest first - `creator seeding > extension marketplaces == connector hubs > downstream packaging > curated lists > code-host surfaces > trust signals > release stream > registry metadata == machine-readable surfaces > dependency position`
- **value, individual adoption** - `dependency position > registry metadata > extension marketplaces > curated lists > release stream > creator seeding > machine-readable surfaces > code-host surfaces > connector hubs > downstream packaging > trust signals`
- **value, company adoption** - `downstream packaging > trust signals > dependency position > connector hubs > registry metadata > release stream > extension marketplaces > machine-readable surfaces > curated lists > code-host surfaces > creator seeding`
- **compliance cost**, the review it triggers and the reversibility it costs - `downstream packaging > connector hubs > trust signals > extension marketplaces`. Packaging alone is irreversible: a shipped distro package cannot be recalled. Hubs gate on a licence allowlist and signing checked at review; trust signals mean owing a disclosure SLA once published; marketplace terms are acceptance-only and reversible by unpublishing. The other seven families carry no such exposure, so this axis is not an ordering over all eleven.
Effort above is the _recurring_ cost, the scarce resource. Dependency position, trust signals and connector hubs invert on entry cost - a concentrated block once, then almost nothing to hold - so state which you mean when quoting a cost.
The `==` ties are real, each justified by what makes it genuinely equal:
- Extension marketplaces and connector hubs share one cost shape exactly: a vendor review gate, a per-release compatibility tax against a host version the maintainer does not control, and the same harmful decay when that host moves. Only the audience differs.
- Registry metadata and machine-readable surfaces are both wording work on artifacts the project already ships, no third party in the loop.
One near-tie is broken deliberately: curated lists edge out the release stream for individual adoption, because a listing reaches strangers while the release stream mostly reaches existing dependents - its new-adopter value is indirect, through the "last published" liveness proxy.
**What this order starves.** Downstream packaging sits near the bottom on efficiency and at the top of value for company adoption, and it is the classic harmful-decay family: a stale package does not go quiet, it keeps shipping a year-old version to the exact evaluator the plan was built for.
A ratio picks registry metadata over it every round - correct for individual adoption, wrong whenever company adoption is the goal. Promote it above everything but the foundation ring when all four hold:
- Company adoption is the declared goal.
- The install unit is a standalone binary or container image, not a library inside someone else's dependency file.
- Release hygiene is already good enough for a third-party packager to hold it, which moves the recurring cost off the maintainer.
- The maintainer accepts the irreversibility.
Creator seeding also sits last, and that is the ranking working, not starvation: its cost is recurring relationship work nobody else can absorb, and its payoff stops when the pitching stops. Promote it only for a dated milestone, once stages 1 and 2 of the sequence hold.
**The order is a default, not a law.** It shifts with the ecosystem, the goal and who executes it. Re-rank against the interview answers and name which answer moved which family:
- A distro maintainer already packages the project → entry cost paid, recurring cost sits with someone else; move downstream packaging into the foundation ring and spend the hours on the release hygiene that keeps that packager current.
- One dominant registry in the ecosystem → registry metadata and the release stream absorb most findability; curated lists and code-host surfaces drop several places.
- No hours for anything recurring → the order collapses to the set-once families (registry metadata, machine-readable surfaces, dependency position once earned); every family with a monthly sweep is deleted, not shrunk.
- An advantage the default assumes away - a curator or hub maintainer already known, an employer packaging internally, a co-maintainer doing release engineering → the family whose entry cost that advantage pays moves to the front.
**Delete, never demote.** A family the maintainer's constraints rule out leaves the ranking entirely and is named in the plan's Refused section. A ruled-out channel parked at the bottom reads as "later" and reappears as scope next quarter.
### Then propose the mixes
Present **2 or 3 candidate mixes**, never one plan. Three recurring shapes:
- **Coverage-first** - broad foundation ring, no core channel. The bet: accurate presence everywhere beats depth anywhere.
- **Ecosystem-depth** - one language community, packaged and listed everywhere that community installs from.
- **Downstream-first** - packaged into the channels the target company already trusts. Usually what a company-adoption goal needs.
Rank the mixes out loud too, on the same axes:
- **efficiency** - `coverage-first > ecosystem-depth > downstream-first`
- **effort** - `downstream-first > ecosystem-depth > coverage-first`
- **value, individual adoption** - `ecosystem-depth > coverage-first > downstream-first`
- **value, company adoption** - `downstream-first > coverage-first > ecosystem-depth`
Compliance cost does not rank across the mixes: only downstream-first carries exposure, already priced on the family above. Downstream-first is the same starvation case one level up - last on efficiency, first on the axis that decides whether an approver signs. Coverage-first leads on efficiency only because most projects arrive with an unfilled foundation ring; once that ring is fixed the gap narrows and the adopter type decides, not the ratio.
Give each mix a cost in hours per month, the adopter type it serves and what it gives up, then recommend one and say why. Let the maintainer pick before detailing anything further.
## Step 3 - Put every candidate channel through the adoption test
Answer four questions in writing, per channel:
- **Recurring cost** - hours per month to keep it accurate, forever.
- **Decay behaviour** - when neglected, does it go invisible (acceptable) or actively wrong (harmful: a listing, a package, a mirror serving an old version)?
- **Observable signal** - which number moves if it works, and where is it read?
- **Kill date** - when it gets re-evaluated, and what result retires it.
A channel with no answer to the third question is a hobby, not a channel. Adopt a harmful-decay channel only when its recurring cost genuinely fits the declared capacity. Refuse channels out loud, and cut a refused one out of the step-2 ranking rather than leaving it at the bottom - a written refusal (channel, reason, condition that reopens it) is a deliverable. A channel parked last gets re-litigated every quarter; a named refusal does not.
## Step 4 - Match channels to the adopter type
The two adoption paths diverge as sharply as B2C and B2B, and the same channel serves them differently:
- **Individual adoption** - discovery is search, ecosystem browsing and word of mouth; the install command is the conversion point. Optimize registry findability, the one-line install path, presence in the lists that ecosystem reads, and zero-friction defaults.
- **Company adoption** - the evaluator finds the project, but an approver decides, and an artifact proxy or review board can block the install outright. Distribution means being installable through a channel the company already trusts, and being **legible**: an approver can verify the license, versioning promise, security contact, release rhythm and artifact signatures without asking anyone. That is what "legibility" means throughout this skill.
Geoffrey Moore's _Crossing the Chasm_ (1991) names the mechanism behind the second path: pragmatic buyers want references from peers in their own segment, and none exist until someone adopts first. The practical form is a visible wall of named adopters in that segment - making existing usage visible is a distribution move, not a vanity one, and one named company adopter beats a thousand anonymous downloads here.
A channel that serves both paths carries a different value on each: step 2's two value orderings, one for individual adoption and one for company adoption, price that difference already.
Anchor the legibility argument in what evaluators _say_ they weigh - stated preference, not proven adoption drivers. Larios Vargas et al. (ESEC/FSE 2020, DOI 10.1145/3368089.3409711; 115 practitioners) ranked the factors rated "highly influential" in dependency selection: maturity/stability 62%, usability 55%, documentation 51%, license 45%, active maintenance 44%.
Four of the five are things a distribution plan can make _visible_ without touching the code. Full ranking and limits: [references/published-findings.md](./references/published-findings.md).
## Step 5 - Sequence the plan, do not just rank it
Ranking says what to run; sequencing says in what order, and the order changes the payoff. Use this three-stage default, adapted to the interview answers.
1. **Foundation, weeks 1-4.** Fix the audit's metadata and stale-listing findings. If company adoption is a goal, ship the minimum trust posture in the same pass: signed releases, build provenance, a published SBOM, `SECURITY.md` with a disclosure path, an automated supply-chain score in CI.
2. **Passive discovery, months 1-3.** Work the surfaces that compound with no recurring spend: find the highest fan-in hub projects in the niche and target adoption or a first-class adapter with each, build the "used by" wall, and get curated into the code host's topic surfaces through a community ally rather than a self-submission.
3. **Active seeding, ongoing.** Only once 1 and 2 hold: 3-5 newsletter or podcast relationships on a quarterly calendar with a demo or sample repo attached, sponsored slots labelled distinctly from editorial coverage.
This is the step-2 efficiency order re-read as a calendar, with time-to-effect deciding what runs in parallel: passive discovery second for its long payoff horizon, active seeding last for its recurring cost. The one adopter-conditional flip sits inside stage 1: trust signals rank low on efficiency for individual adoption and near the top for company adoption, so the trust posture either ships in the first four weeks or does not enter the plan at all. It is a one-time cost that unblocks a whole buyer segment, so it never gets spent driving traffic that then stalls in procurement.
Four triggers change the plan:
- **Enterprise adoption stalls despite strong docs.** The blocker is procurement, not awareness - escalate the trust posture before adding any awareness channel.
- **Star velocity high, usage and retention flat.** The announcement travelled and the install did not. That is an onboarding problem; move the budget to docs.
- **One hub project drives most transitive usage.** Invest in that relationship and in attribution, not in more small integrations.
- **Regulatory fix-request pressure spikes.** Formalize a disclosure SLA rather than absorbing the load personally. Expect it as demands from downstream companies, since the EU CRA binds manufacturers, not upstream maintainers: reporting obligations start September 2026, SBOM technical documentation becomes enforceable December 2027.
## Step 6 - Make the release stream a channel
A release broadcasts to people the maintainer cannot otherwise reach, and every recipient acts on it:
- Dependency-update bots open a pull request in every downstream repository.
- Packagers' pipelines fire off the new tag.
- Feed-harvesting newsletters pick it up.
- Watchers see it in notifications.
- Evaluators read the registry's "last published" field as a liveness proxy.
Cadence is therefore a distribution decision and the changelog a distribution asset.
The cadence rules follow from that mechanism, practitioner reasoning, not measured findings:
- Commit to a predictable **maximum** interval ("a fix lands within N weeks"), never a mandatory minimum.
- Batch small changes into one readable release.
- Ship security fixes out of band and fast.
An empty calendar release becomes a noise pull request downstream and trains those maintainers to auto-merge or ignore the one channel reaching existing users directly.
A long silence fails the liveness proxy even on a finished project; the cheap correction is an explicit "stable, maintained, low change rate" statement in the README. Reserve named milestones - a 1.0, a rewrite, a rename - as the legitimate reason to return to awareness channels after the launch window closes.
## Step 7 - Write the plan and validate it section by section
Produce a plan the maintainer can run without you. Output shape:
```markdown
# Distribution plan - <project>
## Position today audit findings, current arrival sources, baseline numbers + date
## Adopter individual / company / both, and what each needs
## Foundation ring channels fixed now, with the exact gaps found
## Sequence stages 1-3 with dates, and the triggers that reorder them
## Test ring 2-3 experiments: hypothesis, signal, end date, cost
## Core channel the one sustained channel, and why it beat the others
## Refused channel, reason, and the condition that reopens each
## Release rhythm maximum interval, milestone plan, changelog owner
## Review sweep cadence for decaying channels, quarterly re-decision
## Threshold check each threshold, pass or fail, with the number
```
Present each section and get agreement before writing the next. A wrong adopter call propagates into every channel choice below it, and is far cheaper to catch at the second heading than the ninth. Worked plan and weak/strong entries: [references/distribution-plan-example.md](./references/distribution-plan-example.md).
## Invocation examples
- "Downloads flat since the Show HN. Where do people find us now?" → interview, then coverage audit; expect a half-filled registry page, not a missing channel.
- "Should we get into Homebrew and Debian?" → adopter-type question first. For a language library installed inside a virtualenv, usually no; for a standalone binary aimed at company laptops, it is a downstream-packaging plan.
- "We ship a VS Code extension. Is one marketplace enough?" → no. Dual-publish to the Microsoft marketplace and Open VSX; Cursor, Windsurf, VSCodium and Gitpod default to Open VSX.
- "Our connector is on our own GitHub. Should it be in the vendor's hub?" → yes if the hub is where their users install, but read the support tier first; see catalog family 11.
- "Will an OpenSSF Scorecard above 7 grow our downloads?" → no evidence supports that. Sell it internally as procurement enablement.
- "We have 3 hours a month. Give us the plan." → capacity is the binding constraint; propose a foundation-only mix and refuse the test ring out loud.
## Measurement and pass thresholds
Distribution rarely offers clean attribution, so measure at two levels:
- **Coverage** - facts you control, auditable today.
- **Arrival** - behaviour observed as a trend over quarters against the step-1 baseline.
Hold the plan to these thresholds and iterate until it passes. Only the first is backed by published policy; the rest are bars this skill sets, and you must say so when reporting them:
- **Sourced** - every stale listing found in the audit is fixed or removed before a new channel is added, because curated lists and distro repositories drop projects that read as unmaintained by published policy, not by taste.
- _Adopted bar, not an industry standard_ - if company adoption is in scope: supply-chain score above 7 with green artifact attestations. No public standard defines a passing score; this skill adopts this bar for enterprise review ([references/published-findings.md](./references/published-findings.md) § 4), as a procurement gate, never an adoption forecast.
- _Self-set baselines_ - three thresholds this skill sets rather than measures:
- Every registry has 100% of its metadata fields filled (description, keyword slots, categories, license, repository, docs, homepage, funding).
- Total recurring cost is at most 60% of declared monthly capacity, leaving room for sweeps and the unplanned.
- Every channel carries an owner, an hours-per-month estimate, a named signal and a review date, with no harmful-decay channel entering without a scheduled sweep.
Report the threshold check explicitly at the end. A plan failing on capacity does not need discipline - it has one channel too many.
## What the evidence supports, and what it does not
State the confidence level on every claim - the maintainer is spending scarce hours on it. [references/published-findings.md](./references/published-findings.md) holds the citations and each study's limits.
- **Supported** - three of four developers consider stars before adopting or contributing, and 36.7% starred a project _because_ they already used it (Borges and Valente, _JSS_ 2018; 791 developers). Visible usage is a real social-proof lever - but the same survey shows promotion drives stars, so a star count measures reach as much as merit.
- **Supported** - only 27.5% of npm packages are depended on by any other package (Wittern et al., MSR 2016; a 2016 npm-only snapshot - trust the skew, not the digit). Entering that depended-upon core is a structural advantage.
- **Not supported** - supply-chain scores, signing and provenance as adoption drivers (unestablished, with maturity and funding confounding every apparent correlation), and badges as a growth lever (a first badge gives only a small, non-sustained bump - Trockman et al., ICSE 2018, npm). Weight behaviour over self-report: read dependency and download data ahead of survey preference, remembering both are gameable.
## Common failure modes
- **Spray-and-pray listings.** Twenty submissions in a weekend, all stale a year later. Three maintained surfaces outperform them and cost less.
- **Confusing publishing with distribution.** Shipping to a registry is table stakes; being findable there, and installable through the channel the user already uses, is the work.
- **Pitching trust work as growth.** Signing and SBOMs remove a procurement blocker. Promising a download lift sets up a failure the next security ask will pay for.
- **Reading stars as the outcome.** Stars measure attention and promotion reach; downloads, dependents, cloners and issues from strangers measure distribution.
- **Planning past the capacity.** Capacity shrinks when the project succeeds - support load grows first. Plan for the worst realistic month.
- **Never retiring anything.** A quarterly review with the power to kill a channel keeps the portfolio inside capacity.
Per-family traps - self-submitting to curated code-host surfaces, treating a downstream package as owned, cadence theater, one description copy-pasted everywhere, trusting external trending tools - are listed against the family they belong to in [references/channel-catalog.md](./references/channel-catalog.md).
## References
- [references/channel-catalog.md](./references/channel-catalog.md) - the eleven families: what each rewards, its cost, decay profile, traps.
- [references/coverage-audit.md](./references/coverage-audit.md) - inventory, metadata checks, coverage and arrival metrics.
- [references/distribution-plan-example.md](./references/distribution-plan-example.md) - worked plan, weak vs strong entries, refusals.
- [references/published-findings.md](./references/published-findings.md) - the studies and policies behind every sourced claim, and what each does not prove.
- `samber/developer-relations-skills@readme-optimization` - the repository surface every channel points at.
- `samber/developer-relations-skills@changelog-writing` - the release notes this channel broadcasts.
- `samber/developer-relations-skills@oss-release-policy` - the cadence model, version scheme and support windows behind each release this skill broadcasts.
- `samber/developer-relations-skills@coding-agent-docs-optimization` - execution for family 10 (machine and agent-readable surfaces).
- `samber/developer-platform-skills@github-engagement-playbook` - GitHub-specific execution for family 2 and Step 6: release notifications, Discussions, topics, star policy.