Search form

Trust: the catalyst of the open source way | 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?

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

I agree Chris.
If "being the change you want to see" doesn't influence others to change then, sometimes you do have to let it go and try another time. As John Wooden said: "Things turn out best for the people who make the best of the way things turn out."

Chris, I think you have it really right: trust is the catalyst. I also believe that openness to participation is the architecture/design objective.

One other comment: I think that one reason that Fedora has been successful in bootstrapping such a large community has been trust in the Open Source Way itself. Sometimes sheer faith alone can move mountains.
But working with people you trust--community--is much less lonely and usually more rewarding than faith alone.

The idea of being open and trusting each other is not an easy one for a lot of people to handle. Whether they find themselves squashed at work or even burned by other open source projects, the idea of opening up does take a little nurturing and a lot of Trust.

Fedora has worked well as an inspiration/example of an open source organization. At this point, it is so much in the fabric of the entire organization that even the most clueless person will learn the Open Source principals before long.

From what I've seen with reading, Fedora seems to offer guidance and assurance which allows people to come to their own, at their own pace. This is an important ingredient to fostering the Trust.

If open collaboration requires trust, and if trust requires absence of competition between collaborators, then is open collaboration possible within competitive organizational environments (or should it not even be attempted)?

On the second part of your statement, I'm not sure trust requires an absence of competition between collaborators.

My view? There is healthy competition and unhealthy competition. Sometimes, you'll see the best work coming out of projects where the contributors admire each other's work greatly and trust each other completely, yet also are driven by a strong desire to continue to impress each other with their individual work and ideas. I'd view this as healthy competition.

I'd agree with you that unhealthy competition can make it hard for open collaboration to be successful. I'd define unhealthy competition as a place where competition between contributors puts the project goals or purpose at risk vs. bringing them even closer to fruition. Where people compete at the expense of the project for individual gain.

Had the surreal experience of entering an org in transition and therefore lacking solid structure -- which for my team meant minimal supervision --- in which we defaulted to working 'the open source way' and within the spirit of healthy competition you describe.

Ideas were thrown around freely and experiments tried under the radar as employees invested their own time & effort in building systems/products that responded to client needs. The result: our team gained prominence as a consequence of rave client reviews and we were able to successfully pitch and win funding for a major project.

That's when the problems started -- competition between units over the funding dollars, competition between employees over project positions, political jockeying over hierarchy as the new structure began to take shape -- all within a context of job losses resulting from wider org shifts.

That was the surreal part -- watching the same people shift as the org contexts shifted -- and here's the kicker: the project itself was about building a collaborative working culture.

I appreciate your pragmatic recommendation to "find another project to work on where you can build a culture of trust" -- that's the route I took -- nothing like worst practices to teach you what not to do again.

It often goes unnoticed that collaboration is a critical ingredient for innovation--for reasons you just laid out very nicely.

Some organizations were founded on the idea of healthy competition that Chris mentions above; but it seems to me that 'healthy competition' is a not very stable situation. It tends to dissipate with industry maturity.

Think Microsoft when it was young, and Gates could throw three teams at a problem and see who came up with the best solution fastest; that could work when the three teams worked on projects that were discrete. Nowadays, in a more mature industry, you can't afford to have discrete teams; they're all working on parts of a whole. In such a situation, collaboration is a more dependable and richer culture than competition.

Main menu

The opinions expressed on this website are those of each author, not of the author's employer or of Red Hat.

Opensource.com aspires to publish all content under a Creative Commons license but may not be able to do so in all cases. You are responsible for ensuring that you have the necessary permission to reuse any work on this site. Red Hat and the Shadowman logo are trademarks of Red Hat, Inc., registered in the United States and other countries.