From the standardization of packets of information in Internet protocols to the radio buttons we click on in social media privacy settings, the insistence on standardized tools drives Internet communications technology. These protocols and technologies worship at the alter of “scalability.” Any networked software tool attempting to gain traction (that is, venture capital) must have a plan for scalability. It must be usable by individuals, small groups, and large groups without much customization. It must operate in some kind of standardized way.
Scalability and standardization have become entirely invisible and commonplace, so much so that it is now just common sense. Who would question standardized Internet protocols? Who would argue for “unscalable” software that is built for very specific purposes? This push to standardize means that networked environments are, in essence, always built for “someone else.” They are an attempt to be as generic as possible so as to be scalable. (This also means that they are aligned with whiteness and its desire to disappear, the subject of a future post.) And so this software is by definition “badly made.” For some, it is especially bad – what is an inconvenience for one community is openly hostile and dangerous to another. Sometimes it’s even worse than this, since a convenience for one group might be actively harmful to another. Consider the fact that Discord, the chat tool initially designed for gamers but now applied to a range of other communication situations, allows different group discussions (called “servers”) to generate invitation links so that others can be easily invited to the conversation. This same function, when used by groups who are targets of harassment, can serve as a backdoor for organized raids of abusers and harassers (this is something Greg Hennis and I wrote about for an edited collection called Digital Ethics). Invitations links circulate on message boards, and bad actors use them to coordinate raids and attacks. This is just one example of how a standardized set of tools is simultaneously built for everyone and no one.
Given that we appear to be mostly locked in to certain software environments (Facebook, Google, Amazon, Alibaba, etc.), what are our options for living within and with these ill-fitting tools and environments? Our best approach may be to seek out and learn from the practices of those who have long had to work against the grain to live in an ill-fitting world. We could refer to these practices as the building of “bespoke networks” within these ill-fitting, standardized environments. They offer a glimpse at how we can reimagine networked life on a broader scale. These bespoke networks/tools exist throughout the networked life, so my argument is not that we need to necessarily start from scratch to build an entirely “new” set of tools. Instead, we can turn to those who have worked to build tools and spaces that operate by different logics, logics that do not fit well in standardized networks. When such tools catch the eye of the standardized scalable Internet, they are too often misunderstood as “add-ons” for this environment. But not everything is an app or a plug-in, especially when the tools and methods in question have been built for specific communities and purposes.
Darius Kazemi’s take on this (mentioned in my previous post) is especially helpful:
Any time I propose a new piece of software to a group of software engineers I’m asked the same question: how will it scale? We are trained as a group to ask this question. I think it’s the software equivalent of in manufacturing when someone asks “What will it cost to produce?” Since the marginal cost of producing software is effectively zero, it’s the scale, the ability for the software to be used by millions or billions of people, that becomes the limiting factor that everyone brings up.
Imagine two different software developers. One person writes a piece of software that makes the lives of one million people slightly easier. Maybe it’s better routing for navigation software and it shaves 30 seconds off the commute of a million people. Another person writes a piece of software that only ten people ever use, but it tangibly changes their lives for the better in very material ways; maybe they learn a trade that becomes a career.
One of these outcomes is not necessarily better than the other, and yet due to myriad factors, only the software with a million users is likely to get funding from entities—whether the context is for profit or not for profit.
I’d like to advance the notion that software does not have to scale, and in fact software can be better if it is not built to scale. I hope some of the examples I’ve given above have illustrated what is possible when software is used by a small number of people instead of a large number of people.
This approach to software design can be generalized to the design and maintenance of social networks, and this is also what Darius argues in his “Run Your Own Social” project. A small network of people can gather together and determine how they want to connect to others or whether they want to connect to others. They can gather under the banner of unscalability.
