// growth

GitHub Marketing: Turn Your Repo Into a Distribution Channel

Open your own README and stop at the fold. That is everything an evaluator sees before they scroll. If that screen is a logo, badges and a paragraph on why the project exists, the command they came to paste sits somewhere underneath. Nothing above the fold says so. Your analytics record a clone, if that.

This service is distribution through developer platforms: the repository itself, the release feed, package registries, curated indexes and the places engineers already look. It is not the wider job of selling to engineers once they have the tool running. That is our developer marketing service, linked at the top of this page. The install command is the seam between the two, and everything on the near side of it is this page.

The five surfaces that actually move installs

The README is the landing page

Above the fold, three things: what this is in one sentence, who it is for, and the smallest command that produces a result. Everything else (badges, architecture diagrams, the roadmap, the sponsors block) goes below, or goes away. We test this by running the README on a clean machine. A README that only works if you already have the author’s toolchain installed will lose people who arrived ready to try it. Traffic is not the constraint in that case. The first five minutes are.

Releases are a publishing channel, not a changelog dump

Publishing a release does three separate things. It produces a permanent, linkable URL for that version, which aggregators and crawlers can fetch. It adds an entry to the repository’s Atom feed at /releases.atom, which anyone can subscribe to without a GitHub account. And it notifies the watchers who asked for releases, meaning people watching All Activity or watching with Releases selected. It does not notify watchers set to participating and mentions, and it does not notify stargazers, who are not watchers at all. That audience is smaller than your star count and considerably more real than it. Most projects waste it on a generated changelog of commit subjects. A release note saying what changed, why, and what you now do differently is content. It is also the only content your engineers reliably write, because they are already writing the release.

Issues and discussions are your research panel

The issue tracker is a list of real objections written by people who cared enough to type. Every recurring question is a documentation gap, an onboarding defect or a missing feature. The distinction is usually obvious once the questions are grouped. This costs nothing. The research is already sitting in your issue tracker.

Curated lists and indexes are a directory economy

Awesome-lists, category indexes, alternative-to pages and registry topic pages send durable referral traffic and are read by people who are already shopping. They are also maintained by humans with stated inclusion criteria and long memories. Getting listed is a matter of meeting the bar and submitting properly, which is slow. No version of it scales through volume.

Package registries are the last mile

npm, PyPI, crates.io, Docker Hub, Homebrew, the marketplace for whatever editor your users live in. The install name, the description, the keywords and the first screen of the registry page are the last thing between intent and installation. They are usually inherited from whatever the first commit happened to contain.

Why we measure qualified stars and installs

A star is a bookmark. It costs a click, it is easy to manufacture, and it tells you almost nothing about whether the software is running anywhere. Downloads are not much better on their own. Registry counters include CI runners, mirrors, container rebuilds and bots, so a busy pipeline can look like adoption.

What we report is narrower and harder to fake. Installs that reached a working state. Repeat pulls from the same source over time. Where the clone traffic came from, and whether that source ever sends anything again. Stars, in that context, become a useful secondary signal instead of the headline.

The tactics we refuse

No bought stars, no star-exchange rings, no accounts of ours opening friendly issues on your repository. The contributor graph is public, and the maintainers whose lists you want to appear on read it before they approve a submission.

Mass-submitting pull requests to curated lists is out for the same reason. So is opening issues on a competitor’s repository to mention your product. That tactic is genuinely sold. It reliably ends with the project being discussed in public for a reason nobody wanted.

Trending placement never goes in a proposal. The signals behind it are unpublished and the window is short. The only way to turn it into a deliverable is to manufacture the inputs.

A contributor drive is the one item here that comes with a condition instead of a no. It needs somebody on your side with time to review what it produces. Give us that person and it is worth running. Without them, a queue of ignored first-time pull requests costs a project more reputation than having no outside contributors ever did.

What you get

A README rebuilt as the page it actually is, with what the tool does, who it is for, and a runnable example above the fold
A release-notes format your engineers can fill in during a release, so every version ships with something worth reading
A submission plan for the curated lists, registries and indexes your category actually uses, with each one's inclusion criteria checked before anything is sent
Registry metadata reviewed against how people search that registry, covering install name, description, keywords and badges
An issue and discussion triage pass that turns recurring questions into docs, examples or a product ticket
Install instrumentation that separates humans from CI runners and mirrors, so the number in the report means something
A monthly readout of clones, referrers, stars and installs together, including the weeks nothing moved

How it runs

01
Read the repo the way an evaluator does
We clone it cold onto a clean machine, follow the README exactly as written, and record every point where it stalls. The people who give up in the first five minutes never file an issue about it. This is the only way that failure becomes visible.
02
Fix the repo before pointing anything at it
Traffic sent to a repository that does not explain itself converts into nothing and burns the referring source at the same time. Ordering the work this way means the listings and launches land on something that holds.
03
Earn the listings on their own terms
Every curated list, registry and index publishes inclusion criteria. We meet them or we skip that listing entirely. A maintainer who rejects a submission remembers which project sent it, and so does everyone reading the pull request.
04
Instrument, then report what happened
Stars are trivially inflated and downloads include machines. We wire up the measurement first, so the monthly number is defensible. The flat months get reported in the same format as the good ones.

Questions we get asked

Can you get us more stars?: We can get you stars that belong to people who installed the thing and kept it. We will not buy them, trade them, or run a campaign whose only output is the counter. Star totals are visible to your buyers and to the maintainers you are asking for a listing. An inflated one is expensive in a community that can read the contributor graph.
How is this different from the marketing service for developer-tool companies?: This page is the channel. The sibling service is the discipline. Positioning, documentation as a product surface, pricing, community and field programs all sit over there. To work out which one you are buying, look at what your traffic already does. Arrivals that never install are a repository problem and belong here. Installs that never reach production are a product and documentation problem, and that is the other page.
Our product is closed source. Does any of this apply?: Most of it does. Closed-source products still ship SDKs, CLIs, client libraries, example repositories and terraform providers. Those live on the same platforms and in the same registries. What does not apply is anything that depends on outside contributors. We say that up front, and do not sell you a community programme you cannot have.
Isn't submitting to awesome-lists just spam?: It is, when it is done at volume by someone who has not read the list. We read the contribution guidelines, check whether the project genuinely fits the scope, and submit to the few lists where it does. If your project does not meet a list's bar we will tell you what it would take. We will not send the pull request anyway.
Do you need commit access to our repository?: No. We work the way the rest of our engineering does, as pull requests from a fork that your maintainers review and merge. If you would rather we only write the specification, we can. README and release work that is never merged produces the same result as no work at all.
What if the repo is not the problem?: Then we will say so and the engagement should be something else. A repository is a distribution surface, not a demand generator. If nobody in your category has the problem your tool solves, a perfect README changes the bounce rate and nothing further downstream.

Want this run properly? Let's scope it.

Book a strategy call