
Why I still don’t contribute to open source - phiggy
http://brandonhays.com/blog/2011/05/03/why-i-still-dont-contribute-to-open-source/
======
jrockway
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.

~~~
pavel_lishin
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.

~~~
davidw
> 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.

~~~
pavel_lishin
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?

~~~
kelnos
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).

~~~
Scaevolus
<https://github.com/mirrors/linux-2.6>

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

------
singular
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 :)

[1]:<http://golang.org>

[2]:<http://code.google.com/p/go/issues/list>

[3]:<http://en.wikipedia.org/wiki/Rob_Pike>

[4]:<http://code.google.com/p/go/issues/detail?id=667>

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

[1]:[http://www.codegrunt.co.uk/2011/05/04/Forward-Referenced-
Rec...](http://www.codegrunt.co.uk/2011/05/04/Forward-Referenced-Recursive-
Types-In-Go.html)

------
agentultra
_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.

~~~
araneae
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.

~~~
pbiggar
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.

~~~
agentultra
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.

~~~
pbiggar
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.

------
DasIch
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.

------
zmmmmm
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.

------
generalk
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?

~~~
Deestan
> > 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.

------
wtn
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.

~~~
ddlatham
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.

~~~
jarin
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.

~~~
jrockway
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.

------
briancurtin
> 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.

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

~~~
pbiggar
We're just starting to do this at Mozilla.

<https://developer.mozilla.org/En/Introduction>

Feedback welcome, we're only getting started.

~~~
mister_m
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.

------
technomancy
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.

------
SoftwareMaven
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!

~~~
andos
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.

------
jjm
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.

~~~
eropple
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.)

~~~
jjm
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!

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

------
wycats
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.

[http://blog.sproutcore.com/post/5166266734/dispatch-from-
the...](http://blog.sproutcore.com/post/5166266734/dispatch-from-the-edge-
contributing-to-sproutcore)

~~~
_pius
_Having contributed to a number of open source projects in the past ..._

Understatement of the day.

<https://github.com/wycats>

------
aarongough
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...

------
jamesbritt
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.

------
phaylon
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.

~~~
pbhjpbhj
>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.

------
mv1
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.

------
Cyranix
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.

------
nwmcsween
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.

------
johnzimmerman
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.

------
mark_h
> 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:

[http://blog.lydiapintscher.de/2011/04/18/how-vidalia-and-
gim...](http://blog.lydiapintscher.de/2011/04/18/how-vidalia-and-gimp-found-
new-contributors-just-by-asking/)

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

------
pbiggar
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:

<https://developer.mozilla.org/En/Introduction>

(feedback very welcome)

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

------
christkv
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 :)

------
tehviking
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.

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

~~~
tehviking
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".

~~~
eropple
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.

~~~
tehviking
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.

~~~
eropple
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.)

------
michaelochurch
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.

------
leon_
> 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>

------
Hisoka
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.

