It’s scary to join an open source project

February 26th, 2012 in mozilla, open source, PlanetGNOME

Photo by DennisSylvesterHurd

Think of the last time you walked up to a complete stranger, stuck out your hand and said, “Hi, my name is …” Depending on how often you do that, it was probably a scary moment. Before you walked up to the person, you had to steel your nerves, decide what you were going to say, and then approach them.

Joining an open source software project is a bit like that. You have to send a mail to a huge list of random people. Or file a bugzilla bug that goes to a ton of random people.

And then imagine the immediate response is “WONTFIX” with no comments. That’s like if the person you got up the nerve to introduce yourself to said, “Not interested.”

I once spent weeks convincing a friend she should help out on an open source software project. She did. And she sent in her work to the mailing list and the first response was full of harsh critique. None of the follow up messages made up for that first message. I never did convince her to push her work forward. Nor to participate in open source again. (She does know exactly what she’d say to that first critic if she ever met him in person!)

What can we do to make sure people trying to shake our hands get a better reception?

28 Responses to “It’s scary to join an open source project”

  1. Nemo says:

    It is not “people”, it is programmers. Most of them have the social skills of an asteroid.

    tom jones Reply:
    February 26th, 2012 at 10:21 am

    as opposed to people who make sweeping generalizations..

  2. there says:

    There’s also the case of being met with cold silence.. wondering what you did wrong.

  3. Talking as a programmer and maintainer of an application (krita), I say: teach people to be polite. That goes for everyone, developers but also people like “Nemo”. Ban the words “suck”, “fuck(ed-up”, “brain-dead”, “clown” and so on from your communication channels. Make it a rule on the forum, bug tracker and mailing list that every effort should be appreciated and answered. I’ve got some hard limits: every bug report is answered in a week (most probably by Saturday, since that’s my spare time day…)

    If you have a hard and fast rule that the first thing you say when replying to a bug report is “Hi XXX, thank you for your report.”, your bug database will be so much more useful, free of flames and your users will actually become your patriots.

    On the mailing list, on irc, make it a rule that everyone needs to be helpful and polite. If they are not, tell them in private that they need to be polite and helpful. That goes for project members, newcomers and users.

    Being polite takes a little effort and time and won’t help you feel like you’re Linux Torvalds — but in the end, your community will be a great place to be. And in my experience, everyone learns, even the most die-hard four-letter word abusers realize soon that, hey, this place feels great.

  4. William Layfield says:

    I’ve tried to contribute to open source before and been absolutely amazed at the hostility to potential contributors.

    I had some time off college and wanted to do some work in a real project. The project had a wiki page with a list of potential ideas for contributions, picked one of those, asked a couple of questions about it on the mailing lists and got started.

    The problem was that three influential people in the project had sort of started to implement this feature in the past, and their code was still lying around. Each of them independently took offence that I wasn’t using their code. I was accused to NIHS. Obviously, even if I was guilty of that, I wouldn’t be able to use all three implementations!

    I was crazy because I was offering to do the work, I was very capable of it, and it was on their list of projects that they wanted people to do, but because I wasn’t using each person’s only half started code, I was stupid and evil. If they had shut up I would have delivered a finished feature on my own. Even if I used nobody else’s code the job would have been done and the gain to the project would only be positive.

    The first problem was the way each person spoke to me. So incredibly, incredibly rude. Really horrible. Dismissive. Patronising. Not taking any time to think or give me the time of day.

    The second problem was that all three contributors threatened to not include my work since they didn’t like that I wasn’t using their starting point. Why should I invest time if they’re going to shut me out at the end of it.

    I’m a really talented programmer, highly educated and experienced in shipping high quality products. But I will never again put myself through the humiliation of volunteering to help an open source project.

  5. Michael says:

    To be fair, at least some of the requests that get harsh responses, or silence, are not reasonable or useful. Asking everyone in the project to devote time to following up on those requests case by case is a big ask, although it would be nice if it was possible – people have other priorities.

    If you found your random stranger to say hi to by walking into their office uninvited, or turning up on the doorstep of their home, you might also not get a good response.

    Filing a bug in bugzilla is often not the best first act – posting on a web forum or a newsgroup might be better, for example. Doing some reading first would be good. But people don’t want to (and so generally won’t) spend 2 months learning about everything before saying something. So I guess the solution is to try and make it easy for them to say something appropriate in an appropriate place. Mozilla is so huge and has so many channels and people to interact with, that’s probably a hard task…

    The community could try and be nicer about responding to people who get their “hello” wrong. But even if they are nice about it, if the message is something like “actually you should have read web page X before posting this”, it’s still not a great situation – ideally you want the person to find and read web page X themselves, so they don’t need to first get things in the wrong order and then be redirected.

    stormy Reply:
    February 27th, 2012 at 12:57 pm

    I agree it is really hard to respond to everyone. But I think if we keep in mind how hard it was for them to say something to begin with, we will respond differently when we do.

  6. Bob says:

    I think that increasing management resources, at least in bigger projects, can help here: promoting some regular contributor to the status of “maintainer” would engage them more, invite them to follow and manage others’ contributions, and distribute the effort of reports’ handling to more people.
    At least, perhaps, harsh responses depend to the fact the person managing the wannabe contributor has lot to do and is annoyed by losing time about badly formatted patches, irrilevant features, reports on now-fixed bugs… Having more people handling those requests would alleviate the effort, and permit everyone to live happy ;-)

  7. It’s frustrating to hear these stories, not because I don’t know that people often encounter hostility (trust me, I know!) but because not all projects are the same. I would say don’t give up on free software/open source altogether.

    I would suggest that new folks try finding a project that has a reputation for being welcoming. We’re very nice at MediaGoblin (I’m the Community Manager) and I promise you that if you contact OpenHatch (Free Software’s Welcoming Committee) you can find nice people who want to help you contribute to a project that interests you — and feel appreciated for doing so.

    Projects are no more homogeneous than contributors!

    stormy Reply:
    February 26th, 2012 at 11:52 am

    Deb, I agree some projects are much better than others but even the best of projects are guilty of this behavior. I know many people who have submitted bugs to Mozilla and GNOME and gotten back no answer at all. Or their first bug is a “WONTFIX” and even knowing what it means, it feels like rejection.

    William Layfield Reply:
    February 26th, 2012 at 12:22 pm

    WONTFIX is part of another problem: how on earth are you supposed to know what the direction of the project is? What you should be developing towards? If I worked on my own to add a new type of graph to Libre Office, my time could be wasted because they’re not interested in that feature. They could think it was bloat, or just not what they want in their product. Even in Gnome, with all it’s wikis and developer docs, I’ve no idea what the direction is or how it’s decided what features are wanted or not. I’m guessing the people who did Gnome shell didn’t just start the feature on their own and then suggest it to Gnome. Presumably there is some kind of behind the scenes decision making. Maybe it’s in the open but I can’t find it.

    This means that good ideas from good people may just not be wanted by the leadership of the project.

    Benjamin Otte Reply:
    February 26th, 2012 at 1:18 pm

    It kind of works like everything else – you talk to people and agree on what to do. There’s no magic “this is what we’re gonna do the next X years” roadmap and it’s essentially impossible to write one, because the future is always changing.

    In fact, as a GTK developer, I don’t have any idea what features will be in the release in 6 months time. I have a hunch on where people want to go, but that’s about it.
    So the only option really is asking people and taking to them. For the “do we want a new chart type?” question, that is usually quite easy to answer: Just find the developer in question and get a “yse” or a “no” before you start.

    Michael Reply:
    February 27th, 2012 at 5:26 am

    ‘Just find the developer in question and get a “yse” or a “no” before you start.’

    In Mozilla “just finding the developer” may not be easy. Working out who to ask to review a patch can be harder than writing the patch. Actually the most effective thing is to go on IRC and talk to people, but that’s not obvious and it doesn’t scale…

  8. Benjamin Otte says:

    Just wanted to point it out, even though I think you’re aware of that: As a long-term contributor I don’t have that problem. I just go on IRC/bug tracker/mailing list on whatever project I have an issue with and ask away.
    And if I get rejected, I know that’s normal. I don’t even think about it. Sure, I form an opinion about the community in question, but there’s no personal issues.

    stormy Reply:
    February 27th, 2012 at 12:59 pm

    It’s not so much a “personal” issue. I don’t necessarily think new people take rude answers personally (although I’m sure some do) but it doesn’t encourage them to stick around.

  9. Stephen Smoogen says:

    I think that “communities” that allow for such communication attract the people they “want”. We start off thinking “Oh we should allow for people to say what they want because that is freedom..” but end up with people who for one reason or another are looking to be the biggest bully in the virtual playground. I think the biggest failing of the Fedora project has been that in allowing the bullies to rule the roost we have thrown away more potential contributors and imported a lot of “helpless” users because they know asking for stuff will be shouted down. I see this in parts of the GNOME, KDE and definately the Linux kernel world too.

  10. stsp says:

    http://producingoss.com/en/communications.html has some very good points on this topic.

    Also, for new contributors, http://open-advice.org/ has some encouraging stories. I really enjoyed Rich Bowen’s chapter.

  11. Jack says:

    I think it may be useful to consider how other non-profits handle contributions. They usually have a representative who speaks on behalf of the interests of the group and helps people along. This sounds a lot like the position you took when you invited your friend to participate.

    I was thinking about this the other day- I’m not sure if we can train all of our developers to take the time to patronize new members of our community when they have a lot of serious work to do. It might be useful to have a position in our communities dedicated primarily to bridging that gap. I’d gladly volunteer, since I feel I mitigate a lot of disputes among users misunderstandings developers already.

    I think there are two things we can focus on in the short-term. First, focusing on whatever code of conduct or etiquette your community follows- making sure it’s clear, accessible documentation that people think about.

    Another thing we can do is make sure new contributors are given opportunities to start on small, approachable tasks that won’t have as much potential for backlash. The first impression counts for a lot, and if we make sure people come into our communities feeling safe and useful, they will be much more likely to stay and have confidence in their skills.

    William Layfield Reply:
    February 27th, 2012 at 4:50 am

    As I said in my post, I took on a small, approachable task, which was even listed as such on their wiki. It didn’t look like it had much potential for backlash. It was quite easy technically, it just needed someone to get on and do it. And yet I was still verbally abused as an idiot for not using person X’s existing code, at the same time as being abused for being an idiot for not using person Y’s totally unrelated and incompatible existing code. When I said I was happy to develop it from scratch to avoid this conflict, they told me I was wasting time. Who’s time?! Theirs? Mine, surely!

    And it was all so personal and nasty! Not a technical discussion, no an attack on my reputation and abilities (which hadn’t even been displayed yet).

    I just walked away.

    stormy Reply:
    February 27th, 2012 at 12:59 pm

    I agree. And some projects have a way of identifying small projects like GNOME Love.

  12. Nemo says:

    Yes, generalization. Like lets say the whole OSS. Where forking and fighting and re-doing the same things again and again is a rewarding lifestyle instead of a nonsense. That happens when ever coders aren’t supervised. So you ask how to make a “project” friendly, while the usual coder approach is “go making your own project”. Maybe it is me living in lala land. Maybe not.

  13. drago01 says:

    Well people have to learn to deal with critics. i.e try to understand why the work has been rejected and not interpret everything as a personal attack.

    Some people are getting to easily offended nowdays.

    stormy Reply:
    February 27th, 2012 at 1:00 pm

    I offer lots of advice to newbies. But I don’t think the answer is always telling them to grow thicker skins. There can be change on both sides.

  14. Andrew Jones says:

    I’m involved with Foswiki, and no one ever gets treated like that.

    Most contributors come and talk to us in IRC first. Its much easier to talk about their ideas before any patches are submitted.

    SVN commit rights are given out freely, to the whole repository. If they submit something a bit stupid, someone will reply to the commit email and let them know, politely, often with a recommendation of a better way to do it.

    It might be because Foswiki is a small project and we need as many contributors as possible. Might be harder for bigger projects to manage more contributors.

    Buildbot, another small OSS project which I am on the mailing list for, also have the same attitude from what I see. Makes me want to get involved when I get some time.

    I think you were just unlucky – I haven’t yet come across a project like this.

  15. Mårten says:

    A long time ago (10-12 years ago) my primary OS was Gentoo or SUSE or Ubuntu. I used to report lots of bugs and point out stuff that needed fixing. I saw it as a sport of being the first to report a bug and getting all the duplicates to “my report”… But I’ve long since quit the Linux community (apart from reading Planet Gnome) and all I use Linux for is running a server for Gourmet the Recepie manager. Why?

    Well of all the bugs I reported only a handful got fixed most of them are still open today 5-9 years later because they are not prioritised for the developer, and I’m talking about real bugs not just feature requests. Feedback on old bugs are really strange to get, The URL to a project I posted 6 years ago might not give the developer the answer today, but a quick google would have, is it my responsibility to keep track of a bug that the developer should have closed 5 years and 6 months ago if they weren’t going to fix it anyway?

    The last bug I reported that I was actually happy about when it got fixed was the fixing so that the F3 key rotates the character case in LibreOffice. It’s in 3.4+ !
    I reported that because my mother complained about that lacking feature…

    T Reply:
    February 29th, 2012 at 10:01 am

    Ubuntu is 7 years old.

    Mårten Reply:
    February 29th, 2012 at 10:04 am

    So I got the timeline wrong, Gnome was still there, it was Gentoo 10 years ago, Suse and Redhat before that and then Ubuntu when that showed up.

  16. NotZed says:

    If it’s any consolation I find it scarier today than I did when I submitted my first patch over 15 years ago.

    I started writing a reply to this but it got too long, so I moved it to my blog and kept waffling on, in the end I feel there is no real problem to solve here, and it’s just a matter of expectations.

    http://a-hackers-craic.blogspot.com.au/2012/03/its-scary-joining-free-software-project.html