NTPsec is preparing for a release, which brought a question to the forefront of my mind. Are tarballs obsolete?
High on my list of Things That Annoy Me When I Hack is sourcefiles that contain huge blobs of license text at the top. That is valuable territory which should be occupied by a header comment explaining the code, not a boatload of boilerplate that I’ve seen hundreds of times before.
Hackers have a lot of superstitious ideas about IP law and one is that these blobs are necessary for the license to be binding. They are not: incorporation by reference is a familiar concept to lawyers and courts, it suffices to unambiguously name the license you want to apply rather than quoting it in full.
This is what I do in my code. But to make the practice really comfortable for lawyers we need a registry of standardized license identifiers and an unambiguous way of specifying that we intend to include by reference.
Comes now the Software Package Data Exchange to solve this problem once and for all. It’s a great idea, I endorse it, and I will be using it in all my software projects from now on.
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.
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.
This is a brief heads-up that the reason I’ve been blog silent lately is that I’m concentrating hard on a sprint with what I consider a large payoff: getting the Emacs project fully converted to git. In retrospect, choosing Bazaar as DVCS was a mistake that has presented unnecessary friction costs to a lot of contributors. RMS gets this and we’re moving.
I’m also talking with RMS about the possibility that it’s time to shoot Texinfo through the head and go with a more modern, Web-friendly master format. Oh, and time to abolish info entirely in favor of HTML. He’s not entirely convinced yet of this, but he’s listening.
Ever since the open-source rebranding in 1998, I’ve been telling people that “open source” should not be capitalized because it’s an engineering term of art, and that we would have achieved victory when the superiority of (uncapitalized) open source seeped into popular culture as a taken-for-granted background assumption.
There’s a thriller writer named Brad Thor who I never heard of until he publicly offered to buy George Zimmerman any weapon he likes as a replacement for the pistol the police impounded after the Trayvon Marin shooting. What Thor was really protesting, it seems, was the fact that Zimmerman didn’t get his pistol back when he was acquitted; instead, the federal Justice Department has impounded it while they look into trumping up civil-rights charges against Zimmerman.
This made me curious. The books are pretty routine airport-novel stuff, full of exotic locations and skulduggery and firefights. Like a lot of the genre, they have a substantial component of equipment porn – lovingly detailed descriptions of weapons and espionage devices.
Amidst all this equipment porn the characters casually use “open source” (specifically of encryption software) as a way of conveying that it’s the best available. And the author writes as though he expects his readers to understand this.
Victory is sweet.
Congratulations, Adobe, on your impending move from selling Photoshop and other boring old standalone applications that people only had to pay for once to a ‘Creative Cloud’ subscription service that will charge users by the month and hold their critical data hostage against those bills. This bold move to extract more revenue from customers in exchange for new ‘services’ that they neither want nor need puts you at the forefront of strategic thinking by proprietary software companies in the 21st century!
It’s genius, I say, genius. Well, except for the part where your customers are in open revolt, 5000 of them signing a petition and many others threatening to bail out to open-source competitors such as GIMP.
The following question appeared in my mailbox today:
If a certain program (that you need) was proprietary, and its open-source counterpart was (currently) 40% slower. Which would you use, the open-source one or the proprietary one?
The answer is: it depends. I’m going to answer this one in public because it’s a useful exercise in thinking about larger tradeoffs.
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.
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.
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.
I just left the followiing comment on a Creatice Commons blog thread debating the NonCommercial and NoDerivatives options:
It’s beginning to look like Apple’s legal offensive against Android might backfire on it big-time. Comes the news that Judge Koh has declined to suppress evidence that Apple may have copied crucial elements of the iPad design from prototypes developed by Knight-Ridder and the University of Missouri in the mid-1990s.
In “Who’s Afraid of Huawei?” you point out the need for the telecoms industry to adopt transparency guidelines to head off risks from kill switches, spyware, and back doors covertly installed in their equipment.
One minimum necessary condition of such transparency is that all software and firmware in these devices must be open source, with customers permitted to install their own software images from published source code and development toolchains that can be audited by third parties.
While open-source software cannot completely head off the possibility of Trojan horses embedded deep in telecoms hardware, it at least reduces the management of aggregate security risks to a tractable problem. No lesser measure is or can be even remotely as effective, even in principle.
Telecoms customers should insist on open source – and, as any competent counter-espionage agency would do, should consider vendors’ insistence on information asymmetry to be indicative of an unacceptable security risk.
In my last blog post, I made a public stink about language in a so-called Declaration of Internet Freedom, which turned out to be some libertarians attempting to expand and develop the ideas in this Declaration of Internet Freedom. Mostly they did pretty well, except for one sentence they got completely wrong: “Open systems and networks aren’t always better for consumers. ”
That’s wrong. Open systems are better, always. Cisco has just provided us with a perfect lesson in why that sentence is completely backwards, and why we can never trust closed-source software vendors not to do evil under the cover of their code secrecy.
There’s been some buzz in the last few days about the Declaration of Internet Freedom penned by some prominent libertarians.
I wish I could sign on to this document. Actually, considering who appears on the list of signatories, I consider the fact that the composers didn’t involve me in drafting it to be a surprising mistake that I can only ascribe to a collective fit of absent-mindedness.
But, because neither I nor anyone else from the hacker tribe was involved, it has one very serious flaw.
Comes the news that Nvidia just lost an order for 10 million graphics cards to AMD because it wouldn’t open the source for its driver. At a very conservative estimate, that’s north of $250 million in business Nvidia just threw to a major competitor because it couldn’t get its head out of its rectum. Somebody’s quarterlies are going to suck.
The really interesting aspect of this isn’t the amount of money Nvidia’s idiotic secrecy fetish just cost it, but why it happened – and why it’s likely to happen again, soon and repeatedly, to other hardware companies with equally idiotic secrecy fetishes.
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.