Friday, March 16, 2012

Confessions of an Open Source Community Pragmatist

I just recently wrote a post talking about job titles, which got me thinking of how I would classify my current career role.  That, combined with other discussions which have been happening inside the walls of my employer, made me realize that the best way to describe myself would be as an Open Source Community Pragmatist.

I can see the heads shaking, the puzzled looks, and even the sighs from some of my colleagues who are a bit more on the idealistic side when it comes to these topics.  Let me assure you, I have total respect for those folks who make everything they do in life about the ideology - it's just not the path I've chosen for my career, and here's why:

The vast majority of the day-to-day work of society & business happens between the ideological extremes:
  • Conservatives vs. liberals
  • Proprietary vs. open source software
  • Emacs vs. vi (a little inside joke for my technology readers)
Does this mean that we don't need the extremes?  No, I think they need to exist to define the boundaries, and in many cases, to push better ways of doing things to the center of the spectrum.  The reality though, and those of you at the extremes may chafe at this, is that most people are closer to the center than to either extreme, and their primary goal in life is to get their jobs done, stave off starvation, and pay their mortgage on time. That is the cold hard reality of life, and these people are the ones who make the trends happen via purchasing decisions based on how easy it is for them to utilize things like technology as a tool to get their jobs done, stave off starvation, and pay their mortgage on time. :)

People of this ilk are very much in the 'easiest tool that gets the job done', vs. 'absolute best tool for the job' mindset.  These are the people that choose Windows and Macintosh computers instead of putting in the time to get Linux properly installed and working on their laptop.  Has Linux made great strides on the ease of installation and desktop use?  Yes, but still not enough to displace the ease of use (or perception thereof) of Microsoft or Apple products.  However, there are opportunities to mix these two camps, and this is where the pragmatism label comes in.

I'm very proud to work at Red Hat because of what they stand for in the Open Source world (disclaimer - these opinions are not necessarily reflective of those of Red Hat, our mascot Shadowman, or anyone else who might or might not be wearing red fedoras today).  However, because of my role in consulting, and my frequent travel and personal usage habits, I chose a Macbook Air as my primary computing platform.  Cue the wailing and gnashing of teeth from the ideological camp. :)

However, the Open Source Community Pragmatist in me justifies it easily by running virtualized instances of Fedora 16 (Red Hat-sponsored community distribution of Linux) as well as Red Hat Enterprise Linux 6.2 (our enterprise version of Linux).  Oh, and also, with the exception of iCal, pretty much all of my day-to-day productivity application needs on Mac OS X are met by open source tools (Thunderbird, Firefox, Adium, LibreOffice, etc.).

Do I use proprietary tools on this machine - yes, as customer needs dictate (primarily MS Office).
 The main argument I get from the ideological side is that I'm doing a disservice to my company by not using the products we sell.  First of all, I've already noted that I do use the products, and also, I believe that pragmatism wins many more hearts and minds with a customer than blind devotion to an ideology.  Are Red Hat's products great choices in the enterprise/data center?  Absolutely, and I champion their value in that arena all day long.  Are they the best choice for end-user workstations?  In some limited cases, yes, but by and large, customers are better served using their existing infrastructure and supplementing it with open source productivity apps (as I showcase on my machine).

Obviously, we all have our passions and particular opinions about why we do the things we do.  I guess my point in writing this post was to simply highlight that the motivations for why we do things are different for each individual (and business), and while we may not necessarily agree with someone else's viewpoints, we cannot function as a society or community unless we learn to respect the need for those viewpoints to exist.

Tuesday, March 13, 2012

Community Manager or Community Sherpa?

What's in a title?

While a lot of us community types don't get caught up in what you call us (we prefer to be catalysts in getting the job done), the fact remains that those outside of our sphere sometimes fixate a bit too much on the word 'manager' in our typical title.  In point of fact, some of the most successful community people I've run across are closer to a community 'sherpa' than they are to a community 'manager.'  What is the difference, you might ask, and does this mean that they don't perform typical 'management' tasks?

The answer to the second part of that question is no - in fact, they can and do step in to get their hands dirty on tactical tasks (moderating forums, building content, refereeing competing interests) all the time.  However, building an effective community requires someone who is also fairly strategic (the 'sherpa').  This strategy comes to the forefront in areas such as charting the community direction, or determining how the community may need to interface with a sponsoring organization. Does this mean that every community person starts out in the sherpa category?  Speaking from my own experience, I'd have to say the answer is no to that question as well. While there may be natural born community sherpas, I think that the far more usual path is that community managers are groomed to become sherpas.

Let me bring in an analogy from my primary career path (before I started drifting into community work). In computer science, there are computer programmers and software engineers (and at higher levels, software architects).  No one in the computer field expects individuals to come directly out of college as software engineers (despite what their starting job title may be).  Computer programmers are very adept at taking very specific specifications and building something that meets those specifications.  However, they do not have enough experience to consider how what they're building fits into the larger picture.  Software engineers, on the other hand, are a mix of tactical ability (writing code) as well as understanding the ramifications of what they're building.  This allows them to interface with other engineers and systems architects to help provide strategic leadership to software development efforts.  In general, programmers work in conjunction with software engineers until they reach an experience level where they can become software engineers as well.

At this point, readers are probably asking this question: 'Are you saying I have to hire two people to work on building/running my community?'  Interestingly, Vanessa DiMauro does argue for a separation of manager and strategy functions in this blog post. While I can see her point, I think that most organizations would probably be better off hiring what I'm calling a 'community sherpa,' and then, as their community grows and becomes successful, bringing in a 'community manager' to be groomed by the current sherpa.  If this sounds like an apprenticeship, that's exactly right - learning how to deliver an effective mix of community tactics and strategy takes time and experience.  Community people may have a natural affinity for the overall role, but they need to learn how to effectively apply strategy and tactics in equal measure.

Also, remember that you never know where you might find a community person hiding in another career.  A lot of times, they can be in a slightly tangential career path, but their aptitude and desire make them ideal candidates to take on community roles (and they could be ready to step in as sherpas with just a little coaching).  In my case, I found that while I enjoyed technology (I still do), I had a set of strategic skills acquired through having to interface with different software engineering groups (Quality Assurance, Configuration Management, etc.) that set me on the path to doing community consulting.  However, even those skills required refining by working with others who had more community experience than I did.

So, now it's your turn to sound off - are you a community manager or a community sherpa?  Do you agree with the distinctions I've drawn?  Either way, I'd love to hear your opinion.  Thanks for reading!