I think it’s weird that I have to write this post in 2015, but earlier today I had to explain to someone with the technical skills to submit a good patch that he was doing the process wrong in some basic and extremely annoying ways.
Googling revealed that most explanations of patch etiquette are rather project-specific in their advice. So I’m going to explain the basics of patch submission that apply to just about any open-source project, with a focus on how to do it right when you aren’t a regular committer (that is, it’s what’s often called a drive-by patch). Here we go…
Earlier today I was in an email exchange with a Tier 1 tech support guy at a hardware vendor who makes multiport serial boards. I had had a question in as to whether a particular board supported the Linux TIOCMIWAIT ioctl. Tier 1 guy referred the question to an engineer in their Linux development group, and Tier 1’s reply to me happened to include his email chain with the engineer.
The engineer wrote to Tier 1 “Is that Eric Raymond ‘ESR’? He’s a big deal in open-source circles.” This made me smile, because when I get made that way it usually means the engineer’s going to work rather harder to make me happy than he would for some random. This is helpful to get my work done!
But there is a duty which is the flip side of that privilege, and that’s what I’m here to write about today. Because if you are reading this at all, your odds of becoming a geek-cred certification authority someday are higher than average, and if that happens, it’s better if you consciously understand what you ought to be doing.
I think Terry Pratchett’s death finally hit home for me today. I’ve been kind of numb about it before now, but today I learned abut this proposal for GNU Terry Pratchett. And as I was commenting about it on G+ I found myself crying.
Here’s a very slightly improved version of what I said on G+. I don’t think I knew Terry well enough to give him the tribute he really deserved, so this will have to do.
An incredibly shrinking Firefox faces endangered species status, says Computerworld, and reports their user market share at 10% and dropping. It doesn’t look good for the Mozilla Foundation – especially not with so much of their funding coming from Google which of course has its own browser to push.
I wish I could feel sadder about this. I was there at the beginning, of course – the day Netscape open-sourced the code that would become Mozilla and later Firefox was the shot heard ’round the world of the open source revolution, and the event that threw The Cathedral and the Bazaar into the limelight. It should be a tragedy – personally, for me – that the project is circling the drain.
Instead, all I can think is “They brought the fate they deserved on themselves.” Because principles matter – and in 2014 the Mozilla Foundation abandoned and betrayed one of the core covenants of open source.
I just read Okay, Feminism, It’s Time We Had a Talk About Empathy. and When Nerds Collide.
I’m caught between admiration for Meredith Patterson’s writing ability and what she’s trying to do, and a feeling that the attempt is fundamentally doomed.
I’ve just had an insight I find a bit disturbing. Though perhaps I shouldn’t.
Occasionally I visit Scott Alexander’s excellent and thoughtful blog, Slate Star Codex. Today’s entry reminded me of Laurence Iannaccone’s research on Sacrifice and Stigma, which argues that onerous religious requirements are effective ways of building in-group trust because they are commitment signals that are difficult to fake.
It occurred to me to wonder: do hackers do this? And…I think we do.
How To Learn Hacking: Version 1.2, with a new section on being original. Incorporates more feedback from here and G++
For those of you who wondered why this didn’t just become a major section in How To Become A Hacker, it’s because I think it might become long enough to make that document too bulky to read at one sitting.
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.
In Solving the CVS-lifting problem and Announcing cvs-fast-export I described how I accidentally ended up maintaining two different CVS-to-something-else exporters.
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?