In the mid-2000s, around the time when “Web 2.0” took off, Google started its enclosure of the open web with its push to HTML5, there was a series of badly animated and robotically voiced videos, with all kinds of humorous conversations.
I say “humorous”. I pretty much only know one, and how funny it was depended on the time. The example I think of had one developer discuss database technology with another, specifically the then nascent “NoSQL” vs. relational database models.
The response to just about everything the relational database guy said was the question “but will it scale?”. At the time, some vendor had launched a NoSQL product with the “web scale” slogan attached, and a bunch of naive nerds figured that only “web scale” really mattered, therefore relational databases were declared dead.
Predictably, history shows something else.
One of the more useful products of the time was the comparison of horizontal vs. vertical scaling. Horizontal scaling is when you add more instances to a system, which requires that does not need to be shared amongst instances, or one shifts issues from “the instance canna take any more” to “the state sync canna handle any more”. A fruitless exercise.
Vertical scaling is seen as the counter point, which is to install beefier single instances with more CPU or memory in order to handle the load.
Both completely miss the point on scale.
The real measure of scale is whether given the same amount of compute resources, my software can handle larger amounts of parallel requests better (in the extreme case: more than one).
We exist in a world where the cost of vertical or horizontal scaling is externalized, but the cost of investing more time into a software algorithm is not – because spending time means that the competition can go to market faster.
This has gotten to the point where cranking out features is touted as more “efficient”, regardless of how many resources are burned in horizontal or vertical scaling.
Some confuse not doing this with “premature optimization”. But that misunderstands that phrase. Optimization is premature when it is done for its own sake, or without knowing bottlenecks. Calling this premature implies a mental framework caught up in the same mistaken sense of “efficiency” that focuses on feature delivery at all costs.
This needs to stop.
If we start with human rights, it also means we center the human experience. This is not limited to, but most definitely must include the experience of contributors to the commons, the MOSS gardeners.
Scale, then, means first and foremost that efforts put into a particular project must scale with the capability of its contributors.
This may affect the software’s ability to “scale” to more users. But first and foremost, it’s the scale of the gardening efforts that matter.
We cannot demand more.
However, we can provide more.
Capacity building means increasing the capacity of a community to perform certain tasks, such as software maintenance or feature development. Capacity building occurs when new contributors join, are trained. When more occultFrom Latin “occludere”, to hide. The bits of info that get lost because they only exist in one person’s head.
knowledge gets shared, such as in documentation. When communities are fostered. It also means increasing the community’s understanding of the hurdles people may face in joining the community.
Scaling capacity allows scaling to more users and more disparate demands.
In MOSS gardening, scale is about people.