Why ...
distributed cloud computing didn't stop Amazon, Microsoft, and Google from dominating the market;
decentralized source control didn't stop GitHub, BitBucket, and GitLab from consolidating that market;
open source code didn't prevent Facebook and Google from dominating digital advertising;
trusted certificates don't prevent hacking and other malicious behavior;
and trust-less algorithms don't stop people from lying.
"Git is a distributed, decentralized source control system"
In contrast to the old, centralized systems, where masters knew they were masters and replicas knew they were second-class, and they even ran different code... a Git server runs the same Git as its clients, doesn't even know that it is a server because its role is defined elsewhere, and doesn't care if one of its clients acts a server sometimes.
I remember, first rolling out Git at companies that had been used to centralized repositories, two opposite but equally wrong reactions:
- If we adopt decentralized version control how do we send clients to the right version of the website? How can a company even operate if every employee's code is equal? How do we find and fix bugs? It's madness.
- Well, my code works on my machine. If it doesn't work with the changes the rest of the company made, who's to say whose fault that is? When was the last time I rebased off of master? Master should rebase off of me.
This is, of course, a conflation of the engineering terms "distributed" and "decentralized" with the regular-world concepts.
If you're familiar with Git and have been using it in the real world, the answers to both questions should be fairly obvious (though, you might be surprised how many engineers that doesn't include).
- Of course there's an official version of our software. It's the version that we put on the website. Period, full stop. All switching to Git means is that the algorithm doesn't care what version we push to our website, or even that we push any version anywhere. We can test individual change sets and merge them directly into master, or we can periodically merge master into release, or we can create a new branch a month before every deployment and release that. We can let people push directly to the main branch, or we can review in pull requests. Git itself doesn't know or care about our workflow.
- That's a management decision. The fact that we switched to a version control system that doesn't inherently differentiate your code from any other version doesn't mean that your manager has to stop doing so. You're responsible for making sure your changes play nice with the changes everyone else made since you last looked because your boss says so. Git does allow us new freedom to more easily merge in changes and have someone other than the authors take responsibility for getting the code to all work together, and some projects do indeed operate that way, but it doesn't force us to.
Git is so popular and widely used because (among other reasons) it doesn't contain any opinions about management structure or workflow - that allows it to be incredibly flexible. This is very different from actively containing an opinion that there be no management structure. And it certainly doesn't have embedded in its code some nebulous but idealized management structure in which we're all free and equal.
Linus Torvald's code might not make a value judgement over whether my version of the Linux kernel (in which I introduce bugs just 'cuz) is better than his, but the rest of the world sure will. And so, I suspect, would Linus, if I sent him a pull request.
Likewise, the same is true when it comes to markets.
Plenty of distributed, decentralized algorithms exist in concentrated markets because those words mean fundamentally different things when it comes to computer science. Distributed software allows for execution across multiple machines, decentralized algorithms have no notion of greater authority. In contrast, we expect a distributed political system to have de facto local control. We expect a decentralized market to have robust competition.
We might be using the same letters, but the words are different, depending on context.
There's no shortage of companies today claiming that their code/algorithm/blockchain/database will enforce "open" or "democratic" data. They're wrong.
There's nothing to stop me from reading from the open data store and then ... not ... writing to it when I'm supposed to.
This has been tried before, with open source code. People realized that code couldn't enforce open-source-ness, so they created stuff like the GPL - which exists because code can't enforce values, so they're embedded contractually. It's not perfect, but the legal system, unlike math and programming, is rarely conceived to be.
The trust examples tend to be more obvious (at least these days), but still not always, and not to everyone.
A trusted certificate (green lock) means that your traffic to and from the website you're on is encrypted, and that hackers.com isn't masquerading as gmail.com.
It does not mean that the internal security of the site meets any standards at all, or that they're not willingly selling your data to Cambridge Analytica. It's not a stamp of approval on your products, licensure, compliance, or even that you're a legitimate business at all.
I could easily set up a gmail.scoutcorpsllc.com, and your browser would tell you that you can trust that it's actually me, but I'd advise against typing your gmail password into it. A lot of scams revolve around people who are less tech-savvy conflating that initial, specific, definition of "trusted" with a broader, less specific one.
Public-key encryption means that you don't have to trust someone in order for them to securely message you; you don't have to share your ability to read your messages with someone who wants to write you one, but ... no one really thinks that I can't lie in an encrypted email, right? But people (in blockchain-land) do seem to forget that a tamper-proof trust-less distributed ledger of land deeds doesn't do anything to prevent the corrupt local official who simply lied in the first place.
P.S. This post isn't about Blockchain, cryptocurrencies, or ICOs, but that space is rife with investments driven by the (often but not always intentional) false narrative that words like "decentralized" and "trust" in a technical sense mean what you want them to mean outside of it.