I had intended to stay quiet in this discussion since I am not a core developer and also no longer even lead the doc project. However, I've watched two organizations go very wrong very fast recently. Both were similar in structure to this one. I've done some study as a result and there are some lessons to learn. The committee-of-doers-and-executive format is very effective when it works. It's worked well for numpy and many other OSS projects. Benevolence and commitment of the leader are made likely by choosing someone who is already doing a lot and whom everyone knows. Yet it can still go wrong. By studying the failures, as well as the successes, we can build in some safeguards. So, I'll tell the story of Pack 608. (It's the next four paragraphs if you want to skip it.) This is a Cub Scout Pack, which for those who don't already know is a group of 20-100 boys, ages 6-10, who participate in a variety of indoor and outdoor activities that are designed to build good character (whether they do is a different discussion). Our group has about 80 boys. It is run by parents who volunteer their time, and it is led by a Pack Committee, with a Chair and a Chartered Organization Representative. The latter is an overlord who can overrule anything but by design usually observes from the sidelines and only steps in when things go wrong. He represents the organization (usually a church or community service organization) that owns the pack. There is also a Cubmaster, who is the face of the organization to the boys. He reports to the Committee but is a really big dog there, often as big as the Chair. Sometimes bigger. Running a group of 80 boys doing a dozen activities a year is a huge job, way too big for any individual with a job, so finding and developing parent volunteers is hard. In our group, one married couple, extremely committed, got involved and began doing a huge number of tasks. Whenever anyone slacked off, they took over that job. They did those jobs extremely well. As our top leadership moved on (their boys turned 11 and became Boy Scouts), eventually we looked around and the clear choice for the Chair and Cubmaster were these two. We were not exited about installing a married couple in two of three key posts, but we had few options. We didn't want to do it, but nobody else stepped up. It was the biggest mistake we ever made. Even though everything this couple did was, in their eyes, in the best interest of the boys and the group, their style was so overbearing and their opinions so inflexible that there were serious verbal conflicts and other leaders began to quit. Some non-leaders complained, the Chartered Org. Rep. called a meeting, and these two were forced to step down. But, by this time, they were doing so many tasks that between them and the other departed leaders, we had lost EIGHT critical leadership roles (for those who know Scouts, these were Committee Chair, Cubmaster, Outdoors Chair, Events Chair, Advancement Chair, Fundraising Chair, and two Den Leaders). The pack nearly folded, but we managed to pull in a few parents (including me) who were neither eager to get close to this group nor really ready to spend a lot of time on it. We aren't yet up to where we used to be a year ago, but we're surviving. It's been brutal on our personal and work time, however. It would have been much easier had we stepped up before the fiasco. While such near-collapses are infrequent in small organizations, they happen often enough that many readers have probably experienced one. They can happen out of poor choice of leaders, feelings of possessiveness, differences of vision among stakeholders, and a host of other causes. The point here is to build into any organization plan not just the structure that will let it succeed, but also the safeguards that will reduce the chances of failure by catching and correcting organizational health problems early. With OSS, we have an ultimate safeguard, which is that anyone can fork the source and start a new org. But, as we've seen in this project, forks are *very* damaging and can take years to recover from, so it makes sense to think about safeguards in this organization, too. There are organizations of organizations that provide advice on this topic. Among the key suggestions: - Have uninvolved oversight. In Pack 608's case this was the Chartered Org. Rep. For us it could be an external board with some community reps. This oversight itself can be abused, so it must be limited to removing problem leaders and calling an election, or even just to calling an election. It should probably NOT extend to changing decisions on the code, other than forcing a vote of reconsideration. - Rotate key posts. When people do a job forever, they can become possessive of it. Not everyone does, but it's common. The job becomes tailored to the person, others don't know how it's done, key practices go undocumented, and if that person leaves or is temporarily unavailable at a key time or if a change needs to be made and that person disagrees, there's trouble. Feeling part ownership is good. Feeling full possession is not. The lack of central ownership is a big piece of why we can trust OSS in a way we can't trust commercial software. So, rotate key jobs. - Ensure that critical authorities (keys, passwords, certificates, title to important property like a web domain, signatory authority on a bank account) are never held by just one or even two people. Make sure the oversight entity has ultimate access. - Have multiple sources of key resources, like labor and money, so that the threat of taking them away is not debilitating. This means not letting one person hold too many jobs, too. - Have a well defined voting procedure and rules of order. You don't have to use them all the time when consensus is clear. They can be slow and cumbersome. But, when there is conflict, they ensure fairness. - Have a no-confidence vote procedure that removes a problem Chair. The rules for this need to be carefully thought out. - Have the consent group, and not the outgoing Chair, choose the next Chair. There are many reasons a Chair moves on, including lack of time, becoming tired of the job, and differences of opinion with the consent group. Especially in the latter case, you don't want the former Chair to influence the future. - Have open meetings with posted minutes. Keep no secrets (except passwords, etc.). As Ondrej pointed out, identifying the potential leaders isn't hard, in our case, but I think those in the consent group should include more than just coders. There has been a lot of work on the docs, for example, though not as much recently. Leaders of key client packages should be involved. Representatives of key user classes (astronomers, neuroscientists, statisticians, numerical programming teachers, newbies, etc.) would be important. Perhaps it's ok to let most coding questions go to the coders, but significant decisions that could change the direction of the effort should be referred to the wider group of stakeholders. That could be the mailing list, but then voting becomes vague. I would suggest including some number of core coders and an equal number of community representatives. Or perhaps the community reps become the oversight board, which also includes a small minority of coding reps. One method that works well for continuity is to elect a Vice-Chair who shadows the Chair and is involved in decisions for a period, then becomes Chair. The Past Chair can be a formal position, too, whose role it is to provide advice. This also eases the transition out of the top job. The Past Chair should be a resource only, and have no special authority. There are lots of sample organizational bylaws available online that can serve as a template. If we join an existing organization, e.g., for fundraising, they likely have requirements that our bylaws need to meet. To sum it up, the BDFL system is great if you have a truly BD. It's most likely to find one in the founder of an effort. Once they step down, be wary of centralizing too much authority. If one out of four leaders is less than fully committed, competent, and benevolent, it's trouble. We should at least have oversight and procedures that can remove a problem leader. Numpy is at a difficult stage, where we like the freedom of not having written rules and procedures, but we're at risk if we don't. Much larger and it's clear we need them, and vice versa. The time we'll wish we had them is when we have a leadership crisis. The chances of having one are small, but not vanishingly so. --jh--