On Thu, Aug 27, 2015 at 9:36 AM, Matthew Brett <matthew.br...@gmail.com> wrote: > Hi, > > On Wed, Aug 26, 2015 at 11:46 PM, Stefan van der Walt > <stef...@berkeley.edu> wrote: >> Hi Matthew >> >> On 2015-08-26 10:50:47, Matthew Brett <matthew.br...@gmail.com> >> wrote: >>> In short, the core structure seems to be characteristically >>> associated with a conservatism and lack of vision that causes >>> the project to stagnate. >> >> Can you describe how a democratic governance structure would look? >> It's not clear from the discussions linked where successful >> examples are to be found. > > Ah yes - as I was writing at the top of the xfree86 summary, it's > difficult to assess governance models, because you cannot tell if a > project that has a particular governance model would have been more > successful with another model. For example, would clang be competing > so successfully with gcc, if gcc had had a different governance model? > Would Apache be further ahead of the many competitors in the > web-server space with different management? Difficult to know. > > The advantage of studying forks is that they usually arise from > disagreements about how a project is managed. All other things being > equal, we might expect a fork to fail, given the general aversion to > forks and the considerable new work that has to be done to get one > going. So, if a fork succeeds in the long term, that is probably an > indication that the governance / management of the fork is indeed an > improvement on the previous model. > > So, in answer to your question, it's difficult to know if a particular > governance model is successful. It isn't enough that a project has > lasted, or is still active, because there are so many factors in play. > On the other hand, I think it is possible to point to models that > have a tendency to fail in particular ways, and the by-invitation > meritocratic 'core' group (I think this is close to the 'steering > committee' in our current draft) is the model that failed for NetBSD > and XFree86, with a particular pattern of poor or absent > accountability and lack of project vision.
Sorry to follow up on my own email, but: I'm just speculating here, without data, but I suspect one the key elements that led to the decline and fall of NetBSD and XFree86 was the perception that there was no way for the community to depose the government. It seems these projects managed to combine aspects of the dictatorship model, with lots of emphasis on personal loyalty and expected gratitude, with a dysfunctional oligarchy, in which no-one felt able or willing to change the project direction, when the project was failing. The other problem with the meritocracy / invitation model, is that some people are terrible managers. In the XFree86 project, for example, I think David Dawes did a terrible job of guiding the project when it ran into trouble. He was in the position he was in because of his huge commitment and contributions to the project, but I think he was not the right person to manage the project. The standard 'core' model, doesn't take that into account. For example, I suspect that, if we had a David Dawes, no matter how terrible we thought they were at managing, we would feel obliged to put them onto the steering committee. It is much easier to count or review commits than it is to assess someone for their qualities as a leader or manager. We most of us would hate to be the person to make that assessment, and it's very tempting to negotiate ourselves into a world-view where this assessment is not necessary. So, I speculate, that a good governance model would have: * one 'president' who has to take final responsibility for all decisions; * this president might well have a fixed term, maybe with limits on the number of terms they can serve. * the president would be chosen by community vote and explicitly on the basis that they were good managers as well as coders; * for the presidential election, the candidates should set out what their vision for the project is, and how they plan to achieve that vision; The point about these features is that we explicitly emphasize accountability, vision and management ability. Instead of a small number of people being in the position of assessing their peers for their ability to manage, the whole community (somehow defined) takes responsibility for that assessment, therefore making it easier to think about without distracting issues of personal loyalty or implied obligation. See you, Matthew _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
