Finally. After ten months of work, it’s done. Emacs is fully converted to git. You can clone from git://git.sv.gnu.org/emacs.git and if you have commit rights you can push to it and the changes will stick. The bzr repo is still up but only as an archive.
Lately I’ve been wrestling with various members of an ancient and venerable open-source development group which I am not going to name, though people who regularly follow my adventures will probably guess which one it is by the time I’m done venting.
Why it so freaking hard to drag some people into the 21st century? Sigh…
I’m almost 56, an age at which a lot of younger people expect me to issue semi-regular salvos of get-off-my-lawn ranting at them. But no – I find, that, especially in technical contexts, I am far more likely to become impatient with my age peers.
A lot of them really have become grouchy, hidebound old farts. And, alas, it not infrequently falls to me to be the person who barges in and points out that practices well-adapted for 1995 (or, in the particular case I’m thinking of, 1985) are … not good things to hold on to decades later.
Why me? Because the kids have little or no cred with a lot of my age peers. If anyone’s going to get them to change, it has to be someone who is their peer in their own perception. Even so, I spend a lot more time than seems just or right fighting inertia.
Young people can be forgiven for lacking a clue. They’re young. Young means little experience, which often leads to unsound judgment. It’s more difficult for me to forgive people who have been around the track often enough that they should have a clue, but are so attached to The Way It’s Always Been Done that they can’t see what is in front of their freaking noses.
This landed in my mailbox yesterday. I reproduce it verbatim except for the sender’s name.
> Dear authors of the RFC 3092,
> I am writing this email on behalf of your Request For Comment “Etymology of
> ‘Foo’.” We are currently learning about the internet organizations that set
> the standards of the internet and our teacher tasked us with finding an RFC
> that was humorous. Me and my two friends have found the “Etymology of
> ‘Foo'” and have found it to be almost as ridiculous as the RFC about
> infinite monkeys; however, we then became quite curious as to why you wrote
> this. Obviously, it is wrote for humor as not everything in life can be
> serious, but did your manager task you to write this? Are you a part of an
> organization in charge of writing humorous RFC’s? Are you getting paid to
> write those? If so, where do you work, and how may we apply? Any comments
> on these inquiries would be greatly appreciated and thank you in advance.
> XXXXXXXXXXXXXX, confused Networking student
I felt as though this seriously demanded a ha-ha-only-serious answer – and next thing you know I was channeling Master Po from the old Kung Fu TV series. Reply follows…
When I have to explain how real hackers differ from various ignorant media stereotypes about us, I’ve found that one of the easiest differences to explain is transparency vs. anonymity. Non-techies readily grasp the difference between showing pride in your work by attaching your real name to it versus hiding behind a concealing handle. They get what this implies about the surrounding subcultures – honesty vs. furtiveness, accountability vs. shadiness.
One of my regular commenters is in the small minority of hackers who regularly uses a concealing handle. Because he pushed back against my assertion that this is unusual, counter-normative behavior, I set a bit that I should keep an eye out for evidence that would support a frequency estimate. And I’ve found some.
There’s a documentary, The Hedgehog and the Hare, being made about the prosecution of Andrew Auernheimer (aka “the weev”). The filmmaker wants to interview me for background and context on the hacker culture. The following is a lightly edited version of the backgrounder I sent him so he could better prepare for the interview.
The responses to my previous post, on the myth of the fall, brought out a lot of half-forgotten lore about pre-open-source cultures of software sharing.
Some of these remain historically interesting, but hackers talking about them display the same tendency to back-project present-day conditions I was talking about in that post. As an example, one of my regular commenters inferred (correctly, I think) the existence of a software-sharing community around ESPOL on the B5000 in the mid-1960s, but then described it as “proto-open-source”
I think that’s an easy but very misleading description to land on. In the rest of this post I will explain why, and propose terminology that I think makes a more useful set of distinctions. This isn’t just a historical inquiry, but relevant to some large issues of the present and future.
I was a historian before I was an activist, and I’ve been reminded recently that a lot of younger hackers have a simplified and somewhat mythologized view of how our culture evolved, one which tends to back-project today’s conditions onto the past.
In particular, many of us never knew – or are in the process of forgetting – how dependent we used to be on proprietary software. I think by failing to remember that past we are risking that we will misunderstand the present and mispredict the future, so I’m going to do what I can to set the record straight.
I did something unusual today. I pulled the plug on one of my own projects.
I finally got enough round tuits to put together two-thirds of the head-to-head comparison I’ve been meaning to do – that is, compare the import-stream output of cvs-fast-export to that of cvsps to see how they rate against each other. I wrote both git-stream output stages, so this was really a comparison of the analysis engines.
I wasn’t surprised which program did a better job; I’ve read and modified both pieces of code, after all. Keith Packard’s analysis engine, in cvs-fast-export, is noticeably more elegant and craftsmanlike than the equivalent in cvsps. (Well, duh. Yeah, that Keith Packard, the co-architect of X.)
What did surprise me was the magnitude of the quality difference once I could actually compare them head-to-head. Bletch. Turns out it’s not a case of a good job versus mildly flaky, but of good job versus suckage.
The comparison, and what I discovered when I tried to patch cvsps to behave less badly, was so damning that I did something I don’t remember ever having felt the need to do before. I shot one of my own projects through the head.
Last night, in an IRC conversation with one of my regulars, we were discussing a project we’re both users of and I’m thinking about contributing to, and I found myself saying of the project lead “And he’s German. You know what that means?” In fact, my regular understood instantly, and this deflected us into a discussion of how national culture visibly affects hackers’ collaborative styles. We found that our observations matched quite closely.
Presented for your amusement: Three stereotypical hackers from three different countries, described relative to the American baseline.
Every few months I get a letter from a would-be hacker petitioning me to accept him (always a “him” so far) as my disciple. Happened again today; I think this time I’ll share part of the request, and my response, so I have it to point to next time this happens.
My usual audience is well aware why I am qualified to review Gabriella Coleman’s book, Coding Freedom, but since I suspect this post might reach a bit beyond my usual audience I will restate the obvious. I have been operating as the hacker culture’s resident ethnographer since around 1990, consciously applying the techniques of anthropological fieldwork (at least as I understood them) to analyze the operation of that culture and explain it to others. Those explanations have been tested in the real world with large consequences, including helping the hacker culture break out of its ghetto and infect everything that software touches with subversive ideas about open processes, transparency, peer review, and the power of networked collaboration.
Ever since I began doing my own ethnographic work on the hacker culture from the inside as a participant, I have keenly felt the lack of any comparable observation being done by outsiders formally trained in the techniques of anthropological fieldwork. I’m an amateur, self-trained by reading classic anthropological studies and a few semesters of college courses; I know relatively little theory, and have had to construct my own interpretative frameworks in the absence of much knowledge about how a professional would do it.
Sadly, the main thing I learned from reading Gabriella Coleman’s new book, Coding Freedom, is that my ignorance may actually have been a good thing for the quality of my results. The insight in this book is nearly smothered beneath a crushing weight of jargon and theoretical elaboration, almost all of which appears to be completely useless except as a sort of point-scoring academic ritual that does less than nothing to illuminate its ostensible subject.
This is doubly unfortunate because Coleman very obviously means well and feels a lot of respect and sympathy for the people and the culture she was studying – on the few occasions that she stops overplaying the game of academic erudition she has interesting things to say about them. It is clear that she is natively a shrewd observer whose instincts have been only numbed – not entirely destroyed – by the load of baggage she is carrying around.
Today’s very special non-world-ending software release, triggered if not originated from here at Eric Conspiracy Secret Laboratories is the amazing Zen simulation, Robot Finds Kitten. I bow in respect before Leonard Richardson and the other giants of kitten-finding history and am humbly proud to be counted among the select few who have contributed to this monumental, er, monument.
Get yer hot fresh tarball right here. It will improve your sex life, clear up your financial problems, cure your acne, and make you as a god among men. Would I lie?
I nearly issued a forking threat a few minutes ago. Only the second time I’ve felt a need to do that and the first was in 1993, so this is not something I do casually. And I drew back from the brink.
But I may have to if the maintainer I’m dealing with doesn’t clean up his act. His library is critical to one of my projects, but his behavior has been increasingly sloppy and erratic lately. He made a serious design mistake which he’s been trying to paper over with kluges; the kluges have made the code unstable and the latest shipped version is actually broken to the point of unusability without a patch.
I learned a new way of thinking about social behavior at Agile CultureCon last week – Dave Logan’s taxonomy of tribal stages and his interestingly specialized notion of what a “prophet” is. For review, see Logan’s TED talk.
Logan explains the distribution of tribal stages as follows: Stage 1, “Life Sucks”, is the violent and profoundly dysfunctional tribalism of gangs and prisons (approximately 2% of tribes); Stage 2, “My life sucks”, is bureaucracy (about 22% of tribes); Stage 3, “I’m great (but you’re not)!” is most of business and academia (about 48% of tribes); Stage 4: “We’re great!” is where you start to see serious creativity, tribal self-awareness, and collective sense of mission (about 22% of tribes); and Stage 5 “Life’s great!” is high-creative behavior totally driven by values rather than ego or struggle against some adversary (about 2% of tribes).
A “prophet”, in Logan’s model, is somebody who expresses the deepest shared values of a tribe and invites people in it to change stage (and fuse with other tribes at the new stage). Because most people, most of the time, live in tribes with a stage 3 culture, the most common upward transition (and the most common kind of prophet) is from stage 3 to stage 4.
I noted in a previous post that hearing this in a talk made the hair on the backs of my arms stand up. Because I have lived through, and was one of the prophets of, the hacker culture’s transition from largely unconscious mixed stage-3/stage-4 to fully conscious mostly Stage 4 behavior (“We’re great!”) in the 1990s.
But. I am by no means sufficiently ignorant or egotistical to think I was our only prophet. Most obviously there was Richard Stallman a decade before me, issuing a stage 4 call to higher values around “free software”. But because I was a historian before I was a prophet, I can’t really stop there. I find myself asking who the earlier prophets were!
My last four days, at the Agile CultureCon split between Philadelphia and Boston, have thrown more new ideas and techniques at me than I’m used to encountering in a normal four months. Or more. It was very challenging and exciting, the more so because I was immersed in a culture at some distance from those where I usually hang out.
The organizers (Dan Mezick & Andre Dhondt) and various friends (now including me) are launching from agile software development into new ways of organizing work and communication that dynamite a lot of common assumptions about the necessity of power relationships and hierarchies. What makes this really interesting is not the theory but the working examples. They’re not dealing in vague platitudes, but in methods that can be taught and replicated. (And yes, I will describe some of them later in this post.)
Nobody in this crowd thinks politically (or at least if they do, it doesn’t show); it’s all framed as ways to fix corporate cultures to make them more productive and happier. But what this was, underneath occasional freshets of vaguely new-agey language, was a three-day workshop in practical anarchy.
One of my commenters reports that he showed my essay on evaluating the harm from closed-source software to Richard Stallman, who became upset by it. It shouldn’t be news to RMS or anyone else that I think he’s a fanatic and this is a problem, but it seems that every few years I have to explain the problem again. I make the effort not because of personal animus but because fanaticism does not serve us well – we’ve made huge progress since 1998 by not repeating RMS’s mistakes, and I think it’s important that we continue not to replicate them.
Some people are obsessive about never using closed-source software under any circumstances. Some other people think that because I’m the person who wrote the foundational theory of open source I ought to be one of those obsessives myself, and become puzzled and hostile when I demur that I’m not a fanatic. Sometimes such people will continue by trying to trap me in nutty false dichotomies (like this guy) and become confused when I refuse to play.
A common failure mode in human reasoning is to become too attached to theory, to the point where we begin ignoring the reality it was intended to describe. The way this manifests in ethical and moral reasoning is that we tend to forget why we make rules – to avoid harmful consequences. Instead, we tend to become fixated on the rules and the language of the rules, and end up fulfilling Santayana’s definition of a fanatic: one who redoubles his efforts after he has forgotten his aim.
When asking the question “When is it wrong (or right) to use closed-source software?”, we should treat it the same way we treat every other ethical question. First, by being very clear about what harmful consequences we wish to avoid; second, by reasoning from the avoidance of harm to a rule that is minimal and restricts peoples’ choices as little as possible.
In the remainder of this essay I will develop a theory of the harm from closed source, then consider what ethical rules that theory implies.
That is: having noticed that open-source volunteers now have a large and increasing role in maintaining critical shared infrastructure like the Internet, is there a sustainability issue here? Once the old guard who were involved in the early days (people like Jim Gettys and Dave Taht and myself) dies off, are we going to be able to replace them?
I shall set forth my reasons for optimism.
During the last few years I’ve noticed a change in the meaning of my life – well, my life as a hacker, anyway. I had an exchange on a mailing list last night that made me think it’s not just me, that the same change has been sneaking up on a lot of us.
It’s part of the hacker ethos to (as Alan Kay put it) predict the future by inventing it – to playfully seek solutions to problems people outside our culture are not yet even thinking about. We still do that, and I think we always will.
But increasingly, as the world of pervasive networks and ubiquitous computing hackers imagined decades ago has become reality, we’re not just the innovators who thought of it first. Now we’re responsible; having created the future, we have to maintain it. And, as the sinews of civilization become ever more dependent on the Internet and software-intensive communications devices, that responsibility gets more serious every year.
This makes for a subtle change in our duties and our relationship to our work – a gradual shift from merry prankster to infrastructure gnome.