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...

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.

For two days last week myself and the other CollabNet community managers brainstormed ideas, shared experiences, and drove direction for an Enterprise Community "Cookbook". Over the course of time, it has come to the managers attention that written processes were needed, problems shared, and solutions derived and pulled together into a single resource area, not just for ourselves but the community at large.

Communities should, after all, be based on collaboration to be successful and healthy. No single person can accomplish this, nor should they. At CollabNet, collaboration has been its theme and foundation from its inception, so it only made sense that we share our processes and findings with anyone who can benefit from our experience and knowledge. The flip side of that is that we hope to get input and feedback, and have collaboration with other community managers.

We started our discussions by comparing the Open Source community with the Enterprise community, and identified the commonalities. This turned up some fascinating information about the nature of the communities themselves, and their needs. Next, we discussed community goals, and what right kinds of questions would provide intelligent types of metrics. So far, I was seeing the value of our strategies not just for Enterprise communities but for Open Source communities as well.

Over the course of the two days, we had covered the walls with large sheets of paper, which contained many sticky notes from each of us. All of this now has to be distilled into formats that would be easy to understand to outsiders.

We realized that before any community, Enterprise or Open Source, can be built, a community plan must be written out. This would help our sales people communicate to customers what they get when they request community managerial support, but also what we hope to achieve with our Open Source community and what we are to give in return.

Our first document to take shape that others can use is Best Practices and Steps to Creating an Enterprise Development Community. Many other documents will emerge from our meeting. As we complete them, we will add them to our public project where you can glean from what we post there.

We also agreed that all of this information is fluid, subject to change, and must be rejiggered with various clients and communities. None of these documents are intended to be written in stone, or will be the last word on the topic. It's an evolutionary process, and we decided to meet at least once a year to reassess and rewrite process as needed.

As the openCollabNet Community Manager, I would like to distill the useful information and processes that are specific to creating Open Source communities, so we end up with "cookbooks" for both Open Source communities and Enterprise communities, or we may create branches off of the other information.

However we decide to present the information, watch this blog space and Twitter for links to these documents as we make them available.

In the echo chamber of developer tools, a hot topic these days is "distributed vs. central version control." The debate has an unfortunate tendency to polarize into "developer vs. organization," which of course doesn't really help anyone at all. WANdisco's Jim Campigli, writing as "SubversionMan" (jeez, Jim: show a little respect for the nearly one thousand committers and other folks who've actually contributed to Subversion!), tackles a more productive, if more narrowly nuanced, question: how can we preserve the organizational benefits of central systems, while mitigating the obstacles for the developers?

In his latest screed, Jim identifies three key trade-offs in version control for global organizations: WAN costs, server performance, and server availability. That's a pretty good list; I'd only add one more: support of enterprise-scale work flows. Having agreed on the list, though, I'm not sure we agree on the outcomes (but, hey, that's what blogs are for, right?):

Matt Aslett of the 451 Group has provided a great example of some powerful yet overlooked aspects of some of the most successful open-source projects. The example is a utility called memcached, an in-memory caching daemon to speed up web applications.

As I thought about the title for this post, I realized I'd be taking my chances with it from a hype and buzzword perspective. If there were ever two concepts that are emblematic of where we are today in technology, it would have to be 'Community' and 'Government 2.0'.

Unfortunately, they are also two of the most overused and over-hyped phrases in our technology lexicon. However, given what I attempt to do everyday in my role as Forge.mil's community manager, I'm hoping I can cut through some of the hype and bring some practical ideas to this space. This is also an opportune time for me to get some of these thoughts down here, as I'm planning on giving a new, more community-focused presentation on Forge.mil to the folks at the Online Community 'Unconference' being hosted by ForumeOne Networks on June 10th, 2009 in Mountain View, CA.

Because of my engineering background, I love reuse, so, I've titled the talk 'Generals, Colonels & Community - Refactoring DoD Software Development'. Some readers of this blog will recognize the first part of that title from a previous post of mine on this subject. So, without giving away all of my presentation (I'd love to have folks come see it in person!), here is some of what I'll be covering from the 'What Have We Learned about Gov 2.0 Communities?' perspective:

• They are more risk averse than their corporate counterparts
• They're addicted to email - if the community platform doesn't reach into email, you're in trouble
• They require slightly more 'Stick' (top-down pressure) than 'Carrot' (grassroots)
• They tend to grow around efforts to extend tools (SharePoint, Lotus Domino, Red Hat Enterprise Linux), rather than their own technology
• They require more of a 'contact-sport' approach - face time and one-on-one explanations

The good news I've found in the short time I've been working in this space is that there are pockets of somewhat frustrated, but extremely passionate Open Source/Open Collaboration champions in this world. Those are the people that keep the momentum going, and as a community manager, you have to give them as much care and feeding as you can, since they are paddling upstream against a very strong cultural current.

I'll do a post-conference write up on what I learn from giving this talk, as I plan to utilize the cadre of community-minded folks in attendance as a sounding board to help me improve it. I hope to see some of you at the event - it should be a productive day listening and learning from some of the best community management minds in the field!

I spent a great half-day at CloudCamp @ CommunityOne, this week. This was an Unconference, "a facilitated, participant-driven conference centered around a theme or purpose," meaning that the agenda and content were provided by the participants. The format can be very effective, especially in cutting-edge, rapidly evolving areas like this.

Last week I attended the Virtual Edge Summit, which  focused exclusively on providing education, training, and solutions for planning and producing virtual events. I attended the first day in person, and the second day virtually.

It's not surprising in this economy that virtual conferences are becoming more popular. What I did find interesting was the number of virtual conference vendors out there, and the quality of their software and services. In addition, it was fascinating to listen to some of the top dogs, such as IBM and Oracle, speak about their experience with virtual conferences, the mistakes they made, how they corrected, and what expectations should be.

Conferences are at heart about community. You aren't bringing together hundreds or thousands of people just for the heck of it. Every conference must have a purpose, a goal that is wrapped up in intention to better serve that particular community with services, products, and communication. After all, this is not a one way street. Companies need to find out what their communities need from them and how they can better serve them. Conferences are a great opportunity to do just that.

So, when considering a platform for your virtual conference, it's vital to make sure it's going to satisfy the social aspects of a conference. All the speakers at the Virtual Edge Summit made it clear that virtual conferences do not replace face-to-face contact and in-person conferences, but rather they extend and enhance the typical conference. Businesses need to make sure the virtual experience is every bit as satisfying as the in-person experience.

Most of my experience with virtual conferences and meetings has been in Second Life (SL). I like SL a lot, and use it way too frequently for my personal fun, but I have found professionally that SL has a steep learning curve for many, has big computer requirements, and therefore some attendees are less likely to join that platform. What is great about SL, though, is the 3D environment lends to a feeling of "being there" and having avatar-to-avatar contact gives more of a face-to-face feeling than does 2D.

The Virtual Edge Summit did a great job of uniting the in-person experience with the virtual. While in sessions, we could see the virtual session while they had us on a screen, so we could see each other. Virtually folks entered their questions and comments through text, and chatted with each other, commenting on what the speakers were saying, while listening to our in-person questions and comments.

The Virtual Edge Summit used VirtualU, a virtual universe created by Digitaltell Inc. This platform provides a 3D and 2D experience, which I really liked. First you download the software, which has a small footprint, then select an avatar. Navigation buttons are at the bottom of the screen at all times. The virtual environment is on the left, while a small panel of 2D features is on the right, giving you access to any file downloads, such as PDFs, text chat, etc. It was nice to use the software in a real conference to see how it worked. Other vendor software there worked similarly, some using only 2D and menuing systems, which offered a lot of nice features.

For CollabNet, since we are a smaller company, some of these platforms are going to be out of our budget. I'm researching less expensive alternatives, while being careful that the platform gives as "real" a conference experience as possible. Community is important to us, and one big attraction to having a virtual conference is that more people can attend since travel is not an issue.

I would love to hear from you on your experiences with virtual conferences, how likely you would be to attend a CollabNet virtual conference, and what some of your expectations would be.

Another interesting use of this platform is that some companies are extending their websites with this software so that folks can visit virtual chats and 3D forums year-round. Sites have had text discussion forums for a long time, but it seems our online communities are getting 3D face lifts, such as extending into places like Second Life or platforms like VirtualU. I welcome your thoughts on this topic as well.

Dana dnourie at collab.net

I must admit, I really enjoy my job, and the industry that I'm in. This week I went to the Virtual Edge Summit conference in Santa Clara. Today, I am attending that same conference, but I'm participating while lying on the couch, laptop on my lap (go figure) in my jammies, and getting other work done at the same time.

Virtual meetings and conferences are wonderful. I'm not saying this replaces face-to-face interaction, but there are many advantages to attending meetings and conferences virtually:

1. Convenience -- no traveling; easy to join in; can squeeze in between other tasks because you don't have to go anywhere
2. Increases productivity -- you can do other work when parts of the meeting don't apply to you, or during conference sessions of no interest to you
3. Document share -- you can share documents or other computer assets instantly
4. Increased communication -- while one person is talking, you can IM others pertinent information
5. Expense -- virtual conferences and trade shows cost a lot less to run than physical ones, or extend the physical
6. Increased Participation -- Folks from all over the planet can join since no physical travel is involved
7. Near face-to-face - Video and avatars, plus live chat or voice, provide a near face-to-face experience that is immediate

I'm looking into various software applications for CollabNet to use for virtual conferences and trade shows. Yesterday while at the Virtual Edge Summit in person, I had a chance to talk to a few vendors. My experience has been mainly with Second Life, so this was a nice opportunity to see what other folks are using, and what features are provided.

Some of the software was mostly 2D, some of it 3D similar to Second Life, and one ran in the browser, using graphics and a menu system. I was impressed with all. Some are quite pricey but have a lot of features. I'm also looking online for less expensive alternatives, and to see what is available.

I welcome suggestions from you folks who have experience with particular software that you really like. I'd also welcome hearing your experiences with virtual conferences and tradeshows.

Email: dnourie at collab.net

One thing that makes communities so interesting is their diversity, which can be characterized by how the community structures itself.  Compare openoffice.org vs. tigris.org, for example. While both are focused on building open source applications, they differ in how community efforts are organized.   Where tigris.org is organized by tool type (scm, issuetrack, requirements), openoffice.org is categorized by product management (product development, promotion, distribution, language development and support). 

So, how do communities categorize?  Sometimes natural groupings form around areas like technology drivers, organizational alignment, partner alignment, and application type.  For others, the need to categorize manifests later when the community realizes that there’s lots of good stuff out there, but no way to find it all.    

If it becomes your task to assert some community structure, consider the following:

• How would new community members easily find stuff?  Would they start out looking for efforts within a specific branch of government or efforts that relate to a specific type of artillery used in any government branch?
  

• How do community members characterize their efforts?  Do they align with .Net vs. Java code efforts or accounting apps vs. marketing apps?  

• What type of alignment supports your Community Goals?  Would having a category for each Reference Architecture help you identify improved levels of knowledge sharing and compliance?  This typically resonates with Enterprise communities, who want to prove the value of their community investment.

Community categorization reinforces the mission of the community.  As many thriving communities have discovered, having a strong categorization helps new community members understand how to successfully participate within the community. 

How is your community categorized?