Unlaunched
Last summer, I began work on a collection of projects with a common theme. The public face of those efforts was and is meant to be triplescripts.org.
But wait, if you type that into the address bar, it's empty. (If you're reading from the future, here's an archive.org link of the triplescripts front page as it existed today.) So what's the deal?
In December, I set the triplescripts.org launch date for January 7. This has been work that I'm genuinely excited about, so I was happy to have a date locked down for me to unveil it. (Although, as I mentioned on Fritter, I've been anticipating that it will succeed through tenacity—a slow burn, rather than an immediate smash hit.)
Starting in the final week before that date, a bunch of real life occurrences came along that ended up completely wrecking my routine. Among these—and the main thing that is still the most relevant issue as I write this now—is that I managed to get sick three times. That's three distinct periods with three different sets of symptoms, and separate, unambiguous (but brief) recoveries in between. So it's now a month and a week after the date I had set for launch, and triplescripts.org has no better face than the blurby, not-even-a-landing-page that I dumped there a few months back, and these ups and downs have me fairly deflated. Oh well for now. Slow burn.
Unloading a month's thoughts
The title of this post is a reference to Nadia Eghbal's monthly newsletter, which has been appearing in the inbox under the title "Things that happened in $MONTH". I like that. Note, in case you're misled by bad inference on the title, that the newsletter is about ideas, not autobiographical details.
I've seen some public resolutions, or references to resolutions by others, to publish more on personal sites and blogs in 2019 (such as this Tedium article on blogging in 2019). I don't make New Year's resolutions, so I was not among them. But I like the tone, scope, and monthly cadence in the idea behind "Things that happened". So on that note alone—and not motivated by a tradition of making empty promises for positive change when a new year begins—I think I will commit to a new outlook and set of practices about writing that follows in the vein of that newsletter.
The idea is to publish once a month, at minimum, everything that I considered that month as having been "in need of a good writeup", and to do so regardless of the state it's actually reaches by the end of the month—so something on the topic will go out even if it never made it to draft phase. Like continuous integration for written thought.
Although when you think about it, what's with all the self-promises, of, you know, writing up a thorough exegesis on your topic in the first place? Overwhelming public sentiment is that there's too much longform content. As even the admirable and respectable Matt Baer of write.as put it, "Journalism isn't dead, it just takes too damn long to read." (Keep in mind this is from the mouth (hand) of a man whose main business endeavor at the moment hinges on convincing people to write more.) And this is what everyone keeps saying is the value proposition of Twitter, anyway, right? High signal, low commitment, and low risk that you'll end up snoring.
Ideas are what matter, not personal timelines. I mentioned above that Nadia's newsletter is light on autobiographical details, as it should be. Sometimes I see that people aren't inspired to elaborate on any particular thought, but find themselves in a context where they're writing—maybe as a result of some feeling of obligation—so they settle into relaying information about how they've spent themselves over some given time period—information that even their future self offset a couple months down the line wouldn't find interesting. So these monthly integration dumps will remain light on autobiographical details, except in circumstances where those details fulfill some supporting role to set the scene or otherwise better explain the idea that's in focus.
Unlinked identity
I'm opposed to life logs in general. I hate GitHub contribution graphs, for example, because they're just a minor variation of the public timeline concept from any social network, and I've always disliked those. This is one reason I never fully got on board with Keybase.
Keybase's social proofs are pretty neat, the addressing based on them is even neater, and in general I feel some goodwill and positive thought toward what I perceived as Keybase's aspirations towards some sort of yet-to-be-defined integration point as your identity provider. But I realized a thing a few months after finally signing up for Keybase, which is that their implementation violates a personal rule of mine: participation in online communities originates from unlinked identities, always.
When I was throwing my energy into Mozilla (and Mozilla was throwing its weight in the direction of ideals it purported to be working for), Facebook Connect was the big evil. The notion that the way to participate—or, as in the worst cases, even just to consume—could happen only if you agreed to "Sign in with Facebook" (and later, with Google; nowadays it's Twitter and GitHub), was a thing unconscionable. BrowserID clearly lost, but the arguments underpinning its creation and existence in the first place are still valid.
I'm not sold by the pitch of helping me remember how I spend my time. I'm not interested in the flavor of navelgazing that you get from social networks giving you a look back at yourself N months or years down the line. And we should all be much less interested, further still, in the way that most social networks' main goal is to broadcast those things to help others get that kind of a look at you, too.
Look at it like this: if you and I work together—or something like that—then that's fine. You know? That's the context we share. If I go buy groceries or do something out in public and we happen run into each other, that would be fine, too. But if one of my coworkers sat outside my place to record my comings and goings, and then publicized that info to be passively consumed by basically anyone who asked for it, then that would not be okay.
My point is, I like the same thing online. If I'm contributing to a project, for example, I'm happy to do so with my real name. If you're in that circle (or even just lurking there) and as a result of some related interest you run into my name in some other venue, then, hey, happy coincidence. But I'm less interested in giving the world a means to click through to my profile and find a top-level index of my activity—and that's true without any desire to hide my activity or, say, my politics, as I've seen in some cases. After all, if that were the goal, it would be much easier just to use a pseudonym.
So I say this as a person with profoundly uninteresting comings and goings— but I realize that giving coverage to this topic from this angle will probably trigger the "what are you trying to hide?" reflex. Like I said, I use my real name. My email address and cell phone number are right there in the middle of the colbyrussell.com landing page, which is more than you can say for most people. (I've mentioned before how weird it is that 25 years ago, you could look anyone up in the phonebook, but today having something like that available seems really intrusive.) Besides, not even the Keybase folks themselves buy the pitch; at this time, the most recent post to their company blog is the introduction of Keybase Exploding Messages. And Snapchat's initial popularity says something about how much the general public truly feels about the value of privacy, despite how often the "if you have nothing to hide…" argument shows up.
So in the case of Keybase, keep the social proofs and keep the convenient methods of addressing, but also keep all those proofs and identities unlinked. I don't need a profile. Just let me create the proofs, the same principle in play when I prove everywhere else online that I control the email I used to sign up, but it need not tie into anything larger than that single connection. Just let my client manage all the rest, locally.
Unacknowledged un-
Sometimes an adage is trotted out that goes roughly like this:
Welp, it's not perfect, but it's better than nothing!
And sometimes that's true. It's at least widely understood to be true, I think.
What I don't see mentioned, ever, is that sometimes "it's better than nothing" is really, really not true. In some cases, something is worse than nothing.
My argument:
Voids are useful, because when they exist you can point to them and trivially get people to acknowledge that they exist. There's something missing. A bad fix for a real problem, though, takes away the one good thing about a void.
For example, consider a fundraising group that (ostensibly) exists to work on a solution towards some cause—something widely accepted to be a real problem. Now consider if, since first conception, and in the years intervening, it's more or less provable that the group is not actually doing any work to those ends, or at least not doing very good work when measured against some rubric.
Briefly: we could say that the org is some measure of incompetent and/or ineffective.
The problem now is that our hypothetical organization's mere existence is sucking all the air out of the room and hampering anyone who might come along and actually change things.
That is, even though we can argue rationally that their activity is equivalent to a void, it's actually worse than a void, since—once again—you can point to voids and say, "Look, we really need to do something about this!", but it's harder to do that here. Say something about the underlying problem—the one that the org was meant to solve—and you'll get railroaded in the direction of the org.
So these phenomena are a sort of higher order void. They're equivalent with respect to their total lack of contribution to forward progress on the issue we care about, but then what they also do is disguise their existence and act like sinks, so not even the potential energy stored nearby never gets put to effective use.
Underdeveloped
Other stuff from January that requires coverage here, but doesn't exist in longform:
I had an animated conversation with my friend that what the United States and the world in general really needs in order to adopt the metric system is to use the "metric hand" as the de facto human scale reference unit to fill the void created by the deprecation and displacement of the 12-inch foot. Meters are too long, and centimeters are too short. ("How tall is that guy? 1.8 meters?" C'mon.) Spoiler alert: the metric hand (or just "hand" for short) would be defined as 1 decimeter (10 cm). To easily convert between hands and feet, approximate 1 decimeter as 4 inches, thus there are approximately 3 hands in a foot. We say the proper term is the "metric hand" to distinguish from the existing unit from the imperial system called the "hand", which is exactly 4 inches, but also used essentially nowhere, except in some equestrian circles. So there shouldn't be much confusion, and even if there were, the figures would only be off by 1.8 mm, which is tiny—and also not an approximation; that is, it's off by exactly 1.6 mm, no rounding.
Zero-obligation communities could probably extract more value from their contributors (including converting passive bystanders into contributors) by fostering a culture of voluntoldism and getting maintainers to put in some asks of their own. Right now, people are half-insisting that there's something intrinsic to open source that is placing a high burden on maintainers. Mostly, I regard this as the result of bad practices originating from the culture of GitHub, not intrinsic to open source. But either way, it's widely reported that maintainers are burning out. Users are showing up and asking for too much. How about reversing polarity and start conditioning maintainers into asking for things from users and less involved contributors? The idea is for maintainers to give consideration to the most effective way a project would benefit if it had at its disposal a voluntary group of mechanical turks. These would be people willing to execute the routines that the maintainers write with awareness and intention of them being carried out in meatspace.
Resource-proportionate billing was back on my mind, and it seems like an underutilized trick of consumer psychology. Recently I heard a creator complaining of the absurdity that people will pay $5 every day for something as trivial as coffee, but generally won't help fund the people creating the things they like, even when its effect is greater than coffee. Few people buy books (though some do). Fewer support intangible creative output. Now, when you consider the tiny pool of those left, what those in the pool usually want is to know is why you need money—what your expenses are. So that's the complaint. Okay. Right. So leverage that. Approach it from the other end and think of it not as the absurdity that it is but some psychological effect that you can optimize for to convince people that paying is worthwhile. I have more on this topic, but in the spirit of the commitment, I'm disclosing my thoughts here in their rough form. As I wrote before on Fritter: "Radical transparency about global costs as well as the actual load caused by your individual account activity (down to the cost for servicing a GET request) underpins the whole idea. Sandstorm's recent changes (no more free accounts + numbers Kenton published after the switch was flipped) are a good case study." I also think lower prices are key. Lots of people are trying for $7–9/month, but that's more expensive than paid email—and email is way more important than whatever you're probably trying to charge for. This is another thing that I was happy to stumble upon when looking at what write.as is doing. The lowest priced paid option is $12 per year. And why not? $1/month at scale is certainly enough to cover resource costs (where "the time of the people running the thing" is rightly considered to be a resource, too).
Who should fund open source? Are companies to blame for being leeches? Why not place the responsibility with the developers working at those companies when they are leveraging others' work and converting it into increased stature and personal wealth for themselves? When payday comes around, funds flow from the corporation into the hands of its worker for making progress on his or her assignment, but it generally stops there. Why do we treat this differently than if you took on a project, used subcontractors to complete a portion of the work, and then stiffed them? I understand the argument that the "subcontractors" here were never promised anything, and that's at least consistent. What's inconsistent, logically, is when I see people introducing the idea that there's a problem with funding in open source because companies are leeching from the fount of FOSSomeness and not giving back. Where does the idea come from that it's the company's responsibility to settle the debts involved? Programmer salaries are high—above the US national average income for an entire household. To repeat: why aren't the corporate programmers here being held responsible, rather than the company in the abstract that happens to employ them? Jeff Kaufman exists as an extreme example at the other end—a programmer "earning to give" and willingly redistributing his pay, albeit not in a "compensate FOSS subcontractors" style, but for reasons that fit under the familiar label of "philanthropy".