Archive for July, 2008

When Is Low Quality Good For Your Project?

Ben Collins-Sussman from Google’s Open Source Project Hosting project shares his view on why you should allow early collaboration on your project, even when it means releasing a low-quality product to the public:

Be transparent. Share your work constantly. Solicit feedback. Appreciate critiques. Let other people point out your mistakes. You are not your code. Do not be afraid of day-to-day failures — learn from them. (As they say at Google, “don’t run from failure — fail often, fail quickly, and learn.”) Cherish your history, both the successes and mistakes. All of these behaviors are the way to get better at programming. If you don’t follow them, you’re cheating your own personal development.

One of the key reasons for publishing your work in the early stages is to allow community to get acquainted with it and provide feedback. This is like LISTEN behavior, as opposed to TELL behavior, where you come to the community with a polished product and ask them to accept it. Bob mentions here the open source programming “anti-pattern” of code bombs:

That is, what do you do when somebody shows up to an open source project with a gigantic new feature that took months to write? Who has the time to review thousands of lines of code? What if there was a bad design decision made early in the process — does it even make sense to point it out? Dropping code-bombs on communities is rarely good for the project: the team is either forced to reject it outright, or accept it and deal with a giant opaque blob that is hard to understand, change, or maintain. It moves the project decidedly in one direction without much discussion or consensus.

I think this is a great piece of advice not only for programmers, but for any project in the social networking space. If you’re a blogger, write your posts without striving for completeness and allow readers to provide their feedback via comments.


Chief Jongintaba Story

Recent Time features a great article Mandela: His 8 Lessons of Leadership. One of the lessons seems to be perfectly fitted to online community leaders, and it is based on a story about Chief Jongintaba, Mandela’s adoptive father.

Chief Jongintaba was a tribal king very much concerned about the opinions of the fellow tribesmen. Every time an important decision was to be taken, he formed a circle of advisers who would each tell their perspective on the discussed matter. Laborers as well as landowners would travel many miles to participate in a tribal meeting and raise their concerns. Only after all men had spoken, did Chief Jongintaba begin to speak. He would not impose any decision, but instead nurture consensus from the contrasting views.

The lesson that Nelson Mandela learned from this story was that leaders should lead from the back, and let others believe they are in front. By forming consensus, a leader ensures there is a high level of trust in the community, which makes it easy for it to move in the right direction. A leader should not enter the debate too early, Mandela says.

“You can do nothing if you don’t get the support of other people.”
African proverb

Challenges for Open Business Models

Another article from The McKinsey Quarterly (see previous post) provides very useful insights on the process and challenges of open innovation. Jacques Bughin, Michael Chui, and Brad Johnson provide several examples of organizations following an approach which they call distributed cocreation, characterized by multiple parties collaborating to jointly create new products or services.
Continue reading ‘Challenges for Open Business Models’

4 Leadership Lessons from Mitchell Baker

A few days ago I got really excited when I found out a few old (2006) posts from Mitchell Baker, the Chairman of Mozilla Corporation, on leadership challenges in open source projects. Leading the distributed effort to create Firefox, Baker definitely has a word to say about leadership in online communities. Here are some tips I extracted from her posts and one interview featured in The McKinsey Quarterly.

  1. Make sure you create, publicize, and live by mission, values and goals. Mozilla project was all about open Internet and safe browsing, and people that identified themselves with this mission became the most valuable contributors to the project. Continue reading ‘4 Leadership Lessons from Mitchell Baker’