How to get other developers to actually notice your GitHub repositories
I’ve had the pleasure of working with Daniel Bruce on a handful of Github repositories that are somewhat popular such as DUnit, Whip, and SnappyRouter. Honestly, he does all the work. I just get the word out about the repositories.
I noticed a repository on Github’s trending page called Wealthbot. After I had skimmed through the repository’s README, I was convinced that I should contribute to it. After that I thought, “Out of all the projects on Github why this one?” That question is what inspired this post.
Avoid Building Garbage
Repositories that seem to be successful tend to fall into one of three categories: being of eminent quality, being a standalone product/service, or simplifying an existing problem.
Creating a project outside the scope of these three categories will make it challenging to draw attention to your repository.
Don’t be discouraged if your project isn’t of eminent quality or are not out of this world new concepts that amaze the development community. Most repositories are in the same boat, because we can’t all build things like Docker. And that is perfectly fine.
Daniel St. Jules is a good friend of mine and has a fairly popular repository called Stringy. He’s happy the repository is on its way to hitting 1,000 stars, but he wishes he had something else more noteworthy there instead.
See, Stringy isn’t exactly the most exciting project he’s written, but people still flock to it. Stringy is popular because it was written well, and provides a simple solution to string manipulation in PHP.
Minimize barriers
What personally turns me off altogether with a repository is when it uses third party solutions. There is a project I’ve wanted to contribute to on multiple occasions called, Joind.in. The reason I haven’t contributed to the project is that it ignores the Github issues tool and instead uses Jira. I am simply not passionate enough about the project to spend the time learning another third party tool.
The most common problem is that it is hard for an individual to contribute when the documentation and or roadmaps are missing. These are the most common pieces to include directly or indirectly in the README:
- Basic documentation
- Expectations of style & unit tests
- Roadmap
Show It In Action
My initial attention span for a repository I stumble upon is roughly less than 10 seconds. That time is spent reading the description, the first sentence of the README, and then I’ll quickly scroll through rest of it.
A picture can be worth a thousand words. GIFs can be worth even more by showing off the functionality of a utility.
In the past, screenshots and live demos videos have also sold me on the value of repositories. Your readme should feature something visual that demonstrates the value quickly.
Tell The World About It
I rarely meet developers who take marketing their project seriously. The phrase that comes to mind is, “I just want to write code.”
Well, creating a repository and adding a README on Github isn’t going to cut it. For the community to care what you’ve been working on, they first need to hear about it somehow.
Not Known At All? Not A Problem.
If you are not known in the community, the best thing I can recommend is writing up an introduction post about your project. Then submit that post to these places:
If you’re not sure where to begin with writing or you’re a terrible writer? Good writing takes practice, so there’s no time like the present to start writing.
For reference, this is what I wrote for DUnit:
Testing Your Current Code Against PHP7 Or HHVM
Intro To DUnit. Think Travis-Ci But Locally.
medium.com
Wrap Up
“Your work is going to fill a large part of your life, and the only way to be truly satisfied is to do what you believe is great work. And the only way to do great work is to love what you do.” - Steve Jobs
Great work deserves to be recognized. Put the effort into getting your work recognized. Your work deserves it, and you deserve it.
