So if you start a project and send email to a bunch of folks and ask them to just jump in and contribute, which group do you think will get going more quickly?
This article is predicated on the premise that most open source projects actively recruit strangers to work on them. This has not been the case for any open source projects that I have worked on. Instead, I normally address my own needs by contributing to open source. I assume most others first participate in a similar manner, so I think the article is built on a faulty premise.
Not necessarily faulty, just non-universal. She seems to be speaking from her experience with Mozilla, which does actively recruit strangers. I think large projects are always looking for contributors.
Your answer is predicated on the premise that all possible contributors to open source projects are comfortable with the habits and processes of a low context culture just like you are. If anything, your example strengthens the argument of the article, you are comfortable walking up to someone you have never been introduced to wearing weird clothes, ah, sorry, writing code that doesn't do what you want and tell them how to change it.
It is exaclty the point of the article that open source projects are more attractive to people like you and that people who don't behave like that have a harder time joining.
There's a difference between fixing a bug because it's getting in your way and helping somebody out with their project. Fixing a bug in code you're running on your own computer is not like walking up to someone and criticizing their clothes. It's like sewing up a hole in your own clothes.
Of course, the actual action of fixing the bug is the same in both cases. It's just a difference in how you see it.
For cases like that — where someone makes a change to some open-source software for their own purposes, not in order to help out the project — the question is not how to "recruit" them, but how to make sure that they can make those changes easily, and then how to induce them to share the changes. Stormy's point about different cultures needing different approaches still holds in that case, but they'll be different different approaches.
It sounds to me like the author is indicating that people with the "high-context" don't just jump in. If they make their own changes to the code, presumably they'd not attempt to get them merged (due to distrust of others or distrust of self?). They need a soft and gradual introduction into the development community and the group of people that work on the project regularly before they feel comfortable enough to submit patches and interact in otherwise meaningful ways.
That's what I took from the article. It's an interesting problem.
Not necessarily. Your example does not refute the premise. You would have to give an example where people contribute a project of yours, not the opposite. I.e. because you contribute in a certain way to a project voluntarily, it doesn't mean that that same project doesn't live by a low context culture fashion.
I've thought about this many times. I see many people with programming skills far greater than mine submitting code to many open source projects, but if I need someone to jump in a form a team with me and I will indeed choose somebody I know personally, even if it's a person with lower technical skills than me.
Good post. Having just started reading Duncan Watt's "Everything is Obvious" (http://amzn.com/0385531680) critique on common sense, this looks like exactly what he's talking about... people who aren't familiar with the difference between the cultures (like me) don't even realize there is a distinction, and hence won't realize that there's even a problem. Even if the problem isn't that big, as some of the comments on the blog suggest, it's still good to know that the distinction exists.
Thanks for the recommendation, I just started reading the book and really liked the initial parts. The author has a very good discussion of how a result in sociolgy is obvious, and it's opposite is equally obvious which leads people to undervalue the findings in studies.
"Typically Asian countries are more high context than Western countries. Think Korea and Japan."
"Low context cultures are process driven. They rely on facts and processes."
Ergo, Korean and Japanese programmers don't rely on facts and processes?
* in response to the downvotes: I'm not trying to be pedantic here. I can kind of guess what the author is trying to say, but this is such a vague, confusing statement as to be completely useless. Perhaps she meant some other phrase besides "facts and processes"?
In an unfamiliar situation a westerner is more likely to go it alone, follow the signs and work through the process. Where as an easterner is more likely to seek help and have a knowledgeable person walk them through it. So yeah a western programmer is more than likely going to read the docs, and an eastern programmer is more likely to have a meeting with the stake holders. They both get the job done just in different ways.
The original title is misleading. The actual thrust of the article is "are you soliciting help in a way which encourages participation by people from HCCs?" That's certainly something to think about, but it's a very different question from whether open source itself excludes them.
I don't believe cultures are intrinsically high or low context. The English only became a culture that valued process and communication because it works. Victorian England was all about who you know being more important that what you know. The brutal reality that family can be a ball and chain, and that corrupt officials helping out their friends and family is a detriment to society took a while to set in.
China and India are dirt poor. Japan and Korea were dirt poor a generation ago.
OK, low-communication (high context) might be part of a culture, like a preference towards old, white men. But I think it's one that cultures need to jettison if they want to stay relevant.
I think you mean Japan was dirt poor a couple if generations ago. A generation ago they were in the middle of their economic bubble. A couple of generations ago, they were rebuilding from the devastation of World War II. Before that, they were already an advanced industrialized nation, far ahead of their neighbours.
Good topic for discussion. The article of course simplifies, but it was inevitable. Anyway, being from india, i can see the validity of the point. I am no highly active contributor in any open-source project, but have realized (from participating in IRCs) i usually hold more context in my head than others. Infact, i actively try to avoid that(just respond), and found that, the discussion becomes too painful for others.(I was told there's too much tooth pulling in an IRC forum, once as i tried this).
How much has this author worked in open source? Getting a patch into Linux is pretty damn high-context, indeed git was created specifically as a way for Linus to manage a network of trust instead of just a sea of patches.
She has a lot of experience in open source, to say the least. From the author's about page -
"I currently work as the Head of Developer Engagement at Mozilla. I also am an advisor for HFOSS, OpenSource World, and IntraHealth Open, as well as founder and president of Kids on Computers, a nonprofit organization setting up computer labs in schools where kids have no other access to technology.
Previously I have worked as Executive Director of the GNOME Foundation, established OpenLogic‘s Expert Community and founded and ran HP’s Open Source Program Office."
I think trust in the context of Linux has nothing to do with interpersonal context and is about procedural trust (kind of like CA certificates and SSL). Not the same thing at all.
Because of the depth of its impact, the Linux kernel is also probably different from other OSS projects. As a user and developer, I am orders of magnitude more likely to submit a patch to FF than Linux. Maybe that's just because I'm more familiar with higher level coding, but I think working something as involved as a kernel necessarily requires a significant amount of technical context.
This article is predicated on the premise that most open source projects actively recruit strangers to work on them. This has not been the case for any open source projects that I have worked on. Instead, I normally address my own needs by contributing to open source. I assume most others first participate in a similar manner, so I think the article is built on a faulty premise.