Slashdot Mirror
How Open Source Projects Survive Poisonous People
CoolVibe writes "Two Subversion developers talk at Google about how to keep pests and malcontents out of your open source projects. From the abstract: 'Every open source project runs into people who are selfish, uncooperative, and disrespectful. These people can silently poison the atmosphere of a happy developer community. Come learn how to identify these people and peacefully de-fuse them before they derail your project. Told through a series of (often amusing) real-life anecdotes and experiences.'"
I think you misunderstood that part of our talk.
We didn't boot any person at all, we simply rejected the offered patch. The person wasn't a member of the community, just a drive-by patch contributor.... we didn't "throw him out", because he wasn't "in" to begin with! Patch contributions are great things, but if we can't come to an agreement, then that's the end of things. The person wasn't interested in resubmitting without his name attached to the patch, so we had to reject the patch. Our honest hope was that not only would he contribute his patch properly, but that he'd become a regular committer too. Instead, he was annoyed at us and walked away. C'est la vie, we're not going to change our code submission rules for a single visitor. Twas a shame.
"I wrote this program for myself. You want Feature X, you code it!"All I have to say is that if the program was written for your own use and you didn't want people filing bug reports, why the hell did you release it to the world?
I've found lots of such programs useful, if the features in already don't do it for me I can either modify the code nyself and add it.
All you're doing then is giving open source a black mark.
Oh, I'd say you were. Open Source isn't about having someone do something for you, its about having the ability to do it yourself (ie: have source code and can modify it). How about instead of telling someone who is likely busy and gains almost NOTHING (save an ego boost) from more users to code something for you for free you instead do it yourself or maybe pay them for it. Hell many of these people are getting paid for the parts they're coding for their own use so you essentially want them to work for free to implement what you do while they'd get paid to implement what they need.
They're simply being honest about who they're coding the project for, not everyone is unemployed and has 60 hours a week to burn on a hobby.
The final type of person, the one that bothers me perhaps the most, is the coder or contributor who simply doesn't answer bug reports or emails (whatever the appropriate method may be) at all, even after several weeks of waiting. Are you guys *trying* to turn your users away!?
It's likely that many gain very little from users, they're not a company and have no incentive to reply to you. It's likely, as someone else, mentioned that if your email was more useful then they would answer. Possibly they already know of the issue and are too busy to answer, that's life.
We imitated this CVS behavior because it achieves two feature goals:
:-)
1) severability: you can 'break off' any part of a working copy, and it still functions as a standalone working copy.
2) portability: you can transport a working copy to different disks or machines, and it still functions.
That said, we're now re-evaluating the utility of these features... it seems that few people actually use them or care. In svn 2.0, we might just go for the 'all metadata in one place' design, much like svk and other systems do.
By the way, you don't need to use slashdot to "get our ear", come post questions on the dev@subversion.tigris.org lists.