Hacker News new | past | comments | ask | show | jobs | submit login
Why I still don’t contribute to open source (brandonhays.com)
170 points by phiggy on May 3, 2011 | hide | past | web | favorite | 97 comments

Here's how you contribute to open source. Start writing some software. Use an open source library.

One day, something will break. Instead of whining on the bug tracker or hunting for shitty workarounds... open up the library source, delete the bug, make a diff, and send that to the project maintainers with a note like, "I was trying to call foobar, but it segfaults because bazquux is off by one. Patch attached."

That's contributing to open source.

Alternatively, write some code and share it with people. That's good too.

I just committed a change to someone's library last week. It was like a lightbulb going off in my head - "Oh, so it's just this easy."

I wonder how much more difficult this was before Github.

The real breakthrough wasn't github, but patch by Larry Wall, http://groups.google.com/group/mod.sources/browse_thread/thr... together with UUCP.

In the grand picture, github is just a nice frontend to patch that also replaces UUCP with something more modern.

I'm a hardcore UNIX fan that hates "social networking", but Github is really a major advancement over patch + email.

Here are a few questions that might come up if you aren't using Github: "Is what I'm patching the canonical source?" "How do I set up my own VC for my patchset I'm maintaining?" "Am I sending my patch to the right person?"

That adds up to mental friction that distracts from actually writing the patch. With Github, you click a button and get your own repository. You click another button to inform the author (and! other people with their own forks, if you want). The author accepts your patch and the revision history has your name attached to it.

It makes it so easy that there is no excuse not to fix that tiny bug. Especially documentation bugs... you don't even need a git client to fix those!

The trouble isn't in installing git, or interacting through mailing lists. The trouble is in getting started. In order to contribute to something(fix a bug/develop something new) one has to understand what the expected behavior of the software is, how is it deviating from the current behavior. How and what can one do to correct it.

This involves understanding of many things. Technology, the programming language and some CS areas. All of this most of the times a little out of reach of the ordinary day to day to programmer. The problem in simple words is 'The barrier to entry' to contributing most Perl/Python interpreter kind of projects is too high. You need to know a lot to do anything there.

I think that prevents most people from contributing even if they want to contribute.

I'm not an expert in Unix history, but I think that long before "patch" the tool, the output of diff was a script that you could use as a patch by piping it into ed.

> I wonder how much more difficult this was before Github.

Not much. Open source, and... well, software development in general is about people. Github makes it a bit easier, but the basic process is the same. Here are some programs developed before github:

Linux, Emacs, X11, Gnome, KDE, Apache, PHP, Tcl, Perl, Python, Ruby. They turned out ok and managed to garner their fair share of contributors.

Dealing with weird build chains and getting each projects particular patch acceptance processes correct was pretty annoying. Dynamic languages / more "sane" build systems and "pull requests" have reduced friction, but it is not a categorically different process. The interesting thing is that the friction has been so reduced that GH has made contributing patches upstream my default behavior instead of something I would do if I wanted to commit to being a contributor.

Sure, but I imagine that actually working on the Linux kernel, making and testing patches, submitting them, and having them accepted was much more difficult.

Yes, they turned out okay, but that doesn't mean it wasn't much more difficult, right?

The difficult part is in understanding and working with the code. The rest is 'transaction costs', which are certainly lower with github, but IMO not that big a deal compared to getting difficult C code right.

What does github have to do with the Linux kernel? iIt's not hosted there, and I don't imagine cloning from git.kernel.org and pushing to github would provide much value (not to mention you'd probably blow right past the free account's space limit).


Github hosts mirrors of a few popular open-source projects, which is handy because they have much better source browsing than the alternatives.

That was an example.

When the process to doing something becomes easier it acts as a catalyst to doing things(Increases the pace of things, makes people less stressed out). But that itself doesn't increase the total number of new projects.

Doing something new is totally different. What it takes to do nobody knows very clearly. This question has eluded humanity since its existence. You don't find Pyramids like the ones Giza in all ancient civilizations. You don't find literary works like that in India in any other ancient civilization. Sure the process to do anything in those societies may have been a catalyst.But starting something new totally depends on the quality of people who are there and in what many volumes they exist.

While git might have made contribution easier, it will not make number of new projects higher.

> I wonder how much more difficult this was before Github.

It wasn't really that more difficult. You either uploaded your patch into their bug tracker, or you sent it to them via email. Not a big deal at all. Many projects still work that way.

EDIT: Those who downvoted this comment, would you care to explain what's wrong with this statement? That would be very helpful. Thanks.

It wasn't much more difficult.

It just wasn't as good looking.

I would say it was.

First you have to search for information about where to get the source and where to submit patches. Sometimes even this can be annoying.

Then systems like SVN makes it complicated when you want to work on it, try things out, etc., i.e. when you want to produce a patch-series where you could also revert some stuff. I.e. all non-trivial work. You need a system where you can make offline-commits.

Then there is some extra work to generate the patch, zip it and attach it to some report somewhere.

On GitHub, you just fork, work on it and make a pull request.

You're mostly talking about the free git Software by Junio Hamano and Linus Torvalds [1] not the commercial GitHub [2] system, by GitHub Inc., right?

[1] http://en.wikipedia.org/wiki/Git_(software) [2] Of course, free software on github is hosted for free.

Well, for one part. Whereby I was talking even more generally; any decentralized revision control system can do what I meant. But 'before GitHub' was a time where such decentralized systems where not really in wide use as they are today now (and GitHub has played an important role here).

But another important part where I was indeed referring to GitHub: The portal allows easy forking on the site and you can easily make pull requests. That means you don't have to prepare a patch-queue or so which would require additional work. The project maintainer can actually easily look at your fork. The functionality GitHub provides makes it just simpler and more importantly also straight forward, i.e. you don't need to figure out first where to put your patch.

Exactly. All the time while I was studying I've lamented about contributing to open source, especially to the kernel. I've read tons of things, code, os books. I think I've teached myself a pretty good understanding of how it all works (never taking a os course at the university, majored in math).

Not a single patch came out of it over the course of almost 10 years (taking the time into account I dabbled around in Linux in high school).

Then the massive linux graphics stack rewrite broke my laptop. I've had no clue. Zero. Nada. But I've tried to fix it and actually succeeded somewhat. Then I've noticed that other stuff isn't working anymore in the new graphics stack (it was an old machine and devs were busy porting the newer chip generations). So I've started with more serious stuff. In retrospection, re-reading old mails and patches my lack of clue about the code, process and people is hilarious. But pretty soon some fools started to use my XVideo implementation (despite all the bugs) and reported problems. And I just wanted to get my laptop back into a working order with the cool new linux graphics stack.

I've had a reason to ship and users that bugged me. So I've shipped.

Now, two years later I'm a major contributor (even managed to once get a top 20 position by patches for a kernel release due to a major cleanup). In a specific area (Intel graphics memory manager) all patches are either reviewed by me or written by me.

I absolutely felt the same, but basically made myself take a look at the go[1] issue tracker[2], before just committing to working on a bug. Once I got one fixed, it was an amazing feeling - I can contribute to this project that is run by people from goddamn bell labs, legends in the industry[3], etc. - though my contribution may be small, I was able to fix something. Getting past that first hurdle was just amazing

Theeeeeeen I tried a more serious bug[4] - the only high-priority one in the whole tracker which hadn't been solved for over a year (yeah. Maybe a bit over-ambitious). After hours of learning C and the codebase (my day job is as a financial CRUD C#-er) I was able to find a way to fix it :-)

It has genuinely been a voyage into the unknown and taken quite some effort + despite feeling utterly not up to the task, but being able to contribute even minor changes to a project you believe in is just the most amazing thing, really.

So I am with @briancurtin on this one - just push yourself to try it, it's genuinely worth it. Knowing you contributed something to a project you care about is just damn awesome. Seriously :)





For those who are interested, I just blogged about the patch I made[1] :)


It’s not obvious where to start.

Just ask. If you feel like you are overwhelmed or too inexperienced (maybe not in skill, but just in this project) -- just ask someone. IRC is good if they have a channel or the mailing list if you have to.

Just ask for some easy tickets. Read the source, figure out the problem, create a test, make your patch, submit the patch using whatever process they use on the project. This will get you familiar with the source code and their development process at the same time.

Trying to contribute and failing makes me feel stupid.

Maybe you should take the time to find out why your contributions are being ignored or turned down. You might not get an answer right away, but it doesn't hurt to ask. Internalize the responses you get and adjust your approach accordingly.

Few people contribute to open source with the intent of making other people feel stupid.

There’s no time.

Priorities. It helps if your employer gives you a little time at work to contribute back to open source. But ymmv depending on where you work.

Even a couple of hours out of your weekend to squash a bug is appreciated by everyone.

I've only tried contributing to OSS once. They had n00b-tagged tasks on pivotal tracker, the problem is they wouldn't give me the permissions to sign-up for that task. Instead they said to claim it on IRC. Except that two other people thought they were the only one doing the same task (because that's a really stupid way of doing it) and I just said "screw it"- it wasn't worth all the drama. I'd just rather just work my own stuff.

That was just a poorly managed open-source project. There are enough of them out there, but not contributing because of only one experience is like saying you won't ever listen to music again because you bought a nickelback album.

I've worried about this a little at Mozilla. We have people who get in contact looking for a first bug, and the ideal would be to say "take this exact bug" (this has a very high follow-up rate). But what happens if one person starts that bug, and then another does too. Have we scared both away? Not sure the solution here.

...yes... cough

I agree that it's not an easy problem to solve, but I'm also not sure that you want to solve it (i.e. minimize attrition). You don't want to cripple your project by collecting the maximum number of n00bs possible.

For me it was more like "oh, right, I hate working with people. I can't believe I forgot that." I was just pointing out that the difficulty of collaboration might be a more significant barrier than the commenter I was replying to made it out to be.

You might end up with two patches. Pick the better one.

Or you might end up with a patch in two days that the other person who started it has left to atrophy for two months.

Not a problem really. The hardest part for a lot of new comers is literally, "Where do I start?" Not every new comer asking for a ticket is a drooling zombie hoping to trash your beautiful project with horrible undead patches.

Yeah. I'm probably worrying too hard about this.

> The hardest part for a lot of new comers is literally, "Where do I start?"

I'm thinking we have a good answer for this, feedback welcome: https://developer.mozilla.org/En/Introduction

> Not every new comer asking for a ticket is a drooling zombie hoping to trash your beautiful project with horrible undead patches.

We have the opposite problem - newcomers providing patches that get lost because they didn't know to ask for review, or didn't ask the right person (also our fault really), or because we fucked up and didn't respond. We're working on this problem too - dashboards, metrics, awareness, etc, to stop it happening in the future.

Don't sign-up to do a task.

Write the code, then say you've done it and ask where you should put the source.

In my experience running a few open source projects it's all too common to get a random person asking for commit privileged (or whatever) before they actually do anything.

Working code has a way of focusing people.

Don't contribute to open source for the sake of contributing, contribute because you are excited about something.

Implement this feature you always wanted to have, fix this bug which has been annoying for who knows how long and you will be motivated and excited which is pretty much a prerequisite.

Also if you want to contribute to a project get to know the community around it, find out who is responsible for what and use this knowledge to talk directly to the people who are working on the stuff you are interested in.

If you want to be in for the long run, no amount of posting tickets to the mailing list will make you a member of the community. A discussion in the development IRC channel, no matter if it's about the latest piece of tech, Portal 2 which just came out or our all time favorite the best editor, will teach you more about the community in a couple of minutes than any amount of posting tickets to the bug tracker will.

Despite the stereotype of the autistic geek this sort of socializing is an important part of any project with a healthy community, if you want to contribute to open source you should be aware of that.

You definitely need to adopt a reasonably thick skin when contributing. I've had many patches flat out ignored (literally no response at all from the mailing list despite other discussions going on around it), I've had patches interpreted as a kind of subversive / ideological attack on the project (usually it's a feature or issue that was discussed before and you're unknowingly picking at an old sore) and rejected.

What amazes me most though is that while I've had plenty of positive comments from other users of the projects I've contributed, not once have I ever had a project maintainer say "Thank you". I can understand this from some perspectives (they created the whole project and gave it to you, and now they have to do more work to accept your patch for something they probably don't need themselves - so saying thank you in return for one tiny patch seems very asymmetrical). Nonetheless, it surprises me that simple words of encouragement are often so lacking from the open source movement. At a human level it feels very strange to spend hours working on something for free, to give it as a gesture of good will to a community of people you thought were your friends and get a response somewhere between neutral and hostile.

Nonetheless, the rewarding feeling from patches I've had accepted has outweighed all negatives, so I can highly recommending just putting on your thick skin and going out there and trying.

What a lot of folks might not get is that there isn't one thing that can be called "contributing to Open Source", which is why setting that as a goal is somewhat vague and difficult to accomplish. If you can find a project that you want to contribute to, then that's awesome. If you can't, that's understandable.

  > There’s no certification, ceremony, or merit badge
That's part of the point. Anyone can code, design, document, whatever. There's nobody telling you you're ready and there's nobody telling you you can't.

  > It’s not obvious where to start.
If you don't have an obvious starting point, that's okay. Most Open Source contributions are coders solving problems that interest them. If you don't have one of those right now, that's no big deal. Not contributing to open source isn't the end of the world, it's just one of many ways to sharpen your skills.

  > Open source is for people who are 
  > better at this than me.
Gotta start somewhere though. In my experience, a project's owner usually gives invaluable feedback if you send in a patch that isn't quite there yet.

  > Trying to contribute and failing makes me feel stupid. 
I have the same problem. For lots of projects, I'll never meet the maintainers, so I just hold my breath and click send. What's the worst that could happen?

> > Trying to contribute and failing makes me feel stupid.

> I have the same problem. For lots of projects, I'll never meet the maintainers, so I just hold my breath and click send. What's the worst that could happen?

You can get a gruff rejection by a (clearly) skilled developer, which unless you have a big ego acting as buffer, will make you doubt whether you are cut out for programming at all. This again will hurt your enthusiasm and make you stop working on hobby projects (what's the point?) for weeks, or even months if you are already insecure or slightly depressed.

People shouldn't be trying to contribute to open source—you use something, you need to extend it, so you submit your patches upstream. Nothing more.

It's not always that simple. Sometimes a piece of software has only one instance, and you want to contribute to that particular instance and not the general one. For instance, you may use a particular website or web application, so you would like to improve it. But the people running that project are disorganized or not open other contributions, so you end up just saying "screw it."

If this is just software you have installed locally, that makes sense though.

I didn't understand your comment before reading the article, but it's perfectly clear afterwards.

This guy is trying to do a good deed for the deed's sake, instead of for the sake of the project. No wonder he doesn't get accepted!

People often recommend contributing to open source projects as a good way to learn and to build your resume and reputation. In that case you're not necessarily motivated by an existing product need.

I agree with jrockway (but perhaps not the phrasing) that its not an appropriate response to the requirement.

People advise new programmers, "Its good to have work on an open source project on your resume." because that gives them access to your check-ins, how you responded to reviews, and generally mailing list chatter. That is invaluable for potential managers since its like having a 'preview' of how you work. However ...

When people hear it "Go contribute to some open source project." That is not the correct interpretation. And the reason is that there two conflicting assumptions.

The manager person is looking for folks who write code, whether or not it pays the bills. These are people who love to code. So if you're not already writing code, then your already not someone they really want to talk to.

If you're writing tons of code in your spare time, but none of it is 'out there', then one of three things might be true;

1) You're one of those people for whom someone elses code is never good enough so you've written everything yourself from scratch, probably have your own mail program, dns server, tcp stack, you name it :-)

2) You are keeping all your code under wraps because someday you're going to sell it as the next version of Office or something for $1000/copy. :-)

3) You can't tell if anyone would even care to use your code even if it was available so you just work on it in isolation.

Of these types, if you're #3 the solution is easy, pick a couple of things you're doing, throw them up on github so that there is a copy 'out there' if you need to recover it and you will find people will discover it and start feeding you back comments.

If you're #2 you probably aren't going to be a good fit but feel free to create the next Microsoft. Some of the people in #2 will create the next SAP or Salesforce.com or Autocad so don't let me stop you.

If you're in group #1 you're possibly a brilliant coder who will argue with everyone :-).

When people come to me and ask "How can I get a job at Google?" I ask them what software they are working on. If they answer, "What do you mean?" I explain the whole "If you are someone Google might hire, then you are someone that writes code whether or not you are getting paid for it. If you aren't that type of person then working for Google is probably not high on the list of possibilities (although I hear that is changing).

<picture of cat with caption that reads, "you're doing it wrong">

Seriously, if you want to engage in some activity to "build your resume" but you can't figure out how to do it... maybe there's a message in there.

Shipping a product (even if it's just a dumb little side project) is way more impressive to most people than contributing a patch to an open source project.

I contribute to projects that I use as often as I can, but I've never had to point a potential client to my Github account to land a contract.

Impressive to the average person, yes, but not impressive to people hiring someone to work on a team. It's great to be able to do whatever you want, but it takes a special kind of person to put their personal tastes aside, open up someone else's work, and fix it. Incidentally, that's what most programming jobs are, and most people are terrible at it.

Even non-programmers can contribute to open-source software. Proofreading and copy-editing patches are always appreciated - especially if the developers are ESL (English as a Second Language)!

There is a lot of stuff where if no one puts there hand up to improve it will just languish because no one really encounters it in a way that motivates them to patch it for their own needs. So a lot of documentation stuff that would require a lot of time to fix up. A good example I guess was PHP6, without reading to much in it it seems that making all the string functions UTF8(16) compatible was one of the very time consuming tasks that didn't have a lot of momentum behind it.

> There’s no certification, ceremony, or merit badge that says, “you’re ready to contribute to OSS”.

I strongly believe that everyone, and I mean everyone, is ready to contribute to OSS. On the Python project, Jesse Noller recently started a "core mentorship" group to help people put the rubber to the road. There's an almost endless amount of work to be done on CPython, and we'll literally take anyone with any amount of knowledge and help them contribute. Whether it's people contributing to OSS for the first time, or people new to contributing to Python, we can find something.

If you understand English, you can write documentation. If you can write Python code, which is obviously a common skill for someone interested in contributing to Python, there's plenty of work. If you know C, dig right in.

The group of core contributors ranges from 18 to the upper 60s, from the self-taught to multi-PhDs, from students to Googlers. I think the only people who aren't ready to contribute, wouldn't be interested in contributing in the first place.

> It’s not obvious where to start.

This is definitely an issue for a lot of projects, and as mentioned above for CPython, the core mentorship group is hoping to tackle this.

Online and in person, I've pointed countless amounts of newcomers to the "easy" bugs list on our tracker, but that's not always a great starting point. Half of the issues are a 35 comment bikeshed, but it's tagged as "easy" because the end result will probably be a 2 line change. The other half of the issues are easy, but in uninteresting corners of obscure modules.

I've had success leading newcomers at the PyCon sprint to start with test coverage, and I think that approach worked pretty well. You can't get too far without writing tests anyways, so it's a good educational step that you can even take back to your day job if you aren't already doing so. Additionally, it's a task that gives you a tangible sense of accomplishment. Being able to fix bugs is cool, but often they are very low impact. Being able to say you raised test coverage from 30% to 70% is nothing to shrug at.

Having early success is key to having continued fun on the project. No one wants to spend their evening working on a patch to have it rejected and shot down -- that's not fun. My approach, and one I also suggest to some first-timers, is to start with documentation. You can bang out 10 successful doc patches a lot easier than you can do 10 successful code changes. In order to get some attention to yourself, find the easiest way in the team and stick with it a bit before branching out.

> Guidelines often make a maintainer’s life easier, and mine harder.

I can certainly feel for this, and speaking for CPython, I think we've tried to keep the guidelines simple and well documented. Overall, the process doesn't deviate too far from "write it, review it, commit it", when it comes to being an external contributor. Once you have commit access, some of the source control process gets hairy, but it mostly stays out of your way and lets you do the work.

> Open source is for people who are better at this than me.

I'd put myself on the bottom of the pile both on the CPython team and at my day job. I told my dad programming was stupid when I was in high school, I barely got by in college, and finally found myself the first year on the job. I'm not a bad developer by any means, but I'm not blowing the doors off of companies when I interview with them. I just like what I do and I have fun doing it -- I think a lot of the people involved in this stuff are probably the same way.

> Trying to contribute and failing makes me feel stupid.

Failure sucks, straight up. It especially sucks when it's on an open source project that you're trying to help in your free time outside of work. It's not news that you're going to fail from time to time, but something that worked for me and apparently some people I've helped was choosing the right thing to work on. I touched on it earlier, but fixing 5 small easy things sometimes looks better to a maintainer than fixing 1 regular thing. If you start with that approach, soon you'll have 15 successful pull requests and may feel more confident to dive into deeper and harder things, and the maintainer may have more confidence that you can offer quality work for those harder things.

> There’s no time.

Time is the biggest bottleneck in open source. Not only do you have a kid, job, and responsibilities, everyone else does too. Submitting a patch or a pull request only to have it sit un-noticed for months sucks. The only way to get it through the system is more time. I don't know of any really good solutions on the maintainer side other than quitting everything and going full steam on the project, but that's clearly not viable :)

> It’s pretty lonely.

The CPython core mentors group aims to fix that. I don't remember the numbers off the top of my head, but the ratio of core contributors to new outsiders is pretty tight, and we've helped a bunch of interested contributors get their work accepted. Your average 1-man project might not be able to do this, but we've tried to make a group available for those who need a helping hand on Python.

An important piece to this that isn't mentioned is filing bug reports, good bug reports. If you track down where some fails, figure out why, and find the smallest, easiest set of steps to reproduce, you have helped the developers a lot. Even you don't know how to fix it, or know that the fix is not trivial, the developer now has a great place to start.

I have created several bug reports for Django where I pointed where it fails and even offered "bad" solutions in the description. I rarely provide a true patch because I don't have the latest of Django and rarely have the time to check it out, create a patch and tests. In the few cases that I have, my patch hasn't been used because the developers, in the wisdom, found better solution, usually very similar to mine, but more thought out or handling other cases I wasn't aware of. This doesn't bother me, because the developers are never hostile over proposed solutions, in fact they have been appreciative for the help in a starting point.

Very good point. The worst report is the one that isn't written, so any report we receive we're thankful for. Doing the things you said like finding the smallest steps to reproduce or a test case are a big help. This is an area that didn't come up in the original article, but I'm thinking about doing some further writing on the topic and writing bug reports are certainly worthy of significant mention.

This is spot on. I'm a contributor noob and when I search bug trackers for an issue I'm experiencing I run across a lot of reports like, "the user profile page is broken". That's not helpful to anyone. I'll then submit a detailed bug with detailed steps to reproduce, php errors generated, etc.

Thank you for saying this Brian. Very well stated - and here is a link for the page on the python-core-mentors stuff: http://pythonmentors.com/

Jesse, you and I chatted briefly at PyCon. I'm Asheesh, that person who gave that PyCon talk about outreach.

You (and this Python Mentors program) totally rock. It's hard to even name all the things the program gets right.

I adore Python and the general ethos of the community. I can be a bit of a sideliner and I usually don't have a lot of spare time - when I do I fritter it away playing with code and general programmer style procrastination. On a number of occasions I've thought it would be nice to contribute to Python in some way. I just didn't know how, if I could, or what the barrier for entry was.

This is one of the most encouraging things I've read in regards to getting my finger out and starting to give something back. You've sparked my interest and I will definitely be looking at this and seeing how I can contribute and get involved.

If you understand English, you can write documentation.

The bar is a lot higher than that. You have to understand English and understand the functions themselves. Sometimes even getting bullet-point list of functionality out of devs is like pulling teeth - leaving you with nothing to document in the first place. Similarly an understanding of why something was designed a certain way helps angle the documentation more accurately.

Clean documentation is hard, and doubly so if you're not the person who wrote X module for OpenFoo.

> The bar is a lot higher than that. You have to understand English and understand the functions themselves.

In general, you're certainly correct. I was thinking too much about Python, where there's a strict but easy to follow guideline that all public APIs are documented, so the lowest level work has already been done. Because of that, there aren't a ton of places where you'd need a super deep understanding of the code in question to make a documentation impact. A lot of it is updating, removing, and reformatting. You'll see a lot more "reformat this paragraph as a table" issues than "write the whole doc for the wizbang module", the former being a fairly easy task.

Also if you understand the project well enough to write documentation you have to have the ability to put yourself into a new user's position. Many people lack this ability and create just unusable docs.

Agreed. It's a hard skill even when you're trying consciously. One way to improve the situation is to actually give your draft documentation to a trusted user for feedback. I've been lucky enough to have an enthusiastic user in-house who has road-tested some of my documentation, and it's much better for the exercise.

Amazing! This is the best explanation/encouragement I have ever seen on contributing to FOSS.

Even though it seems python specific, it can be used almost verbatim for other project.

Double Thumbs Up.

I know a little python, very very little c, but I'd like to help.

The first step to getting started would be to run through the development guide: http://docs.python.org/devguide/

After you are setup there, http://bugs.python.org/ is the bug tracker. Bugs are sorted newest first, and there are a bunch of queries on the left side of the page, plus a query builder. The search feature works fairly well, and I sometimes suggest that people search modules they are comfortable with. If you use zipfile a lot, search it, and you'll find 46 issues.

In addition to that stuff, as Jesse mentioned in one of the responses, http://pythonmentors.com/ is the mentor site. There's a mailing list you're more than welcome to join should you have any questions, comments, or anything about the process. We can help you get setup, help you figure out what to work on, and help you successfully contribute your work.

This has motivated me to somehow contribute to Python now. Although I have been Python/Perl programmer for a while. Other projects need this sort of stuff to attract contributors.

Will be nice if Perl can also do this. This will help Perl 6 efforts a lot.

Do you know of any other open source projects that take a mentor/mentee approach?

With Leiningen, my Clojure project (http://github.com/technomancy/leiningen) I make an effort to periodically publish any "low-hanging fruit" TODOs that are suitable for newcomers to implement. There hasn't been as much recently since most of that kind of thing has been implemented, but explicitly calling out those places has helped a lot in the past.

KDE has mentor programs for various types of contribution, e.g. programming (the mentor list is toward the bottom): http://www.kde.org/community/getinvolved/development/

More here: http://www.kde.org/community/getinvolved/

We're just starting to do this at Mozilla.


Feedback welcome, we're only getting started.

I think stuff like this is great. I was interested in contributing to this project years ago before I really knew how to program very well. I still have never contributed to OSS, or anything like that. I will have a guilty conscience if I don't now.

If you're finding it difficult to contribute to a project, the odds are way in favour of this pointing to a deficiency in the way the project is run rather than any shortcoming of your own.

After developing software for 15 years, I submitted my first patch to an open source project yesterday, and it was because I needed the functionality for my day job (being able to actually stream AES CTR and HMAC in Erlang). Somehow, I've managed to be successful in my job without many commits.

Don't beat yourself up if you aren't a contributor. Can it be valuable and fun? Yes. Is it a requirement to succeed? No. Life is for living, not checking off boxes other people say are important. Have fun with that kid, that will likely be far more rewarding than any patch!

Yes! People think that contributing to OSS is some kind of moral duty. OSS is not a cancer hospital for kids.

Do you work on a project that depends on OSS? There will be bugs (lots of bugs — OSS is generous in this regard) and the need to contribute will arise naturally. Or else.

You don't? Why bother? Go help the local cancer hospital for kids instead.

I'll try to keep this very very short.

Every one of your points is grounded in... fear.

Fear of X, Y, Z.

Just do it friend. Take the plunge, you'll end up learning a lot while engaging in great discussions.

Or you'll end up being shat on, from a great height, from people whose credentials largely involve "being there first."

(Not all open source projects are like that, fortunately, but running into one or two can sour your view on the whole process.)

As is life.

You'll always find people that oppose everything that makes you... you. Religion, politics (<-- oh and i think you know about that one), ethics, money, fighting (Boxing vs MMA), Operating systems... etc.

For every several pieces of 'shat' you take, you'll find a couple golden nuggets. Those make the difference, builds character and knowledge.

Who knows, it may even help you build the next startup or 'cool app'.

Take the plunge!

Hey, I've done it. :p I can understand why others may not, though. It may just not be worth the hassle.

I get it. Unless your life is on the line, fear is a very bad way to make a decision.

I would say more "exasperation and confusion". But your point is extremely well taken.

Having contributed to a number of open source projects in the past, I definitely feel the pain. In order to help people get up to speed with SproutCore, we just released a four-part screencast and guide for contributing to the various parts of the framework.


Having contributed to a number of open source projects in the past ...

Understatement of the day.


I would suggest starting by creating your own open source projects, that way you get to learn the ropes without anyone hassling you...

Once you feel more comfortable you'll contribute to other projects as if they were your own...

BTW, for those who do not feel up to hacking code for patches, please consider adding documentation. It's bastard child of OSS, the task often no one, even the code creator, wants to do.

If those are the hurdles one sees, I'd suggest starting by contributing documentation. It's welcome help in almost all cases, since it's something the people that do know the problem domain in and out often have too little time, and too little need for. Also, as someone who is not yet fully emerged you're in the perfect position to design documentation from the point of a user who isn't familiar with the code base.

It usually also consists of small jobs (fixing documentation, keeping it up to date, making sure documented behavior is tested) and bigger projects (tutorials, cookbooks, main manuals). So it's possible to start out small and work your way up. From documentation you can go to testing and code cleanup contributions (X needs a better error message, Y is not the way library L says you should do it anymore) and then, depending on the project, on to larger tasks.

>If those are the hurdles one sees, I'd suggest starting by contributing documentation.

I don't code: for my contribution but instead answer user questions about one of my most used applications. I figure this helps to strengthen the eco-system.

When they come up I try to register bugs and be a good FOSS citizen that way.

Not trying to blow my own trumpet just suggest alternative options for anyone reading who's not a coder.

I would add to the list "It is too frustrating".

I've contributed to several open source projects in the past (Linux kernel, gnome, etc.), but doing so is hard work, even if the changes are trivial and you don't have a reputation in the community for the project. Most recently, it took almost a dozen emails over 4 days among 3 different people to get a 3 line patch committed to a driver.

The truth is contributing to open source is a social problem. You have to get to know the maintainers, build their trust, and over time, it gets easier to get patches in. If you can meet the maintainer for an hour or so at a conference, it lowers the bar but maintainers of popular projects are often swamped at these events.

More often than not it is easier to fix the bug for yourself and move on, using git to keep up to date with new releases.

I had this same sentiment within the past few days, as I resolved to finally get involved in an open source project.

I'm grateful for the mentions of OpenHatch and Launchpad -- I started with Github, and for as much as I enjoy the site, I felt like the emphasis on popular projects made it harder to find a place for a relative newbie to get involved. I seriously doubt that I'm enough of a JS ninja to add value to a project as thoroughly picked-over as jQuery, so seeing it listed repeatedly as a suggested repo was disheartening.

I accept the advice of other commenters who say that contributing to OSS becomes much more natural when you're actively using a library in your own project and stumble across a bug or feature idea... but not all of us have those projects, and I think that's okay.

A very important rule in almost all OSS projects: have a thick skin. There is usually a few abrasive and argumentative people that derail good development due to ego or trivial issues, avoid projects with people like this.

openhatch.org and launchpad.net are good sites to look for projects needing help. Take an open source application you use on a daily basis and think of ways you can contribute. Bigger projects may be difficult to dive into, but its always worth a shot.

> It’s not obvious where to start.

This is coming up again and again; this blog post is another data point I read recently, about a couple of projects dedicating time specifically to get potential new contributors up and running:


For me the biggest problem I have contributing to OSS projects -- and something not mentioned in the article -- is dealing with politicking/egos.

For Mozilla, we're trying to improve a lot of the things being discussed on this page, and make it really easy for contributors to get involved. If you've ever wanted to contributor to Mozilla, go here:


(feedback very welcome)

Try openhatch.org. It's a startup with the intent to make contributing to open source easier for newbies.

Read the code of your favorite projects, pick some tickets fix some bugs and submit some patches or pull requests :) Most of us who have projects love when get patches as it makes us feel less lonely :)

If you want people to show you how to contribute to open source, be an internet loudmouth and complain that you don't know how to contribute to open source.

Seriously, these are amazing comments and I hope it's OK if I compile the best ideas into another post for others who are as adrift as I sometimes feel.

Sounds like the author is just making excuses to rationalize his laziness/fear.

This is a terrifyingly accurate assessment.

You've drilled into the focus of the article:

1. I'm too lazy to overcome the inertia of not knowing what to do next

2. I'm too scared of rejection or looking dumb

The resulting question is: is there an onus on the community to provide additional tools to help the lazy/scared people like me push through these barriers?

My opinion is "yes, within limits", but I would also understand if someone said "no".

And I assume you would then also understand if people had better things to do than be shat on by that community (in the case of #2). #1 is simply false; when there is little context for how to contribute it is completely understandable that someone may be paralyzed by indecision. It has nothing to do with laziness.

Contributing to open-source projects is, in my experience, often more trouble than it's worth--precisely because all too often the people already involved have forgotten (or never had the social capability to know and understand) that #1 is a falsehood and #2 is an eminently reasonable reaction for any remotely normal human being. I still contribute to some projects, but only projects that I or close personal friends maintain. It allows me to tell them to unscrew their heads when they act like the grandparent poster.

Yeah, I understand and empathize with your viewpoint. I wrote the article and felt like the detractor captured some of the weaknesses I possess that led to its writing.

I'd call it less "weaknesses" and more "normalcy." It's extremely intimidating to deal with certain aspects of the open-source community. Not because you're dumb or stupid or lazy, but because they're kinda, y'know. Crazy.

(Note that in some cases it's a very beneficial form of crazy, and is not inherently bad, until it starts becoming an issue with other people.)

Alternatively, maybe attitudes like yours are the problem.

Look in the mirror.

The problem with many OS projects is that being distributed leads to isolation. Obviously, OS projects need to accept input worldwide, but they should work more to establish cores in major cities (San Francisco, New York, London) that meet once a month, and have "hackathons", on the weekends. A lot of communication that really can't happen through Git and mailing lists would occur, and the projects would come out a lot better. In-person interaction between developers, as much as is possible, would really help these projects a lot.

> Open source is for people who are better at this than me.

If you think that then you're possibly better than the most people contributing to OSS. Just look up http://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect

Life is too short to spend any enormous amt of time on an OSS project. Invest your skills into your own business, and reap the rewards of it.

Registration is open for Startup School 2019. Classes start July 22nd.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact