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?

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

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.