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?):

WAN costs (both latency and bandwidth) are a complex problem, with many handles. In the enterprise world (unlike the open source world), it's often possible to work with your network provider to improve network performance. Indeed, global enterprises often already control their networks explicitly, and performance problems are very often only the result of configured "Quality of Service" policies colliding with evolving use patterns, which can be reconfigured once the right measurements meet with the right people. 

Server performance is another of those things that can be managed in an enterprise context, and particularly in a good hosted deployment like CollabNet's. The Subversion server code is actually remarkably efficient. Leaving aside pathological cases like runaway spiders, a single Subversion server host can easily support tens of thousands of active enterprise developers, or hundreds of thousands of open-source developers (who, as an over-all average, are less active). As for detecting and preventing the pathologies, that's what quality hosting is all about.

Server availability is much the same: good management can provide very high availability, fail-over, and disaster recovery at reasonable cost and switchover times of only a handful of minutes, with complete transparency to any user not actually performing some operation at the moment of failure. A fail-over strategy that requires end-user reconfiguration when your connected server fails gives the end user some sense of control, but ends up costing each user the switch-over time, regardless of their level of activity at the moment of failure.

Enterprise work flows are one more consideration. A global enterprise will involve many individual repositories, which typically need to be accessed by multiple teams in various groupings. In any replication strategy, the administration of these groupings becomes key. The simple extremes, where either every site has all repositories, or every repository is unique to only one site, are pretty rare. Whether due to co-development, collaboration, shifting team composition, or 24x7 support commitments, most global enterprises need a replication map that's both complex and constantly evolving. Simple central hosting completely eliminates these challenges, of course. 

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.

The first, oh so obvious yet oh so overlooked aspect: As John Mark Walker noted just today, you have to offer something compelling that others want. Memcached does something people really want: "speed up the performance of dynamic Web applications." Everyone wants that--everyone. On the other hand, if you've got some software even you don't want, you're not likely to create a lively community around it.

Secondly, the recent flood of corporate backers are not tripping over each other in order to sell memcached, but rather to ensure that memcached is available to accelerate their actual product. It's infrastructure. It's an enabler. As I pointed out in Open Core, Open Complement, most of the most effective open-source projects are actually about infrastructure: Linux, MySQL, JBoss, Apache HTTPD, PHP, GCC, Subversion. An infrastructure project enables many users, and hence draws many contributers. Opening your core limits your community's potential audience to just your market; opening your complements limits the audience even further, to the programming-proficient members of your market. But opening key infrastructure widens the audience.

Finally, memcached is drawing this flood of interest and contribution because of its very permissive license, the BSD license. This license is among the least restrictive, most commercial-friendly, of all the open-source licenses. We'll see people charging for their version of memcached; that's allowed. We'll see variant versions; that's allowed. We'll see contributions back to the core implementation, forks, and proprietary variants; all allowed. In the world of "commercial open source," it's not the GPL that ensures the most freedom for the licensed software, but the BSD (and the fairly similar Creative Commons - Attribution). GPL was originally about preventing commercial exploitation, and lately has become popular as the open half of a dual licensing model, but those are both prevention strategies, not enablement. BSD and CC-A are about enablement.

If you're innersourcing, applying the techniques of open source development to enhance your internal process, the same rules apply:

• You have to give away something people want
• You'll have the largest audience by innersourcing infrastructure  
• You'll have the largest audience, community, and contributer list if you let go of control 

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.

Indicative of the state of cloud computing, our first order of business was to hammer out a definition: what is "Cloud Computing"? We quickly agreed that abstraction from hardware management was a key thought, but I don't think anyone really believes that's the whole story. Certainly not this group! As we talked, it became clear that most participants thought Cloud Computing also requires refactoring your application for horizontal scale, statelessness and location transparency, and a few other fairly new programming disciplines. These might be part of the definition, or perhaps just "best practices," but they were high on everyone's interest list. (There is, by the way, some good work on-going at NIST in defining the terms of cloudy discourse.)

What strikes me in all this is that, if you're deploying into a cloud, you're going to need several of 'em. Just as you can't let developers and testers and untried code onto a production system, so also a production cloud needs to stay clean. You may be able to share lower levels, but you'll need security separation, debugging tools, experimental versions, and so on. NIST talks about three "cloud delivery models":

• Cloud Software (Applications) as a Service
• Cloud Platform as a Service
• Cloud Infrastructure as a Service 

This all fits very nicely into CollabNet's Lab Manager component: the Lab Manager can allocate infrastructure instances from several providers, and track the profiles that distinguish production from test, test from development, application from platform, and so on. If you're developing at the Infrastructure level, you can use the Lab Manager to allocate physical boxes in your own office, so you can poke and prod. If you're working at Platform level, you can allocation physical boxes anywhere, and exercise your location transparency in and out of lab, test, and even production. And if you're clouding up your application, you can float blissfully above all that, while still complying automatically with your local policies.

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