January 1, 2021

Deprogramming the Programmerthrow off your jargon and be free

Nobody sees all of open source, or all of law. Least of all me. There’s too much going on, in too many places, public and private, for anyone to take it all in. Or to declare their personal crop of anecdotes a representative sample.

It’s even worse than that. Where we do have experience, limited as that must be, time served doesn’t bestow any perfect picture of the past. Memory doesn’t work like that. It gets worse, not better, as we go along. It’s never that great to begin with.

Even when we do remember vividly, or feel that we do, we can’t separate what we remember from how we thought and felt about it at the time. Details we thought unimportant, unworthy of great attention, don’t suddenly come walking out of the haze, sharp, bright, and squared away, ready for first inspection.

Revisiting my “open source” past has proven incredibly valuable over the years. But also dangerous and disorienting. The more I think about what I’ve seen and done, the less I feel I know.

I trust the “open source guy” I used to be less and less all the time. The theories, clichés, and fables he relied on, the big, plastic Duplo blocks with which he built models of software, competition, collaboration, business, intellectual property, and politics simply weren’t that refined. Mostly, they came hand-me-down, products of somebody else’s experience, since I had little or none. A disturbing number proved propaganda, good for someone else, or the mass they deigned lead, but not so much for me or my clients.

The understandings of software and the Internet that dominated early on, when most people contributing to the Net, or even merely using it, were real or aspiring geeks, haven’t held their grip. Where once “open source” represented the Way Things Work online, with little popular ideological opposition, those starting now tend to look elsewhere, and to different ideas, even if they end up as programmers. Ideas about how to collaborate. Ideas about how to do business. Ideas about how to build a name. Ideas explaining what the heck is going on.

How could it be otherwise? Most successful projects, movements, and platforms have taken off quite without paying any dues to the open source creed, as platforms of yore often strained to do. Of course, the new stalwarts of the Web have been happy to run and even contribute to open software. But there’s less and less need for those driving the “information superhighway” to look under a hood. Google, Facebook, and friends aren’t ads for open source software. When something goes wrong on one of those mega sites, you don’t end up browsing a forum or a manual page for beardy hacker types.

To make it blunt: When you sit down to make some great software, we don’t ask first and foremost whether it will be open source. When we want to get paid for our work, we don’t look to Eric Raymond. We look to Patreon, OpenCollective, an App Store, or another platform. When we want to be famous, we look to “likes”, followers, karma, reputation points, and viewer counts.

With the kids these days looking first to social media, streaming services, e-commerce platforms, and the like for their big ideas and osmotic lessons, what’s an old man of the forum, mailing list, and conference set to do? Keep the old religion, speak the catechism, and take pity on the eye-rolling youths who just don’t get it, and wait? Dial up my missionary game, write more screeds, and hit the lecture circuit?

On the law side of things, the answer was a lot more clear. American contract drafting is a morass of big intelligence, high energy, long history, momentum, and damned lazy, safe-with-the-herd repetition. It’s easier and more comfortable for lawyers to read and write a bunch of jargon, obscurantism, and archaisms, than it is to remember how they used to write before law school. But apart from avoiding the irksome disapproval of one’s peers, that’s a recipe for rather terrible contracts, from literally anyone else’s point of view, including the client’s.

What’s a conscientious expert to do?

Step One: List out the jargon, archaism, and prolix you depend on.

Step Two: Banish them from your speech, writing, and subconscious thought, as ruthlessly as possible.

When a word people actually use these days will do, use that word instead. When a shorter, friendlier phrase will say the bit, say it that way. When a technical concept comes up, explain it in English. If you must name the term, put it in scare quotes, so folks know what they’re dealing with.

If you can’t explain a term, you do not understand it. You have merely kept the company of too many brethren who assume you do, and likely assume they do, too.

This is very difficult, and takes a lot of discipline. It takes a lot of time you won’t always have, in the fray. It means stepping away, at points, from the social fellow-feeling of the norm. But the payoff’s incomparable. All of these evasions and obscurities were defense mechanisms. You’ll find out quick what they defended you from. In the main, what your clients thought they were paying you for.

You begin to discover you didn’t always really know what you were talking about, because you had expert-sounding words and phrases to hide behind. You start having better conversations with clients, because you now seem vaguely approachable, which is way above the norm. Clients’ minds aren’t warped by years of legal education. You begin to hammer yours back straight, not with big whacks, but with tiny ball-peen hammer blows.

We could do the same for “open source”. Instead of working “open source” into every conversation possible, and getting nowhere, I find it far more difficult, and eventually freeing, to do the opposite.

Pick a week. All the week long, banish the following words and phrases from all your speech and writing about software:

If you can think of more words for this list, add them. And let me know.

You will probably cope, to start, by substituting canned replacements for these words wherever they come up. You will run into problems there. Others will find edge cases, or demand more fulsome definitions. Your replacements served well enough to remind you what you actually meant—a word on the list—but your audience doesn’t come with your associations preloaded.

Responding to these quibbles, you won’t be able to provide definitions without caveats, either by drafting your own definitions or pointing to others’. You will have to acknowledge vaguenesses, ambiguities, and conflicts. You will have to talk about history, motives, interests, and other pesky context. Frankly, you’ll have to do a lot more explaining, and likely no small amount of backfill research. The explanations you provide, and the holes of uncertainty left in them, will be far more realistic.

The result, in my experience, was to move me away from my colleagues and toward my clients. And, I think, to reverse the hardening of my own views and pet theories, which were fast getting in the way of understanding the problems my clients had.

Your thoughts and feedback are always welcome by e-mail.

back to topedit on GitHubrevision history