Ian Skerrett of the Eclipse Foundation has an interesting article at the June issue of the Open Source Business Resource. Some quotes and excerpts below.

In his lecture on “Building Technical Communities” Ian Skerrret observes:

“In a technical community: i) peers, not vendors, determine the message; ii) developers talk to other developers, not through intermediaries or press releases, and marketers produce content such as case studies that help developers sell up to their managers; iii) people speak to people, not a market or a demographic attribute; iv) employees interact with people who are saying good and bad things about their companies; iv) interactions first build trust and then build value; and iv) you learn to live with your competitors being part of the same community.

It is a myth that committers are volunteers. The committers for the established open source projects are nearly all paid by companies to commit code to open source projects.

To successfully interact with a technical community, you should: i) be authentic; and ii) respond and react respectfully, accurately and quickly.

He adds:

“In order to build a community, you must produce good code that solves a compelling problem and/or decreases development costs. You must also ensure that the conversation about the code is worthwhile. Make it easy to contribute to the community by providing: i) documentation that lowers the barrier to understanding the code; ii) tutorials, white papers and books; and iii) experts who monitor newsgroups and bug databases to provide prompt and accurate feedback.

Community building also requires transparency. Signs of transparency include: i) maintaining open bug databases; ii) publishing project meetings; and iii) publishing project plans and incorporating community’s feedback into plans. Be part of the community, do not attempt to control it. Provide a governance structure that fits with the aims of the community.

An architecture of participation includes low barriers to entry for newcomers and some mechanism for isolating the cathedral from the bazaar (http://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar). An architecture of participation allows for a free market of ideas, in which anyone can put forward a proposed solution to a problem. From experience, an architecture of participation that is comprised of a very large run-time system as the platform (cathedral) with plug-ins on top (bazaar) does not work.

A good architecture of participation supports a small cathedral which enables a bazaar where it is easy for individuals to add their ideas to the platform.”