Where design thinking and open source community collaboration meet

In comparing traits associated with design thinking collaboration and collaboration in the open source community, there are many parallels: open exchange, broad participation, rapid prototyping.

There's also one really interesting contrast: The mindset you tend to see when generating and choosing ideas. But what I'll suggest here is that when you apply the best elements of these two mindsets at just the right time in their respective processes, the results can be pretty amazing.

I'll start with design thinking.

The brainstorming phase of design thinking is probably the most recognizable part of the process. These brainstorming sessions are designed to be open. Lots of ideas are generated, ideas are built on ideas--there are no bad ones. To do that, we have to establish ground rules. Stanford's d.school posts their list, and our rules at Red Hat have many similarities. Rather than criticizing someone's ideas, you have to build on them and suggest your own. No devil's advocates allowed. In this environment, a good collaborator is one who generates and encourages the most ideas from others.

There are a few good reasons for the rules. First, criticizing an idea too soon can kill that idea in its most fragile state. It doesn't give others a chance to carry it forward and improve on it. Second, even the wildest--sometimes worst--ideas could spark a great idea in someone else. This happens all the time. Often the worst ideas and best ideas are closer than they seem.

And third, it's essential to create an open, positive environment so people are willing to share their ideas and explore. You've got to believe the best idea is always right on the verge of discovery.

Community collaboration is similarly open, but can be somewhat less nurturing.

A solution is found to have merit when it can stand up to scrutiny. In other words, what doesn't kill your idea makes it stronger.

Here a good collaborator is often the one who finds the most bugs. So rather than looking for the positive aspects to build upon we look for holes. And that's a good thing. As the classic open source saying goes, "With many eyes, all bugs are shallow." It's better to find them in beta.

But that doesn't make it easy. In fact, sometimes it can feel like a middle school dodgeball game where you put yourself up against the wall and invite your classmates to take their best shot.

There are good reasons why this environment works this way, too. If a solution is going to fail, it needs to fail early so it can fail forward. A tough testing environment isn't going to get easier in the real world.

Second, in open source the code is shared, so there's always a possibility, and even an expectation, for improvement. A solution can always be better. If you're lucky, you'll find lots of people to tell you so. If you're really lucky, they'll offer to help fix it. That's the beauty of the model.

In both cases, each environment is dependent on an open exchange. Everyone has access to information. Many people participate. Even design thinking processes have a prototype stage.

But even though their mindsets may seem in conflict with each other--I believe they're two important functions of the same process, simply applied at different stages:

When you're in the early stages of brainstorming and generating ideas--take care to protect creative thinking and the ideas they generate so those ideas can multiply.

And when you've got that idea you think is good--then it's time to to put it to the test. Find the holes. Invite smart people to do the same. I'll be the first to admit this is far easier said than done. Sometimes it can be nearly impossible. But if the idea is still standing at the end, it'll be all the better for it. And then you know you've really got something.