No matter what your opinion is on global warming, it's clear that we need to get off our dependencies on fossil fuels. Everyone needs to put forth effort to go green, including companies and how they manage the employee work processes.

Over the years I have commuted long hours and I have worked remotely. Working remotely has obvious green benefits by saving on gas and emissions, providing more hours in the day that are not devoted to cursing out other drivers, and lends to a better personal balance of home and career. Yet, in talking to folks in various online communities and in person, I come across some resistance to working and running a business remotely.

Some resistance is based on fears of doing things slightly differently. I stress slightly here because the changes in one's work day isn't that different than from the office, except for some distinct benefits. And habits are hard to break when it comes to certain routines. The most common resistance to avoiding working remotely though is simple lack of knowledge of how the remote model works.

The software development  industry has provided a great model for working remotely, yet many, many people are still in their cubes, pounding away at the keyboard when they could be kicking back in an easy chair with their laptop. Instead, from their desk, they pass emails, instant messages, use the phone, and only on occasion, do they leave the uncomfortable desk. Why? All the work is being done in a somewhat distributed fashion anyway, and certain tools can make it all the easier.

I'm currently working two days in the office and the other three I remotely from home. This gives me just the right amount of face-to-face with key people I work with, and the rest of the time I am happy to be off the road and have the extra time in my day. For my job, it's a comfortable balance.

The key to successfully working remotely is collaboration. The software development industry helps us in heaps here. For a long while now, teams have been distributed throughout the country and globally. Companies like CollabNet make working remotely with distributed teams easier by providing a platform (TeamForge) with all the tools necessary. We can have discussions, share wikis and documents, and track each others progress on projects or tasks.

Of course, some face-time is necessary, discussions sometimes are better in person, and it's good for team morale to have a face to attach to an email address.

And in my experience, meetings, especially large ones, are more productive and clip along at a better pace when people are remote. In person, I've noticed some time is spent on arranging chairs, getting a projector to work, chit-chat to catch up with people, etc. before the meeting even starts.

But when folks call into a meeting remotely, or use something like WebEx or Go Meeting, people tend to be ready and get right to the point. There is less time wasted, and gabbing is saved for during technical glitches, which do happen no matter whether you are remote or live, or when in person meetings come along.

The key to working remotely successfully is collaboration, having the right tools for employees to connect with each other and share data, and to track progress, and to understand that remote working does NOT hamper progress or work quality. Less office and cube space is needed for employees, less time is wasted on travel and commuting, and people's attitudes tend to be better when they have enough home time. By only meeting in person once or twice a week, it becomes a treat to get out of the house and out into the world.

We have the technology to work remotely and collaboratively, and distributed software teams have provided an excellent model for those of us who are not crunching code daily but do work on a computer the majority of the time. Of course, there are jobs that just have to be in person and don't fit this model. But so, so many jobs are ideal for working remotely, and I hope to see more businesses taking advantage of going green for the planet and all living on it.

I am grateful for my online job, and the fact that I work for a company who provides an ideal platform for distributed teams, including non-developers like myself, to collaborate with the rest of the company. Because CollabNet was founded on creating tools just for collaboration, the mind set was already there to work with employees in a distributed fashion. But your company does not have to develop a software development environment in order for you to work remotely.

I'm curious, if you don't work remotely, but work on a computer most of the day, what prohibits you from working remotely?

Many of us have come across companies trying to sell a product that they themselves don't use, because unfortunately this is not uncommon.

It's unsettling when companies don't think enough of their own products to actually use them. I understand not all companies can use their own products within the business because of the nature of some products. But, by and large, many, if not most, can be integrated into the business. And should be when they can.

That was one of the things I really liked about CollabNet. We actually do use our own platform and tools, and in a variety of ways. Yes, we eat our own pet food, and that has many benefits:

• You discover the strengths and weaknesses of your product
• You are better able to help customers understand the product and why they should use it
• As your needs grow, you build those solutions into the product, giving you much better empathetic understanding with the customers
• Everyone benefits from the companies product, because everyone makes requests to improve its quality

The CollabNet platform has evolved greatly over the years, and we have used all iterations of it along the way. The CollabNet site resides on the platform, as do all of OCN projects, and all of our internal projects.

For instance, our group of community managers use a CollabNet TeamForge (CTF) project called community-management. Having this project allows us to share documents, use a wiki to share links and miscellaneous stuff, and have discussion areas we can use to help and advise one another, brainstorm, and discuss various topics of interest. Monitoring enables us to receive changes and discussions via email.

I set up a similar project for CollabNet bloggers. With 16 of us, and growing, it's just a pain to email, attach documents, track changes to those docs, etc. through the mail program. This CTF project allows us to do that and more. If we want to set up trackers and project folders, we have that available to us as well.

In addition our web production team, marketing, sales, etc. all also use our platform similarly. And, of course, so does our engineering team. They use it for their development of CollabNet platform and tools.

Recently, with the acquisition of Danube, we'll incorporate more Agile processes and scrum into our work flow. CTF was always Agile-ready, but now we'll be using it more and learning scrum for our own business tasks. It's exciting to have the product evolve in a way that is not only useful to our customers, but to us as well.

Eating your own pet food, or rather using your own products, adds empathic understanding to customer needs, but also adds a great amount of sincerity and enthusiasm, assuming you have a good product. When a company uses it's own product or platform, that product is bound to improve because there is more invested in the quality of that product.

The amount of control a community has over process and direction within a project has recently come up in a situation I've been involved with and I think it's a great topic for a post since it strikes at the heart of many company's trials and tribulations in creating vibrant communities.  The real question in these situations is not one of control but of trust.  Can you just be along for the ride and let someone else influence your project even if you don't agree with everything they do?

Many organizations and people find it difficult to let go and allow their communities to shape the overall direction and goals of their projects.  They fear that by allowing users to get involved at a deeper level chaos will ensue and they'll be mired in endless debate over what they perceive as insignificant issues.  However, the opposite of control is not chaos, the opposite of control is trust. Trust that you're not the only one who has good ideas.  Trust that even if it doesn't follow your established processes it might be okay.  Trust that, you don't know everything!

This lack of trust is one of the biggest reasons your community is not growing and it's not a lack of trust in your project (well maybe it is ;), it's that you don't trust your community!  This is especially common in enterprises that have well established processes or in any company that maintains a title of Senior Vice President of anything:). In larger organizations that have worked hard to develop processes for product development, marketing, and sales, it's hard to find someone in command willing to allow control to slip through their fingertips and into the community and shape their baby in some way they don't agree with or that their processes can't handle. But that's what it takes to grow your brand and community, hopping on and letting your community take you where it wants to go.

One of the best books I read in all of 2009 was Brand Hijack by Alex Wipperfurth.  In it he details the making of many brands that allowed themselves to be hijacked by their communities to become successes: Dr Marten, PBS (Pabst Blue Ribbon not the broadcasting service:), Red Bull, and others.  All of these brands did something unique, instead of trying to define themselves in a traditional marketing sense, they let their fans influence and define the brand.  And that's what you need to do in order to grow your fan base... let go.

Don't confuse letting go with abandoning all your processes, my point is not to let your community suddenly start running everything without any leadership from you.  The point I'm trying to make is you need to stop trying to control EVERYTHING.  Pick your battles and arm yourself with good arguments.  Don't use coercion due to your position or ignore your communities input, use your communication channels to guide your community during those times when you see it straying from the path.  Having this blend of give and take will allow your community to feel a sense of ownership and ... start prospering.

As Jeffrey Hammond, of Forrester, blogged recently, Subversion is the overwhelmingly predominant version control system today. Yet if you read the open-source blogs and discussions, you see loads of growth in the "Distributed Version Control Systems" (DVCS), such as git, Mercurial, Bazaar, and the like. What's going on here?

There's an interesting even just now in the Linux kernel that sheds some light. This week, according to Greg Kroah-Hartman, some Google-contributed, Android-related code was removed from the Linux kernel. The reason: the code in question is both incomplete on its own, and specific to the Android device. Either of these properties makes it constitute a "fork," and in this case there seemed no prospect of ever healing the fork.

Now, you might think a "fork" is something that happens to the code, and certainly that's part of it. But as Kroah-Hartman points out, code-forking happens all the time. The problem here is that "no one cared about the code, so it was removed." This doesn't mean no one cares about the code that's going into Android--certainly not! It means two other things:

• No one was taking care of the code that had been contributed into the Linux kernel tree
• No one was consuming, using, extending, or applying the code for new purposes

It had been, as the phrase is, "thrown over the wall," and left.

That--abandonment--is a big problem for open-source code, both in that it's harmful and wasteful, and also in that it's common. But it's a cultural problem, not a technical one: there's no claim that this was "bad" code, just that it was a dead end.

Open-source communities are actually pretty robust against this sort of harm. This event illustrates one such defense: if it's dead, dump it. Another commonly applied defense is simply to let projects die when no one cares: the notorious numbers of open-source projects that never got anywhere are actually signs of health: the open-source community has a powerful defense called "cheap failure," that allows ideas to start out sounding good, then peter out harmlessly. One of the cool things about DVCS is that it's very easy to start a fork, very easy to reintegrate it if you choose to--and very easy to chop it off and toss it away if it ends up a dead end, as we see here.

But if we recast this whole experience into an enterprise context, it begins to look very different indeed. The essential difference is that failure within an enterprise is never "cheap." If the Linux kernel community, including Google/Android, were an enterprise, then all the work that has been spent on this fork would have come out of corporate wallet, and the decision to toss it would be a recognition of wasted resources: salaries, equipment, time, plans, marketing, process--endless kinds of costs, sunk with no payback.

The great contrast between the low cost of open-source failure, and the high cost of enterprise failure has far-reaching effects, even down to details like tool choice.

• An open-source project can usefully tell prospective contributors "clone the tree, work up your idea, and get back to us when you have something to show," because there's no cost to the project if the idea never bears fruit. An enterprise, however, does have such costs, and at the least has little incentive to allow that sort of work style.
• An open-source project can allow parallel, semi-independent, persistent forks, such as the several Linux distributions: as long as there are enough people (whether sponsored or volunteer) interested in working the fork, as long as things stay controlled enough that work can be merged back and forth, there's no problem. But an enterprise may need to match its centralized budgeting and resource management with some centralized supervision, planning, marketing, and management: making it easy to disappear from the radar is not a good thing.

And that, I think, is at least part of why the centralized Subversion model remains so strong.

Change is hard.

That statement should not come as a shock to anyone who has ever worked anywhere in the business world, or even just lived on planet earth for that matter. However, change is a critical element to moving the collective knowledge of our species forward. Without change, we wouldn't be walking upright, let alone using a netbook to write blog posts from 35,000 feet in the air (yes, I'm composing this missive from seat 8F on Virgin America flight 84 to Washington, DC).

One of the ways many organizations try to deal with change is by bringing in new 'tools'. I work for a company whose primary 'product' is just such a tool (CollabNet TeamForge), but we also offer consulting services around Community Management, Agile development, and process change.

I may be biased here (since I'm in the services group), but I'd argue that the services offerings are the most critical component to the successful deployment of our product. One of the main reasons for this is that it's often easier for an 'outsider' to help companies, or, in my case, government agencies, shift their processes from slow, antiquated, heavyweight affairs to streamlined, agile, community-based approaches that take maximum advantage of the tools. We also provide a critical eye toward making sure that the change-phobic people involved in the transition don't try the 'new wine in old wineskins' trick.

Any historical or biblical scholar can recount the parable of putting new wine into old wineskins, but the short version is that putting new wine (tools) into old wineskins (processes) is a recipe for disaster/bursting, because the old processes are inflexible, brittle, and unstretchy (kudos to CollabNet CTO Jack Repenning for this correction of my original thought process). This is especially true if the transition effort is driven by a top-down edict that ignores the needs of the community. My community management colleague on the Forge.mil project, retired Army Lt. Colonel Susan Grosenheider, calls this the 'mandatory fun' approach, and she has first-hand knowledge of how well that goes over in the Army (hint: not well). At the end of the day, if you've deployed a new tool, but still have your broken processes wrapped in a shiny new package, you have a situation that my CollabNet colleague Drew Showers calls 'A fool with a tool is just a fast fool.'

One of the most rewarding, yet challenging jobs that Community Managers face is walking the fine line between the needs and desires of the business community, and the needs of the developers and/or users. There are times when you have to say no to one group or the other, but having someone who can step into the breach between different members of the community is extremely important to the success of any tools deployment, and pays off in the long run.

While businesses should strive to build up their own community 'champions', having a consultant who isn't tainted by the existing process makes it easier to find a way forward that isn't just 'change for the sake of change'. A good consultant also helps you avoid a culture of 'mandatory fun' which helps prevent the process 'bursting' problem, and ultimately leads to a better return on investment for the tool set you're deploying to help streamline your business or development process.

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!

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

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.

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?

 

It's amazing how restricting the amount of space you have to express a concept crystalizes what is truly important about that idea. Recently, in my 'community' Twitter list, Holly Seddon asked a very good question which helped give me one of those 'A-ha' moments:

'In one word, what should using an online community feel like or give you?'

I loved the challenge of coming up with a single word to describe a key benefit to participating in community. After some reflection, the word that popped into my head was 'perspective'. When communities are functioning at their peak (and I think this is true even of 'development' communities), one of the most powerful things you can glean from your participation is the perspective of one or more of the other community members.

Being able to look at business problems, source code issues, or any other medium within a community from a different angle is incredibly powerful. As an engineer, I used to get some of my most inspired ideas from listening and reading what others in discussion forums were posting. If you have a specific problem, a direct approach to soliciting help from your community gives you (sometimes) multiple different ideas & perspectives on your issue. Throwing these thoughts into the mix as you work toward a solution can be an invaluable step in the problem solving process.

There are a lot of reasons why people or companies start communities, but I believe a large portion of those reasons can be traced back to the need to get additional different perspectives - developers looking for ideas, companies looking for consumer input, social groups looking to connect with other like-minded individuals. I'll admit that not everyone in the corporate world always understands this - mainly because asking for and reflecting on a different perspective requires the kind of humility that some companies (and even some governments) don't always possess.

We've all participated in groups where we've felt our opinions didn't matter, and I'm willing to bet you probably disengaged pretty quickly if that's the experience you encountered. I urge companies and their individual employees to strongly consider this when setting up your own internal or external communities. Ask yourself the question: 'Is this a place where I'd want to participate - is my perspective going to be welcomed and celebrated?'. If the answer is 'no', it's time to go back to the drawing board in the plans for building out that community. If you are already participating in a well-oiled community, remember to appreciate the different perspectives you get - even the ones you might not necessarily agree with. :)