2 min read

Collective madness

Collective madness
Gopher artwork by Ashley McNamara

aka Hive mentality

or sailing the Open Source Oceans


One of the few books I enjoy enough to pick up frequently have been committed by Pieter Hintjens. He shared his take on how some natural hive models could be applied to thinking about technological advances and group work. Some takes:

I love the ant nest as a model. Ants are extremely successful, and they have this tiny genome, I suppose—I mean, ants aren’t very complex, and yet they do really complex things. I think that’s a satisfactory and accurate model for human behaviour, and for technological development.


Well, the physics of software is people and psychology, and you figure that out, and you can make solid software.

I love how he attributes the effort, results, and breakthrough to collective genius and diminishes the egocentric focus on the self and unitary pursuits. I wonder if he knew of the ant mill phenomenon.

It is a fair comparison, a lot of the stories we hear from the open sorcerers are stories of austerity and self-sacrifice.


It is at the same time a story where the collective madness results in such improbable results as Python, Firefox, or Linux. It's even more amazing when you realise most of the bricks have been provided by an anonymous army; and everyone using any device connected to the Internet is undoubtedly using open source software in one way or another.

Hintjens had some ideas that our industry seems to consider idealistic pipe dreams, here are some excerpts from C4:

  1. Maintainers SHALL NOT make value judgments on correct patches.
  2. Maintainers SHALL merge correct patches from other Contributors rapidly.
  3. Maintainers MAY merge incorrect patches from other Contributors with the goals of (a) ending fruitless discussions, (b) capturing toxic patches in the historical record, (c) engaging with the Contributor on improving their patch quality.

or a more personal take on it:

The rules are that we will aim for maximum participation, that’s our first goal. I don’t care about the software in terms of its code, I care only about the people and the way they organize, and I trust they will make the right software.

Which I believe we should all start following to speed up the merge processes.

The software that was build this way, open to mistakes and open to fixes from those willing to provide them, has served serious business for years already. We are all quite ignorant for not realising that and still attempting to build bulletproof QA processes that will find all the errors in the “napkin phase”.

PR process, with the nitpicking we can't give up on, is deeply flawed in my opinion. If you can't prevent yourself, at least offer proper sample / commit suggestions.

Let the countless mistakes and abandoned open source project as far as git searches can go be a testament to the collective madness we indulge in. When we criticise their authors too harshly or offer no support whatsoever to help them, those projects alive.

It's equally strong evidence that this madness leads to progress, the fact we can look up anything within seconds, globally is a miracle. Hicks would be proud! So go on and keep the spirit of the collective bozo !