Posts Tagged with “leadership”

Mellon Foundation Awards for Open Source Projects

April 2nd, 2007

The Andrew Mellon Foundation sponsors awards of $50,000 and $100,000 for “not-for-profit organizations for leadership in the collaborative development of open source software tools with particular application to higher education and not-for-profit activities.”

The deadline for this year’s applications is April 16th. The requirements for these awards are rather specific. The core requirements are below; more details on the requirements can be found here.

If you think you or any organization(s) you know of meet these criteria, and could make use of the grant, please visit the Mellon award site or contact: Christopher J. Mackie at (for full disclosure, I am a member of the Awards Committee).

The overview of criteria for these awards is that the organization “must have contributed its own financial and human resources to a software development project which meets all of the following criteria:

1. Is in public release (not just development) as an open source project, with source code actually available.

2. Provides a direct and demonstrably significant benefit to one or more of the Andrew W. Mellon Foundation’s traditional constituencies. These constituencies are: higher education, with a special emphasis on the arts and humanities; libraries and scholarly communications; performing arts; conservation and the environment; or museums and art conservation.

3. Meets the Foundation’s strict standards for excellence.

4. Includes the development of intellectual property that is freely available to the academic community under one of the approved open source licenses.”

Layers of the Onion

July 5th, 2006

A few days ago I mentioned the need for positive reinforcement to encourage creativity; Ben Goodger noted the prevalence of Stop Energy (a Dave Winer term) and the need to do something about it.

Two obvious responses are: Stop Energy wins, and the status quo resists attempts at change. During his visit to the Mozilla Corporation Bob Sutton has noted how disastrous this is for most organizations. We’re no exception. Another possibility is a determined individual who ignores all comments and plunges ahead, “knowing” that s/he is correct and change is better. I’ll call this the “Loner” approach for now.

The Loner approach addresses the Stop Energy problem but has many problems of its own. For one thing, the Loner approach is hard on the Loner. He or she must have a very thick skin, must proceed based on s/he thinks without listening to others (including possible improvements), and then must somehow be demanding or threatening or otherwise forceful enough to pull the project along. This is exhausting. The Loner approach is hard on everyone else as well. Bull-headed, demanding people who don’t listen to others are usually difficult people to work with. The Loner has to be really, really, really good to make it worthwhile for others to stomach the trauma. Our strength is the caliber and dedication of people who choose to work with the Mozilla project; encouraging difficult behavior to avoid Stop Energy is an unhealthy setting.

Also, if people get into the habit of believing they are always right and don’t need to listen to anyone else, then all sorts of unpleasant things generally follow. Few people are always completely right. It becomes hard to work together. People become zealots. Moderating influences are lost. Our experience has been that the group intelligence within the Mozilla project is very high; far greater than the intelligence of any one person.

So, how to encourage positive feedback for creative ideas, make use of our group intelligence and avoid Stop Energy? I think many of us use an approach I think of as “Layers of the Onion.” It’s a pretty simple idea. When someone has a new idea, s/he thinks it through a bit, then goes to a group of people he or she thinks of as likely to have the expertise to be helpful and the sense of possibilities to be encouraging and make good suggestions. At some point w/he includes people with a sense of the constraints as well to get a reality check. Feedback (positive and negative) is received and incorporated into the original thinking; maybe some implementation work is done.

Then the idea is discussed with a larger group of people. More feedback is received and incorporated. The idea appears in a public forum for public discussion and review. Maybe the idea never gains traction, maybe it needs more work to be generally acceptable, or maybe it’s time for implementation.

There’s nothing too complex or original about this process, I suspect it happens all the time. I’ve called it out explicitly because I believe that –- properly implemented of course — it’s an approach that meets our criteria of openness and transparency while simultaneously helping to minimize Stop Energy. I’m very focused on doing both of these things well, both for the project as a whole and for the work I need to lead on issues of Mozilla identity and governance.

Leadership vs. Coordination

June 11th, 2006

Last week I wrote a bit about leadership and there was a brief discussion of the degree to which a leader helps the community decide and how much a leader actually make decisions.

The coordination function in the Mozilla project is huge. We are a large group of people with many different perspectives. Just developing good communication channels is a challenge. Coordinating the responses, repercussions and interactions of our activities is an even bigger task. This involves constant communication, gathering input, making sure relevant ideas are heard and understood, and juggling some set of activities to get to an answer. At heart, coordination is a process. It’s a critical process, particularly in an open source world where so many people can easily go elsewhere if they don’t like the results.

But coordination is not leadership; leadership is much more. Leadership involves taking all that one knows and setting direction. Open source projects are different from many other organizations in how one achieves a leadership role and how the scope of that role is determined. But the fundamental need for some person or group to make decisions, articulate a direction and lead forward motion remains.

One classic form of leadership in the Mozilla project is the module owner system. A good module owner listens to peers and contributors and in most cases makes decisions that set the direction for the code under his or her stewardship. And yet a module owner’s authority is ultimately determined by the expertise and contributions of the people s/he leads and the degree of confidence of other project leaders. Another classic form of leadership in our world is the person who decides it’s necessary to do something and does it. New projects, new ideas; new technology. Often people lead by doing, and seeing what happens.

Coordination is critical. Good listening is critical. Good leadership is more.

The “community” and decision-making

June 6th, 2006

Periodically I hear people say things like “the community will decide.” Or “let the community handle it.” This has always sounded amorphous to me and I’ve finally realized why. This way of looking at things assumes there is little clear leadership and no actual decision-maker. This is a misunderstanding of many open source projects, which have real leadership and ultimate decision makers. For example, Linus Torvalds makes decisions for the kernel, Apache has a committee system, Brendan is responsible for technical decisions in the Mozilla project. In the Mozilla project we try to delegate authority so that:

  • many decision-makers are involved in their areas of expertise;
  • an ultimate decision-maker exists but is involved only when necessary; and
  • decision-makers are chosen and evaluated by their ability to provide leadership that draws in other contributors.

This last point is extremely important. Decision-makers who don’t provide leadership make it hard to build a good project. Decision-makers who people don’t want to follow will struggle. Open source software always gives people a choice. Participants are always free to try something different using the same underlying code. So the decision-maker’s role has many facets. Basically it boils down to making enough decisions correctly enough that people continue to choose to participate. In other words, leadership.

Other projects may invoke the authority of the ultimate decision maker more or less often. The important point is that many open source projects incorporate clear decision-making into their processes.

Skip past the sidebar