I've been involved at various times with both Martin and Pieter on the projects that motivated this article. The dichotomy here sounds compelling, but I think

I've been involved at various times with both Martin and Pieter on the projects that motivated this article. The dichotomy here sounds compelling, but I think it hasn't any basis in reality at all. Let's look at the data. nanomsg ("the technical endeavor") is, objectively, a project with declining activity, and little of any import has happened in 2015. [0] libzmq (the "social club") merges some 20 patches/week. [1] Now, maybe this is because nanomsg is "done", and has simply already achieved its status as a "small component that does one thing and does it well" where nothing else needs to be added, while libzmq faces "strong pressure to add one more option, one more feature". Except that nanomsg is now in its fourth year of unstable beta, and even its own mailing list is riddled with statements that things are so bad don't even bother to file bugs [2], features are "horribly broken" [3], and you should use a different project instead [4]. From my own experience deploying nanomsg in large environments, this criticism (from core developers!) is absolutely true. One cannot look at these projects and fairly conclude that there is any tradeoff at all between "software as a social club" and "software as a technical endeavor". In reality libzmq is both, while nanomsg cannot even succeed at one. libzmq may be a social club, but it's a social club that ships. Don't get me wrong, libzmq has plenty of problems, technical and otherwise. I am no champion of it. And it was totally plausible, in 2012, that the philosophy enshrined in nanomsg would produce a better library. I believed that. What is wrong is now – now that we have the data – to ignore it and pretend that doubling down on a failing strategy is a good idea. What is wrong is to gloss the serious technical inferiorities of nanomsg as a "personality difference", or that the reason it is in a perpetually unusable state is because "we focus on the code". For nanomsg to be healthy, it needs to do a real postmortem. Admit things aren't working. Think about why. Change the philosophy to something that isn't proven to be broken. Kill some of the sacred cows. Instead, puff pieces like this are written, that tell stories that "feel true" to developers instead of addressing the real facts at any point. The software can never get healthy when this is the approach. [0] https://github.com/nanomsg/nanomsg/graphs/contributors https://github.com/nanomsg/nanomsg/graphs/contributors [1] https://github.com/zeromq/libzmq/graphs/contributors https://github.com/zeromq/libzmq/graphs/contributors [2] http://www.freelists.org/post/nanomsg/inproc-bugs,1 http://www.freelists.org/post/nanomsg/inproc-bugs,1 [3] http://www.freelists.org/post/nanomsg/v07beta-released http://www.freelists.org/post/nanomsg/v07beta-released [4] http://www.freelists.org/post/nanomsg/release-of-nanomsg06beta,9 http://www.freelists.org/post/nanomsg/release-of-nanomsg06be...