One hundred days of open source

Adam Butler
5 min readJan 20, 2015

--

I have no idea how to build a website… well not really. The thought of building, publishing and launching a website end-to-end without using any open source component, be it Nginx or Ruby-on-Rails, let alone the operating system, seems like an impossible task to me. I expect most web developers would say the same; at very least those born from the eighties onwards.

The reason for this is that we rely on building blocks and these blocks allow us to write our intentions in a far abstracted manner. Looking at a typical web application this might consist of a web server, an application engine and a database, all of which have their own dependencies in a seemingly infinite cascade of reliance, hitting rock bottom only deep at the hardware level.

Most of this stack happens to be open source and without it we couldn’t dream of building the kind of sophisticated software that we have come to expect today. I believe giving back what you can to open source is really important and through doing it myself I’ve become a more rounded person by working to other peoples ideals, made new friends and have been involved in the success of various projects that I use myself and love greatly.

I want to tell the story of my first one hundred days of an experiment with making everything I build open source. Naturally I will start from the beginning back in the days when I was doing Flash websites. At this time I was deluded into the assumption that if I gave away my work someone was bound to steal it and make their fortunes from it.

Fresh out of university, I, like most of my peers. had a huge bank of ideas for new projects, each one more exciting than the last. This almost always led to these projects being dropped in favour of the next. I was left with a hundred or so half-baked projects ranging from a server manager to an iPad game. I always found myself doing the bit that I found fun and then getting distracted. It wasn’t all a complete waste of time though, beyond keeping myself entertained I was also learning and working out what I wanted to do with my life.

A couple of years ago I started learning Ruby-on-Rails. I specifically wanted to build a web application called Conduct that allowed you to create questions and make group decisions quickly and easily. This was a product that I wanted to use myself, for arranging meetup talks, but I couldn’t find anything that matched the elegance of what I planned to build. I set out developing the application and enforced a ban on myself to see the project through to the end… eighteen months go by and I’ve not shipped. I’m frustrated and worst of all I’m not learning anything new.

It was around this time, in August 2014, that I broke my rule. I had a server root password that I needed to send to a someone via our client and I wanted a way to do this as simply as e-mail but as it was only on a local network it wasn’t necessary for this message to be encrypted. I wanted to build something just slightly better than asking someone to delete the email after they read it.

In my lunch break I quickly threw together a Ruby-on-Rails application called Kevlar, basically snapchat for text. I quickly threw it up on Heroku for ease and made it open source. I loved this little project, it was simple, required no registration and did one job well. Over the coming weeks I iterated on it, shipping often, it was a refreshing change.

About five weeks later I broke my rule again, I tried using Poll Everywhere at an event I was running but its promising well designed front-of-house doesn’t quite propagate into the application itself. The application also required registration, which for my purposes wasn’t necessary. I decided to build Poll, an application to run polls simply, without registration and in realtime. I now had two little projects I was maintaining on a daily basis and each day I embraced making atomic changes that allowed me to deploy regularly. It was awesome to see people actually using it, a French university even ran their student elections on it.

I’ve always found the best way to learn something new is to challenge yourself, sometimes literally putting your own assumptions or beliefs to the test. Only a couple of months ago I had a bias against HAML because of other peoples opinions, but after challenging this bias I’ve come to love it and am now using HAML in most new projects. Taking the same approach I ran my open source experiment by forcing myself to ship open source everyday, starting by setting myself a few new rules -

  1. Do something every day that is or will be open source
  2. Leave it better than you found it
  3. Ship early, ship often

The work I do every day can be as small or as big as I like but I like to ensure it’s always wrapped up in the same day; if it’s better than I found it then I will usually ship it, even if it has known bugs.

With my long term project Conduct I found that the application was never at the level of quality that I was happy to launch.

One of my concerns stopping me shipping was the imperfect mobile responsiveness. In contrast, when I built Kevlar I shipped regardless of the lack of any mobile optimisation because a bad mobile interface is always better than no interface at all.

In November I started to contribute more to other peoples projects, mostly modules that I consume but also projects like 24 pull requests. I also started digging through my hard drives looking for projects that I could release. I often build tools for myself and found some gems like orientation that had no reason to be closed source at all. I even eventually got back to Conduct and with my refreshed attitude just launched and open sourced it. Turns out unlike Kevlar and Poll nobody uses it, hence rule #3 ship early, ship often; you never know if something is useful until you test it with real users.

With my new projects I started open sourcing before I even wrote a line of code. This stopped me from even taking into consideration of when the project was ready for other peoples eyes.

Quick tip: Git allows you to do empty commits with -
git commit -m “Init project” —allow-empty

More recently I started working on the website for our upcoming wedding. I wanted it to be a tool that took RSVPs, managed guests and tasks, calculated costs and accepted photo uploads. For the last couple of months my efforts have been mostly focused on building this project, which you can find on my GitHub as wedding-on-rails source demo.

Finally my latest venture is Alfred Workflow Package Manager; if you’re looking at getting started with open source I’d love it if you stop by and contribute :-)

All of this has completely changed the way I work in both my side projects and in my day job. I don’t think finding time for open source every day is sustainable. It interrupts me from other priorities and I’ve been writing less since starting but for now I’ll continue to do it when I can.

--

--

Adam Butler

Full-stack Developer @Simpleweb - Tech Geek - Designer of Beautiful Things™ — http://github.com/adambutlerhttp://lab.io