We have a long-standing disagreement with Pieter Hintjens (who invested in ZeroMQ in its early stages and is now leading the community — thanks, by the way!) about nature of software project.
I guess it boils down to the difference in personalities, with Pieter, being an extrovert advocating the idea of a software project treated as a social club, place where people with similar interests get together, feel at home, have a good time and eventually do some good work.
Me, being reclusive to the point of misanthropy, I see a software project as purely technical endeavour, an exercise of craftsmanship, without caring too much about its social aspects.
Still there are some technical consequences to both models that I would like to discuss here.
First, by its nature, piece of software is not a social club. It's a technical artifact that's reliable or buggy, fast or sluggish, maintainable or a tangle of spaghetti code.
However, like almost everything, it can be turned into a focal point of community, a totem of sort to which people flock, base their personal pride and sense of identity on and use it to define boundaries between different tribes with different totems.
This is quite visible in communities gathered around individual programming languages. To see it in action look at any discussion board frequented by programmers: Any discussion of technical merits of a language quickly turns into a mini tribal warfare.
A fair thing to do is to compare this tribal model to the model seen with commercial software. In the later case, the totem, the idol that people swear allegiance to, is not the code itself, but rather the company that produces it. The problem with that is that the needs of the code are readily sacrificed on the altar of the corporate deity. Simple example is adding features that users would rather not have but implementation of which will propel the project lead upwards in the corporate hierarchy.
Compared to that, the model of code as a totem is much superior. At least, the code is treated well and the members of the community try to make it better to boost their personal prestige and to nurture the feeling of close personal association with the godhead.
To put it simply, the lack of corporate structures to associate one's status with channels more attention and care to the code itself.
However, the code-as-a-totem model is not perfect. If you look at a number of open source projects you'll see a wide range of disfunctionalities in the communities which eventually reflect into the code (Conway's law).
There's one problem though that is common to all such communities (and it happens to be a problem I particularly care about): You can't finish the project. It's like killing the totem. A deicide. The ultimate crime that destroys the focal point of the community, zeroes everyone's hard-earned social status and turns the homeland into a barren wasteland.
In other words, as long as we totemise our software projects there's no way to achieve the goal of the UNIX philosophy, small component that does one thing and does it well. As long as our social status can be only maintained by contributing to a certain project, there will always be a strong pressure to add one more option, one more feature, and, damn, why should it not send email in the first place?
To end on a more positive note, let's have a look at the alternative models.
In our own world, there's the IETF model where individual projects (protocol working groups) are deliberately kept short-lived, with hard deadlines, so that they don't turn into never ending political nightmares. Instead, IETF tribe organises itself around large in-person conferences, held three times a year, enough to not let the community disintegrate.
Or you can look at artists, which also organise in loose communities and one's individual prestige is fueled by a steady stream of well-crafted artifacts.
Finally, if you want social experience, go to pub. I've spent ten years of my life in a pub and I liked it.
November 14th, 2015