Of all of the people talking or writing about the future of business right now, no one has more street cred than Gary Hamel. I’ve written about him many times before, and his book The Future of Management is one of the most inspiring and meaningful business books of the last 10 years.

Last year at the World Business Forum, when Gary called open source one of the greatest management innovations of the 21st century, there was some serious high-fiving going on amongst us open source business types.

So I’ve been watching closely as Gary and a team of management superstars have launched an open innovation experiment called the Management Innovation Exchange, or MIX. In the video below, Gary explains a little bit about the goals of the MIX.

Here’s how they describe the MIX on the website:

“The Management Innovation eXchange (MIX) is an open innovation project aimed at reinventing management for the 21st century. The premise: while “modern” management is one of humankind’s most important inventions, it is now a mature technology that must be reinvented for a new age.”

From spending some time on the site, it clearly shares a lot of the same foundations as the open source way, even if the MIX folks prefer the term open innovation.

One of the most wonderful bits? The MIX is a meritocracy, where anyone can join, submit management hacks, stories, or barriers, and then collaborate with others to explore the ideas further.

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

Wow. Yesterday was an interesting day. It started with a coffee meeting with a local architect who’s a friend. We discussed how the architecture industry is getting hammered. Then I ran into an old friend who’s a photographer. We discussed how the photography industry is getting hammered. Then a friend posted a link on Facebook about how the advertising industry is getting hammered. Then another friend posted a link on Facebook about how the design industry is getting hammered.

Oy vey. I feel like going out and getting hammered.

On the other hand, I’m positively optimistic. If businesses are to compete, they must become more innovative. If they are to become more innovative, they must become more creative. If they are to become more creative, they must begin to appreciate creativity better. They have to value creative culture and creative people. They have to learn to identify, recruit, hire, train, manage, sustain and retain creative people.

But we, the grasshoppers, have to let go of some old baggage ourselves. If we continue to battle 20th centuries bogeymen, we’re going to lose 21st century opportunities.

In one of the Facebook posts I noted above, the writer (a damned talented guy) closes his argument with this:

Well, this time let’s dissolve back to the year 1519. (Wavy lines, wavy lines.) Cortez and his marauders have come to pillage and destroy Mexico. The way forward is unknown. The size of the enemy, unknown. So to rally his men, the dude gives a pep talk of just three words. “Burn the ships.”

He removes the option of going back.

What if you burned your ships? What if you had to advertise a brand and you couldn’t use TV and print? Don’t ask me. I don’t know the answer. But I do know it’s probably time to burn the ships and step into the jungle.

My advice? If you see ships, you’re hallucinating; there are no ships. They sunk a decade ago.

Look at the opportunity ahead of you. The significant business opportunity of embracing creativity, design and innovation. Figure out how to multiply your skills and talents— share, engage, lead— become a catalyst. The artifact is dead; be the ‘experience’ you talk about so much.

And quit whining.

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 months ago, I had the opportunity to meet Jim Gilmore, co-author (with Joseph Pine) of the book Authenticity: What Consumers Really Want. I first read the book a few years ago, and it really struck a nerve for me—these guys were on to something.

So I convinced Jim to subject himself to a Five Questions interview about the place where authenticity and the open source way intersect.

CHRIS: After joining the open source world ten years ago, it didn’t take me long to figure out that most open source folks despise marketing as it is traditionally practiced. Is there something inherently inauthentic about the language of marketing? Perhaps open source folks have a low tolerance for inauthenticity?

JIM: I often quote from a letter-to-the-editor that appeared in the Harvard Business Review following the publication of our article, “Welcome to the Experience Economy.” In this letter, Robert Jones of Wolf-Olins shared his definition of a brand as “the promise of an experience.”

Joe Pine and I responded by saying Amen to that, but added that so often the actual experience fails to fulfill against the promise.  Indeed, marketing in general, and advertising in particular, has become a giant phoniness-generating machine.  And not just the language of marketing, but the very practice of marketing so often serves to erode the perception of authenticity among consumers—by making promises that bear little resemblance to the actual experience encountered.

So much creative talent today is engaged in making promises as marketing instead of being employed to create compelling experiences as actual output.  The experience itself should be the marketing.

My friend Robert Stephens, founder of the Geek Squad, is fond of saying, “Advertising is the tax you pay for being unremarkable.”  I feel that way about most marketing.  I’d like to see creative talent diverted from making messages about goods and services and used instead to help create truly remarkable experiences, ones so compelling that they command a fee as product.

[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]

When I was at Red Hat, I sometimes got questions from folks who wanted to know the secret to Red Hat’s brand success. First off, I’d always say you don’t grow a $1 billion technology company on brand alone. We sold great products. We treated our customers and developers well. We had a revolutionary business model. Those kinds of things are the bedrock of a successful brand.

But if I was to point to one “secret” thing I think had a big impact on the brand it would be a very simple one:

We said the same thing. Over and over. For years.

For me personally, sometimes I said things so many times I was just as sick of hearing myself as others were.

When people would come to me and ask if they could make a tan hat to give away at tradeshows rather than a red one, I would always repeat: “But we are Red Hat.” We brand folks would always be the ones to bring up the company mission, values, and culture. We’d steer conversations back toward the open source way when they went astray. When my colleagues and I would speak about the culture and brand in orientation, we’d tell the same stories, show the same videos of Bob Young and Matthew Szulik to new employees year after year after year.

When it comes to brand positioning, the biggest mistake you can make is to invest your time, money, and energy in discovering your optimal brand position… and then give up on it before it has a chance to do its magic. Building a great brand has to be done over time and, to paraphrase Jeff Bezos of Amazon, there are no shortcuts.

I’ve worked with a lot of creative types over the years, and most of them love to come up with new ideas. Heck we all do. But sometimes the thing that makes you stand out when everyone else is saying something new is to say something… well… old.

[Read the rest of this post on Dark Matter Matters]

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]

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]

I’ve always been a fan of the Mozilla Foundation, and not just because of the Firefox web browser. As catalyst for some of the great communities in the open source world, Mozilla is something of a recipe factory for what to do right when it comes to building community. As it turns out, Mozilla’s Director of Developer Relations, Chris Blizzard, is a long time friend of mine.

In fact, this is not the first time I’ve interviewed him– my first Blizzard interview experience was back in 2002 when Mozilla 1.0 came out and he and I both worked for Red Hat.

I spent some time with Chris to discuss his experiences and learn more about community-building the Mozilla way.

1. When I first met you ten years ago, you were a Red Hat employee with a day job keeping the redhat.com website up and running, and, even then, you were hacking on Mozilla for fun in your spare time. Now you run developer relations for Mozilla, and you’ve had some other amazing experiences, including working on the One Laptop Per Child project, along the way.

It strikes me that you are a great case study of someone who has achieved success in the meritocracy of open source by doing good work. Knowing what you know now, if you were starting from ground zero as a community contributor, how would you get started?

That’s kind of a tough question because I don’t have that perspective anymore. I know too much about how these communities operate to be able to answer that with the fresh face of someone new to a project. But, honestly, I think that that if I were to guess I would say find something that you’re passionate about and just start working on it. My own case is instructive.

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