I'm very happy to announce that, as of today, our Laravel and PHP packages have been downloaded a million times. We now have more than 80 packages registered on Packagist. All combined they are downloaded around 150 000 times a month, and that number seems to be growing. Our GitHub organisation has taken the number 13 spot on GitHub Awards. I'm very proud that we could achieve this in a company with only two back end developers. It's really nice to know that the Laravel and PHP community find our packages useful. In this post I'd like to share the story behind our packages.

That one million number sounds impressive, but should be taken with a grain of salt. The amount of real users is probably much lower. Some of our packages require other ones of our own. For example, when downloading laravel-backup, our own db-dumper will get downloaded as well. And I’m pretty sure the total downloads get inflated by CI tools that download the various packages more than needed.

I think the actual number of downloads isn’t that important. The monthly growth number is a more representative figure of how our packages are doing popularity-wise.

The first package

The company where I work, Spatie, exists from 2003. We've always been using PHP. In the early years we dared to write our own framework. Yeah, we were still inexperienced, so that seemed the way to go. It was very basic, but it served us well. We were only creating small sites at that time. But after several years we realised that writing and maintaining your own framework is very time-consuming and we switched to Zend Framework 1.

In 2012 and 2013 we felt that the PHP ecosystem was pretty stale and we considered switching to Ruby and the Rail framework. We even made a couple of projects in Ruby to get our feet wet. But then we bumped into Laravel 4.0. I was immediately impressed by the expressive syntax and the big focus on developer happiness. I used it for a couple of projects and the more I learned about it, the more I loved using it. At that time a guy called Jeffrey Way started his next project Laracasts: a video tutorial site dedicated to Laravel. Realising that his videos could speed up my learning process immensely I immediately bought a lifetime subscription.

On the 4th of March in 2014 Jeffrey published a video titled "Continuous Integration With Travis". My mind was blown. Travis and the integration with GitHub looked so cool that I wanted to use it. A couple of months before he made the Travis video Jeffrey made a miniseries on package development. Those videos sparked the thought in my mind that I could create a package of my own.

In a project at the time we needed to automatically create screenshots of a website. With the things I learned in the Laracasts-videos I started working on my first package Browsershot. In essence it’s just a simple wrapper around PhantomJS. It was pretty exciting working in the open. I was thrilled every time the download counter got up and was incredibly happy that other people started writing about it.

Moarrrr packages!

As time went by we made more a more projects with Laravel. In our Zend Framework days we used a custom-built application template, called Blender, to kickstart all our projects. It was a sort of mini-cms. Beside the traditional CMS-functions Blender could do a lot of cool things: pull in data from Analytics to show graphs about the usage of the site, handle uploaded files, subscribe users to a MailChimp list, ... I started creating a Laravel version of Blender from scratch. I soon realised that some of the things I was porting to Laravel could be useful for other developers as well and decided to export these functionalities to external packages. In quick succession packages like laravel-newsletter, laravel-medialibrary and laravel-analytics were made.

I started to enjoy package development more and more. The positive feedback that I got early on from package users was very encouraging. I always considered coding purely as work, but because it was so much fun creating code that others could use as well I started coding in my free time as well. Besides working on packages I also polished the aformentioned application template called Blender and open sourced that too.

Since Spatie started I always was the only back-end developer. But that changed somewhere mid 2015 when Seb joined our team. He also likes working on our open source stuff. Because I blog and tweet a lot I’m the public face of our packages, but Seb does quite a lot too. He loves working on the more lower level stuff (the regex package is one of his). I myself enjoy working on the bigger infrastructure kind of packages like backup and medialibrary.

Currently every new package that we create gets born inside a client project. In almost every project we find some functionality that can be extracted to it’s own package.

Making time to work on open source

People often ask me if it isn’t very time-consuming to create packages. The truth is that it indeed takes a lot of time. Creating the code for the package itself, writing tests, writing documentation and getting the word out all takes a fair amount of time. And that’s just the start. When a first stable release gets tagged the work is not over. Maintaining a package, responding to issues, reviewing PR’s takes a lot of time (and dedication) too. At the time of this writing we've responded to almost 1 000 issues and reviewed more than 750 PR's.

We do long-term planning at Spatie, but we also have a weekly short-term planning meeting. When scheduling out to the coming week we only plan four days. So we have one work day we can be a bit flexible with. Do not imagine that day as like a fixed day, that time is mostly spread out in that week. Sometimes we do client work in that time, because an estimation was wrong, or we need to do some support things. But that time is also used to review/solve issues and review/merge pull requests.

Like I’ve already mentioned I do enjoy working on packages in my free time as well. So a few times a week I spend some time in the evening to continue improving the released ones and creating new stuff.

The benefits of creating packages

There are many benefits of creating packages that makes time working on open source code well spent. You’ll learn a lot by working on packages. Each package needs to be carefully crafted. Laravel itself greatly emphasises developer happiness. It provides a clear and understandable syntax. I want that all our packages are easy to use too. Thinking about how other people will use your code will make you a better developer. We also learn a lot from the issues reported and the PR’s submitted by the users of our packages.

A second benefit is, that sometimes, as a package gains some traction, you get quality code for free. Our laravel-fractal package is a developer friendly wrapper around The League’s Fractal package. I coded up the basic functionality to I needed myself and tagged that 1.0.0. In the next weeks I almost daily got a pull request adding another great feature to the package. And now it supports almost everything League’s Fractal can do. I think 90% of the code of that package was written by the community.

Another benefit is a commercial one. When looking at our code I hope you’ll conclude that we do know our way around PHP and Laravel. Recently we’ve landed some projects because of our open source work. In most cases users of our packages were telling their bosses to hire us for a Laravel specific project.

And last but not least we’re also dogfooding ourselves. Our own packages get used on most projects. If we discover a bug in a package used in a project we can very quickly fix that and distribute that fix through the power of Composer to our other projects. The only package that didn’t get used in any of our own projects is laravel-permission. That one was coded up just for fun.

Why we require the latest version of PHP

Before PHP 7 got released at the end of last year, we picked the oldest, still supported PHP version as a minimum requirement for a newly created package. When PHP 7 got released we changed our policy on that. Every new package now requires PHP 7.

The most asked question in the issuetrackers of our packages is "Why can't you support PHP 5.6". I'd like to give some background on our stance.

We create these packages primarily for our own future projects. The fact that they become popular is just a nice side effect. At our company PHP 5 is dead. So it makes zero sense to make our packages PHP 5 compatible. The latest new features such as the scalar type hints, return types, anonymous classes and the null coalescing operator can help create elegant code.

I'm well aware that requiring PHP 7 will hurt the popularity of our packages in the short run. But, like already popularity is not our main goal. People who are using the latest and greatest version of PHP can benefit from our work. And I hope others will be nudged a bit towards PHP 7 by our decision. When PHP 7.1 gets released we'll probably set that as our minimum required version. Can't wait to use that fancy iterable typehint.

Top 10 of most popular packages

When taking amount of downloads into consideration these are our 10 most popular packages:

1. laravel-backup
2. pdf-to-image
3. laravel-glide
4. string
5. laravel-analytics
6. db-dumper
7. laravel-medialibrary
8. laravel-tail
9. laravel-fractal
10. laravel-permission

Like already mentioned in the intro some of these packages, like string and db-dumper, probably get a big download boost because there are required by other packages.

Not so popular packages

There are some packages, that we ourselves use in every single project, that I expected to be more popular. I hope by mentioning them here they'll get a little attention. If you decide to give the ones mentioned below a shot, I hope that you'll enjoy using them as much as we do.

The first one in this category is laravel-menu. That one can generate html menus. It provides you with a beautiful, Laravel worthy, API to work with. It can even detect which one of the menu items should be considered active. Maybe I haven't search well enough for it, and I'm certainly biased, but I think there's no alternative that provides such an easy to work with API.

Secondly, there's laravel-translatable. This one can make your Eloquent models hold translations. Unlike Dimitris Savvopoulos' excellent translatable package, ours does not need separate translation tables to store translations. Our package stores the translations as json in a column of the table. It's very easy to work with, there are no extra queries needed to fetch translations. We got the idea to store translations as json in a column from Mohamed Said (who now enjoys fame as Laravel employee #1 ?).

And lastly I like to mention laravel-medialibrary. You saw this package at number 7 in the top 10 above, but I think this one deserves to be a few places higher. The package can associate all kind of media files (images, PDFs, ...) with Eloquent models. It can generate thumbnails, and can store files on external filesystem and generate URLs to the files. It's very easy to work with and it has excellent documentation. I think a lot of applications need to handle uploaded images and files. This package can save you countless hours by managing all of that for you.

The future

The past two years we’ve been regularly released packages. The most common problems in our projects are already solved with one of our packages. That’s why our package output will probably diminish a bit in the foreseeable future.

Of course we’re dedicated to maintaining our code. We’ve recently created new major releases of laravel-backup, laravel-newsletter, laravel-analtyics and a few others.

There’s no fixed roadmap for new packages. It really depends on the client projects we’re handling. If there is something there that can be solved in a generic way, we’ll create a package.

In closing

Creating and working on open source packages continues to be a truly fun experience. On a technical level I've learned lots of things that I wouldn't have learned when working solely on client projects.

The positive feedback for our users also gave me enough confidence to start this blog and start speak publicly. The past year I've spoken at several local users groups (and I'm co-organizing the one in my home town), I got to speak at Laracon EU, and have two talks at [php]world to look forward to. At all those occasions I got to meet a lot of awesome fellow developers.

That all probably wouldn't have happened if I stayed in my little bubble. So in short, working on open source helped getting to connect to the community. That sounds a bit corny, but that doesn't make it less true.

If you haven't used our packages before, take a look at the list on our company website. Probably we've made some things that could be useful to you. If you already are using any of our stuff, and you like it, send us a postcard.