American businesses, along with many others around the world, hustle to find enough programmers and computing staff. The gap widens precariously between the number of job openings and the number students graduating with the necessary skills. And yet, at the same time, we seem to drown in an overabundance of software packages. If you want JavaScript frameworks, large-scale data stores, bulk system configuration tools, mesh networking protocols, or even a new functional language, you have almost too many choices. So the shortage of programmers does not apply when people offer their code to their colleagues across the globe.
Open source software’s ever-expanding options show a programming culture that is proud of its accomplishments and eager to explore untapped potential. But above all, they reveal a desire to work together on problems. The existence of open source packages shows the strength of community.
The Community Leadership Summit (CLS), which started four years ago at the Open Source convention and has been held on the weekend preceding it ever since, drew more attendees than ever this year (I estimate some 200 at the opening plenary), and a large fraction of them actually work as community managers. The field has matured in other ways as well. At early conferences, people expressed aspirations and complained of problems that this year are finding solutions.
In institutions such as government and health care that struggle to adopt lean methods, reformers often yearn for more of the “Silicon Valley mentality.” Most of them mean, by this phrase, a willingness to fund projects that could fail. But I think a much more critical trait of the Silicon Valley mentality is the urge to form communities. Every new mailing list, Google or Yahoo! group, hacker space, and GitHub organization is another brick in the edifice of innovation.
But as with everything, different communities lie along a wide spectrum of maturity. Some well-established projects have a lot of healthy processes for engaging the community; others are still experimenting. Most communities, if they achieve success, have to negotiate the notorious “chasm” between attracting early adopters and becoming a mass phenomenon. Some–notably OpenStack–have grown extremely fast and are trying to adapt quickly. The large contingent from OpenStack at this conference was evidence of their interest in learning more about the field.
Jono Bacon leads off the conference
The transition from early adopters to mainstream practice is taking place not only in communities such as OpenStack, but in the field of online community leadership as a whole. Conference organizer Jono Bacon (who also wrote the book The Art of Community) said that this field was approaching its own chasm, and that conference attendees will soon have to take it to that next hectic stage.
A lot of the sessions had note-takers, so you can read about many details of the conference on the wiki. This article covers the major themes I noticed during the conference.
Attendees check for sessions on the board they created earlier
Inclusivity
It takes conscious, ongoing effort to tamp down a community’s natural tendency to be cliquish and unwelcoming to people outside whatever the current members consider to be the norm. But many attendees at CLS are intent on opening up open source communities.
A session on multi-cultural and international communities covered a huge range of behaviors and tendencies in the field. Projects depend on local champions to spread into new regions of the world, and its important to give trusted people a good deal of autonomy (including control over their budget). But depending on the first few recruits to be your ambassadors may lead to disaster. Some just can’t handle the task, planning events that fail or putting out publicity that poisons the project’s image. Others are competent but self-serving, trying to build fiefdoms or monopolize money-making opportunities in their countries. It’s important to check that people in a particular country have rich interconnections and are not all going through a single point of contact.
Other pitfalls in international expansion are more familiar. For instance, the online culture set up by a project’s founders (usually in a European or North American country) may be more free-wheeling, critical, and non-hierarchical than cultures where the project needs to spread, and not all followers want to be forced into patterns so far removed from their own ways of dealing with people. Because some people are not comfortable speaking up in the predominant culture, you might not even know they’re using your software.
Some barriers to expansion are organizational: project maintainers may want to allocate resources where it gets the biggest monetary return instead of where the need for its software or service are greatest. Time zones are always an issue when synchronous online meetings are scheduled; some projects rotate the times regularly so different people are inconvenienced. And of course, people must be encouraged to use their native language and make translations back and forth as much as possible. Some people post in multiple languages as a matter of course.
Outreach is complicated because not everybody likes Twitter or LinkedIn. Several countries have unique social networks that are wildly popular in that country but don’t reach outside it (famous examples include Orkut in Brazil and Weibo in China). One audacious strategy is to seek out emigrants who are in the country where the project originated and ask them for contacts in their countries of origin. Some session attendees even suggested consulting anthropologists.
Another session covered hacker spaces aimed at empowering women, as well as being comfortable for LGBTQ people. Here again, problems at male-dominated sites can vary. Sometimes, visitors without skills are ridiculed, and women get the worst of it. Other times, women with excellent skills fail to be recognized. Sexual come-ons can take place.
Therefore, in some cities, women have started their own hacker spaces. Some invite everybody, whereas others put restrictions on men’s participation. I suggested that attendees look at BioCurious, which has a female founder and seemed to have a comfortable gender balance when I visited.
Recruitment
Any community that wants to last has to attract new people. Usually this means providing a low barrier to entry, although one speaker challenged that view. She pointed out that some communities require technical gymnastics as a condition for entry, but still attract people who seem to feel special because they figured out how to pass the gateways. She said the challenge in those organizations was to broaden their base while still making participants feel special.
There are established practices for encouraging newbies to participate. Some projects leave the more basic software bugs open until a new project member volunteers to fix it. One attendee suggested that a good goal would be to provide projects that can be reasonably completed in just two hours, from the first download of the software to the successful check-in.
A big part of on-ramping deals with a topic dear to me, good documentation. When projects start, the documentation is minimal. The alpha geeks who start the project write for other people like them: people familiar with the data storage options, the standard protocols used on the web, the concepts of distributed computing, or whatever other background was in the purview of the original developers. The first people who join the project fit this user profile and talk enthusiastically about the project, raising its visibility and making it desirable among a wider crowd. These early adopters also tend to feel that the documentation is adequate, and are nonplussed when others fail to pick up the concepts.
One symptom of a documentation problem is a large stream of questions on project forums. At first, the developers and early adopters are excited to see each new user and proud to provide informal help. But then the project adds more and more new modules and takes more time just to keep stable, at the same time that it attracts less sophisticated users. So the level of informal support drops. Users post questions that don’t get answered (as I demonstrated in a small study and a follow-up). Eventually they silently drift away.
On the technical side, having good information is important, but there is also a personal side to community. A new person has to feel that members of the project are responding.
Finally we discussed some ways to reward participants. When money is not involved, various forms of recognition are required, perhaps even a recommendation.
Other themes
As an unconference, CLS topics reflect whatever attendees bring. Common topics included:
- Trying to apply Agile and SCRUM methods to open source developers, who are geographically remote and have no commitment to the schedule or tasks. Participants in this talk felt they were finding partial solutions, but to me it seemed they had not overcome the fundamental mismatch in conditions assumed by those techniques.
- Balancing the needs of a company that is trying to build a business on open source with the desires of developers and users outside the company.
- Creating change, which is necessary in any community but bulldozes familiar pathways and evokes strong feelings. The general strategy seems to be to encourage supporters of new ways and not to spend much time arguing with the hold-outs.
- Licenses, patents, and (new this year) IRS scrutiny over 501(c)(3) tax status.
- Open source and open data for governments, and how it can encourage civic engagement.
Many of the topics come up every year, but several of us noticed the attendees moving further toward solutions this year. As the field advances, the most trivial mistakes of community management are being anticipated.
Now that CLS is mature, it just needs to reach more places. The power of face-to-face meetings gives attendees both new insights and new energy–I, for instance, would like to pick up my research in documentation for communities again. CLS spin-offs are now held in the Silicon Valley. If conferences of this scope are beyond the means of community organizers elsewhere, they could come together for something as simple as a breakfast to expand their stewardship over the settings that foster ideas.