At my college, everyone had to take a class called Senior Seminar during their senior year to graduate.  This was a liberal arts course that really just got in the way of most of us at our technical university, but it had to be done.  The interesting part about it was that depending upon which of the dozen or so professors that taught it you had, it was either a total blow off class or something that took some real effort to get through.  If you wanted the former (which I’ll certainly admit to), then you wanted to get into one of Professor Goodman’s^*  classes.  I was fortunate enough to be privy to this information and was able to land a spot in one of his classes.  The information proved to be accurate and I was able to devote my efforts to more meaningful endeavors of the day while hearing others complain about the effort required for the class.

Knowledge.  It’s a great thing when you have it at the exact point in time you need it.  In many cases we’ve learned this and try to leverage it whenever we can.  You ask your new neighbors when you move into a new house for a dry cleaning recommendation, you ask the concierge at the hotel for a dinner recommendation, or you thoroughly research a product on-line, including product reviews from other owners, before making a purchase. 

When it comes to enterprise-wide reuse initiatives, I think most software development shops immediately start to focus on ways to reuse executable pieces of software.  Don’t get me wrong, this is certainly a reuse goal that makes a lot of sense and should be planned for and supported through tooling.  But what I think quickly gets lost are the much more prevalent pieces of knowledge reuse that could be going on if people were looking for them and had a proper infrastructure to make it happen.  Little things like being able to find expertise in a certain subject within the organization or finding that someone else has already failed with a new piece of technology that is sure to doom you, too, are just as valuable to the overall productivity of a development organization as is having the perfect reusable executable you can use.  Let the known (to others) hack of a dry cleaner ruin your favorite suit and this lesson hits all too close to home.

Achieving knowledge reuse is one of the real strengths of a community.  This is supported through the social infrastructure that exists in the “real world”.  An enterprise-wide software development community also needs infrastructure support to facilitate knowledge reuse.  A platform such as CollabNet TeamForge certainly provides this infrastructure support from a tooling perspective, but you also need that thriving community around that tooling to really create an atmosphere where members of the community have enough trust in it to look to pull from its collective knowledge base as a routine course of action during their development activities.

So when you consider reuse initiatives at your own organization, please don’t let the daily opportunities for knowledge reuse get overshadowed by other types of reuse that might get more press, fanfare, or budget in your organization.  Work toward creating opportunities for this kind of reuse and leverage them as much as you can.  Professor Goodman wouldn’t want it any other way.

^* No, that wasn’t his real name, but I can’t recall his real name.  That was way too long ago.  Even if I could, I wouldn’t use it here.  Besides, I needed a title for this blog post.

During a recent trip to see my doctor, I decided to forgo the typical waiting room Hollywood trash fodder and picked up copy of Diabetes Health. This particular issue had an article in it about the Chicago Diabetes Project.  This is an effort that is using open source concepts to help find a cure for Diabetes.  The article is mainly an interview with Dr. José Oberholzer, the leader of the CDP, in which he extols the virtues of a collaborative approach that are already known to many in the software development arena.  As someone interested in collaborative approaches to solving problems both in and out of the software development space, there are so many angles I could take for commentary on this article, but for some reason the thing that popped out at me the most was when discussing the challenges of this approach, Dr. Oberholzer mentions how the process of funding such research through grants isn’t really conducive to a collaborative approach and that not collaborating is a matter of academic survival. 

For me, that’s the rub that so often inhibits true reuse and collaboration in enterprise software development shops.  While I can certainly understand the need for medical researchers to be protective of their work to keep their funding going, I think we’d all agree that complete transparency into that work is something that would benefit the race to cure many diseases.  Unfortunately this same attitude seems to be all too prevalent in today’s software development shops, where funding is ultimately all coming from the same place and everyone’s main end goal is presumably the overall health of the company.  Being closed as opposed to open seems to be a more comfortable way of operating for all too many people.  It all reminds me of the line from the American sitcom Cheers where the Norm character, in response to a typical throw away greeting of something like “What’s happening”, says "It's a dog eat dog world, and I'm wearing Milkbone underwear."

So while tools and environments are key to helping organizations realize the benefits of open source approaches internally, may I suggest as step 1 just a simple change of underwear into something a little less comfortable?  Leaving the details of this analogy to each individual reader, quite often the change takes some getting used to before it becomes so comfortable that you start wondering what took you so long.

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!

Commenting on the differences between the business models of Red Hat and Acquia, Matt Asay really nails a point: there's value to be added by a company simply packaging and redistributing open-source work, but it's greatest where there's intimidating complexity to be managed. Both Red Hat and Acquia provide reliable, solid packaging of underlying open-source work (Linux and Drupal, respectively); both also provide additional value of their own, built on top of that infrastructure. But Red Hat's model relies proportionately more on the value of their packaging of the infrastructure, while Acquia weights itself more towards extensions attractive to enterprise customers.

But looking forward, he suggests that the increasing use of unpaid Linux "has the potential to disrupt Red Hat, Novell, Canonical, and other Linux vendors," and I'm not so sure of that. The trend is indeed worth watching, and the potential for disruption is real, but the value of simple, trustworthy distributions, with a legal entity answerable, remains very real for enterprises. Aside from present economic circumstances, the unpaid Linux growth is surely due at least in part to the increasingly good job of packaging and QA being done by the various distributions (not all of which are commercially backed). But mostly, I think it's the Linux-level mirror of the "adoption" benefit of more contained commercial-open-source projects. And that means much of it is use in circumstances where a commercial version wouldn't have been used anyway, and much more grows from unpaid to paid when the project at hand succeeds.

CollabNet's sponsorship of Subversion is a nice counter-example. Subversion is nowhere near as complex as Linux, or even Drupal, and Subversion is widely available in one-click installers, native libraries, and most or all of those Linux distributions just mentioned. But the CollabNet Subversion packages remain extremely popular, because they're certified by CollabNet. Many of our customers could build Subversion themselves--but that's not where they choose to spend their developer time and energy (they have their own jobs to do). Many could download some other package, or use the one provided with their platform--but CollabNet's timely updates are more important, especially for security fixes. And for enterprises, having support people, people who will answer the phone and the questions, provide the training, and provide the experience, are worth not only the trouble of using CollabNet's free downloads, but also make a support contract a worthwhile investment.

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!

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 

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?

"Open source development" is vastly more about the openness of the development that the openness of the source. This can be confusing, and may be at the root of some of the classic first-encounter confusions.

A great exploration of the point has just surfaced in a totally non-code area: O'Reilly Media and authors are pioneering an "open source publishing" system. They're really excited about the results, and you might be surprised at how thoroughly their success parallels the successes of the best of open-source software.

Basically what they've done is to make early drafts of their books available on line, with an in-line comment system. As each draft goes out and draws comment, they incorporate the feedback into the book. The authors remain the authors: while I'm sure they'll find some way to acknowledge their over 700 reviewers, they're not changing the names on the cover. This work is most similar to the "Commercial Open Source" model discussed in my "Open core, open complement" post.

But whatever the structure, the open sourcing is a resounding success:

• 7000 comments
• 700 reviewers, where most technical books might have only 2 
• comments from every relevant demographic, from highly experienced to neophyte 

Have these reviewers provided actual publishable content? Probably in some cases, but many also have contributed by comments as vague as "I have no idea what you're trying to say, here." They're all valuable; they all save the authors tremendous effort; they all make the result a better book.

Every open-source software project needs this kind of contribution: real and potential users guiding the way. How accessible a given project is to actual code contribution can vary widely, but your potential-commenter community is always just exactly as large as your potential-customer community. Get them involved!

A lot of people are struggling, just now, to understand how to make "the open source magic" into something repeatable (or anyway, as near to repeatable as other business models). 

• Dirk Riehle, of SAP Research, has captured and codified a wide sweep of thinking on The Commercial Open Source Business Model
• Matt Asay, of Alfresco and cnet, has given us an Open Source Continuum, a handy framework for open-source related commercializable license models
• Eugenio Capra (Politecnico di Milano) and Anthony Wasserman (Carnegie Mellon West) have provided A Framework for Evaluating Managerial Styles in Open Source Projects
• Guy Martin, in this blog, has drawn out the distinction between community "management" and "leadership" (with an appeal for both) 

It seems to me, though, that there's still something missing. I guess it's easiest to discuss in the context of Matt's Continuum. He talks about openness of the process and code relative to "core" and "complement", but there's really a third aspect as well: infrastructure.

As Matt points out, some open-source companies open up their core functions: MySQL and JBoss are two examples where the core functions of the product are open-sourced, and the money is made on on "complementary" aspects, which might be service, add-ons, or support. Matt points out that this approach tends to favor the disruptive entrant. Conversely, some open-source companies open the complements while holding the core proprietary; Microsoft and IBM have both demonstrated this strategy.

But I think the most successful open-source companies have been built around another model: opening the infrastructure:

• Linux is everybody's favorite example of a wildly successful open-source project, but the success of Linux is best measured by all the many different ways it's used, by someone else, to do whatever they want: it's infrastructure to web sites and telephones, laptops and supercomputers. Many companies have contributed to Linux, and are now profiting because it exists, by building something else on top of it. Linux is, of course, a big place! There are also Linux companies making money by more ordinary "open core / proprietary complement" strategies, but the success of Linux as a whole is far greater than even the sum of these.
• JBoss is very similar "open infrastructure" example. Yes, there's a company there, working directly to profit from the product, but the success of JBoss is vastly more than that: it's all the companies that have built applications on top of it. Infrastructure. 
• Apache httpd? No company there at all, but a community of companies collaborating to create infrastructure, infrastructure that completely dominates its market. 
• CollabNet's sponsorship of Subversion is like this as well: much as we believe in the project, the resulting product is only a piece of the infrastructure for our collaborative development and distributed ALM product.

This has implications for inner-sourcing as well (naturally: everything does!): when you're considering how to benefit from open-source techniques within your organization, you're most likely to benefit from "open infrastructure," because that's the model that maximizes all participants' ROI.

Do companies really give back to open-source communities?  Matt Asay suspects they do not, which would be pretty bad juju for open source. But I'm not so sure. In the Subversion project (initiated and sponsored by CollabNet), most of the top committers say they do their Subversion work as a part of their "day job." 

To begin with, of course, CollabNet employs several primary committers specifically to work on Subversion. In addition, from asking around about this in the past, I've learned that there are one or two others who are explicitly employed to work on Subversion as at least a part of their formal job description. But most of the others do what they do because they themselves, at least, recognize that it's the most efficient way to get good version control for their company and profession. These people aren't just creating Subversion, they're not disinterested (or fanatical) hackers: they're giving back. They're contributing to the commons.

Why does my survey differ so markedly from Matt's? Hard to say, but I have a couple theories:

• Maybe the give-back ratio among enterprises doesn't really need to be any higher than among the general population. It's pretty well accepted that the proportion of users of any given open-source project who actually contribute code is quite small; maybe the same is true of corporate consumers. In which case, both Matt and I have skewed our results by our survey sample. 
• Maybe the CTOs and CIOs Matt surveyed just don't know what's actually going on down in the trenches of their companies. Much of open-source give-back is at the individual contributor level, anyway. Very few corporations I know of have policies or reporting structures around such things. I'm a CTO, for instance, and although I happen to know a lot about our Subversion contributions, I know vastly less about our contributions to the other 200 or so open-source projects on which we depend. 
• Or, who knows: maybe this is just one more way in which the Subversion community is head-and-shoulders above any other open-source community. Wouldn't surprise me in the least! 

  

This all has important implications for the inner-source community as well. You can have a healthy inner-source project with very small contribution rates from the rest of the company. You shouldn't take that to mean the project is unsuccessful! Success is primarily measured by reuse. Contribution is a way to get there, not a measure of having arrived.