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".
On advice from a Sage (sagemath.org) developer: anything. The core devs gain little by withholding the "contributor" merit badge, and simple recognition is usually the main thing that motivates a newcomer to follow through with a patch and stay with the community. So now, if a new developer helps us with any contribution -- one-line patch, test case, documentation -- we offer to add their name to the contributors list and news file.
This is why I've largely avoided getting into the F/OSS community. It's people who say those quotes or have that same attitude. Every time I hear it on places like #ruby or #rails I have to calm myself down and switch channels for a bit.
That will require some additional effort from Python core developement group - somebody would need to go through the bug tracker, categorize the tasks etc. - but it will probably mitigate some of the issues mentioned by jesse above ("Don't know how", "Don't know where" etc.)
I miss nothing in Python, it's all there, source code, excellent documentation and website, very nice and clean language, superb datastructures, a fairly complete stdlib and a fantastic community of people around it.
Is Python complete? It seems that for me it is indeed. Others may still miss things. But I perceive the 'stagnant design' mentioned in another post as an advantage: it provides stability.
The current Python website continues to be a terrible first stop for new-to-Python visitors, despite this very issue being discussed at length at recent PyCons. Compared to the excellent Git and Ruby sites, for instance, it's really second rate from a design, navigation and identity perspective.
However I haven't pursued contributing to the site. Here's why:
1. Contribute to the website options on Python.org seem limited to "bug fixes". The "SiteImprovements" page is a mess. The whole site design and identity is a bug, unfortunately.
2. The stagnant design (only a marginal improvement over the previous iteration) implies that there is either a serious design-by-committee problem when it comes to the site or a serious lack of good-design-sense from whomever is actually running it.
I'm not trying to be a grouch about this, but the site needs strong direction in terms of visual identity, navigation, presentation, etc., not just incremental fixes.
I'll put my time/money where my mouth is on this. If there really is a chance to radically improve the site and contribute, I'm there. Point me in the right direction. If there is a roadblocker committee issue that needs to be sorted first.
My all time personal favorite project website is openbsd.org.
After one experience like this most people would be ready to submit patches on their own...
I think it would be cool to have the community provide this sort of "training wheels" to help people get past all of the roadblocks and not feel relegated to dealing with bug report paperwork (as valuable as that is)...
The conundrum with projects like Python is that the people talented enough to submit useful patches are usually not the ones who have the time to do so.
As for me, I find it is a lot easier to contribute to smaller, less developed projects. There is more to do, and I feel I can have a bigger impact. Also, its less intimidating than big projects, you don't need as much domain specific expertise with smaller projects.
Though I have looked at Rubinius (Wishing they had a better name :/)
Most of the standard library is written in Ruby, and my guess is that there are things in there that could use some love.
"How Python is developed"
"Python, like any other open source project, has its own way of doing things when it comes to development. To an outsider it can seem complicated and difficult to break into. But in fact, Python's development practices are simple as long as you know what the basic workflow is. This talk will go over that workflow, from how a bug ends up getting fixed to how a new language feature get added. In the end people should have an understanding of how Python is developed and how anyone can contribute to the project."
That, and the amount of bike shedding going on the dev mailing lists is ridiculous. At least it seemed that way the last time I kept up with it. So much pointless circular discussion.
- A Python implementation with some obvious and easy to find bugs (plus hints).
- A checklist of the patch notes/emails that would be expected.
- The e-mail address of someone who will read and respond to the submitted patch and offer feedback. (Should be low traffic, and it'd be worth answering the email to get a new patch submitter.)
I know some of the Django core developers hang out here. I wish one of them would undertake a similar exercise for Django. I tried to help out Django in some teeny tiny ways but soon gave up due to a mixture of the reasons cited, including silence.