On Feb 16, 2012, at 12:08 AM, Matthew Brett wrote: >> The question is more about what can possibly be done about it. To really >> shift power, my hunch is that the only practical way would be to, like >> Mark said, make sure there are very active non-Continuum-employed >> developers. But perhaps I'm wrong. > > It's not obvious to me that there isn't a set of guidelines, > procedures, structures that would help to keep things clear in this > situation.
Matthew, I think this is the crux of the issue. There are two kinds of disagreements which could polarize Numpy development: disagreements over vision/values, and disagreements over implementation. The latter can be (and has been) resolved in an ad-hoc fashion because we are all consenting adults here, and as long as there is a consensus about the shared values (i.e. long-term vision) of the project, we can usually work something out. Disagreements over values and long-term vision are the ones that actually do split developer communities, and which procedural guidelines are really quite poor at resolving. In the realm of open source software, value differences (most commonly, licensing disagreements) generally manifest as forks, regardless of what governance may be in place. At the end of the day, you cannot compel people to continue committing to a project that they feel is going the *wrong direction*, not merely the right direction in the wrong way. In the physical world, where we are forced to share geographic space with people who may have vastly different values, it is useful to have a framework for resolution of value differences, because a fork attempt usually means physical warfare. Hence, constitutions, checks & balances, impeachment procedures, etc. are all there to avoid forking. But with software, forks are not so costly, and not always a bad thing. Numpy itself arose from merging Numeric and its fork, Numarray, and X.org and EGCS are examples of big forks of major projects which later became the mainline trunk. In short, even if you *could* put governance in place to prevent a fork, that's not always a Good Thing. Creative destruction is vital to the health of any organism or ecosystem, because that is how evolution frequently achieves its greatest results. Of course, this is not to say that I have any desire to see Numpy forked. What I *do* desire is a modular, extensible core of Numpy will allow the experimentation and creative destruction to occur, while minimizing the merge effort when people realize that someone cool has been developed. Lowering the barrier to entry for hacking on the core array code is not merely for Continuum's benefit, but rather will benefit the ecosystem as a whole. No matter how one feels about the potential conflicts of interest, I think we can all agree that the alternative of stagnation is far, far worse. The only way to avoid stagnation is to give the hackers and rebels plenty of room to play, while ensuring a stable base platform for end users and downstream projects to avoid code churn. Travis's and Mark's roadmap proposals for creating a modular core and an extensible C-level ABI are a key technical mechanism for achieving this. Ultimately, procedures and guidelines are only a means to an end, not an ends unto themselves. Curiously enough, I have not yet seen anyone articulate the desire for those *ends* themselves to be written down or manifest as a document. Now, if the Numpy developers want to produce a "vision document" or "values statement" for the project, I think that would help as a reference point for any potential disagreements over the direction of the project as commercial stakeholders become involved. But, of course, the request for such a document is itself an unfunded mandate, so it's perfectly possible we may get a one-liner like "make Python scientific computing awesome." :-) -Peter Disclaimer: I work with Travis at Continuum. _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
