Almost exactly four years ago, I started writing code for what became my side project, Landscape. git log tells of the first commit, with a terseness that would define quite a few commit messages as it turns out.

Wed Jan 30 07:42:29 2013 +0100
    Initial commit

Its initial task was simply to scratch my own itch. I was always a big fan of Java's static analysis tools and things like sonar, so I wanted something for Python to do a similar job of automatically running code checks on every commit and checking progress over time. The less errors the more betterer.

It was quite a while before I thought it worthwhile to actually "launch" and did so with little fanfare, only for my own repositories and a few friends. After a while I announced it in a few places such as /r/python, and slowly people started trying it out and using it. It helps that it is free for open source, in that regard.

Fast forward four years and it's grown quite a bit, around 7,500 open-source repositories are being checked now, about 30,000 checks a month. And while it does have a few paying customers, which just about keeps the light on in the server room, the project isn't yet even ramen-profitable for me, the only person working on it and that's still in my spare time between freelancing jobs.

What follows is the list of lessons I learned in the last few years that I would certainly apply at the start had I known them.

Handling 'growth'

It's fair to say that I have never really handled the growth side well. To start with, everything happened organically, through word of mouth or snazzy badges to display on GitHub which look like this: . I never made any particular effort to get more users, however it keeps growing which is a good sign!

Of course it's a fairly recognised trope now of the engineer who focuses only on the technical problem and not on the business or customer problem. Despite being aware of this I still managed to fall into this trap. Rather than concentrating on "how is Landscape useful" and "what do people need" I spent more time dealing with building out infrastructure and having what is probably an unnecessarily well-managed deployment setup. I did not do enough of customer onboarding, conversion of users with free trials, keeping existing subscribers...

A lot of this came about from growing the userbase too fast. The resulting complexity required to keep it going with so many checks running meant that the majority of my time was spent fixing bugs and debugging failures in certain checks. This has lead to the current situation, in which I have more users and more to support than I have capacity to do so well enough to my own standards. This is especially a problem since most people using Landscape do so for free with open-source. That's something I would never want to change, since Landscape is built almost entirely of open-source parts, and I want to be able to give something back. I do need to get a balance between fixing problems without earning income from doing so and spending time increasing the chance of getting enough income to support the site.

It also means that support has prevented properly being able to move forward in adding requested features and making better customer acquisition. Having a plan for, or at least reacting in an objective manner, to unexpected growth would definitely have been useful.

Personal life versus side project

Your paid 'real' income

I have been both a full-time employee and a freelancer during this time, and each has a different set of problems. As an employee you can never really set aside a whole week to finish that big feature without taking holiday, and as a freelancer there's always the trade-off (or perhaps, Hobson's choice) between a nice contract that comes up or working harder on your own idea.

My main problem was never taking the time to categorise my ambitions for Landscape nor even the scope of the idea. Of course those change over time but I'm sure it would have found conundrums in 'real work' easier to deal with if I had.

Free time

Be careful not to neglect hobbies, friends and time to relax. I found that easy to do especially once there were quite a few users - I suddenly felt I had an obligation. Of course that's true, but it's important to take time out for yourself so you don't start resenting the side project, and also necessary to prevent burnout. If your side-project gains even a tiny amount of success, in terms of users or traction, that can be enough to make you feel like you need to work on it a lot more. If you still have a full time job, now you have two sources of work and stress to contend with.

This advice is just as true for working normally too. It's often hard enough to take time for yourself as it is. Don't let your side-project become an extra drain.

Emergencies

There is a German saying which translated directly is "life isn't a pony yard". It's very true - the best laid plans can often go wrong or be waylaid. There is a slightly morbid metric in the world of software development called the 'bus-factor'. It is a measurement of the problems that would occur if a team member who is the only one who knows a certain part of the system gets hit by a bus.

This is particularly poignant for me as I did actually get hit by a bus. Or at least, I got hit by something. I was riding a scooter while on holiday in Thailand at the end of 2015 and... woke up in hospital with brain damage a month later. This brought a swift halt to my ability to do things like walk, sit up straight and write code and keep the side project going.

It may sound silly in retrospect but I was definitely stressed while recovering due to worrying about 3 years of work going down the drain.

The lessons I learned from this episode were firstly, make sure you have a good backup and restore plan. Due to Murphy's law, the database server decided to have disk corruption while I was sitting in a hospital bed barely able to read let alone focus on a screen. Fortunately a friend was visiting at the time and managed to help me get a new machine up and running and restore the database backup. Equally, another friend kept tabs on new issues being opened to at least let people know that I wasn't going to be fixing any stability issues in a hurry. After a while I opened an issue to let people know, and I have to say the support received there was overwhelming.

The solution here is to have some friends who you trust enough to keep the project going in your absence, or to be willing to walk away and put your health and personal life first.

"Free for open source"

There are quite a lot of types of ways a software-as-a-service projects can start up and be small, either as a side-project, or skunkworks, or small team trying to bootstrap a startup, or even small startups with funding.

Most of them will be built on open-source libraries and frameworks, and there is fortunately often a sense of 'giving back', providing a service for open source for free. You can get continuous integration, deployment, testing metrics, static analysis, error reporting and much more for free if you're creating an open-source codebase.

It's worth noting that this does come with a burden, however, especially for a side-project. David Cramer, who created Sentry, has some useful words about building an open source service. It's hard to get the balance right but it's also something I never even thought about.

Open-source first then into customers

One thing to remember is that you have to have a boundary or goal for your project. If you're scratching an itch or just making something for fun, don't worry about it. If you're planning to make money, keep in mind that time spent working on the free version is time not spent working on the paid version. They operate in symbiosis - bug-fixes in one improve the other.

It is easy to concentrate on the bug-fixes at the expense of all else, neglecting the work required to gain paying customers which in turn means less income which in turn means less time to fix issues. I'd certainly say that my biggest failing for the duration of my project was that I was so fixated on fixing bugs and keeping the system stable that I never invested time in getting to the point where I had the time or income to improve the system at a fast enough rate.

Know where to draw the line between the desire to fix all bugs, the desire to help out open-source, and the desire to monetise the project, if that's your goal. At the end of the day, if your income gets to the point where you can work on it full time, that's benefiting all users!

Constantly adjust expectations and be prepared to fail

Always be ready to change your opinion. Don't get fixated on making your side-project successful. Don't aim for some vague goal such as 'location independent lifestyle' alone. I certainly think now that I should have concentrated on making a good product that people wanted than my own goals because that would have allowed me to see the good bits and the bad bits much quicker.

The main things I think are important to keep an eye on and be ready to change your mind are about the potential of the idea, the quality of what you have, and about yourself.

For myself, I needed to learn quite a lot about the skills I had and those I lacked. Since a side-project is very different in terms of discipline compared to working in a team, I had to get into the habit of actually sitting down and writing code regularly. I also needed to learn to prioritise without team members to bounce ideas off or a hierarchy above me to make those decisions.

Thinking of the future

After a very odd 2016 I'm now thinking about how I should move on professionally and also with this project, and have decided to make a run at making this into a full time job and a "real" business. Sort of an epiphany after being basically dead twelve months ago, it seems like the right time to grab the bull by the horns and make a go of it.

This blog post is more of a personal perspective, but there are plenty of other lessons learned that are specific to running the type of service that I have been. If you're interested in reading about those, there will be a blog post on the Landscape blog soon detailing exactly what kind of challenges it faced.

In order to start, I decided to create a crowd-funding page or sponsorship page. There are lots of people who have used Landscape for free and also several companies that have added their open source projects, so I'm hoping to drum up enough support via donations to at least kickstart the transition into a self-sustaining entity and start adding so many of the useful features and bug fixes that need to be done.

If you use Landscape, if you like Landscape, if you just want to read about that approach, check out the sponsorship page here: https://hugs.landscape.io !