# Some realizations on FOSS-Governance

If you haven’t read/paid attention to the Numpy Governance Discussions goingon in the numpy discussion mailing list, I wouldn’t blame you. They’re probably dry and boring.

But, for me, as someone who has been involved in a few Free/Open source communities over the past 8 years, I’m sensing a very interesting divide in the Numpy discussion (and FOSS Python more broadly) that I think is presented more strongly there than I’ve seen it elsewhere. I’ll try to make my understanding of this divide clear.

First, it’s helpful to provide some context. Numpy is the numerical python library, designed to support and enable scientific computation in python. It’s central to scientific computation in python, and has been an incredibly old project. I can’t give its history a full presentation, but it suffices to say, this project contains (or itself is) the “core” of the scientific Python ecosystem.

Travis Oliphant, a longstanding contributor to Numpy, recommended some adjustments to a Numpy governance document. Nathaniel Smith, a very active developer in the project, initially resisted or rejected these recommendations in a titanic response. This set up an interesting exchange between the two that (I think) demonstrates some pretty evident division in the community. Highlighting this isn’t meant to exacerbate them, but is intended to illustrate them for my own benefit.

### Who is We?

In the discussion on the mailing list, Nathaniel frequently refers to a network, a community, a “we,” of which his perspective represents “all.” Travis is very skeptical of this, and I think he has rights to be.

Focus on consensus in FOSS Projects is inherently cliquish. Some voices are louder than others in FOSS comunities, and, as Travis rightly points out in a later response

    How did "we" all work it out when not everyone was there?


Who is the “all” that Nathaniel refers to? Well, it’s the people who speak up to assent and those who aren’t bothered enough to dissent.

That’s more of a rule-by-clique than anything else. Having sat on the outside of this inner circle quite a few times now, I’m very uncomfortable with the cliquishness of this group.

Nathaniel refers to the relatively anemic Debian CTTE as somehow a counterexample to Travis’s desire for more long-rooted involvement in any Numpy advisory council. The point that is totally missed is that the CTTE is not very frequently used because Debian uses a referenda voting system to resolve WAY more debates than the CTTE could ever adjudicate.

Without some formal instantiation of a consensus VOTING procedure, any reference to the opinion of “we” is incredibly suspect.

Of course, voting comes with its own issues. I think this is why successful open source projects typically have a BDFL who is a founder or longstanding contributor-type who contributes institutional knowledge. However, the voting process makes clear where the “we” in the community is.

### The Johnny-Come-Lately

But, there’s more than resistance to this “we” that Travis is speaking to. He mentions reluctance to empower people who have many recent commits over people with experience in the project. Nathaniel is again dismissive of this in the exchange.

Why would Travis want that? Why would any long-standing contributor/originator feel the desire to add this experience to the governance of an open source project?

At first brush, this seems like simple ageism. And, I’ll admit, that’s what I felt it was upon reading the exchange initially.

But, after thinking on it, I believe there’s more to it than that.

Python has been around for a long time. Numpy is like… 20 years old. Many (if not all?) of the non-Debian project governance examples Nathaniel cites in this discussion are from Jupyter/Ipython, which is an incredibly young, superstar project. And, resistance to the de facto standards imposed by these new superpopular projects is understandable. But, as I’ve been meaning to state flatly in my own dev community:

I started learning python right around 2.7’s initial move into End-of-life. I hardly ever used the python interpreter before IPython. I have never done social science without decent python GDAL bindings & pandas tabular data.

And, in all likelihood, I’ll have to relearn quite a bit.

You see, longstanding contributors who feel ownership over their python packages are usually concerned about the diffusion of responsibility. This fear of diffusion comes into play when considering to add a dependency on the newest, flashiest framework or when transitioning from BDFL to community-governance models. Really, any time a project becomes less self-contained, these kinds of anxieties resurface.

And, I think this is understandable. There’s a python ecosystem, but it is anchored on different packages that operate as self-contained islands. And, it’s difficult to understand exactly how transitory some things are in this ecosystem. The islands never move, but flotsam and jetsam abound.

Travis and other longstanding contributors built Numpy for specific reasons and have unique insight into both the package and the vision of what it should be that is simply unavailable to any johnny-come-lately like myself. A community where every voice is equal is one that relies on “meritocracy” to do quite a bit of heavy lifting. It’s also one that should bear in mind the classic Asimov caution about democracy being the state where:

my ignorance is just as good as your knowledge.


Founders/longstanding contributors have unique, irreplacable institutional knowledge about the software they have helped create. In my own life, coordinating new ideas with code debt and legacies of involvement has both been frustrating, but ultimately rewarding for the project.

And, I hope projects like Numpy find ways to involve their tall trees that don’t blot out the sun for saplings like me.

imported from: yetanothergeographer