8 Lessons after Releasing a Laravel Package

As you may have noticed, last week our small team released a package called QuickAdmin - an adminpanel builder for a quick start. For me it was the first public open-source release of a package, so it was a really interesting experience. And I want to share some thoughts - hopefully it would help those who plan to release something similar.

1. Just ship it, no one will notice

If you want to release something to GitHub and/or Packagist, you can do it as soon as you're ready - don't be afraid of critics or bugs - there won't be any. I mean, no one will even notice that you released something (unless you're already famous). So don't postpone a release and don't procrastinate - just ship something and call it a version 1.0. Or 0.1. Or 0.0.1. Whatever. Then you can do as many iterations as you want. Same happened for us - we were silently creating new small versions until we decided that IT'S TIME - and at the time of the release we called it version 0.2. As a side benefit of this - when you later start talking about your package somewhere, people will notice that it's already not the first version and you are actually working on it. Cause quite a lot of packages get abandoned and not updated after first release.

2. You need marketing, cause no one will notice

Same thought - but from the other side: if you do want the world to hear about your package, you need to shout about it. I have a benefit of having this LaravelDaily blog (with 1000 daily visitors and 500+ email subscribers, yay!) - but you can just email or tweet someone from the community and ask to spread the word about your package. People don't bite. Thinking about it, even in open-source community, even if you release something for free - you need marketing. If you want to be heard and noticed, you need to tell people about yourself and convince them to spend TIME (which is money) on your package.

3. Spend time on documentation

One of the most common reason of NOT using some open-source package is lack of documentation. Imagine yourself trying to use something and then you see that you have to figure it out by yourself, without any instruction from the vendor. Come on, even IKEA does a better job. Another point - have a documentation somewhere separately, like we did as a separate webpage. In this case you won't rely on GitHub or any other system to update the docs, and you won't need to release a new version or commit anything to GitHub to fix typos or add small details to the docs. Also - please make some screenshots with the results that people will get from using the package. I know we are developers and we all think in command-line style, but visual results of the package are invaluable - they help people to evaluate whether to try at all.

4. You don't test enough

While releasing the package, we made several quite important mistakes: assuming that other people use the same server-stack as we do (silly, I know!), and not writing unit tests. The latter is debatable for open-source packages, but with operating system variety we bumped into issues. Windows/Linux/Mac environments work differently with folder and file permissions, and for some people the package didn't work at all. So it was a fun time hot-fixing, and some details remain to be fixed up to this day. Also, you don't even imagine the scenarios how people will use your package. Totally not in the way you predicted. They will make "dumb mistakes", and you will be thinking "how did they even come up with this use-case". But the thing is that they will blame you that "IT'S NOT WORKING!! HELP!! THE WORLD IS DYING!!" The best way of initial testing is to give your friends a package and actually WATCH them using it. Literally, sitting near them and watching their action sequence. You will have a better understanding of actual user use-cases.

5. People are kind and helpful

We already have more 50+ Stars and 10+ Forks on GitHub. It means not only that people are interested, but they spend their time to report issues, give suggestions and even make pull requests (we have several already). In general, I was quite amazed by positive reaction from the community - not only from those who read about package, but especially from those who actually installed it. That's the thing about open-source people, they try to help each other and share knowledge. But there's an important point to make - you have to react fast. If you get an issue report or a pull request, please be quick in your response. If you don't have time to actually look into issue or fix it, at least reply to a person with a "Thank you" note. Small things like this do matter a lot.

6. People are lazy and want everything for free

There's another side of free (or cheap) packages/things. People want it all to "just work", without them making even small single step in thinking. Therefore from several people we received reports that something doesn't work, and the solution for the "bug" that they didn't even bother to properly install the package, and in some cases didn't even understand what they did wrong. I've heard the same thing from a fellow package creator who sells his package on CodeCanyon - the buyers are usually junior developers who struggle with any small use-case which is out of their league. They want quality support and help with their server stack, they expect package creators to teach them how to code etc. Ridiculous, but the argument "WE PAID FOR IT!" (16 USD is a huge price for them, I imagine) is a killing one. Actually, on a phylosophical note, it's the same logic for business in general. If you give something for free or really cheap, people usually don't value it. They don't value your time, cause it's freebie-mentality people who have much time but little money. So they probably think that all people have much time, so why should they value yours?

7. The future is yours

After launch of the package, we received some ideas from the community on the future versions. As expected, there are multiple scenarios to use QuickAdmin (some of them radically different from our vision), and now it's up to us which to take on board. But the good thing is that the community are only the advisors, but not the decision makers. You hold all the keys and all the rights to do whatever you want with the package (or do nothing), so there's always room for improvement.

8. Work on it

The final and probably the most important point - popularity of the package depends on how will you work on it in the future. The initial release is just a start, and actual value of the package will be seen after at least half-year. As I mentioned, GitHub is full of abandoned packages, in Laravel case the most common example is packages who weren't converted from version 4 to 5. * * * * * So here are the thoughts - maybe you will add something? If you released any package or open-source code, maybe you have some more lessons or tips for newcomers to the scene?
Login or register to comment or ask questions

No comments or questions yet...

Like our articles?

Become a Premium Member for $129/year or $29/month
What else you will get:
  • 58 courses (1056 lessons, total 44 h 09 min)
  • 78 long-form tutorials (one new every week)
  • access to project repositories
  • access to private Discord

Recent Premium Tutorials