[Numpy-discussion] Numpy governance update

Matthew Brett matthew.brett@gmail....
Wed Feb 15 15:25:06 CST 2012


On Wed, Feb 15, 2012 at 1:00 PM, Perry Greenfield <perry@stsci.edu> wrote:
> On Feb 15, 2012, at 3:01 PM, Matthew Brett wrote:
> [...]
> My 2 cents.
> I think you put too much faith in formal systems. There are plenty of
> examples of formal governance that fail miserably. In the end it
> depends on the people and their willingness to continue cooperating.
> Formal governance won't protect people from misbehaving or abusing the
> formal system if they are so inclined.

I think that's bad argument.  I doubt any sensible person would claim
formal systems can't be abused.  Nor that formal systems are harder to
abuse than no system.

> So my thought on this is why not see how it works out. Even if
> Travis's company has a conflict of interest (and that is certainly a
> possibility) it isn't always a bad thing. Look at two scenarios:
> 1) a project requires that all work is done by altruistic people with
> no conflicts of interest. But it languishes  due to a lack of
> sufficient resources.
> 2) a big, bad, evil, self-interested company infuses lots of resources
> and talent, and they bend the project their way to meet their
> interests. The resulting project has lots of new capability, but isn't
> quite as pure as the altruistic people would have had it. (Mind you,
> it's still open source software!)

Again, this is a false dichotomy.  No one is suggesting stopping
Continuum working on numpy.   It's not sensible to paint 'the
community' as 'altruistic' and Continuum as not.

We are not discussing whether Continuum is good or bad.  That's
discussion is pointless.  We are discussing whether Numpy in general
would benefit from a governance structure which could protect it from
the risks inherent in the situation where a company holds a very large
part of the development talent and time for an open-source project.

What are the risks?

1) The main development discussions are happening in the offices of a
company rather than on-list.   The understanding of the code and the
code changes moves into those offices.
2) The decisions are being made by these same people who, of course,
can wander into each other's offices and discuss the problem.  Hence,
even if the decisions are good ones, it is can be hard for others
outside those offices to review them, understand them or own them.
3) When discussions arise, without formal governance, it is easy for
the impression to form that there is a 'Continuum' view and other
views.  Suspicion can naturally arise even if the reason for the
Continuum view is fully in the interests of the community.
4) It is possible for Continuum to want features that are good for
Continuum, but bad for the code-base in general.  For example,
Continuum may have some product that requires a particular arcane
feature in numpy.

Through these mechanisms, Numpy can lose developers and commitment
(please note) *relative to the situation where there is formal

Obviously, at worst, this can lead to a split.   We can avoid that
*risk* with a sensible governance model that is satisfactory for all
parties.  I'm sure that's achievable.

> Neither is ideal. But sometimes it's 2) that has led to progress. If
> the distortion of the self interested companies it too big, then it's
> a net negative. But even the self-interested company has a large stake
> in seeing the community not split.
> And you see this in the open source community all the time, even from
> the "altruistic". Those that do the work generally get the most say in
> how it is done.
> Finally, I think you should cut Travis some slack here.


>  Why not base criticism on actual problems
> rather than anticipated ones?

1) I don't feel that I am criticizing here, I am arguing for
particular political change in numpy governance.  We must distinguish
between criticism and constructive suggestion, otherwise we're going
to get stuck.
2) We have already had problems (NA / masks, 1.5.0).
3) The current situation is new and has obvious risks that may be easy
to deal with.   Not to consider these problems on the basis they
haven't come up yet does not seem wise to me.



More information about the NumPy-Discussion mailing list