Getting your project seen

Published: May 4, 2019 by C.S. Rhymes

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.

webdev showdev git

Share

Latest Posts

Track HTTP Client requests in Laravel with the Laravel DebugBar
Track HTTP Client requests in Laravel with the Laravel DebugBar

I started working with the Laravel HTTP client on a recent project and I had the debug bar package installed. I wondered if you could use the Laravel Debugbar to record how many api calls were being made and how long each was taking to run? I reached out to it’s creator, Barry vd. Heuvel, on twitter and the rest is history!

Using the HTTP Client and Data Transfer Objects in Laravel 7
Using the HTTP Client and Data Transfer Objects in Laravel 7

Recently I have been working on a project retrieving some data from an API in a Laravel project. I was using Laravel to retrieve and display data from a Moodle installation and started using the HTTP Client in Laravel 7 and wondered if I could convert the retrieved data from an array into a more predictable object. I asked my colleagues and one of them recommended I take a look at the Spatie package called data transfer object.

How NOT to make a Website featured in net magazine
How NOT to make a Website featured in net magazine

I have some exciting news to share! My book, ‘How NOT to make a Website’, was featured in the June 2020 edition of net magazine as the Side Project of the Month.

How NOT to make a website

How NOT to make a Website

By C.S. Rhymes

How NOT to use a smartphone

How NOT to use a Smartphone

By C.S. Rhymes