This post is part of a series called Open Source Citizenry in which I discuss ways to eliminate the barriers that developers and companies face to participating in the open source community.

Last week at Red Dirt Ruby Conf, a tweet came through my stream that seemed to fit quite well with what I was already thinking about for my Open Source Citizenry post this week:

There are still too many developers who work with Open Source and not enough Open Source developers.Mike Perham

mperham

In last week’s post I tried to give some insight as to why open source is important for companies. This week, I’ll be looking at the other end of the spectrum: why should you, as a developer, actively contribute to open source? For some, the answer to this question feels natural; however, for many developers the idea of contributing to open source can be daunting, confusing, and somewhat frightening.

It Will Help You Land Your Next Job

Are you unsatisfied with your current job? If you are, it’s a great reason to start contributing to open source. If you’re stuck using a language or framework that you don’t enjoy, or a development practice that you don’t believe in, it’s practically imperative that you begin contributing to open source. Why, you ask?

Because the person that is in charge of hiring at the kind of company you really want to work at is going to be looking at an applicant’s open source contributions as a way to gauge talent. The more (good) open source you release, the closer you will be to getting your dream job before you’ve even had an interview.

Open source contributions are a fantastic way to evaluate incoming employees. The very first thing I do when I’m evaluating a potential hire at Intridea is look them up on GitHub. That’s not to say that we don’t hire people who haven’t done much in the way of open source contribution (there’s more to the hiring process than a single factor). However, I can say that I am going to be much more adamant in my arguments to hire a person if I can see the way their mind works from the open source projects they’ve released.

You Will Write Better Code

Open source is open to the entire world. Everyone can see what you’re writing. If you think this doesn’t have an effect on your willingness to take hacky shortcuts, you’re very wrong. Not only does the mere fact that it’s open source make you write your best code, but open source also helps you to think about your problem domain from a wider perspective.

As I released more and more open source projects, I began to have a kind of Spidey Sense for when something would make a good abstraction. When I’m architecting a project I’m already thinking about how certain pieces could be built in a modular way to maximize reusability. Even if these pieces don’t end up getting released as open source they are still useful extractions that get used in other projects down the road. The concept of building code for a community instead of just for an application makes the work more enjoyable.

Reputation is Real

For a software developer there are essentially two paths to extremely enviable positions of respect in the community: either you can be the tech genius behind a multi-billion dollar startup or you can release open source projects that thousands (not millions) of developers find useful. Guess which one is easier to accomplish?

Reputation isn’t just about vanity, either. Sure, it can feel good to have someone say “Oh cool, I’ve used X!” when they meet you, but building a reputation brings real benefits for you:

If you love your company, your company is automatically more respected because you’re a part of it if you have a good reputation. You’ll get the chance to meet, talk to, and learn from the people that you respect. Not that these people are otherwise inaccessible, but having your own “known” libraries gives you some common ground to strike up conversations, get input, and become a better developer. It will get you hired at awesome places. See above. You will get help when you want it. If you have a good reputation and embark on a new project you’ll be able to round up volunteers more quickly if you’re a known entity.

It can occasionally feel shallow or awkward (at least to me) to be thinking about and concentrating on my reputation in the community. However, look at it another way: open source reputation is built on real, honest-to-goodness work that is making people’s lives easier. And if you start releasing bad code, guess how long that reputation will stick around? Reputation is simply a measure of the respect that others have for you based on the merits of your code. And that’s not a bad thing.

That Warm Fuzzy Feeling

It just plain feels good to contribute to open source. The rush you get the first time (as an example) your patch is accepted into a major open source project is exciting. Seeing people using and talking about a library that you wrote is awesome. Hearing that some company that you really admire is using one of your libraries internally is amazing.

Open source feels good because it is good. You are offering value to a community of people free of charge, and in return you get to feel good about yourself and enjoy what you’re doing. Don’t be afraid to pat yourself on the back (maybe not too hard) for getting code out there. It’s more than most people do, and even if only ten developers ever find it useful, that’s ten people that saved hours or days of work because of something you did. And that’s a warm fuzzy feeling.

Standing on the Shoulders of 1,000,000 Dwarves

Open source is amazing because it doesn’t rely on the herculean efforts of a single person or even a few people. Open source is about thousands of people contributing tiny useful things that thousands of other people can build upon. It’s not about building the biggest boat, it’s about making the entire ocean rise. Each and every person who contributes to open source is making a difference to the ecosystem as a whole, and the more people that get involved the better the whole system works together. There can never be too many open source developers.

Barriers to Contribution

I think it’s relatively clear to most developers why open source contribution is a good thing. Additionally, I think there is something intrinsic to the developer’s mindset that drives us to crave the scrutiny and the ups and downs of publicly available code. So why doesn’t everyone write lots of open source? Here are a few reasons with my responses:

I’m not good enough to release open source. Poppycock! My first open source release was literally forking another project and hacking at it until it did something I wanted it to do that it didn’t do before. I had no idea what I was doing. I still don’t, most of the time, and I’ve released dozens of open source projects. People will think I suck because my code sucks. Nope, people will ignore your project if your code sucks. That’s the worst case scenario. And, to be honest, if you’re solving a problem that other people haven’t solved, they’ll probably use your code even if it sucks. And then they’ll patch it so it doesn’t suck anymore. Wins all around. How do I even do it? It seems complicated. It’s not, especially in the GitHub era. If you want to know how to do something, find a project that does something similar and steal their execution. Just steal and steal from everyone until you understand it well enough to forge your own path. I don’t have enough time! Find a way to make time! Identify a piece of your existing app code that other people would find useful and extract it out. This cuts your open source time down to abstraction instead of creation. Work on open source for half an hour a day. Convince your company to sponsor some open source time for employees. Contribute small patches to the libraries that you use on a regular basis. Where there’s a will, there’s a way.

I could go into detail and examples on each of these points (please feel free to ask me sometime), but the point is that whatever you think is holding you back from contributing to open source, the reality is much less frightening. Your first project will be the hardest to get out the door, but it gets exponentially easier each time after that.

In coming articles in the series, I’ll talk specifically about how to be a good open source user, how to be a good contributor, and how to be a good project owner. But if you only needed a tiny push to start getting involved, hopefully I was able to supply it. Please feel free to discuss anything related to open source contribution in the comments, I’d be happy to lend what knowledge I have to the service of getting everyone more involved!

Open Source Citizenry Series