Bad Reasons to Hack on Open Source Projects

Update: the original title was "Reason Why You Shouldn't Hack on Open Source Projects", but commenters pointed out that this title would fit better.

People admire open source contributors, just like they admire entrepreneurs and artists. That's awesome, they'll tell you. Improve the world, I love that. Go for it! (It's easy for them to say.)

But as with anything that becomes more prestigious, people recommending it to you will ignore your opportunity costs, and you may try to do it for the wrong reasons. You shouldn't become an artist so you can be famous, but because there's art inside of you that will kill you if you don't let it out. You shouldn't found a startup to make money, but because it's your life's work. And you shouldn't hack on open source projects because someone told you that your GitHub profile is your new resume, but because you want to code socially. I won't focus on why open source is good in this post, but rather warn you about some common, bad reasons to hack on open source projects.

(image: jalbertbowdenii)

1. Some workaholic company expects you to.

Some companies only want to hire programmers who eat, breathe, and sleep coding, and if your nights and weekends aren't spent hacking on side projects that they can see on GitHub, then you can't prove to them that you're enough of a single-minded workaholic to fit in. So don't–find somewhere else to work.

We've just talked to a lot of companies and a lot of programmers for our Gridmancer challenge job matching. Almost all the good programmers had scant GitHub profiles but felt somehow ashamed of it, as if they were missing some HR checkbox. Most of the employers were looking for that checkbox, but only as a substitute for a portfolio. It's a far stronger signal to have well-presented projects in a portfolio on your personal site, closed-source or not, than to have some hard-to-evaluate code linked to your GitHub profile. (Your GitHub profile is not a portfolio.) If you can present projects that you did at work in a previous coding job, then that's good, too. It's worse when you can't show off any of the great projects you've worked on because your past employers won't let you–but even then, the best way to get jobs is through referrals, not resumes, so if you've even gotten to the HR checkbox phase, you're doing it the hard way.

A variant on this is when you want to work for a particular company, but they insist that you do free work for them so they can see how good you are first. Given how in-demand programmers are right now, this usually only makes sense when either you really want to work at that company and they know it, or you have no experience, free time, and no other way to show them just how great you are.

If you want a job, don't hack on open source just so you can get a job. Just try to get a job.

2. You want love and acceptance.

When you come into an open source project, figure out what needs doing, do a bunch of work to help out, and submit your mighty pull request, you may be like the Peace Corps volunteer proudly saying so everyone on the plane home can hear, "I really helped those people. I helped them a lot." After all, you put in many hours of effort, and you're just trying to be helpful.

But meanwhile, the part-time volunteer maintainer who has to merge your pull request, while appreciative, is already busy and now has to test, understand, and merge your new code, and perhaps your changes interfere with some existing functionality or need documentation or don't quite have the right style. He's grateful (as long as your code actually helps), but he's busy, and he probably doesn't realize how long you spent on this, or even that you're as human as he is–it's the internet, after all. He merges in your pull request, says, "Thanks! Can you sign the CLA?", and that's it.

Some open source projects grow into great communities and are warm and friendly and will go out of their way to get to know you, but most won't. Hacking on open source is usually an inefficient way to connect with other people, since the code is right in front of you, but the coder isn’t.

At CodeCombat, we're making a big effort to be friendly and appreciative with our contributors, since we know how hard our Archmages work on the game, but I'll be the first to admit that it's difficult. I really hope that you care about the code more than about me caring about you caring about the code, because the code really needs to be its own reward for you (at least until you're in San Francisco and I can have you over for dinner to express my appreciation).

3. You want to be a hero who transforms the vision of the project.

If you have strong ideas about how the future of some open source project, then it's not going to work to come in with your sleeves rolled up and a manifesto prepared. Even if you are ready to do all the work to transform the project and could just get it done by yourself in two weeks, you still have to understand that it's a community effort, and the community has to agree on things. That's more important than the time you're willing to put in. In the worst case, you split the community and kill the project.

If you want to have control, then start your own project–and either keep it closed-source or make it clear that you're going to be the benevolent dictator. Most open source projects are like early communist countries: the individual is less important than the community, the idealists work hard while others watch, and no one gets paid. If that turns you off, then you can try to find or found a project with a different political system.

4. You want to contribute to a project you don't actually use.

I was visiting the Google Summer of Code IRC channel, and many of the GSoC organizations were complaining about how they have never, ever gotten a good long-term contributor from someone who wasn't already a user of their open source software. I don't know why you would work on software that you don't use, if you had the choice. How can you know what to improve? How can it be any fun?

5. You want to claim credit for contributing and then move on.

This actually works. You can make a few pull requests to several high-profile projects, add "Minor contributor to X, Y, and Z" to your list of accomplishments, and very efficiently impress certain people and employers. It probably won't work this well for long if too many people start doing it, and it seems a little disingenuous, but I guess you did help each project out a bit. So who are we open-source maintainers to complain that you didn't stay and write even more code for free?

I don't know, but I think you'll find it more rewarding to really get involved in a project. You'll at least learn a lot more from truly understanding the codebase and figuring out how to make significant changes.

6. You don't realize how much your time is worth.

If you can code well and want money, then don't fall into the ultra-common programmer trap of undervaluing your time. Many heavy open source contributors are less motivated by money than by filling the world with great software. If that's not you, and you need money, then find a way to get paid, because you're worth it. Don't let anyone convince you that you need to give your time away to open source before you're worth paying.

That's all I could think of. There are many more good reasons to hack on open source projects, and if it's something you want to do, you'll already know most of the obvious ones. Here are three more:

CodeCombat is now in the Google Summer of Code 2014, so if you're a student developer and want to get paid to hack on open source for the summer, then check out our suggested projects (or propose your own). There's some really fun stuff in there, like adding massively multiplayer sandbox play. And if you want to hack on something other than a programming game, there are many other great organizations to work with.

We're also giving away $3250 in prizes for writing open source parsers for your programming language of choice on a new ChallengePost challenge. Like compilers? Choose your favorite language and write your own in-browser parser to the Mozilla abstract syntax tree format. The best parser will win a 13" MacBook Air, and there are also three iPad Airs to claim.

Help the world. In our last post about why startups should go open source, we mentioned that the non-profit peer-to-peer microlending organization Zidisha was considering doing it. Well, we convinced them, and now they're seeing great contributions from enthusiastic volunteers wanting to make a difference and fight poverty. They need a lot of help, and it's really easy to make a big difference, so if you know any PHP, why not see how you can help?