This weekend I attended the Community Leadership Summit in San Jose. Before it even started, I had an interesting discussion with Jack Repenning and a man who was investigating various community models for a homeschooling organization he's working for. As we talked about the needs of the parents of homeschoolers, I realized how much they had in common with open source community members:

• They are joiners and have need of connecting with other parents like themselves
• They do not want an overt governing body controlling the way the community interacts
• They have need of shared resources and discussions
• They want to stay away from institutionalized or corporate rules and pressures, and instead want the community members to have roles emerge organically

There are likely some similarities I'm missing here, but I realized in this discussion that these types of communities can benefit from the open source community model. In an open source community, it's important that creativity is encouraged and unbound, that community members are treated equally, and that any roles assigned are appropriate and emerge out of needs rather that what an official overhead dictates. This type of community is self-regulating for the most part, if not entirely.

The parents of homeschoolers, and many groups like them, are rejecting conventional methods of education, but that does not mean they don't have a driving need for support, communal togetherness, or collaboration.They do join groups, parenting, educational, as well as many others, but they want to avoid the school "feel."

Additionally, I can see how a project model and platform would work for homeschoolers and their parents. Homeschooling often involves collaboration similar to software development. Needless to say the Subversion and TeamForge platform would be ideal so that children could work together on various projects, keeping all versions of a project and adding to it, while parents could make use of collaborating on resources, documentation, and discussion forums.

Both the open source community model and the CollabNet platform and tools would work well for the homeschooling crowd, and no doubt many other non-developer types.

I'm noticing more communities wiggling out from "the man" and opting for an open environment in which community drives and guides itself. Everyone seems to be tiring of corporate or institutional pressure and dictates. I think we'll be seeing the open source community model becoming more the norm than not over the next few years. And it will be interesting and fun to see what kind of creativity emerges from these communities of free thinkers.

 

Why do people contribute to open-source or inner-source projects?  It's long been recognized that one major aspect is something usually described as "peer esteem." In Apache and the future of open-source licensing, Matt Asay makes the mistake of assuming it's the only factor, and compounds the mistake by assuming he can (re)define the term for everyone else, but he's certainly right that it's one important factor. So what does it mean, and what can we do about it?

Also this week, and totally out of left field for this blog, American Public Media's Speaking of Faith program has published an interview with neuroeconomist Paul Zak and a wealth of supporting material on the neurobiology of economics and cooperation. The research reveals some remarkable things that can be applied to this idea of "peer esteem" in the building of communities.

And (as retweeted by another author in this space, Guy Martin), Steffan Antonas has published a great discussion on How To Say Thank You On The Social Web. As he points out, "saying thank you" is more than courtesy in a community: it's the primary "currency" of the virtual gift economy—which is just the sort of economy, it turns out, that Zak is talking about.

Where these all come together is this: the kind of esteem, the kind cooperation, and the kind of thanks that each build community is, in every case, the person-to-person kind. The effective kind of esteem is not just the esteem of some faceless mass of objectively assessable "peers," it's the esteem of the peers I know. And it's not the esteem of those known people who are my peers by some scientific test, but those who I esteem as peers.  And, further, my esteem for them arises from and contributes to their esteem for me: we are mutual peers.  And such mutual esteem can only grow within, and cannot help but further feed, a strong sense of belonging to the same community. And this is just exactly the sort of community that Community Managers need to foster and feed, in order to spark the contribution and cooperation that makes open- or inner-source work so productive and powerful.

The sources I link here reveal a rich interplay of insights into what "peer esteem" is, how it's done, and what it produces. So there you are, Community Managers: you have your reading assignment for the week!

With 'Government 2.0' receiving a disproportionate amount of coverage in the press lately (due in part to the new administration's focus on transparency - a good thing in my opinion), there have been a number of pundits who have asked, 'When will we know that we've reached Government 2.0, and how long is that going to take?'

I think that begs the question of exactly what constitutes Government 2.0, as well as sets an unrealistic expectation of a finite process that has a clear beginning and end. Clearly, any effort designed to fundamentally change within the Government such things as technology acquisition, transparency, or collaboration will not be a 'forklift revolution,' but an ongoing and constantly reviewed process. I think most intelligent and knowledgeable folks within government realize that successive approximations are the only realistic way to make this happen.

There has been good progress on some of these fronts (both for internal government & public collaboration) - notably data.gov, Intellipedia, A-Space, whitehouse.gov, and even Forge.mil. However, one of the recent approximations that I believe is critical to this effort has happened within the Department of Defense - a call to streamline the acquisition process for Information Technology. Currently, the IT acquisition process is the same one used for things like tanks and missiles, systems that require a large up-front investment in requirements analysis and a strict process to ensure they can perform the necessary mission before the 'crank is turned' and thousands of items are produced and delivered.

Software, as most of us know, doesn't operate that way, and in fact, needs to be able to adapt to changing technologies and requirements throughout the life cycle of deployed systems. The DoD will be fielding 10 systems in fiscal 2010 to be acquired under the new, more streamlined process, and if these are successful, there is a strong chance that the program could be expanded to add more systems in the future.

I should also note that there need to be approximations within approximations. I know this sounds silly, but the best example I can think of is cultural change in how IT and other software support systems are developed and fielded. A large change in the culture that we are attempting to engender with the Forge.mil effort is shared (and in many cases, 'open' within the DoD) collaboration. There are approximations within this cultural change effort aimed at getting people used to not developing in silos, looking for, and building reusable components, and accepting contributions from qualified members of the department outside of their immediate project team.

Once I fully realized the need for these approximations in my efforts as one of the Forge.mil community managers, it was easier to relax and treat this entire effort as a continuous process, not as a finite deliverable. I believe it is critical that the larger government community adopt this same approach as well - attempting to build out all parts of what Government 2.0 could or should be right away would be expensive, and doomed to a lackluster reception by those in the community who need it most. The new DoD acquisition plan seems to correctly recognize a need for 'course corrections' or 'approximations' as we move forward toward building a more participative technology infrastructure for government. I'm hopeful that it will become the model for other government agencies going forward - quite honestly, doing it any other way probably portends failure from both the technology and fiscal perspective.

Most people know the definition of a chameleon - but, true to my engineering roots, I'll take no chances and quote Wikipedia on the subject:

"Chameleons are people who can change their personality and appearance with ease, morphing into a seemingly different person..."

I think that is a great definition of what community management is all about. By the way, credit for planting the seed for this missive goes to my colleague Carey O'Brien - we were having a great discussion on the skill sets/personas needed to be an effective community manager, and we came up with the list below. Feel free to comment and suggest your own additions, since we might have missed your favorite. Community managers should be equal parts:

• Psychologist
• Coach
• Information Synthesizer
• Matchmaker
• Referee
• Customer Support Person
• Business Development Professional
• Karmic Leader
• Public Relations Guru
• UPDATE: Rabble-Rouser - credit to Jim Storer - see his comment below...

Amber Naslund recently wrote a great blog post entitled: 'Five Myths of Community Management,' which I think crystalizes the varying roles mentioned above in this statement:

Community Management is '...a different and evolving discipline that needs to adapt based on the needs of the business. And it does every community person a disservice to park them in the communications basket and leave them there.'

The fact is, you really DO have to be a community chameleon, playing one or more of these roles on a day-by-day, minute-by-minute basis. Yes, you can and should recruit community leaders to help, but ultimately, the buck stops with you as a community manager. Learning how and when to play each of these roles is not something that you can easily teach or write down - this is a skill you pick up by experience, mentoring, and by having a natural ability. There are plenty of people who are great managers of people that report to them, but those kinds of skills are not always as helpful when you are trying to influence and mold a community with choices as to who they'll follow.

What I also find interesting is that though there are common skill sets all community professionals seem to possess, there is a vast difference between running a developer community (my area of expertise), versus a primarily social community. For example, I'd be a horrible community manager for a site catering to fly fishermen. :) However, don't let a perceived requirement for deep domain expertise put you off to a potential community manager within or outside your ranks. Amber hits the nail on the head when she mentions evolution and adaptation - those traits are usually present in folks with the right 'curiosity bit' turned on. These kinds of individuals can quickly get up to speed and bring their own unique skills from the list above to bear on the community they are tasked to manage.

The variety in community management is one of the main things that makes it appealing (and challenging) for passionate people, and why determining success is sometimes very 'squishy'. You can have great metrics (# of members, # of forum posts, # of source code checkins (for dev communities)), but still have a horrible community. Conversely, you can have what would seem to be sub-standard metrics, but have a thriving ecosystem, because people are getting their needs met, which, in the end, is the ultimate definition of a successful community. Learning to accept a certain amount of uncertainty and being willing to 'change your spots' when necessary is critical for both people charged with building community, and the senior leadership asking them to do so.