You can trace the entire history of our industry by its enthusiast-generated events. The microcomputer revolution was begun by volunteer, community organizations (such as the Homebrew Computing Club at which the Apple I was initially demonstrated) and continually energized by yearly events like the Trenton Computer Fair. I’ve been involved in creating more than a few community-created events myself, from the Downeast Computer Fair in the late 1980s to the still-ongoing Warpstock (it outlasted my involvement). Professionally-led tech conferences have their place (a good place), but there will always be a role for the “by and for ourselves” event. That has to be true especially for the open source community and its philosophy of everybody chipping in to improve the quality of life.
And by that measure, last week’s Open Source Bridge conference in Portland Oregon was a significant community success. Over 400 people attended (primarily but not exclusively from the Pacific Northwest). It was a knowledgeable crowd; 83% of them have been involved in FOSS for more than three years. One in four attendees were also presenters; notably, one in three presenters were female. Some of the speakers have names you may recognize, such as Ward Cunningham (inventor of the wiki), Sam Adams, the mayor of Portland, Sarah Sharp (author of the first USB3 driver), and Deb Bryant (from the OSU open source lab). But plenty of the people who contributed time and expertise are relatively unknown, at least outside the local area, and their sessions were just as attractive.
This wasn’t a “news”-centric event, with big product releases or industry announcements. There were a few items of note, which I’ll get to in a moment, but primarily everyone’s attention was on sharing technical and community how-to. To some degree, members of the open source community also examined it as a social phenomenon, as in cyber-anthropologist Amber Case‘s analysis of how open source software spreads cyborg culture (or how, as she explained it, “humans and technology co-create each other through an actor/network of technosocial interactivity”).
The conference had several tracks, from tech-centric guts to business issues to community. I’m no longer a programmer, so I left others to attend the (popular) sessions on topics like “Layers of Caching,” “Five things to know about MySQL if you don’t have a DBA,” and “Drop ACID and think about data.” Regretably that meant I had little reason to attend the well-designed “CodeIgniter as a drinking game” (Rules: Every time I demo a new CodeIgniter library, we drink. Every time I say “Can you believe how little code that took?” we drink.).
Instead, I spent most of my two days (I didn’t stay for the un-conference or the Hacker Lounge) at the squishier people-centric and business-centric sessions ‚Äî and I didn’t regret it for a moment. I’ll share a sample of the information I acquired below, in a necessarily disjointed fashion, but I can’t possibly impart it all. (I already covered two of the sessions about Starting a Business as an Open Source Consultant elsewhere.)
Portland and Vancouver Duke It Out
Let me start out with that cheerful news-ish item, announced by Mayor Sam Adams of Portland in one of the several keynote addresses. Adams, who is promoting technology as a core competency of the city of Portland, said, “City government has been a laggard in open source approaches. I’m going to do everything I can to change that.” He sees open source as an opportunity to help out local community efforts particularly because “We’re big spenders in digital media.” For example, he said, the city is currently working on RFPs to create applications to turn city-generated data into useful and compelling data for consumers ‚Äî not just lists ‚Äî and his intent, at least, is that those applications will be open source. “There’s a lot of knowledge in our data. It’s just not accessible to decision makers in a way that’s easily understood,” he said. “That’s important for the basic functions for democracy.”
But Adams didn’t stop with just a couple of Web apps. He threw down a gauntlet, challenging the city of Vancouver BC, which recently announced its intention to become an open-source government. “I’ve gotten to know their mayor,” said Adams. “We’re going to do everything we can ‚Äî in a very friendly competition ‚Äî to out-open-source them.” Won’t that be fun to watch?
Managing the Jerks
One of my favorite sessions, “Assholes are killing your project,” was led by Donnie Berkholz, who learned some of his lessons the hard way in his involvement with Gentoo Linux. “This talk will teach you about the dramatic impact assholes are having on your organization today and will show you how you can begin to repair it,” he promised. “The strength of your community is the best predictor of your project’s long-term viability,” Berkholz said. “What happens when your community is gradually infiltrated by assholes, who infect everyone else with their constant negativity and personal attacks?”
Among the issues he addressed — with wisdom and humor — were:
- Strategies beyond banning and “don’t feed the trolls”
- Funneling negativity into something constructive
- What we can do when we’ve been beset by trolls
- How to help people realize they are assholes (even when the key leaders are the guilty parties)
Berkholz necessarily started by discussing the elements of community, and what makes one great or horrible. For instance, people engaging in conflict isn’t inherently bad behavior; it’s usually just the opposite. “When two people argue, you come up with more and better ideas,” Berkholz pointed out. A new contributor should be able to suggest something and be given the same respect as someone with 10 years experience. But when one person becomes a jerk, that inhibits others’ desire to talk. As professional community moderators have known for a long time, the distinction is usually when people are arguing about the ideas and not insulting the people. (There’s a vast difference between “That’s a dumb idea” and “You are dumb.”)
But many people don’t know how to argue productively, and it’s safe to assume that you, oh most loyal of readers, have encountered someone with that particular character weakness.
Berkholz has two tests for whether someone is an asshole:
- After talking to the person, does the target feel bad about themselves? (oppressed, humiliated, belittled)
- Does the asshole target those less powerful?
The first, he points out, is really the key criteria, especially when it’s a patterns of behavior. We all have our bad moments, but some people are always having a bad moment. “If you’re having bad moments 90% of the time you might be an asshole,” he said.
Berkholz suggests that open source projects “get in the spirit of being quanititative and using measurements to see what the impact is on your project.” It’s hard, he admits, but it’s do-able. Look at how often an offending individual posts on a mailing list and how many people unsubscribe, for example. Do a 360-degree survey in which you ask project members how they feel after they deal with this list of people. “Try to come up with some kind of numbers,” he urged, because you can’t determine if you’re improving unless you have some way to measure it. “We can’t measure how much asshole they’re being… but you can measure how much code he committed. You need a way to counter that and deal with both sides of the issue,” he said.
Berkholz cited research to judge how well the good balances out the bad: Does one insult balance out one compliment? He found studies indicating that a negative interaction is five times more powerful than a positive interaction. Or, as Berkholz summarized, “Less than one sixth of your people can be assholes [for your project] to break even. To build a better community you have to beat that.”
Maybe you think that your project is relatively immune, but Berkholz cautions that the jerks are still having an effect, particularly on new people. “Over time it becomes less obvious who the real problems are,” he said. “You build up a tolerance.” For example, he said, every active developer in the Debian community has put some people on Ignore. But new subscribers see every one of the messages from the jerks ‚Äî and those subscribers are your potential new contributors. “You need the inflow of new people who aren’t being scared off.”
That has especial impact on the gender balance in open source projects (and in technology overall) since, he said, when a man is attacked personally he fights back. “It turns into a battle of the wills to see who can win. Both walk away with bruises.” But when a woman is attacked, in most cases she avoids the problem instead of retaliating. In collaborative communities, “avoiding” can easily translate to “walk away forever.”
I probably don’t need to belabor the point: Assholes are bad. How do you fix it? Among Berkholz’s suggestions:
- Get to know people better, with more personal interactions. An IRC channel, not just a mailing list. Have a conference.
- Model what a good interaction is like. Set the community norms into a code of conduct. “It takes a long time to understand a culture when nothing is written down,” he said, “like dealing with undocumented code.” But do note that the assholes will find the loopholes!
- You need a way to deal with people who are being assholes. The targets need a place to go to report a problem, and to get fast response. They are encouraged when they think something is going to happen. “But if nothing happens… it’s even worse because now you’re a hypocrite too,” Berkholz added.
- Remember: the mission is not “Make these assholes better people.” The mission is to make this software work. Identify to the jerks what is okay to say and what’s not. “Try a few times to see if you can get them to change,” he said. But if they haven’t learned after three times, they won’t get it.”
Open Source Press Relations
I had a vested interest in attending Josh Berkus’ session on how open source projects should deal with the press, because I’m leading a similar session about the topic at OSCON (though from the journalist’s side of the desk). Although you might associate Berkus primarily with PostgreSQL, he also organized the OpenOffice marketing project in 2001, and successfully got it plenty of coverage.
And, he stressed, no matter its size, your project needs a marketing department. Like any other area of specialization within the project, the marketing and PR efforts need their own resources, including volunteers, press contacts, reference users, a press kit, and (occasionally) just a little money. As usual, the people-resources are the most important, including translators (it’s easier to get coverage in Turkey if the press release is in Turkish), writers, and designers. “PR contributions are as valuable as code. Treat it that way,” said Berkus.
He emphasized the need to create a press list, separated into three categories of contacts:
- Cold contacts: They get major news only, such as version releases with a major new feature.
- Warm, such as people who have written previously about your project or competing ones: Tell them about major releases, as well as general significant project news.
- Intimate: The people who show up at open source conferences. “You can send them anything that might be newsworthy,” Berkus said.
His advice was specific and, speaking from the frequent-recipient side of the desk, very good. In a discussion on writing press releases, for instance, he pointed out that a press release is not simply a copy of your release notes. He gave a useful timetable for drafting a release (start eight weeks out, and debug the writing just as you do code, allowing 3-4 weeks to finalize a draft). He explained what “an embargoed release” is (a concept that many professional PR people fail to grasp, alas). And he compared-and-contrasted the way that amateur bloggers and professional reporters cover events. Good suggestions, all.
Making a DIY Event Work
It’d be awfully easy to focus only on what people said during the sessions at the Open Source Bridge conference, because that’s the meat of what made the time useful for most participants (and, I hope, for you as a reader). But I want to devote a little space here to cheering the success of this event as a community activity, because I think it was exceedingly well done. You might want to participate in the Open Source Bridge conference next year ‚Äî yes, they’ve already said they’ll do another in 2010 ‚Äî but if travel to Portand is not feasible (and really, I do encourage you to try; Portland is a relentlessly friendly town with great chocolate, beer, and coffee), you might want to consider rolling your own event in your own community.
One hallmark of the Open Source Bridge conference was an incredibly warm, welcoming ambiance. Strangers talked with one another… and they didn’t stay strangers for long. People said Thank You ‚Äî often, and with sincerity. The underlying theme seemed to be, “How can we make this work?” so, for instance, I spoke with one attendee, currently unemployed, who’d arranged to volunteer for a certain number of hours instead of paying the event registration fee. I don’t know whether to attribute this to the general Portland friendliness (not only in the FOSS community; a stranger on the street saw me looking at a map and asked if I wanted help), to the high proportion of women involved (there I go with my own gender stereotypes), or to the Portland-area in-person FOSS community (do other towns have anything approximating the Portland Open Source Software Engineers?)‚Äîbut gosh, it sure worked.
That’s not to say that everything worked perfectly; few volunteer events (or commercial events) do. There might have been a little bit too much overlap in session topics (was it really necessary to have two or three sessions about making a living in open source, in addition to Kurt von Finck talking about the hacking business model?), and the exhibit hall was mostly a bunch of 8-foot folding tables with brochures, abandoned by humans most of the time. But that was okay, because when a problem came up, someone usually offered to help solve it.
And that’s what community is all about, isn’t it?
