> decentralization never seems to work
Not true, and there is many technologies, both new and established, which are fundamentally decentralized. Bittorrent is the first example that springs to mind. Cryptocurrencies are another example, etc.
Not true, and there is many technologies, both new and established, which are fundamentally decentralized. Bittorrent is the first example that springs to mind. Cryptocurrencies are another example, etc.
The issues involved with everyone pulling from everyone, dealing with merge conflicts, etc in a distributed way with no agreed upon, central, source of truth seems fairly implausible for any reasonably sized team but I'd love to know if there are gitflow style workflows for this that make it easier than it first appears.
Even in centralized workflows, the decentralized core of Git makes things better.
You've never had a central repository go down and then pulled from the person sitting next to you? At the last organization I worked with, this happened multiple times. And when Microsoft bought Github and a bunch of people panicked, a lot of them were able to move to Gitlab (even without deleting their Github repos) specifically because the technology behind Git allowed you to add multiple remotes.
The article makes the point:
> No system is simply decentralized, full-stop. We shouldn’t expect any to be.
Git is the same way. Even with Linux, where patches are sent around using Email and there is no central repository that has every in-progress effort, there's still ultimately one person signing off on the final release. But that doesn't mean that there aren't decentralized parts of Git that are very, very useful, specifically because they are decentralized or because they allow you to fall back to decentralized workflows when necessary.
One of the things this article is getting at is that people treat decentralized as a binary state -- you either have one source of truth that coordinates everything, or you have complete chaos. Most decentralized systems are in the middle; they allow centralization, but also support fallbacks for when that centralization fails.
Git's branch strategy is another good example of this. Most Git systems use a master branch. But the value of branching is that you can have diverging code states that aren't yet centralized into a single location. You can fork off of master and have a completely parallel codebase, if for some reason you need to. You can have your release in a decentralized state for a week, where multiple people are working on separate branches and there is no single branch that has everyone's changes, and then you can re-centralize everything to master or a staging once you feel comfortable with the features you want.
There is in theory nothing that prevents an issue tracker to be decentralized in the same way git is, but so far that hasn't materialized. You can export issues from github as .json, which allows you to transfer some things over, but users only have a username in those bug reports, not an email, which makes it impossible to contact them after a move to gitlab.
When one of the largest torrent sites go down, the torrents do not go down with them. You can still seed them and indeed many people continue doing that. Others can still download them provided they have the torrent file or the magnet links. These sites are usually archived, you can still have access to such magnet links. Plus, there are many torrent search engines, and so forth. You can use as many trackers as you want, or none! These torrent sites are really just aggregators for better discoverability. Plus there are trackerless torrents nowadays that use DHT in which every peer acts as a tracker. This is called decentralized tracking, a trackerless system. I do not think that comparing this to git or GitHub makes any sense.
But the actual thesis of the author is that you can't decentralize "everything" (the HN title has the straw man though). Even in successful decentralized networks, some aspects (usually governance) stay or become centralized. The author easily succeeds in making that point because everyone already agrees with it.
Whether that's a problem worth discarding the whole movement towards decentralization is mostly a matter of preconceived opinions.
Imagine if someone said, "competitive markets aren't always possible, and over-saturated markets are usually bad for consumers anyway. Therefore, people who advocate for more competition with ISPs or who try to block mergers are just being unrealistic. A competitive market just isn't possible at scale."
Yet plenty of people will argue that Git's goals around decentralization ultimately failed just because Github is convenient and widely used. Or that because social media platforms often naturally trend towards centralization, that efforts like Mastadon are bad for consumers and are a waste of time.
That many real-world decentralized systems have some centralized parts shouldn't be seen as unusual, and it isn't some kind of killing blow to people who advocate for more decentralization. This is the world working as expected.
If the only two states of government possible were anarchy and totalitarianism, then totalitarianism might be the better choice. But those aren't the only two governments possible. Similarly, decentralization is not a binary state. You can use centralization and decentralization in tandem to cover for the flaws and gaps of functionality that both strategies have.
The Internet is decentralized to the extent there's no single "Internet company" which can kick you off.
Various companies try very hard to make you forget these things.
The very fact you think it is impossible to reach end users without using Google should highlight just how much they have cornered the market.
Remember, internet search was not always a given, and the worked just fine.