When people talk about growing an open-source project, the advice usually sounds vague:
- post on social media
- share it on Reddit
- write blog posts
- keep shipping
That advice is not wrong, but it is incomplete.
What worked for me with Pompelmi was not “being everywhere.”
It was making the project easy to understand, easy to trust, and easy to discover in places where the right developers were already looking.
Pompelmi is an open-source file upload security tool for Node.js. It scans files before storage to help detect malware, MIME spoofing, risky archives, and other upload-related problems. It works with frameworks like Express, Next.js, NestJS, Fastify, and Koa.
At the time of writing, the repo has grown to hundreds of stars and picked up mentions from places like Stack Overflow, Help Net Security, Node Weekly, Detection Engineering Weekly, and Bytes.
I did not get there with paid ads.
I did not get there with a huge audience.
And I definitely did not get there from one viral post.
I got there by treating an open-source repo like a product that deserved positioning, packaging, distribution, and trust.
Here is exactly how I approached it.
1. I built around a painful problem that is easy to explain
A lot of open-source projects struggle because they are technically interesting but hard to describe in one sentence.
Pompelmi was different.
The core message is simple:
Your file upload endpoint is part of your attack surface.
That is something backend and security developers immediately understand.
A surprising number of apps still treat file uploads as a basic “accept file, save file” workflow, when in reality uploads can introduce malware, MIME spoofing, archive abuse, and downstream processing risks.
The project became easier to promote once I stopped describing it as a collection of scanning features and started describing it as a clear security layer for file uploads.
That positioning matters a lot.
If your project solves a problem people already worry about, distribution gets much easier.
2. I made the GitHub repo do the selling for me
A lot of traffic is wasted because people land on a repo and still do not understand:
- what the project does
- who it is for
- why it matters
- how to try it quickly
So I tried to make the repository itself act like a landing page.
That meant focusing on:
- a clear headline
- a sharp one-line value proposition
- framework-specific examples
- visible badges and trust signals
- a social preview image
- relevant GitHub topics
- mentions from recognizable sources
In my experience, stars usually come after comprehension.
If someone has to read too much to understand the value, conversion drops.
A good open-source repo should answer this in seconds:
“Why should I care about this right now?”
If it cannot, growth gets harder no matter how good the code is.
3. I stopped thinking only about “promotion” and focused on distribution channels with intent
Not all traffic is equal.
A random viral post can bring views.
A highly relevant placement can bring users, stars, issues, contributors, and long-term trust.
For Pompelmi, the best distribution channels were not generic “look at my repo” posts.
They were places where developers were already thinking about:
- file uploads
- backend frameworks
- Node.js security
- web application security
- malware scanning
- upload validation
That changed how I spent my time.
Instead of chasing broad attention, I focused on channels where Pompelmi was obviously useful.
That included:
- framework ecosystem pages and docs
- developer newsletters
- practical tutorials
- curated lists
- security-focused publications
- posts that answer real implementation questions
This was slower than hype marketing, but much more durable.
4. I wrote for existing ecosystems instead of waiting for people to “find” the project
One of the best things I did was to move closer to where developers already work.
If someone is building with Fastify, Next.js, Express, Koa, or another Node.js framework, they are much more likely to adopt a tool when they discover it in a context they already trust.
That is why ecosystem visibility matters so much.
For an open-source dev tool, this can mean:
- integration docs
- example apps
- framework-specific packages
- PRs to community pages
- entries in ecosystem lists
- guides that show the tool inside real workflows
This is more effective than generic promotion because it reduces friction.
The user no longer has to imagine how your project fits into their stack.
You already showed them.
That has been especially important for Pompelmi, because it is not a standalone product people browse for fun. It is infrastructure. It has to feel practical, easy to slot in, and low-risk to try.
5. I treated every mention as leverage, not as a one-day win
One mistake I see often is that a project gets featured somewhere and the maintainer celebrates for 24 hours, then moves on.
A better approach is to turn every mention into a permanent trust asset.
Once Pompelmi started getting mentioned by recognizable publications and newsletters, I made sure to surface that credibility.
Why this matters:
- it reassures first-time visitors
- it increases perceived legitimacy
- it gives future outreach more credibility
- it compounds over time
When a new reader sees that your project has already been noticed by respected people or publications, they are more likely to take it seriously.
Trust is one of the biggest bottlenecks in open-source growth, especially in security.
If your project touches something sensitive like file scanning, people want reasons to believe it is real, maintained, and worth trying.
Mentions help with that.
But only if you actually use them well.
6. I wrote articles that create curiosity first, then route people into the repo
Another thing that helped a lot was writing content that was broader than the project itself.
If every post is “here is my repo,” people tune out.
But if the post is genuinely useful on its own, it can attract a wider audience and still send qualified traffic back to your work.
For example, list-style articles can work surprisingly well when done right.
Not because they are magical, but because they have built-in clarity:
- readers know what they are getting
- they are easy to skim
- they create curiosity
- they naturally expose multiple projects and ideas
That is especially useful on developer platforms where attention is competitive.
For Pompelmi, I found it better to mix different types of content:
- practical tutorials
- list articles
- launch/update posts
- ecosystem-specific examples
- opinionated posts about a real problem
A tutorial can bring search traffic.
A list article can bring discovery.
An update post can re-activate existing followers.
Together, they create a loop.
7. I learned that consistency beats one big launch
A lot of people want one giant post that changes everything.
Sometimes that happens.
Usually it does not.
What usually works better is repeated exposure across relevant channels.
For an open-source project, that can look like:
- shipping releases consistently
- improving docs regularly
- posting new examples
- publishing tutorials
- sharing integration updates
- reaching out to relevant newsletters or blogs
- submitting to framework/community pages
Each action on its own may look small.
Together, they create the feeling that the project is alive.
That feeling matters.
Developers do not just star code. They star momentum.
A maintained repo with fresh releases, better docs, ecosystem integrations, and outside mentions feels safer to trust than a clever repo that looks abandoned.
8. I made the project easier to adopt, not just easier to admire
A star is nice, but the things that usually create long-term growth are:
- usage
- word of mouth
- references
- integration into real apps
That means adoption matters more than aesthetics alone.
So beyond promotion, I tried to reduce practical friction:
- make the README clearer
- provide examples
- support popular Node.js frameworks
- keep the messaging concrete
- show the exact use case quickly
This is especially important for technical tools.
If someone sees a repo and thinks “cool project,” that is nice.
If they think “I can add this to my upload pipeline today,” that is much better.
The second reaction is what creates compounding growth.
9. I leaned into credibility because security projects need it more than most
Security tooling has a higher trust bar than a casual utility library.
If your project claims to make file uploads safer, people naturally ask themselves:
- is this maintained?
- is this serious?
- is this just marketing?
- who is using it?
- has anyone reputable noticed it?
That means credibility is part of distribution.
Not just code quality.
For me, credibility came from a mix of things:
- consistent releases
- clear scope
- practical documentation
- presence in real developer ecosystems
- recognition from publications and newsletters
- visible maintenance
The more serious the problem you are solving, the more important this becomes.
10. What I would tell someone trying to grow an open-source repo today
If I had to summarize the whole strategy in a few points, it would be this:
Build something with a sharp problem statement
If people cannot repeat what your project does in one sentence, growth will be harder.
Treat the repo like a product page
Your README, social preview, examples, and topics all matter.
Go where intent already exists
Ecosystem pages, newsletters, practical searches, tutorials, and framework communities are better than random exposure.
Turn every small win into a trust multiplier
A mention, a PR merge, a tutorial, a release, an integration: each one should strengthen the next.
Focus on repeated relevance
One post can help. A system of useful distribution points helps more.
What I would do next for Pompelmi
If I were pushing the project even harder from here, I would double down on five things:
More framework-specific tutorials
Not just “what Pompelmi is,” but “how to secure uploads in Express / Next.js / Fastify.”More ecosystem placements
Community pages, official docs, plugin directories, curated security lists.More comparison-driven content
For example: why file type validation is not enough, or why extension checks fail.More proof-driven trust
Mentions, examples, case studies, and implementation patterns.More discoverable educational content
Articles that solve the reader’s problem first, then naturally introduce the repo.
That is the real lesson I learned from promoting an open-source project:
Growth is rarely about shouting louder.
It is usually about making the project easier to understand, easier to trust, and easier to encounter in the right places.
And once that starts working, every new article, PR, mention, release, and integration becomes part of the same flywheel.
Final thought
A lot of people think open source “speaks for itself.”
Sometimes it does.
Usually it needs help.
If you built something genuinely useful, promoting it is not fake and it is not selfish.
It is part of the work.
That was the biggest shift for me.
I stopped thinking:
“How do I get people to notice my repo?”
And started thinking:
“How do I make this project impossible to ignore for the specific developers who need it?”
That mindset made everything else easier.
If you want to check out Pompelmi, the repo is here:
GitHub: github.com/pompelmi/pompelmi
Top comments (0)