In my day job at New Kind, I spend quite a bit of my time working on brand-related assignments, particularly for organizations interested in community-based approaches to building their brands.

When marrying the art of community building to the art of brand building, it’s hard not to talk about building “brand communities.” It’s a convenient term, and brand experts love to trot out examples like Harley Davidson and Apple as examples of thriving communities built around brands.

The term “brand community” even has its own Wikipedia page (definition: “a community formed on the basis of attachment to a product or marque”). Harvard Business Review writes about brand communities. Guy Kawasaki writes about brand communities.

Yet almost every article I’ve read about building “brand communities” shares a common trait:

They are all written by brand people for brand people.

The result? Articles focusing on what’s in it for the brands (and the companies behind them), not what’s in it for the communities. Learn how to build a brand community so your company will succeed, not so a community will succeed.

Typical corporate thinking.

What if we turned things on their heads for a second and changed the words around? What if, instead of “brand community,” the phrase du jour was “community brand?”

[Read the rest of this post on opensource.com]

It might be a better world if we all worked in open, collaborative organizations where the best ideas win. But unfortunately, the reality is that bureaucracy still rules in all but the most progressive companies. We have a long way to go. The reality doesn’t always match the dream.

In the real world, we generate great ideas, propose elegant solutions, and then force them to run the bureaucratic gauntlet. “the best ideas win” becomes “the safest ideas win” (and then lose eventually) as they travel through the bureaucracy and its meetings.

These meetings are the favorite hiding place of two species of people I dread encountering. Learn to identify, manage, or avoid these bureaucrats, as they are the enemies of meritocracy.

Devil’s Advocates

The devil’s advocate was wonderfully defined by Tom Kelley in his book The Ten Faces of Innovation. Devil’s advocates make a habit of shooting down the ideas of others or offering critiques by starting with the phrase “Let me play devil’s advocate” (or something similar).

This phrase allows the bureaucrat to avoid taking personal accountability for the comments they are about to make. Because they are speaking for the devil rather than themselves, they can crush someone else’s idea without feeling guilty about it.

Professional Meeting Attendees

It is easy to spot the professional meeting attendee because they usually look or sound hurried and exhausted, complaining about how many meetings they have that day and how much they have to get done. Woe is them, for sure.

The reality is they often don’t actually do the hard work of creating and building, but instead sit in meetings all day long. They are happy to offer sage advice and wisdom, but usually avoid taking on work.

In small organizations and startups, the professional meeting attendee species is rare. But it breeds rapidly in large organizations where meetings are plentiful and there is always someone else to do the work.

So what should good open source-minded workers do to improve things when they can’t escape these meeting bureaucrats? A few tips from me:

[Read the rest of this post on opensource.com]

The other day I was chatting with friend and digital strategy/social media expert Ken Burbary on the phone. He was advising a colleague on some good community-building techniques to consider when all of the sudden the following words came out:

“You have to find your cheeseheads.”

What? I did a double-take (or at least the conference call equivalent) and asked him to repeat himself.

I had heard him correctly.

Ken lives in Michigan. Michigan is not far from Wisconsin. Wisconsin is where a lot of cheese is made. Wisconsin also has an (American) football team called the Green Bay Packers.

The biggest fans of the Green Bay Packers wear wedges of cheese made out of foam on their heads to show their support for the team. When someone will wear a big wedge of cheese on their head to show support for their team, that means they are a pretty big fan.

So Ken was saying that good community catalysts seek out and empower the biggest community supporters and advocates—the cheeseheads.

I found a fantastic blog post, written last fall by a colleague of Ken’s named Rachel Happe, entitled Cheeseheads. The post, which appears on The Community Roundtable website, explains in more detail the concept of how to engage your community’s cheeseheads. I won’t repeat Rachel’s advice here, but instead want to ask a follow-on question:

Sitting at a football game at Lambeau Field, it’s pretty easy to spot most of the biggest fans. They have foam cheese on their heads.

But what you do when a community isn’t the foam-hat-wearing kind? How do you find and empower the people who are the community’s energy source? Here are a few thoughts from me on how to find the biggest community advocates when they aren’t in plain view.

[Read the rest of this post on opensource.com]

Let’s face it. There are tons of projects out there in the world being run the open source way today. While the great ones can accomplish unbelievable things, the bad ones, even the average ones, often fail to achieve their goals.

In many cases, the failed projects still used many of the tenets of the open source way, transparency, collaboration, meritocracy, etc. So why did they fail?

Some projects fail because the contributors just aren’t skilled enough at what they are trying to do. Projects also fail because people don’t have the dedication to see them through—folks give up when the going gets tough.

But in many cases, the contributors have the skills and the dedication, yet the projects still don’t work out. My view? Many of these projects fail because they are missing one simple thing.

Trust.

Collaboration works better when you trust the people with whom you are collaborating. Transparency is more believable when you trust those who are opening up to you. And it is much easier for the best ideas to win when there is a base level of trust in the community that everyone is competent and has the best interests of the project at heart.

A successful open source project needs a culture of trust much more than a project not being run the open source way. Why?

[Read the rest of this post on opensource.com]

A few weeks ago, Red Hat CEO Jim Whitehurst wrote an article for BusinessWeek suggesting that Toyota might benefit from doing things the open source way when it comes to building the software inside its automobiles.

From Jim’s article:

Open source is about leveraging the power of participation to solve complex problems such as manufacturing, health care, and government. This advantage is why numerous 21st century successes—from Google to Facebook to Wikipedia—are all based on open-source software and principles. It may also be how Toyota can improve its vehicles and ultimately regain consumer trust.

Toyota may be listening.

Last week, Associated Press reported that Toyota has opened a new Design Quality Innovation Division. The new group will be led by Kiyotaka Ise, formerly of Toyota’s Lexus subsidiary, and will be tasked with more quickly reflecting customer feedback in automobile design.

[Read the rest of this post on opensource.com]

On opensource.com, we aspire to take principles the open source software movement has applied to building better software faster and find more uses for them in business, education, government, the law, and generally in our lives.

So a few weeks back, I was excited to see that BusinessWeek (now Bloomberg BusinessWeek) ran a special report called Eye on: Open Source that also embraced the wider usage of open source principles in technology and beyond.

My personal opinion? I think a few of the articles in the special report confuse true community-driven open source innovation with concepts like user-driven product design, crowdsourcing, and design competitions. But it was still neat to see BusinessWeek recognize the applicability of open source principles beyond software.

[Read the rest of this post on opensource.com]

Poor words. As they get more popular, as we give them more love, we also keep trying to shove in new meaning to see if they can take it.

In the technology industry, this happens over and over. Take “cloud computing,” which used to mean something pretty specific and now means essentially “on the Internet” as far as I can tell. Outside the technology industry, take “news,” which also used to mean something, and now is a muddy mess of news/editorial/advertising.

We’ve even been accused of muddying the term “open source” here on opensource.com (a debate I love to have—there are smart opinions on both sides: protect the core vs. extend the audience).

So when I read a recent post by Gartner analyst Brian Prentice entitled Defining & Defending The Meaning Of “Community” – An Open Source Imperative, I was familiar with the lens he was looking through already.

Brian’s argument? According to his post, community used to mean “a collection of people whose defining characteristic is shared participation.” I might add “and a common purpose or vision.”

But now the word community is often being used to refer to any ol’ collection of people. From the article:

[read the rest of this post on opensource.com]

In my post last week, I talked about what I see as inefficiencies in the system design of many crowdsourcing projects. Today, I thought I’d stick with the inefficiency theme after reading a blog by Umair Haque entitled The Efficient Community Hypothesis (thanks to Rebecca Fernandez for pointing it out).

In this post, Haque makes the case that the efficient market hypothesis often talked about by finance types should be replaced by something he calls the efficient community hypothesis.

From the post (all emphasis mine):

“…where efficient markets incorporate “all known information,” efficient communities incorporate “the best known information.” An efficient market is a tool for sorting the largest quantity of info. But an efficient community is a tool for sorting the highest quality info.”

[Read the rest of this post on opensource.com]

A while back, I wrote an article about why the term crowdsourcing bugs me. Another thing that drives me nuts? When people confuse crowdsourcing and open source. My friend David Burney wrote an interesting post on this subject a while back highlighting the differences.

It finally hit me the other day just why the open source way seems so much more elegantly designed (and less wasteful) to me than what I’ll call “the crowdsourcing way.”

1. Typical projects run the open source way have many contributors and many beneficiaries.

2. Typical projects run the crowdsourcing way have many contributors and few beneficiaries.

It’s such a simple concept, it seems obvious. Let’s look at a few examples to illustrate why this simple difference means so much.

[Read the rest of this post on opensource.com]

In the interview with Chris Blizzard I posted last week, near the end of the article Chris attributes a phrase to Mozilla CEO John Lilly:

“Surprise is the opposite of engagement.”

This may be one of the most simple, brilliant things I have ever heard someone say when it comes to creating engaged, active communities.

When we talk about building communities the open source way, we often mention transparency and openness as critical elements of any community strategy. But when I saw this quote, it reminded me why transparency and openness are so important.

When we are open with people, we avoid surprising them. We keep them in the loop.

Nothing kills someone’s desire to be an active contributor in a community more than when they feel like they’ve been blindsided. By a decision. By an announcement. By the introduction of a new community member.

Few things help a community get stronger faster than simply engaging community members every step of the way. Asking them for input first. Ensuring they are “in the know.”

When thinking about the community you are trying to create, maybe start asking yourself questions like:

[Read the rest of this post on opensource.com]