1. They work good enough for me: a big reason for my contributing is me needing it to work a certain way. I have a tendency to whirlwind into a project, dump lots of source, suggestions and whatnot, then not not come back. There is frequently little incentive for me to continue participation. The ones I stick with have a good little community -- this is important. Even solo authors that respond frequently and quickly are community enough for me.
2. Non-attribution/recognition -- There are at least 2 projects out there that don't attribute my code, despite it being in the "trunk". Another project that factored my code out, took my name off the contributors list. Another never used my code, but took lots of ideas (with email exchanges explaining my intentions with my code), but never recognized my help. In all of those cases I have moved on. I don't like to complain and won't point fingers here, but it does negatively motivate me. Similarly there are a few projects that I would like to participate in, but am very wary based on individual's connections with the above projects.
3. Fear of what I call rabbit-hole-itis. Sometimes it is safer for me not to delve into the code well enough to make it better, because I will spend a week on it instead of being "for-real" productive. This is prolly not fixable as it's about me not the community (of course it wouldn't be a problem if y'all stopped with the neat projects).
4. A lot of times it seems like more hassle than it's worth to try and contribute. I think the article hits those on the head -- mostly the part about "convincing others my patch actually helps". It is frustrating to deal with project core devs that don't want to look at your code because of silly reasons that are not technical -- e.g. "why would you ever need to do that" or "it works 'just fine' already".
HTH