# On 'scaling up' and being the right size - [Home](https://tzovar.as/) - [Blog](https://tzovar.as/blog) - [Photography](https://tzovar.as/photography) - [Projects](https://tzovar.as/projects) - [Links](https://tzovar.as/links) - [About](https://tzovar.as/about) Tuesday. August 18, 2026 [![a group of people looking extremely tiny walking in front of the Perito Moreno glacier](https://tzovar.as/assets/images/2026-08-18-size.jpg)](https://www.flickr.com/photos/gedankenstuecke/55122851811) I regularly encounter questions along the lines of *“how do we scale things up?*, in particular around projects related to free knowledge, FLOSS or citizen science. It has basically started from the first citizen science effort and accompanied me through most of my volunteering work. And it’s a question that has always sat wrong with me. Mainly because of its uncritical assumption that *scale* should be wanted, necessary or even ‘*good’*. To look at this, I want to take a step back: My academic background started off in evolutionary biology, and despite not having actively done research in the field for a while, it regularly shines through: If we’ve ever met, I might have waxed about [*the Spandrels paper*](https://en.wikipedia.org/wiki/The_Spandrels_of_San_Marco_and_the_Panglossian_Paradigm) by Stephen Jay Gould and Richard Lewontin. Or about [J.B.S. Haldane](https://en.wikipedia.org/wiki/J._B._S._Haldane)’s essay [*On Being the Right Size*](https://www.damtp.cam.ac.uk/user/gold/pdfs/teaching/Haldane.pdf), which I’ve previously mentioned when talking about how [there is no one-size-fits-all editor for OpenStreetMap](https://doi.org/10.59350/b6hse-mv263). And it’s this essay that’s relevant here. In *On Being the Right Size*, Haldane beautifully explains how size itself shapes and constrains the biology and complexity of organisms: > \[…] suppose that a gazelle, a graceful little creature with long thin legs, is to become large, it will break its bones unless it does one of two things. It may make its legs short and thick, like the rhinoceros, so that every pound of weight has still about the same area of bone to support it. Or it can compress its body and stretch out its legs obliquely to gain stability, like the giraffe. Or in other words, there is no way to be a gazelle above a certain size. By exploring the physical constraints of the world around us all – such as gravity, the relation between volume & surface area, the wavelengths of light – Haldane shows how *size matters* in very concrete terms. Smaller organisms do not need to fear gravity for their comparatively high air resistance, but the surface tension of liquids mean that *being wet* becomes an unbearable weight for them. And while smaller organisms can absorb sufficient oxygen through their skin, larger animals need some form of gills or lungs to have a sufficient surface area to not asphyxiate. While this might all seem far from our initial question about *how do we scale up a project/platform/community?*, in reality the answer to that question is the same: **You can’t**! Not because growing in scale itself is impossible, but because if you scale things up (or down), you always have to adapt – and often that means losing some things, as you can not stay the same. Just as the gazelle in Haldane’s example can not remain *as is*. Haldane, a committed socialist[1](#fn:1), himself makes the connection to the scales of human organisations, giving the example of the ancient Greek democracies that due to their structure could not work beyond the scale of a small city. He went on to link scale to the limits of full nationalization too, famously stating that *I find it no easier to picture a completely socialized British Empire or United States than an elephant turning somersaults or a hippopotamus jumping a hedge*. All of which is to say: In the context of your community-driven projects, you will very likely not be able to change the scale of it, without also changing some or even a large number of the organisational norms that affect it. Haldane’s ideas were later taken on by planners and theorists who were concerned with how to design and implement structure. One of them was Jane Jacobs, an urban-planning theorist and activist, who organized grassroots efforts to protect neighborhoods from *urban renewal*.[2](#fn:2) In her [1979 Massey Lectures](https://www.cbc.ca/ideas/massey-archives/1979/11/07/massey-lectures-1979-canadian-cities-and-sovereignty-association/), Jacobs directly cites *Haldane’s Principle* in relation to institutions, governments and other organisations: > Haldane presents us with an interesting principle about animal size: Big animals are not big because they are complicated. Rather, they are complicated because they are big. Haldane’s principle, it seems to me, also applies to institutions, companies, governments, organizations of all sorts. The larger they are, the more complications they require. Jacobs recognizes that the trade-off for more complexity can be worth it, as some things can only be done or achieved at larger scales. But, she also outlines how that trade-off comes with certain costs, in particular that larger sizes require a level of complexity that it becomes stifling, to the point that the complexity actively interferes with the reasons for organisations existing in the first place. And those of you who have ever had to deal with a mid-to-large sized academic bureaucracy will undoubtedly have some first-hand experience with that happening, be it for placing small orders, booking/reimbursing travel or the other common ‘deaths by a thousand admin paper cuts’. Another planner who recognized the connection between *Haldane’s Principle* and organisations was [Christopher Alexander](https://en.wikipedia.org/wiki/Christopher_Alexander) – who is often recognized as the *father of the pattern language movement*.[3](#fn:3) In his 1977 book [*A Pattern Language*](https://en.wikipedia.org/wiki/A_Pattern_Language) he makes a claim for *independent regions* based on the natural limits that human governments can take, by citing Haldane’s point about Greek city state democracy. To expand on that point, he outlines how growing group sizes automatically mean that the number of pairwise relationships or links between people in a group grows exponentially, which becomes hard to maintain. Which in turn tends to then also increase the levels of hierarchy. What does all of this now mean for our communities and commons? It means that *Can Mastodon be the next Twitter?”* or *Can Codeberg be the next GitHub* might be the wrong questions to ask. Rather, we should ask ourselves: **What is the cost of trying to scale like this and become so big?** As creating large, centralized structures does come with a cost – at the very least to adapt from the status quo to something else. As Jacobs discussed in her lectures, and Haldane recognized as well, centralization and economies of scale can work for some things, but not so much for others. Placing large orders for hardware might be reasonable (or rather used to be before the LLM-bubble), it tends to break down for social processes. As an example: Content moderation ‘at scale’ by sheer necessity means having to automate it, losing the human connection that can legitimate it, while putting more strain on the moderators and increasing the likelihood for wrong calls. In the Mastodon/Fediverse space, this is one of the reasons why people anecdotally seem to be skeptical of too large instances. And recent research seems to support this: In [a recent preprint that investigates moderation on Mastodon](https://arxiv.org/html/2606.05069v2), the authors find that scaling of Mastodon instances creates a pressure on content moderation similar to the one observed on e.g. Reddit, suggesting that community size itself imposes a fundamental constraint, regardless of platform architecture. And in my own work, I’ve seen similar things around [our content moderation work](https://dx.doi.org/10.1017/dap.2024.21) in a citizen science project where we co-designed the policies with a small community of autistic people, as well as in a [project on data collection](https://www.jmir.org/2021/9/e28116/) that worked *because* of its intentionally small size - not *in spite* of it. Of course, all of these aspects do not just apply to free knowledge, FLOSS or other open* communities and platforms. When politicians and local tech bros wish for “a European Google/Microsoft/OpenAI/…” to exist, just the same forces are in play. There is no reason to believe that a conglomerate of the scale and monopoly position of e.g. Google would be any ‘better’, more ethical, less harmful, … just because it’s based out of the EU instead of the US. As a lot of the harms are built-in into the business model that *requires* scale.[4](#fn:4) If *how do we scale* isn’t the right question, what is a better one? On some level, I believe the question *how can others make their own* is a lot better. In her lectures, Jacobs points to federalism as a potential solution – at least when it comes to governments. But could equally apply to other forms of organizations. We do not need to create large structures that just run the risk of becoming yet another single-point-of-failure and at the same time require approaches to decenter community. We do not need another centralized *Twitter but in open source* that fails at moderation as a result. We do not need *the GitHub replacement* with all its problems, even if, like [Codeberg](https://codeberg.org/), it would be democratically governed by a member-run organisation. Just like we do not need an alternative *AWS US-East-1* that takes down the whole internet when it goes down. Instead, what we might want is many, ‘reasonably’-sized alternatives that can interact, exchange and cross-communicate. Jacobs did not think about ‘federation’ on a technical protocol level, but I think the Fediverse – with all its problems – shows that there is a real opportunity. And the folks working on making federated code forges work might just pull the same thing off for that domain. This is all not to say that there never can be situations where ‘scaling up’ isn’t possible or maybe even the right call. But, instead of making *how do we scale* the knee-jerk reaction, we need to start earlier. By seriously thinking about the trade-offs that increasing scale would mean, and taking them into account to decide *if* a larger scale is even the right choice. And if a decision to increase scale is made, let’s not believe that the existing modus operandi will still serve in the same way. Otherwise we end up like Haldane’s supersized gazelle – with broken legs. ## References 1. S. J. Gould, R. C. Lewontin; The spandrels of San Marco and the Panglossian paradigm: a critique of the adaptationist programme. Proc. R. Soc. B 1 September 1979; 205 (1161): 581–598. https://doi.org/10.1098/rspb.1979.0086 2. Haldane, J. B. S. (March 1926). “On Being the Right Size”. Harper’s Magazine: 424–427. 3. Greshake Tzovaras, B. (2025, August 11). The diversity of OpenStreetMap tools and how they help create a commons. Bastian Greshake Tzovaras. https://doi.org/10.59350/b6hse-mv263 4. Subramanian, Samanth (2021, July 1) A Dominant Character The Radical Science and Restless Politics of J.B.S. Haldane. ISBN: 9781786492845 5. Jacobs, Jane (1980) Canadian cities and sovereignty association ISBN: 0887940870 6. Alexander, C., Ishikawa, S., Silverstein, M., Jacobson, M., & Fiksdahl-King, I. (1977). A pattern language: towns, buildings, construction. ISBN: 0195019199 7. Rasika Muralidharan, Yong-Yeol Ahn, Bao Tran Truong. (2026) Federating Governance: How Community Rules Scale with Mastodon Instances https://arxiv.org/abs/2606.05069v2 8. Aitkenhead G, Fantoni S, Scott J, et al. (2024) How to co-create content moderation policies: the case of the AutSPACEs project. Data & Policy. 2024;6:e28. doi:10.1017/dap.2024.21 9. Greshake Tzovaras B, Senabre Hidalgo E, Alexiou K, Baldy L, Morane B, Bussod I, Fribourg M, Wac K, Wolf G, Ball M (2021) Using an Individual-Centered Approach to Gain Insights From Wearable Data in the Quantified Flu Platform: Netnography Study J Med Internet Res 2021;23(9):e28116 URL: https://www.jmir.org/2021/9/e28116 DOI: 10.2196/28116 ![Bastian Greshake Tzovaras](https://tzovar.as/assets/images/profile.jpg) Generally, things are better if you put *open\** in front of them. Thanks to [*Rogue Scholar*](https://rogue-scholar.org/), you can cite this blog post using the DOI [*https://doi.org/10.59350/5bfg3-bjv09*](https://doi.org/10.59350/5bfg3-bjv09). * * * * * * This page was last built on 2026-08-18 @ 09:29:10 -0300, from git commit [`23554d4`](https://codeberg.org/gedankenstuecke/pages-source/commit/23554d4d1902701fbc3c1127e040ef7d22a61f74/).