FOSS and trust: lessons for blockchain projects
Blockchains enable trust, which has all sorts of wonderful applications. Or do they? When thinking of ways in which technologies like blockchains could help foster trust and co-operation in the future, it helps to have some present-day examples of technology-enabled trust to look at. It would be far too simplistic to say “because of blockchains, trust is now possible on the internet”. Communities collaborating over the internet have relied on a mix of technological and interpersonal trust for a long time. Let’s take a look at free and open source software development as an example of how these two kinds of trust interact.
Human factors
Free and open source software (FOSS), like software in general, is typically developed by teams. Building trust and shared understanding between a large number of developers can be difficult even if they sit in the same building. So how does it work at all, let alone enable the creation of some hugely successful (and huge) pieces of software like the Linux kernel, between random people over the internet ?
Someone unfamiliar with software development might assume that surely it must be because of automated error-checking done by computers. That’s certainly part of it. There are automated analysis and validation tools which can catch certain types of errors and badly formed code. Automated tests are commonly employed to ensure that changes in the code do not accidentally break existing functionality. However, automated tools can’t really tell whether the code on the whole is trustworthy, well-designed, or useful. While software may be “eating the world”, software is not eating software development yet.
If anything, for more than a decade, the software industry has been moving away from bureaucratic, process-oriented approaches and towards recognising the importance of interpersonal trust: “Individuals and interactions over processes and tools”, as the Manifesto for Agile Software Development puts it. So, how to enable this on the internet?
Building communities to build software
A key reason why apparently random people collaborating on the internet are able to produce good, even great software is, in fact, that most of the people involved are not exactly random. Sure, there are “drive-by contributions”, which can add up to large numbers, but the majority of code in typical FOSS projects comes from a core team of contributors. In bigger projects, some of these people may be paid by companies, nonprofit organisations, or the public sector to work on the software full-time. In smaller projects, there might be a few developers writing code in their spare time. In both cases, by working on the projects for extended periods of time, the core contributors learn to know each other and build personal reputations and trust.
When a developer submits their code for inclusion into the project, trust is at play in more ways than one. The developer trusts that the project is competently managed and something one would want their name associated with. The project maintainers, on the other hand, will take the trust built up between them and the developer into account. Does this person have a reputation for writing sloppy or stellar code? In the latter case, they are probably quicker to accept any complex piece of code coming from that person.
In very large projects, like the Linux kernel, the code base is far too large for any one person — even if said person is named Linus Torvalds — to understand in detail. Linus Torvalds can only manage the code by managing people. He knows and trusts the key people involved — the maintainers of various subsystems — and can rely on their judgement on details he himself does not have full understanding of.
Substrate or substitute?
What is the role of technology, then, in this process of building trust? Apart from the useful but limited role of automated tools mentioned above, technology would appear to work best when it’s cultivating instead of replacing interpersonal trust. Linux would not have been written without the internet. Thanks to cryptography, it is possible to communicate on the internet with more confidence. Let’s say I trust Linus Torvalds completely in the matters of software and would not hesitate to run any program he has written on my computer. How do I know, though, that the software I’m downloading is, in fact, coming from him and has not been modified by some malicious third party? Cryptographic technology helps us solve these kind of issues. Instead of having to trust the entire internet, we can choose the people we trust (in this case, Linus Torvalds, who in turn chooses the people he trusts).
Contrast, then, this “web of trust” approach of FOSS to a more impersonal approach taken by most cryptocurrencies. Yes, Bitcoin enables decentralised monetary transactions between strangers over the internet, which is certainly no small accomplishment. However, money alone — even “magic internet money” — is not sufficient to build communities. When this impersonal, algorithmic model of trust is applied to building decentralised autonomous organisations, the results — like The DAO of Ethereum — suggest that algorithmic governance is no substitute for actual human governance. In fact, Bitcoin itself, in addition to being a decentralised network, is an open source project. Forks can — and have — happened. The trust holding Bitcoin together is not just the impersonal trust in cryptoeconomics, but also personal trust in the good judgement of the core developers.
The lessons from FOSS projects like Linux paint a different picture of trust compared to typical selling points of blockchains. Trust is something that is cultivated over time in communities and interpersonal relationships, not technological pixie dust that can just be sprinkled on anything. However, certain kinds of technology can indeed be very useful for enabling such communities and relationships. When designing or choosing to use trust-enabling technologies, we should ask ourselves the question: does this technology allow us to choose to trust people? It is certainly useful to be able to prevent some types of antisocial behaviour by design, but good fences alone are unlikely to make good neighbours (or good software).
