Why I still don’t contribute to open source
brandonhays.com
brandonhays.com
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 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.
Yes, they turned out okay, but that doesn't mean it wasn't much more difficult, right?
Github hosts mirrors of a few popular open-source projects, which is handy because they have much better source browsing than the alternatives.
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.
It just wasn't as good looking.
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.
[1] http://en.wikipedia.org/wiki/Git_(software) [2] Of course, free software on github is hosted for free.
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.
In the grand picture, github is just a nice frontend to patch that also replaces UUCP with something more modern.
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!
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.
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.
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.
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 :)
[2]:http://code.google.com/p/go/issues/list
[1]:http://www.codegrunt.co.uk/2011/05/04/Forward-Referenced-Rec...
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.
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.
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.
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.
> 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.
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.
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.
> There’s no certification, ceremony, or merit badge
> It’s not obvious where to start.
> Open source is for people who are
> better at this than me.
> 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.
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!
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.
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.
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).
If this is just software you have installed locally, that makes sense though.
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.
You (and this Python Mentors program) totally rock. It's hard to even name all the things the program gets right.
Even though it seems python specific, it can be used almost verbatim for other project.
Double Thumbs Up.
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.
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.
More here: http://www.kde.org/community/getinvolved/
https://developer.mozilla.org/En/Introduction
Feedback welcome, we're only getting started.
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.
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.
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.
Will be nice if Perl can also do this. This will help Perl 6 efforts a lot.
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!
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.
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.
(Not all open source projects are like that, fortunately, but running into one or two can sour your view on the whole process.)
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!
I would say more "exasperation and confusion". But your point is extremely well taken.
http://blog.sproutcore.com/post/5166266734/dispatch-from-the...
Understatement of the day.
Once you feel more comfortable you'll contribute to other projects as if they were your own...
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.
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'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'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.
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:
http://blog.lydiapintscher.de/2011/04/18/how-vidalia-and-gim...
https://developer.mozilla.org/En/Introduction
(feedback very welcome)
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.
Look in the mirror.
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".
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.
(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.)
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