[Numpy-discussion] Numpy governance update
Wed Feb 15 17:18:52 CST 2012
>On Wed, Feb 15, 2012 at 1:00 PM, Perry Greenfield <email@example.com> wrote:
>> On Feb 15, 2012, at 3:01 PM, Matthew Brett wrote:
>> My 2 cents.
I am both elated and concerned. Since it's obvious what there is to be
elated about, this post has a "concerned" tone. But overall, I think
this is a great move with some obvious problems to solve before it moves
forward. I think the effort spent now looking for a solution will be
much less than the pain of trying to undo a mess involving contracts and
clients. That way lies court and code splits. So, let's do the hard
work of figuring out governance now.
In principle, I agree with Matt. We're moving from pretty altruistic
code development to a model in which the most active development will be
paid for and therefore controlled by influences outside the user
community. This can have a lot of unintended side effects, including
those Matt pointed out. We might also feel some level of discontent
among developers who are not paid vs. those who are. This might make it
hard to recruit developers who are not Continuum employees.
There are tons of examples of financial interests creeping in and
mucking up community computer projects. Symbolics vs. Lisp Machines,
Inc. Early shenanigans on internet technical committees by engineers
working at companies that were behind the curve on product development.
As for being responsive to the community, Continuum is already promising
the world whole new directions in numpy (see continuum.io). Were those
plans even mentioned on a mailing list? Is that the direction we want
to go in? Are there negative consequeces to those plans? What are the
plans, exactly? Having those who do the work make the decisions only
works when those working consider the needs of all. The community
believes that's true largely when it's included in the discussion and
not taken by surprise, as seems to have happened here.
Of course, balancing all of this (and our security blanket) is the
possibility of someone splitting the code if they don't like how
Continuum runs things. Perry, you've done that yourself to this code's
predecessor, so you know the risks. You did that in response to one
constituency's moving the code in a direction you didn't like (or not
moving it in one you did, I don't remember exactly), as in your example
#2. So, while progress might be made when that happens, last time it
hurt astronomers enough that you rolled your own and had to put several
FTE on the problem. That split held back adoption of numpy both in the
astronomy community and outside it, for like 5 years. Perhaps some
governance would have saved you the effort and cost and the community
the grief of the numarray split. Of course, lots of good eventually
came from the split.
I'd like to see at least some serious thought on how to protect the
interests of the community under this very different development model.
Trying it out and deciding we don't like it later will be a *much*
harder thing to sort out.
At the same time, the idea of multiplying the number of people actually
working, and of having continuous builds and good issue tracking and all
the rest, including the enhancements listed on Travis's web site, are
very exciting! Let's just make sure we retain our community orientation
with this new model.
More information about the NumPy-Discussion