Eric S. Raymond's Blog, page 57

irker 1.0 (a functional CIA replacement) is shipped

OK, I’ve been hacking intensely for most of the last 24 hours and here’s the payoff: irker-1.0 is shipped. Code and documentation are at http://www.catb.org/esr/irker/.

Out of the starting box we have a hook script with tested support for git and (rather clumsily) Subversion; hg should be a piece of cake for anyone who wants to step up. Forge-site operators can begin installing the relay daemon and the repo hook immediately, and should do so.

Coming soon: a long essay I’ve been sitting on analyzing the now-dead CIA service as a case study in over-engineering. It’s not really very surprising that it collapsed under its own weight.

Also note that there is an XML-RPC proxy for people who have limited ability to change their hook scripts. I haven’t looked at the code myself but there’s a pointer in the irker README file.

An emergency replacement for the CIA service is coming.

A few hours ago I learned that, due to a virtual-server mishap, the cia.vc notification service is dead. And not coming back.

This was not entirely unexpected. The CIA codebase was a shambles, the service has been flaky and subject to outages, and the server-site operator who inherited it has for some time been muttering darkly that the end was probably nigh.

I’ve been sitting on a lightweight replacement for CIA since late August, holding off shipping until it was clear whether or not a salvage effort on the codebase was going to succeed. That option is off the table now, so I’m going into emergency overdrive to get a release out.

The main thing that still needs to be done is for me to finish and test a hook script for git repos, so that when I ship the admins at places like SourceForge and GitHub will be able to drop in both a server instance and the correct hook code. This script will also be a model for hooks serving other VCSes such as Mercurial, Subversion, and (ugh) CVS.

I’m working on that now and expect to ship within 48 hours. Watch this space.

Practical prophecy

Inspired by Dave Logan’s keynote on tribal leadership at AgileCultureCon, I did a breakout session and then an open-space followup on “Practical Prophecy 101″.

Recall that in Logan’s terms a “prophet” is a person who moves the behavior of his tribe towards greater cooperation and creativity by (his words) “preaching the inevitability of values-based change”.

Venessa Miemis took notes on my talk. Here’s a lightly edited and expanded version of those notes. In each item I have replayed a quote of mine that she recorded; where appropriate I have expanded a little on the thinking behind it.

1. Right names are powerful

“Shaping the vocabulary and linguistic map of a culture (what postmodernists call its “discourse”) is a particularly effective way to re-engineer it.”

“One of the most effective ways to shape the discourse of a culture is to find a concept that is central to it but unarticulated, and give it a name.”

Christine Peterson and I did this in 1998 when she proposed the term “open source” in 1998 and I popularized it. I believe the reason the transition in majority usage from “free software” happened so rapidly (over about the following 4 months) is that the semantic field of “open source” was a better fit to what most hackers wanted from their effort than the pre-existing “free software”.

I guess the more general advice for would-be prophets is to look for terms of art in your culture that don’t quite fit, that lots of people have spoken or unspoken reservations about. If you can invent better terms, resolving that emotional tension and discomfort will become energy for your cause.

2. Find the Deepest Yearning

“Cultural engineering works best when you are nudging a culture in a direction it wants to go anyway, but hasn’t yet found the right terms to express. If you find what the people in your culture hunger for and articulate it, you will gain power to shape that culture.”

The other side of this coin is well expressed by a quote from Lao-Tzu: “The wicked leader is he who the people despise. The good leader is he who the people revere. When the best leader’s work is done, the people say, ‘we did it ourselves!’” The true depth of that quote, I think, is that the people are not wrong to think that – the best leader unleashes the creative potential of his tribe, directing only to the minimum degree required to get the tribe’s mission done.

3. Use Cultural Capital

“Cultural engineering works best when it has a stratum of preexisting cultural capital to build on. Can you find or co-opt such a base?”

What I had in mind here as an example was the rather large stock of cultural capital that hackers own – the joke RFCs, the Jargon File, stories about famous hackers, other things of that sort.

The agile tribes don’t have nearly as rich a stratum to build on yet. Which is a problem for them, because it makes acculturating people a more difficult and chancy process. I was intending to suggest that they need to discover or create such capital.

“Technologies acquire meaning and transformative power through stories people tell themselves about their use cases.”

My favorite example of this is that the Maya had the wheel – but they only used it for children’s toys! They had no narratives or metaphors that connected the wheel with the idea of transportation or travel. This seems incomprehensible to Europeans because those narratives have been embedded in Old World cultures since our early Bronze Age, but the example of the Maya demonstrates that this is not an inevitable development.

4. Change behavior before theory

“Co-opting people is more effective than moralizing at them. Give people selfish reasons to behave the way you want them to; their beliefs will follow. Outside the tiny minority of people neurally wired to be intellectuals this works much better than trying to change beliefs first.”

5. Give people permission to be idealists.

(Venessa had this header attached to the next item.)

My gloss on Logan’s definition of a prophet as “preaching the inevitability of value-based change” is that a prophet gives people permission to be idealists – to believe and feel as though their work has a larger meaning than they have understood before, that it connects to history, that it’s part of a vast and wonderful story.

Humans have a strong need to belong – to form tribes, chase ideals, partially submerge their individual identies in something larger. Manipulating this need can lead to great evil (from mob violence up to totalitarian societies) so it’s something we need to be ethically very careful about. Still, a prophet who can harness this effect can achieve good outcomes.

When I’ve been troubled about whether I was using this effect ethically, the question I’ve always asked myself was “Am I increasing individuals’ options or decreasing them?” A prophet who uses this desire-to-belong to impose a narrowing vision of right conduct on others is doing wrong; a prophet who opens up possibilities, giving people more different ways to create meaning in their lives, is doing right.

6. Steer by your values

“Your ability to steer for specific results will be limited. When you don’t know where or how to aim, [speak and] act in accordance with your highest values. As a matter of self-protection, you must develop and maintain clarity about what those values are.”

Developing and maintaining this kind of clarity isn’t necessarily easy. A lot of people have trouble telling the difference between what they actually want and what social conditioning tells them they should want. If you want to be an effective prophet, you have to get shut of this sort of confusion.

And it’s not just self-protection. Because human beings are actually quite good at detecting deception and dissimulation, truth – speaking what one believes with honesty and passion – is the most powerful form of persuasion. The most effective prophets are those who wield overwhelming sincerity and pureness of purpose like a weapon. Pureness of purpose requires an exact consciousness of one’s goals and values.

Sincerity, alas, does not guarantee that the content of a prophet’s message is good or even sane. That problem, however, is beyond the scope of this essay.

Who were the prophets of the early hackers?

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!

I think I’ve identified one. Remember that technical excellence is not sufficient; a prophet has to be a person who speaks the desires and deep values of the tribe around him, and enlarges it by forming links with other tribes which then fuse together, displaying a higher stage of behavior.

(Logan is not very explicit about the fusing part; he notes that it happens and is an important function of tribal leadership, but in none of his talks does he get explicit about the fact that fused tribes must frequently crack the Dunbar limit. I mean, if a prophet fuses two large and individually successful tribes that are each hanging out near the Dunbar limit of population, this has to happen.)

So, thinking about this in the context of the hacker culture, the pre-RMS name that jumps out at me is Larry Wall, the inventor of Perl and the patch utility, in the early 1980s. Then and now, he has spoken in prophetic terms about art, beauty, play, and service to others. In retrospect it seems to me that the early Perl hackers were among the first of our subtribes to start exhibiting Stage 4 “We’re great!” most of the time, following Larry into that.

Larry is the first prophet I think I can definitely identify in our tradition. But that may only be because in the early 1980s I was a relative n00b and possibly not clued in enough to notice other prophets operating at more social distance from me. Various questions occur to me:

The IETF. I’m certain I saw it exhibiting stage 4 behavior in 1983, when the leaders of what was then the Network Working Group egolessly processed my one-sentence demolition of their plan to abolish the functional domains. If that had been a stage 3 tribe they’d probably have just booted the smart-alec kid I then was out of the room.

So, who was their prophet; who, in that tribe, said “We’re great!” and lifted them out of stage 3? My suspicions fall on Jon Postel or Fred Baker, but I don’t know enough about the early IETF to be sure.

Who were the prophets of the Model Railroad Club and MIT AI Lab, 1959-1969? Was one of them RMS in an earlier phase of his life? I’m trying to reach Slug Russell so I can ask relevant questions.

Oddly, I’m not sure I can identify a prophet in the early Unix tradition. It’s possible that whole crew was already at Stage 4 when Ken Thompson had his brainstorm – collaboration, playfulness and high creativity certainly seem to have been already well-established traits of the Bell Labs culture when Unix incubated.

I throw this one open to my readers. Where is there evidence of other early Stage 4 transitions in the various subtribes that eventually amalgamated into today’s open-source culture? In what cases can we identify a prophet, the person who said “We’re great!” and made people believe it?

Culture hacking, reloaded

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.

Pulling me in was the result of a nearly last-minute brainstorm by Dan Mezick, who is a leading figure among agile-development coaches in the Boston area. He approached me by email a few weeks ago reporting that he’d read How To Become A Hacker and considered it (his words) “foundational wisdom”. It gave him the idea that my experience of articulating and shaping the hacker culture might be useful information for what the would-be culture-hackers at the conference are trying to do.

(Dan didn’t know when he decided to invite me that the hacker-culture connection with agile development goes right back to agile’s beginnings. I had been invited to the Snowbird gathering where the Agile Manifesto was hammered out in 2001, and if not for a schedule conflict I almost certainly would have been one of the signatories myself. My occasional conversations with people like Kent Beck and Martin Fowler have since confirmed that other signatories were pretty strongly influenced by my articulation in 1997-1998 of of what the hacker culture had been doing. So, in one important sense, the hacker culture is part of agile’s ancestry.)

Their initial problem, as Dan puts it, is that so far agile development hasn’t been scaling very well. Techniques like unit testing and TDD, design by story, pair programming, scrum, planning poker and the like have amply proven themselves at the small-group level (up to, say, a dozen developers). Properly applied they do boost the hell out of the effectiveness of product teams. But evidence that they can be scaled up effectively to much larger projects or coordinated enterprise-wide development is lacking. Dan sees a lot of snake oil being peddled under the “enterprise agile” label, and he doesn’t like it.

So what has gone wrong? Why aren’t agile techniques scaling? Takes no genius to diagnose that problem: agile, trying to scale up from the bottom, collides with the top-down-imposed conventional corporate habits of death marches, rigid hierarchy, and waterfall planning. And loses, because the imperatives behind all that sludge are wired too deep into the culture of most corporations to be displaced by mere productivity improvements, however dramatic.

Where Dan and Andre and their friends get radical is in the cheerful conclusion that conventional corporate culture needs to be blown up – or, to put it more diplomatically, re-engineered to enable higher productivity. Where they get effectively radical is that they’re not willing to stop at slogans and exhortation. Instead, they want to write a how-to manual. How to meme-hack your corporation so it’s not wasting most of its energy on authoritarian bullshit and territorial games, how to make it a place where more value is added and people are happier. Oh, and where agile techniques can be applied throughout.

The conference had some noise and nonsense in it, including one fuzzy-sweatered wack-job who wasn’t ignored as roundly as she should have been. But with that filtered out, the theme was very clear: we need to learn how to change the cultures that hold people and productivity back so they’ll stop doing that. This is a larger mission than simply “make agile development work” and potentially a far more transformative one.

The contrast with the hacker culture is interesting. We opted out and formed our own big tribe, with members in but not of the places where they work; later (after 1997) we built bridges back to the corporate culture from outside it. The agile people were, in a way, braver than us – they never left and never formed a big tribe of their own; instead, they’ve been trying to reform the corporate/institutional world from within, operating as a whole bunch of parallel microinsurgencies with some common ideas but not a lot of sense of shared purpose.

Well, up to now, anyway. Dan asked me in because he thought the experience of the hacker culture might be relevant, and – it is. Because what this conference showed me is that the agile folks are beginning to struggle their way through the same transition we went through between 1990 and 1998. Once again, I see a culture that had been diffuse, mostly unconscious and local trying to wake up. Thinking about shared purpose; moving from craft practice to intentional technique; asking itself questions about what the things it does mean in a larger context – and beginning to find answers.

Dave Taht (aka Dave in my basement) was along with me on this anthropological journey and disagrees. He thinks these people are at a much earlier stage corresponding to us in the 1970s, because they don’t yet have as much shared cultural capital to build on. He’s got a point; they don’t have a significant common corpus of slang or jokes or hero stories – there’s no agile-culture analog of the Jargon File or the joke RFCs.

For good or ill, they also have no equivalent of the Free Software Foundation. That is, there haven’t been any previous attempts to create a unifying “what we’re about” that didn’t take on the majority of people in the culture. Their one previous try, the Agile Manifesto, was a success at least at naming the movement and articulating very broad principles. In effect, they got their “agile” equivalent of the term “open source” a decade before fully understanding their mission, rather than after that awareness had already developed as happened with us.

Still, the parallels are powerful. People there ate up the material I brought about advocacy tactics and meme-hacking and leadership (about an hour and fifteen minutes split over three 25-minute sessions) and clearly thirsted for more. My value to them was that I had already successfully pulled off culture hacks on a large scale at least twice – and could explain how I had done it.

Since my blog audience mostly knows that story already I won’t rehearse any of it here, but rather write about what I learned from the interaction.

I’ll start with something relatively simple. I got enough exposure to agile techniques during this conference to figure out something I’d been puzzled about for a while. I knew that the Agile Manifesto described values very similar to those of the hacker culture. I also knew that wasn’t accidental. I also knew that some agile practices – notably unit testing, test-driven development, and design by story – have easily been absorbed and naturalized by hackers. But others (pair programming and scrum, for example) have not been. And I have wondered why this is. The separation between hackers and agile developers seems largely a matter of historical accident, so why has the cross-fertilization not gone further?

The answer is not complicated and perhaps I should have seen it sooner. Most of the agile stuff is designed to improve the quality of the interactions within teams that meet face to face and have stable membership. The hacker culture, on the other hand, evolved to support remote teams in which partipants commonly never meet each other and membership is unstable. The agile techniques we’ve picked up on are precisely those that can be applied in our communications environment.

When I describe the typical workflow of an open-source project to these people they tend to look like they’ve been hit by a truck. Almost all communication by email and IRC, with only sporadic use of even voice phones? People join projects and cooperate for years without ever meeting each other? We take drive-by patches from people who pop up once, then disappear and are never heard from again? How can that possibly work?

One thing that got through to them and stimulated a lot of talk and thought is the idea that how far inside you are on a project is defined by whether and how frequently you push commits to the project’s repository. More generally, we nowadays define membership in the hacker community basically by who is pushing commits to public repositories (yes, I noted that the criteria used to be fuzzier and there are some interesting exceptions and edge cases).

Several people responded to this by observing that the agile community doesn’t have this objective kind of in/out criterion because it doesn’t have shared projects, and mused that maybe it needs to start some.

But let’s get to the fun stuff. Some of the techniques the agile people are playing with and thinking about now make me wonder “how can that possibly work?” But I’ll start with the easy ones.

The problem all of these are aimed at solving is that coercion and power hierarchies waste huge amounts of time and energy, block an organization’s ability to learn, do needless harm to people, and squander resources that could otherwise be turned into productive outcomes. Evil is not just evil, it’s stupid! Not being stupid pays off, therefore not being evil pays off. These are ways to not be stupid.

Before the conference, Dan educated me about the Core Protocols. This is a set of communications practices to be used among humans that are designed to suppress a lot of the bullshit and primate politics that commonly get in the way when we try to do and decide things together. I got to see and use them both by email with Dan and face-to-face in groups at the conference.

The Protocols have at least two results. One is to create psychological safety, largely by guarding the right of participants to opt out of a transaction rather than be subjected to power trips or other forms of manipulation. Another is to make it easy for participants to model each others’ intentions and desires. The consequence is that groups using them can learn more effectively and make good decisions more rapidly.

The Core Protocols are very clarifying – that much is obvious to me even from limited exposure. One of the authors calls them “software for your head”, and they’re a building block that can be used with other kinds of software for your head, including ways to re-invent how we organize groups larger than will fit in a single meeting room.

Two of these got an airing at the conference. One, actually the less radical one, is a kind of organizational design called sociocracy. Yes, I know the name is horrible – actually, its English-speaking practitioners agree it’s horrible, but think they’re stuck with it for historical reasons. No, it’s not socialist or anything like socialist; in fact, a core part of the theory is concerned with using free-market incentives to reward efficient collective behavior by the members of sociocratic organizations.

A sociocratic organization consists of a set of interlocking working circles. The rules of interaction within circles are constructed to support egalitarian behavior within the circle, suppressing normal primate-political bullshit through means recognizably similar to the Core Protocols (they also include interesting procedures for supporting consensus-based decision-making). There is expected to be a control hierarchy among the circles, but the damaging effects of the power relationships that sets up are mitigated by a clever hack called “double linking”.

Each circle has an operational leader appointed by the parent circle it reports to, and each circle has an elected representative to the parent circle, but they are not allowed to be the same person. The pass-requirements-downwards function is disconnected from the report-problems-upwards function.

There’s a Discordian maxim called the “SNAFU Principle” states that true communication is only possible between equals – because where there is a power asymmetry the inferior will tend to tell the superior what the superior wants to hear, and the superior will tend to tell the inferior only that which preserves his superiority. In hierarchical organizations the SNAFU effect leads to a progressive disconnection of decision-makers from reality as information passed up and duwn the command chain becomes progressively more distorted by this effect.

Sociocratic double-linking is a clever pre-emptive strike against the effects of the SNAFU principle. The existence of a reporting chain separated from command authority at least removes much of the normal incentive for command chains to distort information passing between levels.

There’s still hierarchy in the system, though. The more radical path is to flatten the firm entirely – no bosses, no subordinates, not even sociocratic circles. And this is just what two of our presenters, from a firm called Morning Star, told us about.

At Morning Star, they practice “self-management”. Your job isn’t defined by who you report to, but by your commitment agreements with your colleagues. In effect, everyone in the firm has horizontal contracts with other firm members. The business runs on a painstakingly-maintained process model and objective performance indicators. The contracts include performance targets, and your pay is tied to how you meet them. More details in the book Beyond Empowerment, which lightly fictionalizes the history of Morning Star and then presents supporting factual case studies.

Morning Star must be doing something right – it’s the top company in its market niche and robustly profitable. And it’s far from what most people would think of as the best case for radical experiments in corporate governance – capital-intensive manufacturing using a lot of unskilled seasonal labor. But perhaps the most intereresting thing about Morning Star’s organization is that they’ve scaled it past the Dunbar Limit.

Sufficiently small groups with sufficiently good leadership can make almost any theory of organization work. But human beings have only a limited ability to scoreboard the behavior of acquaintances, which tops out at the Dunbar limit of about 150. Above that size more formal lines of authority and obligation become necessary. Or so goes the theory, anyway. Morning Star seems to be a counterexample.

I shall finish my report by noting that I learned a new way to think about prophecy. Well, a specific and interesting meaning of the word “prophet”, anyway. This was at a keynote address by one David Logan, who has spent years studying what he calls “tribal leadership” – his “tribes” being social networks – usually (though not always) below the Dunbar size limit.

In Logan’s analysis, a firm – or an entire society – is best understood as a mosaic of interlocking tribes, each with its own microculture. Logan distinguishes five culture types or stages: Stage 1 = “Life sucks”, Stage 2 = “My life sucks”, Stage 3 = “I’m great (and you’re not)!”, Stage 4 = “We’re great!”, and Stage 5 = “Life is great!”. The whimsical titles conceal some heft; see Logan’s TED talk about how tribes evolve (or fail to evolve) from the highly dysfunctional Stage 1 (normally found only among criminals) to the high-creative Stage 5.

In Logan’s model, a “prophet” is a person who moves a tribe from one stage to another by – and this is what caught my attention – “preaching the inevitability of values-based change”. If this were a movie, tension-inducing music would be starting to play…

To do this, the prophet first has to understand what the tribe actually wants. Tribes form in the first place because of an alignment of values. The alignment may be around something trivial like rooting for a sports team, or something functional like doing a particular job, or something more profound like a shared aesthetic or political idea.

The point is a tribe does, at least epiphenomenally, want something. But (the music is getting louder) not every tribe knows what it wants. The shared desire and values may be partly or wholly unconscious, and point to something larger than the tribe understands. The prophet’s job is to reflect the tribe’s values back at it in such a way that it changes stage – wakes up and starts to function at a higher level.

At this point in the exposition hairs are beginning to stand up on my arms. It only gets spookier when he talks about tribes organically growing their own prophets out of themselves to transform themselves – exactly expressing the feeling I’ve often written about that the hacker culture created me in order to be able to see itself better.

And what does a prophet do to transform the behavior of a tribe? He tells stories about what it was, is, and might be. He reminds people in it who they are. And this is the point at which I’m muttering I’ve been here. This guy is talking about me. I never thought of myself as a “prophet” before – I preferred to leave that kind of imagery to RMS – but it is undeniably true that I’ve written mystical poetry for hackers.

Huh. So other tribes create their own equivalents of “ESR”, do they? Interesting. Never thought about that before either. Perhaps we could form a mutual-support group for extruded polyps of group consciousness. Or something.

I was so energized by Logan’s keynote that when Dan Mezick told me he had an open session slot because a speaker had canceled it I stormed into it and delivered an extended rant on practical prophecy 101 – not just what a prophet does but how to do it. With major tactics like giving things the right names as a source of power. Dave Taht recorded at least part of that talk; might be it will make it onto the net.

There’s lots more I was originally going to write about – the epic of the party bus that linked the Philadelphia and Boston halves of the conference, for example, and some of the very colorful people I met, and the exciting beginning of our attempt to create a culture-hacker’s manifesto which I think might someeday be considered as important as the Open Source Definition.

But, on reflection, this report has been mostly about ideas, and I think I want to keep it that way rather than wandering further off into personal narrative, no matter how interesting that might be.

So I’ll finish by repeating that I think these are really important ideas. I’m glad I was there for this beginning; there are, I think, many more discoveries ahead of us on this path.

We may yet succeed in culture-hacking not just individual institutions but society as a whole into something saner, kinder, less hierarchical, and more productive on all levels. It’s worth a good try, anyway.

From Dave in my basement, redux

Dave Taht is crashing in my basement again. While he’s here Dave is planning to cut another release of CeroWRT (the third one to issue from this basement, actually), and he has decided it needs a name.

And, well, “the release from ESR’s basement” just lacks a certain…zing.

Obviously, this means my basement needs a name. Something it probably should have acquired sooner, actually, as it is a rather storied locale. Often a resting place for traveling hackers weary of the wars; home to one of the larger collections of SF east of the Misty Mountains, and (as a commenter once noted) “obviously part of a previously unmapped tunnel between the Great Underground Empire and Colossal Cave”

So we have decided to name the basement after its most frequent inhabitant. Yes, that would be the entity most likely to sleep on top of you if you’re sleeping in the daybed…our very own fuzz elemental and companion-to-hackers, Sugar. (Who must telepathically know I am writing about her as she has just materialized in my desk well to snuggle up to my right foot.)

So, um, when you see that the next CeroWRT release is tagged “Sugarland”, do not think of a town in Texas or a valley in the Great Smoky Mountains. Somewhere in Malvern, a cat is purring. And she purrs just for you. Or your router. Whatever….

CC-NC considered harmful

I just left the followiing comment on a Creatice Commons blog thread debating the NonCommercial and NoDerivatives options:

I speak as founder and President Emeritus of the Open Source Initiative. The NC option in Creative Commons has always been a bad idea and should be removed.

The reasons it should be removed have nothing to do with any of the deep philosophico/political positions usually argued in the debate, and everything to do with the fact that there is no bright-line legal test for “commercial activity”. This ill-definedness is reflected in community debates about whether commercial means “cash transactions” or “for profit”, and it is the exact reason the Open Source Definition forbids open-source software licenses from having such restrictions.

The founding board of OSI, after studying the possibility, judged that an “NC” option in open-source licensing would create too much confusion about rights and restrictions, too many chilling effects on behaviors we did not want to discourage, and too many openings for vexatious litigation. What is only a source of contention within our community could prove very damaging to it if unsympathetic courts were to make even mildly adverse rulings.

I have seem no reason to change that judgment, and I think it applies with equal force to Creative Commons. The NC option is a dangerous trap and should be removed.

A shout to the world’s technical journals

So, after my post on ground-truth documents, one of my commenters argued eloquently that I ought to clean it up and submit it to a journal read by people who manage programming projects. He suggested Software Practice and Experience.

This seemed like a pretty good idea, until I read SP&E’s submission procedures and was reminded that (like most journals) they want me to assign the copyright of my submission to the publisher.

My instant reaction was this: Fuck. That. Noise. I’m certainly willing to cede publication rights when I want to be published, but copyright assignment ain’t going to happen. Ever. Nobody gets to own my work but me. (Yes, I insist on this with my book publishers too.)

I have a message to all you technical journal publishers out there…

There is probably still a place for journal publishers in today’s Internetted world. The peer-review networks you maintain and the impact score of your journal still have value to authors. But the explosion in alternate channels for reaching an audience of technical peers means your value proposition has seriously eroded. You don’t have enough to offer me, any more, to buy my compliance to a copyright assignment.

In fact, the balance of power has shifted so much that I cannot but consider that requirement offensively stupid. Insulting. And that’s not my problem, it’s yours. I have a blog with a readership that probably exceeds the subscriber base of most technical journals; achieving that isn’t even difficult, these days, for any competent writer. So who in the bleeding hell are you to think you can still treat me (or any other author) like some sort of peon dependent on your good graces to reach an audience?

These are my terms. My writing goes out under my copyright, with a Creative Commons or equivalent license. You can have any additional quitclaim you want to reassure your lawyers that I’m not going to sue you for publishing me. You get to use my content as an inducement to people to buy your journal, but I still own it.

That’s what you get, and that’s all you get. If that isn’t enough, take your pretensions to power that you no longer possess and ram them up the bodily orifice of your choice.

coverity-submit 1.2 is released

Coverity simplified their remote-submission procedure. Because of this, I have been able to remove the ugliest bits of configuration cruft from coverity-submit; you no longer have to specify either a public drop directory for your results tarball or a URL that advertises it.

Get your remote-static-checking goodness here.

This is a tease.

Yesterday I applied for allocation of a new public port number from IANA. It’s 6659. When the allocation is confirmed, I’ll publish the source code for a reference implementation of the server. It’s a bit over 300 lines of Python.

Let the speculation begin. :-)