I have been talking to many founders who want my little tricks to bring traffic to their GitHub. They might not want to hear that—or it might be a cliche. But you have to prepare your GitHub before you start.
For me, GitHub is the website landing page; if it’s not “converting” enough, you can bring as much traffic as possible. But you won’t get any contributors/stars or pull requests.
Here are the four things you have to do.
Your README.md is your landing page. This should cover everything the application can give. Starting from top to bottom, here is what you need:
Your logo, title, subtitle, and “about” (right top menu) - avoid using generic lines such as “Your developers home for faster iteration”; generally, avoid the “er.” Write precisely what you do, even if it’s multiple sentences. “We a build a React component that can interact with your application, get the context, run it with LLMs, and take different actions on your screen.” - Avoid the one-liners - “AI React Framework for agents,” what does that even mean?
CTA - I have seen many people putting the CTA in the small button like the “version.” The problem is that many people ignore those because they are in every repository. I prefer to use just textual one with a dot between referencing Docs, Quick Start, and Discord.
Features - Write all the features of the product. I prefer to put motion graphics - one picture = 1000 words 🙂
Getting started - it’s nice to have a teaser if you can, npm install novu
followed by a code snippet. Then, link to the quick start.
Resources—We Should Add more resources such as Demos, Templates, and CodeSandboxes. Many people are lazy and prefer to learn by example.
Yeah, it’s not fun. But most people will not try to make contributions if you don’t give them some.
I would recommend adding 20-50 issues and many. good first issues
As juniors are looking for those.
The classical issue for most open-source repositories is to add integration; once you add one integration issue, you can create many by duplicating and changing the name.
Don’t be afraid to add stupid issues such as “Move menu items 20px to the right.” or “Convert inline parameters to interfaces.” Contributors will take that first, increasing your number of contributors. So instead of solving it yourself, in 5 minutes, spend 5 minutes to open an issue.
Do you have an idea for a new feature? Instead of discussing it with the team, discuss it with the contributors. Go to your Discussion page on GitHub and create something. Ask a question, and expose your internal conversation.
Let the internal team also answer the public question and discuss the continuation of the feature there.
If we treat contributors like customers, we can continue acquiring them. However, we must retain them so they contribute multiple times.
Every time you create a change log, tag the contributors for their submitted features. This will give them a stronger connection to your product.
It will also bring them back to your repository to see what they were tagged at (in case they forgot about your repository.)
Only once you have completed everything you can start marketing :)
I will be in Paris between 18.6 - 26.6!
I will be attending ai_dev. Let me know if you are around, and we can catch up! 🙂
Grow your open-source community