The Internet is full of comparisons of the relative popularity of web browsers, but something these analyses miss is that "web" traffic is increasingly not about "browsers" at all. As SOAP and SaaS and Clouds expand, the web has largely become the Internet: the backbone for many services not directly displayed to human eyes.

As a case in point, consider our site Tigris.Org. I was analyzing traffic there recently, for other purposes, and came upon some interesting numbers. In a period of a few (basically randomly selected) days recently, 

• Firefox browsers hit the site 2,964,556 times, making them #3
• Internet Explorer browsers hit the site 3,350,885, making them #2 by a fairly narrow margin (13%, which is narrow compared to the 40% or more these numbers change from day to day)

But "who's number one" you ask? Subversion, with 5,724,275. Subversion traffic is roughly equal to Firefox and Internet Explorer combined! 

Chrome (501,455) is doing pretty well, for a newcomer, clocking in around #6, and Safari (302,483) is at #7. 

"Wait," you say: "there's another gap there, what happened to #4 and #5?" Web crawling spiders working for search engines come in at #5 (1,116,299), but what's #4? Java libraries of several sorts (1,798,848).

Sorted out in order:

1. Subversion: 5,724,275
2. Internet Explorer: 3,350,885
3. Firefox: 2,964,556
4. Java: 2,915,147
5. search 'bots: 1,384,917
6. Chrome: 501,455
7. Safari: 302,483

So: version control operations are overwhelmingly number 1: people are using the web to create new stuff.

Browsers are still big business, at #2 and #3 (don't short-sell your Firefox stock just yet ;-), but on the web, "automation" is "Java" is roughly equal to any human browsing.

We've recently published our CollabNet Community Management cookbook, and have had some good discussions already in the forums surrounding our attempt to give something back to the community (and yes, to showcase some thought leadership around community leading to consulting gigs). :)

One of the discussions that was happening was around 'next steps', or 'rollout plans' and the topic of community champions was raised. Fortunately, there is plenty of commentary/data out there around this subject. In fact, I recently read a great post by Rachel Happe (of the group Community Roundtable) on her version of champions, specifically 'Cheeseheads'. Now, for those readers not familiar with the National Football League, that name refers to the passionate (some might argue overly so) fans of the Green Bay Packers. These folks are some of the most loyal people you'll ever meet, and Rachel's point is it's crucial that you cultivate, nuture, and reward these 'cheeseheads' in your community. These are the kind of people that will make your life as a community leader either very hard or very easy.

As an example, when I was helping run a small skunkworks team at Sun Microsystems, we literally had to rely on the notion of 'Tom Sawyerism' (i.e. - getting folks to come alongside us as we attempted to do great things). Rachel's cheeseheads are people cut from the same cloth as those we found to turn projects from a small 3 person team into some of the largest successes in the company - projects like the JavaCar.

Now that I help companies try to run the same kinds of communities within and outside their organizations, the lessons of the past keep coming to the forefront - one of your primary jobs as a community manager/leader is to find these 'cheeseheads in the rough'. Easier said than done you say? Let me offer a few suggestions:

• Look for people not afraid to bend rules to get things done
• Find people with pain points that your community effort can solve
• Get people who want to make a name for themselves

While two out of these three qualities may seem incongruent with leadership, generally, people with those traits will be your staunchest allies if you are providing them an outlet or capability to solve their pain. Once you've found them, explain to them how the community you are building benefits them (WIIFM principle). Yes, you may have to 'sell' it a bit, but if you can find two or three people like this in a small community, who turn around, advocate your efforts *and* recruit new leaders, you'll be on your way to a healthy community ecosystem.

Always remember that your job as the community manager is partially like that of Tom Sawyer - find other people to come along and help paint your fence. Unlike Tom though, you aren't completely abdicating responsibility - you're there to help guide/coach/mentor your cheesheads. :)

I've just started reading Trust Agents, by Chris Brogan and Julien Smith, and if you're interested in community building and innersourcing, I think you should, too. 

If you know of the book, that might surprise you: Chris is well known in the "Social Networking" world, possibly more closely related to marketing than to software development, and I don't really do marketing. But in many ways, "Social Networking" is one of the ways in which open-source techniques are finding new life in other domains. Here's what I mean:

In "Trust, Social Capital, and Media" (the first chapter), the real money quote is:

Communities don't want to be managed: they want to be cared for.

That's a great statement! You can find it in the foundations of such open source classics as Karl Fogel's Producing Open Source  Software. Actually, I don't think Karl has any one quotable statement of that principle, but it's easily recognizable as one of his primary convictions. Consider, for example, Karl's Setting the Tone:

Choosing a mailing list address is easy; ensuring that the list's conversations
 remain on-topic and productive is another matter entirely. 

Again, Chris describes the dynamics of Trust Agent conversations:

We're just interacting. We used to do that by e-mail, which is private;
 but the fact that it's all done in public view now means that all the participants
 on the Web are creating value for each other simultaneously.

And Karl's Avoid Private Discussions section similarly shows how public discussions benefit many people, not just the original questioner, as well as creating permanent records that go on giving value long after the original conversation is complete.

Chris ties this all together like this:

Social capital is different from other kinds of capital.
 When people come together and share a meal, they not only end up fed,
 they also become tighter as a group. ...
Just think of your favorite television cop drama and how often the phrase
 "you owe me a favor" is uttered. These things are real.

In the literature of open source, this is usually referred to as a "gift culture," well-presented by Eric Raymond in his paper Homesteading the Noosphere:

If one is well known for generosity, intelligence, fair dealing, leadership ability,
 or other good qualities, it becomes much easier to persuade other people
  that they will gain by association with you.

So, what does it mean to care for a community, not just manage it? Again, Chris:

Make everything you write something that's helpful to other people;
 if those people might also be your customers, all the better.

That's the open-source inspired, communitarian spirit in which we recently started up our Community Management project (think we should change the name?).

Are you a Trust Agent? Would you like to be? Come join us, and build up a little social capital!

As community managers go about each day with a multitude of tasks from providing product and site support, managing various programs and projects, creating slide shows and webinars, to answering reams of emails, we don't always stop to see the whole picture of what's involved in creating and sustaining community. Yet, CollabNet has over 10 years of experience now doing just that, and each of the community managers have at last that or more years working with online communities.

We've had a good deal of success in creating and maintaining both open source communities and Enterprise communities, so it seemed only right that we share what has worked for us with other community managers. The question then was how do we go about pulling all that information into one place, and break down our experience in an easy-to-understand format?

Community in Box services was conceived to help software development teams establish and nurture the collaborative culture characterized by the most successful open source communities. As a part of that service, we wanted to offer a free Community Cookbook, full of our expertise and wisdom, outside community managers could use, and so companies could see what is involved in creating and maintaining Enterprise and Open Source communities.

So, back in June '09, five CollabNet community managers and several executives met on the east coast for two full days to cook up, brainstorm, all that was involved with Enterprise and Open Source community management. Carey O'Brien had the wonderful foresight to bring big wall size sheets of paper, and over the course of the two days we each contributed our experience to specific categories and areas of community management.

Of course, sheets of paper can't be shared with the public, so we wrestled that data into a TeamForge project. The Community Management Project contains the Enterprise Community Cookbook and the Open Source Community Cookbook. You need to register and log in to view the pages.

Some of the community components we covered in the cookbooks are represented in the image below:

There are, of course, many topics within each of these components, including why a community is so necessary to have.

This has been an exciting project to work on for all of us in the Enterprise and in Open Source. To see the differences in how we handle and support each of these communities is interesting and important.

While all businesses would like large communities to flock to their platforms, software, and products, it's essential to have made the right preparations for community support and management, and to understand the nature of those communities so they can flourish. Then everyone wins in the end.

Enjoy the Community Management Project!

A while ago, I pointed out that many discussions of open-source related business models are leaving something out: infrastructure. A lot of people have asked me to explain the difference between "open core" and "open infrastructure"--don't they both mean "open-sourcing the basic stuff"? Well, to some extent they do, but the difference is real, and apparently even more significant than I had thought.

"More significant"? Looks like: Kim Weins at OpenLogic provides some survey results that indicate that customers aren't so happy with the "core vs. complement" choice. And apparently, they're not alone: the much discussed decision by the European Union, to look more closely at the Oracle-Sun merger with an eye to protect the open source MySQL product has been widely decried as a misunderstanding of open source, but may really be just another expression of this same discontent. Matt Aslett of The 451 Group has made a good case that the EU's concern strikes to the heart of the distinction I'm trying to draw. The essential concern is that the open-core approach can mean that the proprietary sponsor of the open-source project can delay, divert, or simply out-pace the community version, making it not really viable. When that happens, you're perilously close to "faux-pen source," something that pretends to be open, but is only viable commercially.

In contrast, the "open infrastructure" model identifies a viable, useful product to be created as an entirely open-source project, and then used to build something fundamentally different. The Apache community has many examples; I think this model may have been an Apache invention. To pick one specific example (and one I can speak most about, as I'm involved), let's talk about Subversion.

Subversion is an open source project. It's a completely open source project: the whole product is available under an open source license. CollabNet (yep, that's us) is, and always has been, the primary sponsor of Subversion, contributing around 25 percent of the labor, over the years, as well as a major portion of the community leadership, and the grunt work of release processes, road maps, and project management. 

I don't think there's any doubt but that there would be no Subversion, and no Subversion community, without CollabNet, because of the way the project began: Brian Behlendorf, founder and then-CTO of CollabNet, hired the team, gave them an office ... and then made them work as an open-source project, in the open, instead of an internal development project. Just as clearly, CollabNet did this for business reasons. But the Subversion product, produced by the Subversion community, is in no way "crippleware" merely intended to lure you in to the CollabNet commercial "real" product. Slipping down that slope is the great risk of the "open-core" model, where your profitability depends on a narrow feature advantage over the open source alternative. It's a risk the EU appears to be concerned about. 

CollabNet chose not to follow that path at all: Subversion is Subversion. Any Subversion is all of Subversion. Instead, CollabNet provides another, larger product: CollabNet TeamForge, a product that would be much less valuable without Subversion (which is what justifies our investment), but clearly a different product.

So what's the difference? You still don't see it? OK, maybe it's a matter of degrees. Maybe a metaphor would help. Let's say you want to be a car manufacturer. You can open-source the production of your tires, and build a car that uses those tires. That's "open infrastructure." I don't guess there's a lot of "open source tire manufacturing" going on, but I'm pretty sure that something like 100% of car manufacturers at least "out-source" their tires! It's viable, it works, everybody does it. It's a business model.

But if your automobile business model is to "open core" everything but the paint, if your value-add is only the paint ... well, then you're going to see some paint-thin profit margins, too.