One of the leadership skills is to respond appropriately to competition challenges. Such challenge has recently dawned upon the Mozilla Firefox community with the recent hype about Google Chrome browser. The task was even more difficult, as it required addressing the online community’s fears after being challenged by a giant corporation.
Both Mitchell Baker and John Lilly from Mozilla have responded in their blogs to the Google challenge, and in my opinion they have done a great job. Here are the key elements of their responses that are most important in my opinion.
Respect – both Mozillians show respect towards the competitor. This may be linked to the financial support Mozilla gets from their contract with Google, but I believe that in general talking about your competitor with respect earns you points as a leader. It also helps to overcome fear, and it builds self confidence.
Positivity – both posts are positive in tone. Talking in SWOT terms, they show the opportunities – how the new external conditions can be leveraged by Mozilla, as more healthy competition in the browser world can result in even better Mozilla products. They also focus on strengths – what unique internal properties allow Mozilla to successfully compete in the new situation.
Focus on Core Mission and Values – this is especially visible in Mitchell’s post. She is not talking much about the competitor’s product, instead, she recalls mission, values and goals of Mozilla Foundation. By providing this point of view, the competitive threat is minimized, and motivation is increased. This is very much in line with the first leadership lesson from Mitchell Baker as described here.
Can you think of any other best practices when responding to a competitive threat in an open source, online community environment?
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.