I recently finished reading the book Antifragile, by Nassim N. Taleb,
in which he discusses the idea of antifragility
, the property that allows something to ultimately
improve and grow stronger when subjected to volatility and stressors.
I highly recommend Taleb’s books, they have a tendency to throw conventional wisdom on its head and make you think differently of our world, in which randomness, volatility, opacity and non-linearity takes precedence.
As a software developer, I kept wondering how the insights gained from this book apply to the world of software. Especially given the fact that software is very fragile. The answer lies in the communities or ecosystems that form around software. Many of them are fragile, but some are antifragile.
If you’re also a software developer, you’ll want to be in the second category.
What is antifragile?
Taleb splits everything into three categories, fragile, robust and antifragile.
The initial chapters explain in detail why robust is not the opposite of fragile, and why the neologism “antifragile” is needed to describe the opposite of fragility.
If fragile systems are sensitive to stress and volatility, and need to be kept “safe” from harm, lest they suffer or break down, then antifragile systems are ones which ultimately benefit from randomness and stress.
In Greek mythological terms, one can think of Medusa, which grows another two snakes on her head for each one that’s cut off. That’s antifragile.
So fragile and antifragile can be considered opposites, e.g. positive and negative, while robust is simply neutral. It suffers little harm from volatility but also gets little to no benefit.
Evolution is antifragile
Some good examples of antifragile systems are found in nature and ecology. For evolution to work (i.e. for a species to adapt to its randomly changing environments), random mutations are required between individuals in that species.
A random mutation in a member of a species holds the possibility of making that member better adapted to its environment. By virtue of it being better adapted, that member will on average live longer and produce more offspring, which will be likely to have inherited the same advantageous mutation. The process continues, propagating the beneficial mutation throughout the species, in so doing, the species evolves and becomes more fit and adapted to its environment.
Nature is able to discard less well-adapted specimens and keep the better-adapted ones. An ability which Taleb refers to as optionality. It has the option to keep the “good” specimens and discard the “bad” ones.
The opposite of an option is an obligation. Nature is under no obligation to keep the poorly adapted members of a species, and if it were, it wouldn’t be antifragile anymore.
So, although individual members within a collection (like a species) are fragile to certain stressors, the overall effect on the collective level is antifragility.
Software is fragile
Unmaintained and unsupported software degrades when exposed to the stressors of time and use.
The more software you install on your computer, the higher the chance that your machine will eventually become slow and prone to crashes and bugs.
The word “bitrot” is sometimes used to refer to the gradual degradation of a software program over time and is related to the idea of entropy.
Large software systems that are composed of multiple interacting subsystems, are especially vulnerable to bitrot, due to the fact that a given subsystem cannot anticipate all the bugs or changes that might be introduced to other subsystems over time.
The more a piece of software is used, the more variance there is in how it’s being used. For example in the order, type and amount of inputs it receives as well as in the hardware its being installed on.
Lets assume that a very specific interaction with the software, which the programmer never foresaw, will cause the software program to crash and become permanently degraded.
Given enough time, someone will eventually interact with the software in this specific way, thereby permanently degrading the functionality of the software program (for example due to data corruption).
Are software businesses also fragile?
Businesses are generally fragile. They require a certain level of stability to operate and are sensitive to volatility (like regulatory changes, lawsuites or changing consumer tastes).
An antifragile software business however would be one that does well whenever some metric related to the software experiences increased volatility.
Remember:
- Something that’s antifragile wants more volatility, because the benefit from increased volatility outweighs the harm.
- Similarly, you are fragile to a specific source of volatility when the potential downsides outweigh any upsides.
So, let’s take “number of security flaws” as the metric.
The fortunes of a company that does security audits would improve every time there is a publicised security flaw in the software itself, or the software is compromized by an attacker.
They would therefore be antifragile to the “bad news” of exposed security flaws.
Perhaps with an upper bound. If there are too many security flaws, the reputation of the software itself might suffer irrevocably, and with it that of the company.
This illustrates the point that antifragile systems can handle volatility and stressors up to a point. Given enough volatility and stress, the entire planet can die out.
Conversely, a company whose business model depends on the software being stable, and on attacks not happening, would be fragile to the software having security flaws.
A community of fragile members can itself be antifragile
So, as mentioned earlier, an ecosystem can be antifragile, even if the individual units that make up that system are fragile.
It is however important that the units themselves are relatively redundant and that the fragility is not systemic inside the entire ecosystem.
To put it in more technical terms, units inside the system need to be “hot-swappable” and their interactions with one another should be “loosely coupled”. This is necessary to prevent complex and hard dependencies within the system, which in the case of breakdown of one unit would cause cascading failures and damage rippling through the entire system.
Antifragile software ecosystems
So, we now get to the crux of this article.
Software itself might be fragile, as well as businesses built around that software, but the larger ecosystem that encompasses the software and businesses, can be antifragile.
A software ecosystem that is distributed over many small and relatively self-contained businesses, each providing services around a common shared resource of Free and Open Source software (FOSS), coupled with a low barrier to entry for new businesses, is antifragile.
Conversely, a software ecosystem that is centralized around one large provider (often playing the role of gatekeeper or rent-seeker), artificially restricting access to the software, attempting to stifle any competition with its own services, is fragile and sensitive to large negative Black Swans (difficult to predict but extreme events).
I’ll elaborate on why this is by identifying the requirements for an antifragile software ecosystem.
Requirements for an antifragile software ecosystem
Distributization
Centralized systems provide a large single point of failure that can cause the collapse of the entire ecosystem. Distributed systems can take shocks much better and are able to route around failures and breakdowns.
Redundancy
When one unit breaks down, others need to be able to pick up the slack. For that to happen, they need to collectively be able to perform the functions of the defunct one. For example, if a software community relied solely on one unit in that community for supplying hosting services, then the entire community would break down if that one unit collapsed.
Optionality
The individual members in an antifragile ecosystem need to be able to modify and adapt.
For a software ecosystem, this means the ability to modify and adapt the software itself. Only through being able to modify the software in a distributed, bottom-up way, can the ecosystem withstand stressors in an antifragile way, by making use of optionality.
Optionality refers to having the option to take (or do) something or not. As mentioned earlier, it’s how evolution is able to “design” extremely sophisticated organisms, by keeping the “good” ones and discarding the bad ones, and it applies to software ecosystems as well.
For example, in the Plone CMS (content management sytem) community, add-on modules are developed in a redundant and distributed way. There are multiple blog add-ons, commenting add-ons, newsletter add-ons and so on. Through a process of optionality and selection, the good ones rise to the top while the weaker ones are eventually discarded.
Why the requirement for Free and Open Source software?
FOSS facilitates all three of the above requirements. Communities and ecosystems that develop around FOSS are by nature distributed, redundant and provide optionality.
Distributization and redundancy come from the lack of gatekeepers, “rights-holders” and rent-seekers. Anyone can start using FOSS and selling services around it from anywhere in the world. No license, special qualification or permission required.
Optionality comes from the fact that anyone can do trial-and-error tinkering with the software and keep their improvements. They can also choose the best or most appropriate changes and modifications made by other people.
Without optionality a software ecosystem will not be antifragile, and without FOSS, a software ecosystem will not have optionality.
Additionally, software that is Free (as in Libre) displays qualities much more akin to information than non-Free software, which due to it’s source opacity functions more as a black-box application. As Taleb explains in his book, information is antifragile. You can’t easily kill it, and by trying to suppress it you have to acknowledge its existence and refer to it.
Lastly, the lower barrier to entry fosters competition.
In order to differentiate themselves, individual developers or businesses need to compete on quality and/or price. It’s survival of the fittest, as opposed to the rent-seeking, vendor lock-in and monopoly so often seen in proprietary software ecosystems.
In the book, Taleb alludes to Silicon Valley’s fail fast, be foolish
model as being antifragile as opposed to a more centralized
environment with inherent systemic risks, such as the New York banking
system (his example).
Silicon Valley might provide an antifragile method for producing businesses, but the software produced by these businesses don’t necessarily result in antifragile ecosystems.
Look at the software businesses that have arisen out of Sillicon Valley. Facebook and Google are both large and centralized. Increasing centralization and size results in increasing fragility of the web.
If Google’s servers were to go down (or be compromized or blocked by a government), a very large part of the web would cease to function. The chance of Google’s servers going down are of course very small, it’s a negative Black Swan event. Something which society nevertheless needs to shield itself against.
Antifragile against what?
Having mapped out the requirements for an antifragile software ecosystem, it makes sense to consider the kinds of stressors such an ecosystem will be antifragile against.
This section is a bit more speculative, mostly because we cannot know the exact nature and extend of the stressors a system will be exposed to. Luckily we don’t need to know the stressors to be able to make use of antifragility.
It’s also important to know that stressors are information. In fact, stressors often appear through the disclosure of “negative” information. When negative information is revealed, it can cause shocks to software ecosystems. The fragile ones will suffer and might even break down, while the antifragile ones will ultimately benefit.
Here are some examples of stressors a software ecosystem can be antifragile against:
Malicious Hacking (Cracking)
FOSS is more resistant to cracking than closed source software. Additionally, distributed systems are much harder to target and infect.
Increased awareness and fear of cracking, makes FOSS, its ecosystems and communities more attractive to software users (individuals, companies, governments etc.) and therefore antifragile to the “bad” news.
Surveillance
A big part of surveillance is actually also cracking, so the same rules apply here.
It’s much more difficult for eavesdroppers to embed backdoors in software with freely available and visible source code.
Encryption software is especially vulnerable and can’t be trusted if its closed source.
News of security flaws spread quickly throughout the community and fixes are generally pushed out almost immediately. You won’t easily have the problem of a FOSS community member privately disclosing security flaws to an intelligence agency (so they might use if for surveillance) while hiding it from the users.
Again as surveillance and privacy fears increase, FOSS becomes more attractive, making the communities and ecosystems around it more antifragile.
Negative economic circumstances
Many governments are experiencing budgetary constraints and employing austerity. Governments are able to make significant savings when they switch to FOSS ecosytems. Not mentioning the increased autonomy and control of their software and resulting digital formats.
Other stressors
There are of course many more stressors that might ultimately benefit distributed FOSS ecosystems, for example censorship and economic boicot, but for the sake of brevity I won’t go into detail for each one.
Conclusion
I’ve mapped out the requirements for a software ecosystem (and community) to be antifragile, and have alluded to Plone as an example of such an ecosystem.
The Plone software, like other Free software (Drupal, Wordpress, Apache, Firefox, Libre Office, GNU/Linux etc.), is a technological commons. It belongs to humanity as a whole.
Everything I wrote also applies to the ecosystems around cryptocurrencies, like Bitcoin, Litecoin and Anoncoin.
There are usually vibrant communities of developers, packagers, integrators, evangelists and users around these pieces of Free software, and they usually conform to the requirements mentioned above. Members are distributed all over the world, there is redundancy in development skills and support offerings and the source code is Free (as in beer and in speech).
