Awesome! You created a package for Laravel! But what is next? How do you get people to use it? There are some steps we advise you to take.
Your GitHub page is your package's main entry point and advertising page. Clearly defining what your package does and who it is for is crucial here. Otherwise, nobody will use it. This page is also the first place people look if they have a problem. Let's look at some good and bad descriptions so you can write your own.
Examples of great pages are:
What makes these good? They clearly explain their purpose and the problem they solve. They are also solving problems that any laravel developer runs into.
For example, Any serious developer running code in production needs to do backups. Why not use the package that is called backups? It just makes sense.
Another example is the debug bar uses an image to show the value it provides. With the ease of 1 install command, you get all this information on your page for free. That is a no-brainer to use.
While these pages are better than average, we can improve them. With the goal in mind of providing as much value to the person trying or using your package take a look again at the page of Laravel-backup. Do you know how to install this package? If you don't why is the command not just there? Like it is for the laravel debug bar.
In the next section, we look at some bad examples.
Examples of bad pages are:
Let's take a look at the first text on PHPUnit's page.
PHPUnit PHPUnit is a programmer-oriented testing framework for PHP. It is an instance of the xUnit architecture for unit testing frameworks.
If you are not knowledgeable in the testing frameworks and their approaches would you know what this meant? I certainly don't. And while I love the attention to detail Sebastian has put into his work over the last 21 years. But his GitHub page does not scream "Here is why PHPUnit will fix your problem and how you should use it". There is no real call to action that makes you want to start learning or downloading it.
Take a look at the readme file of the Laravel-messager package. What does it tell you about the package? What problems is it solving? For who is it? You have to think about these questions when writing your homepage.
Documentation comes in many forms and can be as long or short as you want it to be. Some packages have whole sites dedicated to them and others just a few code snippets. But do note that writing documentation is part of releasing a package if you want others to use it. If not for them, write it for yourself because in my experience code written 6 months ago is like new code. Code that you first have to understand.
Writing a lot of documentation at once can be daunting especially when you would probably rather be coding on the package. That is why I suggest you start with small steps. Start with writing about the happy path. These are the steps someone takes to fix their problem with your package. After that you could write something about other use cases your package is useful or some of the settings your packages offer.
Getting the word out about your package is the next step after writing the code and the documentation.
Especially in the beginning of your package you are probably the only one who knows about your package. No body knows that you have a fix for their problems. This is the fun part. You get to tell people about how you are fixing their problems. Doing this correctly is the tough part.
Places like Twitter, Laravel News, and Reddit are great places to start. Try to be helpful and not spammy. Nobody likes a spammer!
Twitter is great and a lot of laravel developers are on there. Using hashtags like #laravel, #opensource, #php #phpc is a great way to get visibility.
The nice thing about these platforms is that they already have an audience which you can leverage.
These 2 have great explanations for what they do and why it is helpful for the programmer who is reading it.