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?
In traditional organizations, where plans, strategies, and leadership are coming from above, people can often simply take their orders and complete their work.
But in an open source project run in a meritocratic way, the ideas, plans, strategies, and leaders can come from anywhere, and often do.
There often is a less clear "chain-of-command," and the people taking the leadership roles may change as tasks change.
For this sort of rapidly-changing organizational model to work well, a culture of trust must be in place.
Over the years, I've observed and been a part of both healthy collaborative teams and unhealthy teams. I'm sure your experiences are similar to mine—obviously you can get a lot more done more quickly when a culture of trust is in place.
When you don't have to worry about someone's motivations, it is a lot easier to focus on trying new ideas and solving problems than playing politics. A team built on trust is less stressful, more fun, and more engaging. It's a happy team. And while having happy people does not ensure a happy project, having unhappy people definitely ensures an unhappy (and probably unsuccessful) project.
If you are having challenges in your project, perhaps look first to see if a culture of trust is in place. If it is not, are there things you could change that would help build one?
Sometimes honest dialog can help, especially when it is done in person or via phone rather than on email. Getting agreement on a mutual shared purpose is also a crucial step.
In some situations, it is just plain impossible for a culture of trust to exist. There is too much history, too much animosity, or too much political maneuvering. My recommendation? If you find yourself in a place where trust can not exist:
a) find another project to work on where you can build a culture of trust or
b) (if leaving the project is not an option) consider whether doing things the open source way is the best strategy.
You may find it easier to cut your losses than try to force the open source way into a place where it won't be effective. Save your energy for projects where the open source way will work well.
Do you have experiences working on projects being run the open source way that did or did not have a strong culture of trust? I'd love to hear your stories and ideas.
7 Comments