I was unable to attend last year's inaugural Community Leadership Summit, but when Karsten suggested that we combine this year's event with both OSCON and some face to face team meetings and goal review, we decided that it would be a great way to get the whole team together, and to ensure that several of Red Hat's community folks were present at the event.
Karsten, Ian, Mel, Robyn, John, and I attended some of the same sessions today, and I was frustrated when we sat down for dinner and I started to express my general disappointment (not with the event itself -- credit and thanks to the organizers) with the results of two sessions that I attended.
Once I was forced to articulate my problems, it became clear what they were:
I felt that the word "community" was very overloaded in the context of this event, and that there were a number of people who participated in online communities, but that there was a wide diversity of what those communities do, and what (if any) goals those communities have. For instance, an online community that is basically just a group of people sharing advice with each other has an entirely different set of dynamics than a community like Fedora that has specific goals, a schedule that results in tangible deliverables, and specific metrics by which success and failure are measured.
In the context above, a conversation about "conflict resolution in online communities" can be a bit frustrating when the majority of the people speaking stop their thinking at "well, just remove dissenters from the mailing list". Within a community like Fedora, that sort of draconian action would only make the situation worse, because healthy dissent and debate is one of the values that the Fedora community exhibits (possibly to an extreme, but that's a different blog post).
Another frustrating session was pitched as "resolving conflict between corporate developers and community developers". I had several problems with this session, the greatest of which was that the entire session took as a given the fact that (a) conflict of that sort must exist and couldn't be reduced or eliminated and (b) the community's influence on roadmap or feature desires were risks to be mitigated or hedged against.
This flies in the face of all the community experience that Red Hat has engaged in, which has demonstrated that being a part of an active open source engineering community not only speeds innovation, but greatly reduces the risk of a small pocket of engineers developing a product or chunk of code that no end users are interested in purchasing or building upon.
I spoke up in the session -- which was attended by several people who stated that their task was to grow new communities around a particular technology -- and tried to get them to talk about what the fundamental goals were. Why is a corporation deciding to invest in a community? It must mean that there is something they hope that community can offer that otherwise would be lacking? Sadly, no real conversation came out of this.
In summary, I felt like there were several different pockets of people at this event (which is fine -- diversity is good), but that everyone was talking past each other, rather than finding common ground.
As Karsten reminded me -- don't file a bug without offering a fix. As such, my plan for tomorrow is to pitch a session that tries to rectify this. I'm going to suggest a conversation that is about not only identifying the goals of communities, but that also discusses the analysis that should be done before saying "yes, this is a task for which community building would be a useful tactic." I'll borrow from bits of talks and presentations that we've been putting together inside of Red Hat and Fedora for years now. We'll see how it goes.