"...communities are living organisms that are most analogous to gardens; they must be tended to, cultivated, and fertilized if they are to take root, grow and thrive."
On June 4, 2008, Ian Skerrett from the Eclipse Foundation delivered a presentation entitled " Building Technical Communities". This section provides the key messages from Ian's lecture. Ian used his observations of working in the Eclipse community to explain why community building is important, its critical elements, and how the traditional roles within an organization relate.
The TIM Lecture Series provides a forum that promotes the exchange of knowledge between university research and technology company executives and entrepreneurs. Readers outside the Ottawa area who are unable to attend the lectures in person are invited to view upcoming lectures in the series either through voice conferencing or webcast.
Community Defined
A community refers to people who share a common interest or passion and interact with each other about the given passion, regardless of their geographic location. Participation in a community can be compelling and sticky in that people return frequently and remain for extended periods. A community is important to your company because, it:
- provides closer contact with your customers and users
- facilitates the development and delivery of a whole product or solution
- supplements technical support
- provides word of mouth marketing
- accelerates technology adoption
- enables a small number of individuals to have significant impact worldwide
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. Non-monetary motives for an individual to contribute to a technical community include:
- satisfy a passion for doing something interesting while receiving immediate feedback
- satisfaction from seeing individual's code being used and talked about
- satisfaction from being able to fix code immediately
- self branding that leads to consulting work and/or increase in the number and quality of job opportunities
To successfully interact with a technical community, you should: i) be authentic; and ii) respond and react respectfully, accurately and quickly. Other insights from this portion of the lecture include:
- customers and venture capitalists wish to know how healthy a technical community is using metrics which include size, diversification and talent
- metrics, beyond counting numbers of downloads, are needed to assess the health of a community
- monetizing a community is a delicate skill
- venture capital firms see a community as a mechanism that lowers their risks as well as lowers their ventures' sales and marketing costs
- old marketing is either broken or changing and new marketing is community-based
- top down marketing is still needed because technical people must sell up to their managers
- old school marketers usually don't have the technical skills required to join a community and gain the interest of developers without insulting them or being insulted by them
Building Communities
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. For example, Eclipse is a platform that includes a small run-time system which enables add-ons and other components to run on top of the platform. It is important that providers of new add-ons are on the same footing as those who provided the original system. A successful architecture of participation:
- empowers individuals and small groups to make decisions
- provides open APIs and commercial friendly licenses
- enables suppliers to compete on implementations and the users, not the platform, to decide who wins
- is easy to integrate and extend
- spurs innovation
- seeds a broader ecosystem
- promotes a culture of openness, transparency and meritocracy
Some successful communities have strong, visible technical leaders. Examples include Linus Torvalds for the Linux community, David Heinemeier Hansson (DHH) for Rails, and Mark Shuttleworth for Ubuntu. Other successful communities have various community leaders. In these communities, the quality of the code is more important than the visibility of the leaders.
To overcome challenges found in communities, it is often better to first obtain feedback and then make an executive decision. Communities fail because:
- they don't produce good code and/or the conversation about the code is not worthwhile
- there are no visible leaders and code is of poor quality
- no or little effort is invested into nurturing the community
Eclipse
Ian finished the presentation with a quick overview of the Eclipse Foundation (http://www.eclipse.org) which has 180+ members globally. The approximate breakdown is: US (50%), Europe (30%) and the rest of the world (20%). Eclipse's main marketing objective is to grow the community and spread the adoption of Eclipse into vertical enterprise markets. Eclipse does not compete with member companies' products. IBM open sourced Eclipse when it recognized that nobody wants to build modules for a locked-in system.
Recommended Reading
Brand Hijack: Marketing Without Marketing
Developing an Architecture of Participation
Does Code Architecture Mitigate Free Riding in the Open Source Development Model?