Community Management:  What it is?  Who does it?  Why do they do it?  How do they do it?

I can certainly provide my own take on the first and last of those questions .  'Who does it' and 'Why do they do it' are unique to each individual so I won't touch on those any further, except to say that the conversations around 'Who' and 'Why' are among the most interesting aspects of what makes the role of the Community Manager so very interesting between peers.

What is it?

Well, Software Developer Community Management is, even as promulgated by many a flowery definition from esoterica, just another set of services driven by the many roles and responsibilities constituting community management.  The challenge is in defining those services as needed on a per-community basis, pairing those services with the appropriate tools and communication mechanisms, then providing the resources (the CM and and support staff) that can in turn provide those services in (hopefully) an iterative, programmatic manner to serve the community.

How do they do it?

That could be considered a loaded question, as it's assuming 'they' do indeed do 'it'.  Unfortunately not all of those with the Community Manager title do their jobs in line with what it takes to properly manage a community.
 
As I assert above, Community Management is a set of services.    

So what is a service?  Or more to the point:  What is Service?

Merriam Webster's On line Dictionary defines Service as:  "The work performed by one that serves b : help, use, benefit c : contribution to the welfare of others"

To me this strikes at the very heart of what it is to be a Community Manager. 

So, 'How do they do it?'  They lead the community by serving its needs.

The Community Manager can't know all or do all, but that person does serve to connect all the dots between questions and answers, between needs and the resources to fill those needs, in order to ensure the community operates smoothly and to the benefit of its members.

The Community Manager represents the community.  This doesn't necessarily equate to being the poster child for the community, though that can happen with the right, rare person.  But that does equate to evangelizing the community at every opportunity.

The Community Manager works to find how the community can be improved.  Be this by gathering requirements for improvements to the hosting technologies (read: Features and Enhancements), by revamping the processes used for operating the community or perhaps even by convening a blind study focus group (though the average developer has no qualms about stating exactly how he feels).

The Community Manager engages in regular communication with the Community's leaders, members and consumers via summits, conferences, conference calls, webinars, weblogs, microblogs, emails and over coffee.  The Community Manager is the voice and the ears of the community, with the former driving the latter for response and vice versa in order to disseminate the items of vital interest throughout the member base.

I could continue on.  And every next statement on the roles and responsibilities of Community Management will stay tied to the same mantra: 

Lead by serving and your community will flourish!

By Bill Portelli, CollabNet CEO & President

I am proud to be sitting here in Frankfurt making my way to Davos, Switzerland, where I will accept a Technology Pioneer Award. While there, I will also participate in a number of working sessions and breakout groups along with hundreds of technical, business, and social leaders from around the globe.  Although I will have the pleasure of accepting this award and participating in these sessions, I accept this on behalf of the hard work, passion, and vision of the current and past employees of CollabNet who have made globally distributed software development a reality. The community of World Economic Forum (WEF) Technical Pioneers was established by the WEF in 2000 in recognition of the importance of small companies that create impact through technical innovation of entire industries.  Since 2000, a rigorous annual selection process by the WEF in cooperation with a host of strategic partners identifies hundreds of companies worldwide, and eventually selects about two dozen companies each year. 

When thinking about why CollabNet won this award, a couple of things struck me.  First, it takes a certain kind of company to win.  Klaus Schwab, founder and still the driving force behind the WEF, founded it in 1971, based on the stakeholder theory, which states that the management of an enterprise has to serve all stakeholders.  In a 2008 London Times opinion piece, he wrote:  “ . . . the management has to lead the enterprise as the trustee of all stakeholders . . . in order to secure the long term prosperity of the company”.  By “stakeholder”, Schwab means all constituencies – both internal and external.  I’d like to believe that CollabNet management has operated in an open manner with this long-term view of serving our stakeholders since we founded the company in 1999 - both internally among our employees, as well as externally with our clients and business partners.   And of course, we need to look no further than CollabNet’s founding of Subversion and continued corporate sponsorship and leadership of it over the last 10 years to see that this multi-stakeholder long term view of the world is a core value of our company.  Perhaps it’s the open source gene coming through….

The second aspect that struck me even more was that the companies honored as Pioneers are recognized for creating “impact through technical innovation of entire industries.”  CollabNet, and our nearly 1,000 customers, have blazed the path for industry to define and adopt industry-changing software development paradigms -- from fractured and decentralized to collaborative and distributed.  We have done this across every industry, and often with award-winning results, such as the recent recognition by the US government for DISA’s CollabNet-based implementation of forge.mil.  Certainly, great technology is critical to winning such an award. Even more important is the ability to have the long-term vision and perseverance to identify an industry opportunity, and to work within that industry to bring to bear that technology for transformative gains for all that participate in that industry.  That’s exactly what CollabNet, DISA, and other companies have done in the past year - but more about that in a blog to come.

About the Author

Bill Portelli is CollabNet's CEO. Read his full bio here.

(Posted by Dana Nourie)

Why do some people choose to communicate and participate openly, while others keep their heads down and mind their own business? 

Over 35 years ago, we were introduced to a quirky character in the sitcom, "Welcome Back, Kotter".  His name was Arnold Horshack.  What did Horshack know about the Internet...Linux....Distributed development...Cloud computing?  Nothing, of course (Al Gore had not yet invented the internet as he was still running for his first term in the House!)  But what he did know a lot about was collaboration.

You see, Horshack knew that the first step toward collaboration was participation.  Always the first to enthusiastically raise his hand with the phrase "Oooh-ooh-ooooh Mr. Kotter!", Arnold was the first person willing to participate.  More often than not his answer was not correct, but he contributed to the conversation.  Without his willingness to add a voice would there have been a discussion or debate?  The lesson learned is that participation is the first step to being part of a greater collaboration.  Whether this collaboration involves decoding human DNA, building better code, or just discussing teen life with the rest of the 'sweathogs'...you need to participate. 

Here are 5 simple steps to help you get your voice heard:

1. Start small by becoming a 'lurker' - it goes without saying that open groups can be a plethora of knowledge.  So, go find one involving an topic that you want to know more about and read what is being posted and shared.
2. Once you understand what a community or group is all about, contribute something to it - reply to a message or a blog, contribute to a wiki - and be sure to identify who you are when doing so
3. Create an online profile for yourself in LinkedIn, Facebook, Plaxo or wherever your colleagues or friends are.  Once there, reach out and request connections and references from others.
4. Tweet your own thoughts - Get setup on Twitter or whatever internal company tool you might have like yammer - then submit a tweet. Keep it short but interesting, adding links are always a plus.
5. Write a blog - it may take a few iterations and drafts before you're ready to post it, but once you do you'll be proud of your own accomplishment and will probably find yourself regularly coming up with new topics to write about.

My advice is to go find your inner Horshack and be part of the discussion.

And if you have 10 minutes to kill, go check out Arnold and the gang participating in a debate

An analysis of several Forrester surveys, by Forrester analyst Jeffrey Hammond, was recently published in Dr.Dobb's online (www.ddj.com). The analysis compares what developers say about their work environments with what their IT managers think is going on. Hammond calls out "seven trends that could have major implications for your IT strategy."

Looks good to me ... in fact mostly, it looks like the CollabNet strategy book:

• Rich Internet Applications, like our Eclipse, Visual Studio, and Windows desktop products
• Open Source use spreading everywhere
• Virtualization and Cloud converging into virtual private clouds (among other things), like Lab Management
• Growing Agile and agile-like development processes

One bit seems odd, though: Forrester finds that

• More than one-third of developers use Subversion for source code management; that's almost triple the share of the next most-used SCM tool, Microsoft SourceSafe.

via www.ddj.com

I might be reading that wrong, but it appears to say that Subversion is the number one version control system in their survey, by quite a wide margin. Sounds good so far. But it also sounds a bit odd: if number one covers 1/3 of devs, and number two covers 1/9, the series seems to converge with less than half of all developers using any kind of version control at all, and I don't buy that. I don't know any developer anywhere who doesn't use version control, even for personal work. In fact, I was accosted the other day by one of the baristas at my favorite coffee shop, because I was wearing a Subversion T-shirt and he wanted to tell me how to make Subversion better! Surely, that's gotta mean that Subversion use is wider than 33%?

Update: Looks like I was indeed reading that wrong: the author clarifies that the survey asked for "primary SCM." I'd expect a healthy plurality for that question. He also confirms my expectation that most developers use several SCM systems (he cites "2.1 in Europe, 1.8 in the Americas," which gets my nationalistic blood up -- come on, North- and South-Americans, we can do better! ;-). Given which, I could well imagine a lot of respondents grumbling "how am I supposed to name a 'primary' in this mish-mash?" and perhaps just checking "None" -- not "no SCM," but rather "no way to choose a so-called 'primary'."

Update number two: Author Jeffrey Hammond has blogged the SCM results in much greater depth at the Forrester Blogs. The greater depth is particularly interesting in the area of open-source SCM tools: nearly half of the respondents listed some open-source SCM tool as their "primary SCM tool." There are a lot of areas in our business where people are given to wondering why on earth anyone still "pays full price" for a commercial something-or-other, when there are such good open-source alternatives--but, in a lot of areas the fact is, people do. Looks like SCM is an area where open-source offerings really are winning!

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.

From MASSForge, the software collaboration environment for the Commonwealth of Massachusetts, comes a great add-on to your CollabNet TeamForge site, the Calendar linked application. Better yet, this is an open-source project, hosted on our public site, ctf.open.collab.net, so if you see some improvements you'd like to make, you easily can—as well as contributing them back to the project, if they might be generally useful.

The application deploys easily into any modern Tomcat server. With that plus "Linked Application" configuration into your project, you're off and running. A new tab will appear in the project's tab-bar:

 

... and Tasks entered in the project's Tasks tool will be displayed in the calendar:

As with any good open-source project, there's a wiki with installation details, and a full suite of discussions for Announcements, Help, and any Installation Issues (none reported so far—be the first!)

You can check the project out from Subversion, or download the latest release from the File Releases area.

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.