#bdfl

If you'd like an essay-formatted version of this post to read or share, here's a link to it on pluralistic.net, my surveillance-free, ad-free, tracker-free blog:

https://pluralistic.net/2024/12/10/bdfl/#high-on-your-own-supply

Silicon Valley's "authoritarian turn" is hard to miss: tech bosses have come out for autocrats like Trump, Orban, Milei, Bolsonaro, et al, and want to turn San Francisco into a militia-patrolled apartheid state operated for the benefit of tech bros:

https://newrepublic.com/article/180487/balaji-srinivasan-network-state-plutocrat

Smart people have written well about what this means, and have gotten me thinking, too:

https://www.programmablemutter.com/p/why-did-silicon-valley-turn-right

Regular readers will know that I make a kind of hobby of collecting definitions of right-wing thought:

https://pluralistic.net/2021/09/29/jubilance/#tolerable-racism

One of these – a hoary old cliche – is that "a conservative is a liberal who's been mugged." I don't give this one much credence, but it takes on an interesting sheen when combined with this anonymous gem: "Conservatives say they long for the simpler times of their childhood, but what they miss is that the reason they lived simpler lives back then wasn't that the times were simpler; rather, it's because they were children."

If you're a tech founder who once lived in a world where your workers were also your pals and didn't shout at you about labor relations, perhaps that's not because workers got "woke," but rather, because when you were all scrapping at a startup, you were all on an equal footing and there weren't any labor relations to speak of. And if you're a once-right-on tech founder who used to abstractly favor "social justice" but now find yourself beset by people demanding that you confront your privilege, perhaps what's changed isn't those people, but rather the amount of privilege you have.

In other words, "a reactionary tech boss is a liberal tech boss who hired a bunch of pals only to have them turn around and start a union." And also: "Tech founders say things were simpler when they were running startups, but what they miss is that the reason no one asked their startup to seriously engage with the social harms it caused is the because the startup was largely irrelevant to society, while the large company it turned into is destroying millions of peoples' lives today."

The oft-repeated reactionary excuse that "I didn't leave the progressive movement, they left me," can be both technically true and also profoundly wrong: if progressives in your circle never bothered you about your commercial affairs, perhaps that's because those affairs didn't matter when you were grinding out code in your hacker house, but they matter a lot now that you have millions of users and thousands of employees.

I've been in tech circles since before the dawn of the dotcoms; I was part of a movement of people who would come over to your house with a stack of floppies and install TCP/IP and PPP networking software on your computer and show you how to connect to a BBS or ISP, because we wanted everyone to have as much fun as we were having.

Some of us channeled that excitement into starting companies that let people get online, create digital presences of their own, and connect with other people. Some of us were more .ORG than .COM and gave our lives over to activism and nonprofits, missing out on the stock options and big paydays. But even though we ended up in different places, we mostly started in the same place, as spittle-flecked, excited kids talking a mile a minute about how cool this internet thing would be and helping you, a normie, jump into it.

Python programming legend Tim Peters succinctly channels the BDFL's guiding principles for Python's design into 20 aphorisms, only 19 of which have been written down:

Beautiful is better than ugly.

Explicit is better than implicit.

Simple is better than complex.

Complex is better than complicated.

Flat is better than nested.

Sparse is better than dense.

Readability counts.

Special cases aren't special enough to break the rules.

Although practicality beats purity.

Errors should never pass silently. Unless explicitly silenced.

In the face of ambiguity, refuse the temptation to guess.

There should be one-- and preferably only one --obvious way to do it.

Although that way may not be obvious at first unless you're Dutch.

Now is better than never.

Although never is often better than right now.

If the implementation is hard to explain, it's a bad idea.

If the implementation is easy to explain, it may be a good idea.

Namespaces are one honking great idea -- let's do more of those.