Most of our daily tasks are powered by open source projects. Your text editor is open source, your website sits on an open source server, your phone uses an open source operating system, you look up things from an open source encyclopedia. The world profits from open source, big time.

In this blog post, we’re going to spell out how you can profit from your own side project, too.

Yeah, you probably know you should be doing it. You just never tried, or you might not even have one.

Yet, we all know the deal: as a developer, you can and will gain extra points in the job hunt and in the respect market for having some open source side projects.

I’ll eventually get to the story of my OSS project, ga-lite. But let’s start from the beginning: finding a good side project to work with.

1. Start by scratching your own itch

As a developer, you are constantly learning something new, right? Using new tools, trying out new, cool technologies, or just finding yourself in projects that require new methods of working.

Inevitably, learning new stuff requires failure. You will hit the same dead ends as many others before you. Sometimes, a dirty hack might be ok: the important part is keeping the forward momentum and taming that technology/tool/line.

However, I suggest you value and cherish the head-wall-moments. Dead ends are not only places where you learn, but also the itches you want to scratch when deciding on the next meaningful side project.

2. Timebox tweaking

The chances are that you hit gold only once every 50 side projects you start, so it is wise to play the numbers. When you find a good itch and the motivation to scratch it — a problem worth fixing — grab your tools, and build the first version as quick as possible.

Why be quick? You might ask. It’s a side project, so there’s no rush. Right?

Well, most often you can’t see what life has coming for you. It may happen that you suddenly get busy with work/school/life (or simply come up with a better idea next week), and there’s not as much time to spare for your new project as you had thought originally.

The best you can do is to make sure you finish something within a closed timeframe (e.g. a week). Which brings us to…

3. Do it. Press publish. Do it yesterday

Is it not good enough yet? Shush. Publish the project, even if it feels a bit awkward. We should all follow this good rule of thumb from the startup-y world:

If you’re not embarrassed by the first version of your product, you’ve launched too late.

– Reid Hoffman, founder of LinkedIn

You’re doing the thing you’re doing for a reason. If your project, squeaky and rough even, solves the problem you were trying to solve, it probably helps out a bunch of other people anyway. Don’t be afraid of people judging your work.

The most extreme reaction to your project would be that it tempts someone to invest time in investigating how they can use it. And then, they’ll provide you honest, non-sugarcoated feedback you can use to become better.

3. Accept that the only thing you really need is a good README

Git, pull requests, issues, wiki, readme, responsibility…overwhelming, overwhelming, overwhelming. It’s all part of the journey: you’re going to need those same tools in almost all your future work, so it’s good to get your hands dirty and fail safely.

The only thing you need is a good README. It will save a lot of pain and provide backup for you.

Don’t want to answer questions about how to use your product? Write it in the README.

Project still under development and things probably break? Write it in the README.

Not able to deliver on issues the same day, week or even month? Well, you get the idea.

You don’t need to be able to answer all possible questions right from the start. Learn as you go and handle new situations as they occur. People are usually helpful, especially for beginners, so just be brave to ask.

A real life example: ga-lite

What makes a side project successful? That someone uses it? Someone finds it so useful they share it at social media? That someone writes a blog post of it?

That’s something you determine for yourself. My most successful project yet is ga-lite, and it currently gets downloaded 10 million times a week. (I know, crazy.)

The itch

We all love benchmarks, don’t we? A good benchmark is like a game you can play, gain more and more and more points, and then you up your level.

There’s a popular benchmark called Google PageSpeed Insights. It’s a tool you can use to benchmark your site’s speed. It gives your site a score from 0 to 100, depending on the perceived speed of your website. If your site doesn’t get 100 points out of 100, Google PageSpeed Insights tells you the exact steps you need to take to make your site perform better.

Now, one of the criteria for the score is the caching time of your assets that you load to your site. Ironically, Google’s own Google Analytics script has a caching time of 2 hours, which reduces one point from your score.

The score is just a guideline. But imagine that you’ve spent hours optimizing only to come one point short of the perfect score. You’re tempted to go to great lengths to finish what you started.

How others scratched it…and how I fixed it

Go ahead – Google a solution. You’ll find some nasty hacks to hastily go around the situation, the ugliest solution being fooling the Google PageSpeed Insights crawler so that the analytics script isn’t shown to them.

You can just download the Google Analytics script to your own server, and then hope there are no breaking changes to it any time soon. This is discouraged by Google for obvious reasons, so some solutions go a little deeper with the thought: they update the script on your server automatically from time to time.

Sure, you CAN either just apply some of these workarounds and call it a day, or dismiss that missing point and settle for imperfectness.

I couldn’t do it. And that’s how ga-lite came to be.

It turns out that there’s a fully supported and documented API endpoint for sending analytics events for Google. To get the 100/100, all you would need to do is to create a simple client-side wrapper for that API that you could cache yourself to the server.

That was the first iteration of the library: just a really simple and lightweight script that sent only the page view events to Google Analytics.

Letting it spread: with some popularity comes great motivation

So it took me a weekend to get the script up and running, to write a readme, and to publish it to Github. The next months it was about small bug fixes and tweaks, with close to no marketing efforts at all.

It was only a year later, after the update from the free CDN provider called JSDelivr (where the main version of ga-lite is hosted), when I found the point-hungry perfectionists had found the project and started using it on different website projects.

The new version of JSDelivr included an analytics tool to check the daily, weekly and monthly downloads of the project. Suddenly the project had come the 50th most popular library of the CDN! Right now, we’re at about 10 million downloads per week. Seeing the project gain popularity eventually lead me to complete rewrite of the project.

…

Instead of a tool for creating value to an astonishing amount of sites around the world, ga-lite could easily have stayed as a bitter blog post. The beauty of sharing your work to the world is that small things can grow big.

My point is, you love free, open source projects. You use them every day. Most of them did not grow big overnight. Most of them started as single-dev projects.

And you couldn’t think of the world without them anymore.

So please: Publish your side projects. Share your work with the world. You’ll only get when you give first.