Getting your project seen

Developers love building things and sometimes we want to share these things with other developers to help make their life easier. Creating you project and putting it on GitHub can seem like the difficult part, but letting people know its there and getting them to use it can be even harder.

Sometimes talking about your own work seems like you are just blowing your own trumpet. I don’t know about you, but I find it hard to talk about myself and suffer a bit from imposter syndrome, worrying if my work is good enough to be used by other developers.

So what can you do to promote your work without sounding like an egomaniac?

Let’s start with your code repository itself and little tips you can do to help promote your work.

GitHub optimisation tips

There are so many repos on GitHub that you need to do some work to stand out from the crowd. There are some tools that are available to you to help your repo appear a bit more in search results.

Topics

As the owner of your repo you can add topics. This is done by clicking the ‘Add Topics’ link at the top of your repo’s homepage. You can then start typing a topics and adding them to the list, before clicking ‘Done’ when you have finished.

Adding topics to your repo should help it appear when people search by topic, by going to https://github.com/topics to see the most popular topics. You can also click topics from repo pages to see other repos tagged with the same topic.

Readme & Documentation

Once people start to find your repo, it’s a good idea to create a readme with the basic set of instructions for how to install and get started with your project and list out it’s key features. This will help people assess whether this package is suitable for their use case or not without having to dig deep into your code.

If you have a lot of instructions, consider creating a webpage with more detailed instructions and examples. You can then add a link to the instructions website from your readme and also at the top of your repo.

Consider adding comments to your code where relevant to help the developers who are using your project as they may want to extend the functionality further and create a pull request.

Respond to issues and pull requests

When I look at a package, one of the things I consider before using it is checking whether the package is maintained. I’m not expecting there to be 20 commits a day, but at least a commit every couple of months or so.

I have used popular packages before, where other users have raised issues and created pull requests, but nothing happens with them. Some people don’t have time to maintain a package they created and they clearly state that on the readme. This is fine with me as it sets expectations from the start, but if you want people to keep using your project then you will have to spend some time going through issues and pull requests and doing some maintenance on your code. It is quite a big turn off to see a load of open issues and pull requests with no responses.

Sometimes as the owner of a repo you have to be harsh and reject pull requests as they don’t fit with the vision of your project. I have tried contributing to other packages in the past and have had pull requests declined, but each time the owner has given a reason for it rather than just rejected it outright. This helps me, and other potential contributors, understand what the owner is thinking and why. I have often learned something from the rejection, helping improve my coding skills in the future.

That said, if someone does provide a really helpful pull request then you can make their day, simply by accepting it and merging their code in to your repo. It’s what open source software is all about.

Releases and Tags

One way of helping users know you have made an update is to create a new release or tag in your repo. This also helps when you make a breaking change, so users who don’t want to upgrade can keep using the previous version instead of just using whatever is on master branch. This is a whole topic in itself so I won’t go into much detail here, but is definitely worth spending some time reading up on.

Writing a Blog Post

Writing a blog post can help you try and put yourself in the shoes of a user of your repo and help you think about the key features they need to know about. After all, you know how it works as you wrote it, well, hopefully you remember how it works…

If you do regular updates to a project then regular blog posts can be short and sweet and talk about a specific release. This provides a bitesize article for your user to find out what they need to do differently to use this feature, instead of having to navigate through many pages of your documentation.

A specific blog post about a specific feature may also help generate traffic to your repo as it will help target specific keyword searches in search engines. For example, if you create a new feature on your project to create with a vertical menu, then people searching for creating a vertical menu might stumble upon your blog post and go to your repo page to find out more about it.

As well as posting the post on your blog, consider other places you can cross post it, such as Medium or Dev.to.

Talk to other site owners

There are some sites that are well established and already have a large following of subscribers. If you think your package will help that particular audience, then why not contact the site owner and send them a link to your package. They might say thanks, but no thanks, or they might feature it on their site and write a blog post about it.

I have found a lot of really useful Laravel packages by subscribing to the Laravel News website that I would not have known about without that site.

The only thing I would say is consider where you try and contact and ensure it is the correct audience. It may be obvious but if the site you are contacting is all about JavaScript, then readers may not be that interested in a PHP package.

Sometimes it just takes time

It’s true, you can do all the hard work and your project sits there unused. If you really believe in what you have produced then don’t give up. Keep pushing small updates as and when you can to help show others what you are trying to achieve.

Most projects don’t have all the features the creator wanted when they are first released, but over time they get better and better with each incremental update, leading to more users and more contributors, building up a great reputation over time.