Next: Enforced Error Handling
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.
Martin Sústrik, November 14th, 2015
Next: Enforced Error Handling
Interesting, especially the point on the lack of closure of "social" software project.
It would be a nightmare for me to have to continually grow a software that is meant to be complete as is.
In your opinion, are the large community driven never-ending project necessarily more successful than little, one person, time-convergent ones?
*projects
Hard to say. People tend to flock to where other people are so lively projects are almost necessarily be more "successful" in sense of being spoken about, trendy et c. On the other hand, if you want a sane technical solution your best bet is to use something that is small, well-defined and doesn't change too much. You may use the term "successful" for that kind of thing as well.
A software project can (in theory) be finished without killing the totem: define the project as a collection of artifacts instead of one particular artifact. In other words, make the community flow along a stream of artifacts, instead of getting stuck adding options to a single one.
Yes, that's what IETF does, as mentioned in the article.
I think the more common problem in corporate cultures is that software quality is sacrificed precisely because a customer is demanding a product or feature in a competitive market, so time-to-market matters: the engineers would rather spend more time on design and implementation, but are instead forced to make compromises to get the product out the door by the deadline, but which lead to technical debt, which either must be resolved prior to adding new functionality or which piles up and slows future development.
Yes. You can go on about deficiencies of the corporate process for ages. In the end it all boils down to the fact that measure of merit is contribution to the company (most often in terms of money) rather than contribution to the code.
Implementing features spends lines of code. If you don't have features to implement, what good is spending lines of code? It's like smashing nails into random surfaces. Maybe it looks nice and tidy to have a perfectly hammered nail, but unless it's fastening something, it's a wasted nail. Unless, I guess, if it's used for decoration…
There is a very general theory about those things and it is called the membrane theory.
Every system has a membrane from which it gets information or new members or material things. When you close the membrane, you are able to separate your internal state from the outside world. This way you can increase the quality of your work. That is necessary if the outside state is not that good. Imagine if a University professor accepted all the views of his students as correct in his course. That would be crazy.
At the same time, if a membrane is closed, no new information can be received or no new experiences from others. Experiences lead to knowledge and this way we can learn new things that we could't learn from a closed system.
Not only that, but when more people get inside and learn of our theory, we have a greater effect on the world. Knowledge that is only known by a single person is meaningless.
Pieter has done an amazing job at building the zeromq community and providing a social protocol in which common knowledge expands.
In his effort, he has lowered the importance of closed systems. Closed systems are very important, especially at the start of pioneering work where others would be a hindrance rather than a helping hand.
I think the dichotomy here is not about inclusiveness vs. exclusiveness. On that front, everybody agrees that the more inclusive, the better.
It's rather about placement of the membrane. I argue that if it correlates with a software project, the social dynamics may in some ways push against good software design.
In other words, that software projects should be treated as small disposable elements without much emotional attachment from the devs.
To achieve the goal though, it may be necessary to create actual wooden totems to redirect the human need for social hierarchy and belonging.
So, does this mean I can't get a libmill sticker for my laptop? :P
Well, nothing against stickers, but look at the logo. Would you like to spoil your laptop with that kind of thing? I've made it while on morning commute to work.
I'll ask the artist / graphic designer friends of mine to come up with something better over Christmas…
You can do better than resorting to cheap, ad-hominem jibes like "ZeroMQ is a social club," eventually doing some good work.
You surely cannot have misunderstood my rationale for building community, after all these years.
I've written extensively about the failure of individual intelligence and the need to work collectively, in order to think accurately over time. I've written about this in my book Culture and Empire, the ZeroMQ Guide, and my blog, for years and in exhaustive detail.
Smart individuals do not make good, long lasting software. To build that requires a group that is diverse, decentralized, and self-organizing.
My organization of the ZeroMQ community has always been towards this goal. It is successful. ZeroMQ is as radical as it can be while staying relevant. This is part of the calculation of success. Move too rapidly and you lose your market and you die.
Making code for its own sake is… well, I spent years doing that and you would know my work if you hadn't suffered from eternal NIH syndrome. Libero, Xitami, GSL, OpenAMQ, Base, Base 2, XNF, the list is huge and each of these was ground breaking. And ultimately, pointless.
Portfolio
I don't think Martin intended to attack anyone.
I'd interpret his words as "[ZeroMQ is] a software project treated as a community, place where people with similar interests get together, feel at home, have a good time and eventually write some code".
This is consistent both with your view of ZeroMQ as a project, and Martin's view of caring about the code (or craft, if you will) above all else.
And that description of the ZeroMQ community is entirely false. It is a straw man that Martin creates so he can defend his (unsuccessful) rejection of the social aspects of knowledge collection. The social aspect is one I've documented and explained over and over. It's not hypothesis any more. Working alone is a failure pattern.
In our community we get together by sending pull requests. That is, we start with code. Not issues, not coffee and knitting. Code, code, code. Also documentation, packaging, etc. Yet these are also all code. It is all about code, from the first step. There is no "eventually." Our only similar interests are good code, *above all else*.
Portfolio
Post preview:
Close preview