
Software Totemism - rumcajz
http://250bpm.com/blog:67
======
teddyh
I agree immensely with this. I recently attended DebConf 15, (the conference
for Debian), and in an introductory session some long-time attendees were
asked to express why they attended the conference. What they said were things
like “ _This is where all my friends are._ ” and I even heard someone say “
_Debian is my family._ ”. This is emphatically _not_ why I go to _any_
conferences. I go to conferences in order to advance the state of the field by
listening to talks and getting to personally talk to people also working to
advance the field, in this case the Debian GNU/Linux operating system
distribution.

I _did_ get a lot of that done, but this spirit of chummy familiarity was
pervasive. Every problem of getting people to cooperate and collaborate more
was approached as a problem of not enough socializing. But I _don’t_ want to
socialize with lots of random people. I want to _make Debian more awesome_ ,
not shoot the breeze with random people with wine and cheese (yes, DebConf has
a Wine and Cheese event _in addition_ to the large social outing). Beyond
having a title and summary for talks (and some rather narrowly scoped BoF
sessions), there were _no_ concerted efforts to get people in the same field
of interest to get to speaking about common topics and solving common
problems. I voiced a complaint to someone about this, that in order to find
anyone who was interested in the topics I wanted to discuss I would have had
to basically randomly wander around and ask every person I met about what they
did, which would have taken a lot of time and energy. But the person I talked
to saw it as a _good_ thing to essentially force me to socialize with people
_even though pure socializing was not my goal_.

Optimizing groups to be more social _to the detriment of all else_ is _not_
what you want to do if your group has any other overriding reason to exist
beyond being a pure social club, since you exclude people who would rather
work towards the group’s proclaimed goal than being social and chatting with
friends.

~~~
vezzy-fnord
At the risk of sounding provocative, Debian are a political effort first and a
technical project second. They're much more of a target platform than a leader
in their own right.

As such, I'm not surprised that there was significantly more interest in self-
preservation and socializing than in any technical work. I don't recall Debian
ever pushing boundaries.

~~~
teddyh
Debian has _plenty_ of technical work done within its boundaries. (Don’t
forget the pioneering work that Debian did with its package format which was
greatly superior to that of Red Hat’s RPM at the time.) A distribution is not
created by simply downloading all software from the upstream authors,
compiling them and burning a CD. Simply read the Debian Policy manual to get a
feel for the vastness of an undertaking which creating a distribution really
is:

[https://www.debian.org/doc/debian-policy/](https://www.debian.org/doc/debian-
policy/)

~~~
vezzy-fnord
Of course they've done technical work, they're a distribution. Of course they
have a distribution standard, they're a large committee-driven project. None
of these are pushing the boundaries as such.

I never said anything to the contrary, but rather that those are all secondary
to the primary political goals. A distribution having a detailed technical
policy does not refute any of this.

I don't support Red Hat, either. dpkg's original conception was a tarball-
based package management Perl script with rudimentary substring match
dependency processing. It evolved as time went on.

GNU is the same. Politics first, technology second. They've generally been
much better at both, however.

~~~
jschwartzi
Any time you put more than two people in a room together and ask them to
finish something, there will be politics. The only thing you can do is make
sure everyone has some goals that are the same as the organization's. In a
corporation, this is achieved by paying people to be responsible for certain
aspects of the company's operations. In a volunteer organization, this is
accomplished by having the people in the organization socialize around the
organization.

Everyone has their reasons. Some people are motivated by producing beautiful
functional code. Others are motivated by the ideals of Free Software. Still
others want to use the community to sell hardware. At the end of the day, as
long as they're all moving in a similar direction, the movement is successful.

Whether or not the movement is a good thing depends on your values and
motives.

------
mtrn
I recently finished three small projects in the sense, that there are no
essential features, that I want to add in the near future. It is refreshing
and I hope can level up the not really trivial analysis effort needed to
actually define the limits of a project and yet be useful.

I wish this kind of "limited projects" engineering skill would be easier to
learn.

~~~
sdegutis
I've written two major projects: a window manager, and a fuzzy matcher.

The window manager inherently requires a lot of configuration because everyone
wants window managers to work differently, and even the same person will want
to change how they use their window manager. So I've written about a dozen
implementations of this; the most popular one one just wraps system calls as
Lua functions, but it's also the most difficult to maintain because of the
complexity of wrapping system callbacks with Lua callbacks and tracking them
and allowing live code reloading etc.

The fuzzy matcher was written in one day, and I use it every single week day.
It just uses stdin and stdout, and takes very few options. I haven't compiled
it since I wrote it, and it's working beautifully.

So all in all I'd say the UNIX philosophy is a win.

~~~
nvader
I'm interested in learning more about the fuzzy matcher you wrote. What kind
of problems does it solve for you?

------
plonh
Suckless.org disproves the authors thesis. Heck, UNIX itself disproves the
thesis. A project can grow to include more compatible components, without
needlessly cluttering each component. Finishing one program is not the end of
all software development.

------
something123
I think this is part of a larger issue of people making programming their
lives. Our profession encourages obsessiveness more than most - and making
your work your life is something people seek out! (just look at startup
culture)

I find it makes finding professionalism a lot harder. Most companies expect
you to be friends with your coworkers/boss/etc. and then leverage that to
exploit their workforce.

I like the artist alternative he proposes. With github you can now take
ownership of your work/contributions. You can go into an open source project
and make a contribution and then never touch that software again - yet your
accomplishment is something that's tracked and stays with you

------
mpdehaan2
Hmm, complicated.

I don't get the wanting to be anti-social bit, but I do get the part about
projects that are sometimes too much about the social bit. Or rather, the
stress that can create. I felt some of this at times, namely the idea of a
project became that it must absorb all contributions, and trying to not offend
people while trying to mediate that.

This is exactly what a project _shouldn 't_ do, and in many cases, it's a
giant challenge.

OTOH, much of what spawned good OSS was people working together across company
boundaries, and that means letting up a bit to let other people get their
ideas in, even if those ideas aren't the ideas you neccessarily feel are the
most important.

It's a hard balance.

I do like socializing with people I meet through OSS projects, but it can be
hard to close the door and say "this code isn't good enough" and "I'm not
interested in this" without being percieved as anti-social, or greatly
overcommunicating to avoid percieved slights.

I do agree with one thing I did read about 0mq though, which was it wants to
merge things first, and break things. I prefer more to see software that is
designed and strictly looked after. The social element is definitely not
first, but it sound be fun.

The problem is, with a lot of people in the game and not monetarily invested
(this is free, etc), people can get their feelings hitched to the project more
than they ordinarily should, if it was a business transaction -- they feel
their price for spreading things or contributing should be that the big social
element takes over and everybody gets their code in... which is anti-quality
in the long run.

Again, balance -- and really only you get to feel this when things start
getting really busy.

I do believe software can be finished though. If you're just continuing it to
keep the community around, I think that's when you don't have a purpose. But
that doesn't really happen unless you're doing it for fun (like a game) - and
if so, great!

But yeah, the first goal of OSS isn't just to collaborate for the sake
thereof. It should be for the purpose, and you can still enjoy the heck out of
the collaboration part.

~~~
rumcajz
I think that UNIX-y "do one thing" projects kind of solve the problem. It's
easy to reject a contribution as being out of scope: "This little program
prints out contents of a file. Your patch that sends it via email is nice, but
you should rather make it a separate project built on top of the existing
one."

------
drewcrawford
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-
nanomsg06be...](http://www.freelists.org/post/nanomsg/release-of-
nanomsg06beta,9)

~~~
voltagex_
Maybe you can help them with a postmortem? It's difficult to admit a project
you spent a lot of time on isn't going to survive.

------
digi_owl
In other words the geeks has taken over the domains of the nerds?

Something i get the feeling started with the web going commercial, and people
that was more interested in presentation and bullshitting than technical
aspects smelled money and potential fame.

And it has been going down hill ever since...

------
raymondh
Brief and well written article giving insights into how group dynamics shapes
software development.

------
Greymoon
thanks

------
Greymoon
help me

------
olalonde
I'm not familiar with what lead to this post but lots of projects on GH do
feel like social clubs. It would be interesting if GH had a feature that, when
enabled, would make all comments on a project's PR/issue tracker anonymous so
that they can be considered purely on their technical merit.

~~~
jordigh
You can still recognise people behind the words. I can usually tell who wrote
a particular line of code within the projects I work with.

It is disingenous to pretend that writing software is a pure robotic activity
that can be separated from its humanity.

~~~
plonh
There used to be a concept called "professionalism" where people didn't let
their personal cultural biases crowd out contributors, and people applied
their humanity problem at hand at work, and engaged in unrelated conversations
on breaks and after work, not disrupting people who are working on the
project.

------
ilaksh
The traditional socializing gets in the way. Making protocol working groups
and manually implementing them. Or meeting at conferences to decide things.

The modern approach to contrast is a semantically versioned registry like npm.
The next step is to do something similar with web assembly that can handle
many programming languages.

