Non-technical GNOMEys
June 6, 2006 10:08 am gnome, guadec, marketingThere has been some debate recently on how the project can attract more people outside of the male geek group. Shaun McCance made the point that non-technical posts in general are typically under-represented in GNOME.
This echoes closely what Mitchell Baker has been saying about Mozilla:
[…] filling [non-technical] roles often means bringing in people who haven’t “come up through the project.” These folks who are new to the Mozilla project need to be accepted by the development community in order to be effective. Status as a Mozilla Corporation employee isn’t enough.
and
If one’s skillset is something other than code, then proving oneself through understanding the intricacies of our code is at best inefficient and probably a blocker for many people. So the challenges are to find mechanisms for people in non-code roles to demonstrate they share the values of the Mozilla project and can make contributions that people want to support.
Conclusion?
Integrating non-engineering contributors takes a lot of trust and feeling our way gently. Those people joining us in non-engineering roles must trust that the technical contributors will give them a fair chance to participate, add value, become respected and gain influence and leadership. The engineering community must trust that these people who may be new to the Mozilla community and don’t have deep technical expertise are worth listening to and giving a fair shake.
In other words: Be excellent to each other.
But more than that, we need to start recognising when there is a skills deficiency in the project, and actively recruit people with those skills, drawing them the map of how the project works, and helping them become great contributors. There are a number of examples of non-technical people coming into the project and making an impact – Quim Gil, John Williams, Telsa Gwynne – but there are probably more examples of people who passed close by, felt the water, and went on their merry way without ever engaging, or being engaged by, the GNOME community.
So during the marketing BOF at GUADEC this year, I would like to focus on this – how can we make non-technical people interested in marketing GNOME feel like their work makes a difference.
Marketing is not just promotion – real marketing is a two-way dialog between the project and the market, with us saying what we do and why, and the market telling us how we can do better, or what they need that we’re not doing. And GNOME marketers will feel like a part of the project from the moment where something we do changes the project for the better.
June 6th, 2006 at 10:44 pm
Amen brother 🙂
So many people in our community drop back to prejudice the moment the word “marketing” is mentioned. I’ve argued in the past that the open source process is a distilled version of marketing: needs are identified, those needs are satisfied and ongoing community feedback ensures that the resultant product remains relevant.
It’s vital that open source/free software projects find new ways to recruit contributors. I’m not a coder and, although I submit the odd bug report, that’s not the best way for people like me to become involved in a project.
When trying to find a project to which I could contribute documentation, I found that I was welcome but:
a. no one really knew how to use my skills
b. the onus was on me to navigate my way round the project to find where I’d fit in
c. I was thrown in at the deep end.
I don’t know how that compares with a coder’s experience, obviously.
With documentation in particular, I’ve often found that there’s an, almost grudging, acceptance that it’s necessary but that it will only really hinder the code.
Mitchell’s assertion that “Integrating non-engineering contributors takes a lot of trust” concerns me. “Them and us” is, it would appear, accepted as the MO. Why should people like me be any more of a risk than a new code contributor?
June 7th, 2006 at 2:23 am
Matthew: “Why should people like me be any more of a risk than a new code contributor?” – because most of the people already in the community have no way to measure how competent you are with their current toolset.
When Mitchell says that we need trust on both sides, it’s because when someone who isn’t technical asks a techie to do something for them, often the reaction is either “who do they think they are?” or “I know better”, or “show me the code”.
We need to have some way to get the first non-technical contributors heavily involved in things like release co-ordination and marketing to get that meritocracy bootstrapped. We need to trust that new people coming into those roles are capable, and trust them, until they prove otherwise 😉
June 8th, 2006 at 6:21 pm
“When Mitchell says that we need trust on both sides, it’s because when someone who isn’t technical asks a techie to do something for them, often the reaction is either “who do they think they are?” or “I know better”, or “show me the code”.”
Which kinda reinforces my point that there is, in some projects, a feeling of “them and us”. I think it falls on existing project members to make the effort to meet non-techie people at their level, as otherwise the whole community side of the open source process could get lost. If non-tech people don’t feel welcome, they’ll quickly become jaded. Who can blame them if the attitude is, as you suggest, “show me the code”?
The Bazaar revision control system is a great example of how it can work, though. They recognise the value of non-coder skills and they’re actively seeking to bring people into the project who have them. Of course, it helps that they have the benefit of Canonical’s backing to employ people.