Your Library Has 4,000 Stars and ChatGPT Has Never Heard of It
Tags: ai, opensource, devtools, career
Ask an assistant to recommend a Python library for scheduling jobs and you get the same three or four names every time. Ask for something more specific, a Vue PDF export component or a FastAPI auth layer, and you still get names, just fewer and less predictable ones. Somebody's project is in that answer. Most projects are not.
I spend my working life on the question of why some names appear in AI answers and others don't. Not for libraries, usually, for companies, because I run a digital PR agency and that is what clients pay me to worry about. But the mechanism is the same one, and the version that applies to a maintainer with a repo is more actionable than the version that applies to a brand, because you control more of the inputs.
Here is what I have found, translated into your world.
The model is not reading your repo
This is the part that surprises people most. Your README is one document. It says what you say about yourself. In terms of how these systems build a picture of what exists and what is good, a self-description is close to the weakest signal available.
The strongest public evidence on this is an Ahrefs study from May 2025 that tested 75,000 brands against their visibility in Google's AI Overviews. Branded mentions across the wider web correlated at 0.664. Backlinks came in at 0.218. Web mentions of your name in other people's writing beat links pointing at you, by a factor of about three.
Muck Rack went at it from the other end this year, analysing more than 25 million links cited by ChatGPT, Claude and Gemini. Earned media accounted for 84% of citations. Paid and advertorial content: 0.3%.
Read those two findings together and the picture is uncomfortable but simple. What gets you named is other people writing about you, in places that were not bought. For a library, that is tutorials, comparison posts, Stack Overflow answers, conference talks that got transcribed, someone's blog post about the weekend they replaced your competitor with you.
Your stars do not appear in that list. Neither does your documentation site.
Why stars fail as a signal
Stars are a GitHub-internal metric. They live behind an interface, they are not prose, and nothing about a star produces a sentence anywhere on the web that a model can read and repeat.
Compare it to a single mediocre blog post titled "Why we moved from X to your-library." That post contains your name, a category term, a comparison, and a reason. It is a sentence-shaped fact. It can be retrieved, quoted, and rephrased into an answer. One of those does more for your presence in AI answers than a thousand stars, which is an absurd exchange rate, and it is the one we have.
I am not telling you to stop caring about stars. They still work on humans browsing GitHub. I am telling you they are close to invisible to the layer that increasingly sits between a developer and the decision.
The comparison post is the format that travels
Look at how the questions get asked. Almost nobody types "tell me about library X." They type "what should I use for X," or "X versus Y," or "best library for X in 2026."
Those are comparison queries, and they get answered from comparison content. If nothing on the open web compares your project to the obvious alternative, you are not in the retrieval set for the query your users are actually typing.
The uncomfortable implication is that you probably need somebody to write a fair comparison that includes your competitor by name, and that you are usually not the right person to write it. A comparison authored by the maintainer reads as marketing, and it also concentrates the mention on a page you control, which is the weak position again.
What works better is boring: answer questions in public, in prose, where the answer will be indexed. A thorough Stack Overflow answer that names your library and explains when it is the wrong choice is worth more than another paragraph in your README. So is a comment on someone else's blog post, if it is substantive. So is a talk with a published transcript.
Where the numbers come from, and my bias
I should be direct about my position here. My agency, ESBO Ltd, sells editorial placements, which means I have a commercial interest in you believing that being written about matters. Weigh that.
What I can offer against it is data rather than opinion. I published a study last week analysing 16,625 publisher sites across 53 languages, looking at what placements cost, what publishers accept, and how that intersects with the AI citation research. One finding cut against my own business model: at the top of the market, 39% of publishers sell nofollow links only, meaning the link passes no ranking value, and those publishers charge a median of $1,840 against $510 for everyone else. The most expensive coverage available carries a link that search engines ignore.
That only makes sense once you accept that the mention is the product now, and the link is a leftover from an older era. An LLM reading a page does not check rel="nofollow". It reads the sentence and moves on.
The language thing nobody accounts for
One more finding worth your attention, because open source is global in a way most industries are not.
Ask an assistant a technical question in Polish, Thai or Portuguese and it leans on sources in that language. It does not translate the English web on demand. In my dataset, the price of coverage in Swedish runs about four times what it costs in English, and the reason is supply: far fewer people are producing content in those markets.
For a maintainer this means your project can be well known in English and completely absent from an answer given to a developer asking in another language. If your library has users who have written about it in their own language, that is not a nice-to-have. It is the only presence you have in those answers, and it costs you nothing except asking.
What I would actually do
If I maintained a library and wanted it to show up when someone asks an assistant for a recommendation, in order:
Answer questions publicly and in prose, including the ones where the honest answer is that your project is the wrong fit. Nothing generates trustworthy mentions faster than being visibly fair about your own limitations.
Make it easy for users to write about you. A migration guide from the obvious alternative gives someone the skeleton of a blog post they were already half thinking about.
Ask the two or three people who have already written about your project in another language whether they would write one more thing. That is your entire non-English presence and it usually consists of one person.
Stop optimising the README for search. It is the document a human reads after they have already found you, and it is the wrong tool for the job of being found.
The honest limitation
None of this is deterministic. Nobody outside the labs can tell you exactly what makes a specific answer come out the way it does, and anyone selling you a guaranteed method is selling you something. What the public research supports is a direction of travel: mentions over links, other people's pages over your own, prose over metrics.
You can test the current state cheaply. Ask three assistants what they recommend in your category, ten times each, and count the names. If yours never comes up, the gap is not in your code.
Boris Dzhingarov is the founder of ESBO Ltd, a digital PR agency he started in 2015. He writes about AI search and how language models choose what to cite, and has covered the subject for Forbes and Entrepreneur. He builds small tools for his own work with Claude Code, mostly badly, and writes about that too. Based on Koh Phangan, Thailand.
