I recently gave a presentational talk to the development team at my work, on what it’s like contributing to open source. A common perception by people not involved is that the open source community seems like one big socialist hippie commune, whose motivations are entirely altruistic with little reward for the individual. The approach I took was to dispel this myth and show that for many who participate, their motivations are mostly self serving, with many personal gains to be made. Despite some of the awkward truths I focused on, the talk was received really well.
If you have a regular 9 to 5 job as a software engineer at a typical company, chances are likely that your job sucks in several ways. You work on the same types of projects every day. You work with the same technology every day, and most likely it’s dated. There are more modern technology stacks out there that are much more elegant, yet for a variety of non-technical reasons, you’re not allowed to use them at work. You also have deadlines. Deadlines lead to knocking out features as quickly as possible, which directly conflicts with the quality of your work, so you’re often forced to take ugly shortcuts, leaving little to be proud of.
If this is your only exposure to programming, it gets boring pretty quickly and isn’t much fun at all. Contrary to this, programming can actually be incredibly fun! Imagine your company had hundreds of different projects to choose from, and let you choose whichever one you wanted to work on. Then on top of that, they told you that you could use whichever technologies you wanted to, and that you could take as long as you needed to build it correctly — so long as the end result was the most well designed and beautifully written software you’ve ever produced. As a professional programmer, that sounds like a dream, but that’s exactly how it is when you work on open source projects. Choose your problem domain. Choose your technology stack. Choose your pace. Choose your quality.
There are two ways to become a better developer: writing code and reading code. This clearly doesn’t make sense in a silo on your own. There’s little to learn from reading your own code beyond reminiscent value, and you could write code on your own for years and the only lessons learned would be those you teach yourself. Naturally the real learning is to be had from interacting with other developers, writing code that they can review and give you feedback on, and reading code written by other developers with more experience and different approaches than you have.
Drawing back to your day job, how many developers do you collaborate directly with. A few? A dozen? A small pool that will give you much to learn from, but is still relatively limited in scope. The open source community is made up of thousands of developers, who over many years have produced millions of lines of code. Code of quality much greater than you’d ever be exposed to without stepping outside of your workplace.
One of the biggest misconceptions abut open source development is that it’s a financially fruitless labour. While true to a certain extent, there are actually several ways in which it can pay a monetary return, both indirectly and directly.
You may work a steady, full-time job, or you’re looking for one, and think of yourself as an employee with a fixed salary, in total contrast to those wild freelancers and entrepreneurs who don’t know where their next meal will come from. Wrong. You are a business, just like your employer is. You have one customer, your employer. Sometimes you might feel as though you’re stuck in your day job, when in actual fact you’re simply stuck with one client.
So how can you gain more clients? How can you gain a better client? By promoting your business of course. Open source provides a great way for you to showcase you and your ability as a developer. Your open source contributions can distinguish your CV from other developers, namely, your business’s competition. Graphic designers have always had the luxury of being able to display their portfolios, and developers can too. I’ve been on both sides of the hiring table, and when choosing between potential hires, someone with significant open source contributions has already demonstrated a clear passion for what they do, and therefore has a major advantage over those who are tasked with convincing people of the same, without having anything to show for it.
Getting your open source projects to the level of quality and usefulness where people are actually building production systems with them is huge achievement in itself. Stemming from that are direct opportunities for paid work. Your corporate users may need your software customised for their use cases. You may even be lucky enough that they’d like features developed into the project that are great ideas — things you might not have thought of, and will take the project to the next level. Who better to develop these than the creator of the software themselves? I’ve had several instances where this has occurred, and companies have sponsored development on features that, had I had the insight to think of, would have developed freely on my own anyway.
Hands on coding is only one small aspect of software development. There are many other disciplines that make up the process of shipping a successful product. Project management, community building, formal writing, product development and marketing. While freelancers and one-man commercial studios may get the benefit of dipping their toes into these different areas, as a developer at a typical company your role often doesn’t take you outside of the day to day coding.
Running an open source project properly will allow you to skill up in broad range of non-technical areas. I spend a lot of my time working on my most popular project, however these days only a small portion of this time is actually spent coding. Most of the time is spent in discussion with other developers on their feature ideas, coordinating the inclusion or exclusion of these, and providing support for new users. It’s hard work, but it’s a great and relevant experience.
Corollary to this, many non-technical people who’d like to contribute to open source in some way, believe that they don’t have anything worthwhile to offer. With all that’s involved, some of the most beneficial contributions are those of a non-technical nature. If this describes you, then please don’t hesitate to dive in. Your help means more than you can imagine.
The most obvious yet least tangible benefit in contributing to open source, is the idea I first alluded to around altruism and giving to others. As I mentioned, coordinating a non-trivial open source project can be hard work. It has its highs and lows, and sometimes it feels like there’s more of the latter. However every now and then, I’ll get a personal email of praise and gratitude. Not in any public forum where the soapbox can be a conduit for ulterior motives, just a private and genuine expression of thanks. I would never have thought of this as being particularly rewarding, until I actually experienced it. It really fills you with a true sense of pride and satisfaction, which makes it all worth while in the end.
The Chinese philosopher Lao Tzu said:
A journey of a thousand miles begins with a single step.
Getting started might seem like a daunting task. Start small. Ignore the inner voice that whispers in your ear, arguing that your open source idea wouldn’t be of any use to anyone. That might even be true, but it doesn’t matter. Do it anyway. A lot of my projects are only a few dozen lines of code. People have found them useful in ways I couldn’t have imagined.
Ideas can be hard to come by. Most of mine were itches I wanted to scratch. Product gaps in the technology stacks I’m interested in, or mundane processes I went through regularly, upon realising they could be automated and productised.
Perhaps you’re an end user of open source software, and it isn’t perfect. A feature works differently than how you think it should, or something is undocumented and you struggled to find it. These days it seems that the modus operandi is to throw up your arms, and complain as loudly as possible about how the software you’re using for free, isn’t exactly the way you want it to be. Don’t. You have the choice to do something about it. Dive into the source code. Contribute something back. Improve yourself, and be a part of something.