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 recently had occasion to go to CollabNet headquarters in Brisbane, CA.  My flight from Chicago to San Francisco was on a totally full Boeing 777.  As the plane was loading in Chicago,  I witnessed from my choice vantage point in seat 22E (yes, that’s the middle seat in coach of a 2-5-2 configuration) a dynamic that I couldn’t help find analogous to a smoothly running community site in action. 

The cattle call that is the boarding process of the economy section of a wide bodied airplane is always good for some entertainment value if you get there early enough and are willing to look for it.  My favorite part comes as the overhead space starts to get tight and people decide that the laws of physics are for chumps and decide that their 3 cubic feet piece of luggage will indeed fit into the 1 cubic foot of space available to them.  I certainly wasn’t disappointed on this flight.  The entertainment factor for me comes when the owner of the luggage just starts wailing away on it trying to make it fit as if it’s going to magically turn into some sort of blow in foam instead of the hard sided luggage that they brought with them.  Of course the entertainment value diminishes quickly when my bag is already in the compartment being asked to accept the extra piece, but I’ll leave that for another time.

This situation usually results in one of many solutions, all of which I witnessed on this recent flight:

1. The owner will finally realize they he can’t defy the laws of physics and take the bag elsewhere on the plane
2. Perhaps a more experienced (or just plan brighter) passenger will offer some help, such as rotating the piece 90 degrees, that will actually make it fit
3. A refactoring of the current distribution of bags in the immediate area occurs to free up the required space for the later arriving bag resulting in room for everything to fit harmoniously
4. The owner will just leave the bag there in the hopes that the flight attendant will make the problem go away, which will definitely happen with the flight attendant:
   • Employing one of the strategies mentioned above
   • Putting the bag in some location only known to the crew as a possibility for storing passenger luggage
   • Removing the bag form the passenger area altogether and checking it much to the chagrin of the bag’s owner who probably should have done that in the first place

So what’s all this fun have to do with community sites?  Well, like most flights, community sites give a diverse population a vehicle for reaching a common goal.  The common goal on my flight was to get to San Francisco.  As the repeated announcements stated, however, we couldn’t get there until all the overhead storage compartments were closed.  This brought into action the collaboration of the folks on board to make the goal possible with 3 distinct roles emerging:

1. The Active Contributor:  While all the passengers had a stake in what was going on with the overhead space (it needed to be sorted before we could go anywhere), not everyone was actively involved in getting things sorted out.  Perhaps some of the passengers who were involved didn’t have anything to store in the overheads, but were nonetheless active in helping others who did either through offering their experience or just a brand new observation on the situation.  Thriving community sites see this all the time.
2. The Observer:  This is the role I was playing as I had nothing to put into the overheads and, from my center seat, wasn’t really close enough to the action to offer any physical assistance and didn’t observe anything that I felt needed my commentary.  Nonetheless, I somehow know what the options are for a bag that won’t fit.  This knowledge has come to me more from observations I’ve made on other flights than from personal experience.  In other words, my observer role on other flights has benefited me even though I wasn’t necessarily an active contributor on those flights.  At any given moment, community sites certainly have plenty of members just soaking in the action and becoming more knowledgeable as they do so.
3. The Community Manager:  This is the role the flight attendants were filling. In the early going when the storage space was plentiful, people were able to fend for themselves quite easily within the confines of the limited space available.  That’s not to say that they didn’t plan for the future by storing their luggage in the most optimal way they could, but even if they didn’t things fit pretty easily.  As the plane filled, the situations and reactions described above took hold.  Most of the problems were mitigated by other passengers helping out before the flight attendant was needed.  This isn’t to say that the flight attendants weren’t monitoring the loading process as it was happening and offering assistance where needed, but on rare occasions were they needed to be arbiters of the situation.  When they were, they had the authority and knowledge to act in that role.  On community sites, this role is handled by the Community Manager.  Note that the flight attendants didn’t dictate what luggage was brought on board, but knew what to do with it when the other passengers couldn’t make it fit.  Likewise, Community Managers need to guide the evolution of their sites with proper oversight of the site’s activity. 

While this analogy doesn’t rank with splitting the atom for the first time, I do find examples of community and community management in the “natural world” to be interesting.  If “community” can just happen on its own, should we be able to create highly optimized communities with a little intervention?