The whole darn internet was built to be decentralized. And yet we all use GMail, the same handful of DNS servers, the same short list of major trunk hubs, the same shrinking list of bitcoin mining pools, etc.
The whole darn internet was built to be decentralized. And yet we all use GMail, the same handful of DNS servers, the same short list of major trunk hubs, the same shrinking list of bitcoin mining pools, etc.
The solution for me would be packages which hold my hand through the install process to make installing such software as easy as possible. Obviously, packaging software in this way would take way more work, and people qualified to do this would rather package more software rather than hold some noob's hand.
That being said, hopefully in the future when software gets even more mature, repackaging will become less necessary, and this type of packages might become more common, allowing decentralized systems to be easy enough to set up that they become common.
It's true - I could set up my own mail server, my own Git hosting etc etc, but why would I? I'd rather just pay Fastmail for email and GitHub for some private repos.
Also, you could also instead pay people to develop easier solutions for self-hosting. Or you could buy a service from a smaller hosting provider. There is more than the extremes of "google is email" and "I have to hand-carve my mail server".
Centralization happens because someone ends up doing it better than everyone else, and so everyone chooses to use that provider and they become the dominant force.
I get the need for diversity, but as an individual, I am going to choose the best provider, even if they are the biggest one.
Maybe, but the world really is too complex to break it down to such a simple question, it obviously is a tradeoff with many more factors to consider.
> Centralization happens because someone ends up doing it better than everyone else, and so everyone chooses to use that provider and they become the dominant force.
Well, but does it? I mean, no doubt such cases do exist, sure, but if you really look into how companies do become dominant, that is only one of many factors, and sometimes not even a necessary one.
> I get the need for diversity, but as an individual, I am going to choose the best provider, even if they are the biggest one.
Well, but how do you evaluate what "the best provider" is?
You might be comparing functionality, say. Or price. Or speed. Or any other property of the product as you could now choose to use it. And obviously all of those are important things to consider.
But my suggestion isn't that you should follow some abstract moral teaching because some ideology says that this is the right way, and the only right way. My point is that it may even be in our very own interest to choose a solution that is inferior in terms of current functionality/price/speed/whatever because there are long-term costs attached to the superior solution that actually make it more expensive, all things considered, than using the inferior solution now. So, arguably, the currently technically inferior option with a lower total cost would actually the better solution.
To maybe make it more practical, but without any claim to being realistic, the numbers are obviously just made up: Let's assume that using Gmail saves you 10 minutes every day vs. using Thunderbird. Now, Gmail is privately owned, so if everyone chose to use Gmail, they would effectively have the monopoly over email. At that point, they have every incentive to add proprietary functionality for the sole purpose of making interoperability difficult. Which could prevent a new competitor from entering the market what would invent a new email workflow that would save you a further 10 minutes every day. Now, does choosing Gmail actually save you time overall? And is Gmail the better product if using Thunderbird now would lead to you being able to save 20 minutes a days a few years down the road?
This isn't about some sort of diversity for diversity's sake, this is about which of those options actually is in our very own long-term interest, and monopolies have a strong tendency to be very much not in the interest of the customer.
So, really, if anything, I would suggest that there is a moral obligation to watch out for people/organizations accumulating too much power and to prevent them from obtaining it if the long-term damage that that concentration of power can do is worse than the short-term benefits obtained from using their offerings.
Well, in the case of GH vs. GL. Existence for one (GH actually existed before GL and was usable since the start), not having to self-host anything for second, everyone using it for third.
> this is about which of those options actually is in our very own long-term interest
Based on your own example, if I have previously used TB for a year and then migrate to the new product that saves me twenty minutes the sum is ten minutes saved and a lot of nerves lost due to slowness before.
If I had used gmail during that time it's going to take the same amount of time I've already used it for the benefit to zero out, if I kept using it until TB became good and then migrate I've only won.
As an user I already get a lot of bad UX, I do not want more voluntarily.
You are assuming that you have that option. Once a monopoly is established, you don't have that option anymore. Also, while you support one solution, you decrease the chances of other solutions succeeding. If you pay licence fees to Microsoft instead of buying Redhat boxes, that has an impact on whether Redhat is better a year from now.
Not moral but, I’ve noticed that things all seems to be tied to a pendulum that swings back a forth. Pushing in the opposite direction is required to attempt a balance.
It runs in containers and provides a webserver, webmail, caldav, spam filter, updater... I have made an ansible role that will back up to a Borg repository every hour as well as restoring the latest backup upon installation if you need inspiration: https://galaxy.ansible.com/coaxial/mailcow/
If you use your own domain name, you can set mailcow to sync with your Gmail account so you have all your emails in mailcow and then pull the plug on Gmail without losing anything. I find it runs pretty well for me on a server with only 2gb of ram.
I do use Github regularly however, but it's because of the "social network" aspect. If you want to interact with many open source projects it has to be on github nowadays. The network effect is strong.
Always start by setting up a strict firewall and then whitelist cautiously anything you need as you set up the rest. Don't bother with SELinux. Be very careful with your Postfix (or if you're masochistic, sendmail) config as it's rather (needlessly IMHO) intricate and it's easy to end up with a configuration that appears to work but is extremely broken. In particular if you end up configuring an open relay by mistake spammers are going to have a lot of fun with your server but you'll end up blacklisted everywhere.
My "stack" is nginx for web, postfix + dovecot + spamassassin for email (+ roundcube when I wanted a webmail). Postfix was by far the trickiest to configure, although if you find a good tutorial online and can spare a couple of hours to understand how it all works it's not too bad.
Fortunately, rolling your own git isn't nearly as hard, and the percentage of people who could run a node compared to total users is larger. Hell, every person using git also has a fully-functional, secure and standard self-hosting stack already installed. Getting a GitHub-like web interface is similarly easy. This fundamentally reduces the risk of centralising, which conversely means that people don't have any qualms about using GitHub, since they can leave at any time. (Less true of issues, PRs, community, but hey.)
In either case, centralising has large benefits: one for handling complexity, one for giving you a community.
When you want decentralisation, it's because you don't want a single entity controlling what the ecosystem becomes. The circumstances where this is true are typically big utility-like things, where we care more about guaranteeing that water and electricity exist than the top end of providers' profits. Email is like this. You would never build your own power station, just like these days it would be bordering on negligent to use anything except Office365/GSuite/etc as your corporate email host. Lots of jurisdictions will create highly regulated marketplaces so you don't get Enron-California-style anti-competition. When things get that bad in Gmail-land, let us know.
[Edit: I was pretty snarky just there, but not at you! It was in general, I swear.]
We also offer a hosted service (GitLab.com), if that's more convenient.
If you’re going to complain about something, at least pick something legit like managing backups or server uptime. The install itself couldn’t be simpler.
As if installing gitlab was the last step in setting up a highly available and disaster safe git server.
For disaster recovery, I put everything in ansible playbooks and roles. The role also takes care of setting up hourly backups (with Borg) and will import the latest backup when setting up the service. Because backups are separate, I can delete the last couple of backups if they've been compromised.
It's obviously not as resilient as using the centralized equivalent, but it feels like a decent trade off.
Still iterating so discussions welcome.
Well, maybe, depends on what you're depending on that service for. However, we were talking about large scale centralization v decentralization. If you took everything currently on GitHub and moved it to a bunch of different self-hosted servers, you would have a problem. Many _do_ depend on what's there on GH.
Even if it's not critical, it really sucks to want something and not be able to get it for 2 days because Jim went on vacation and his server crashed.
> For disaster recovery, I put everything in ansible playbooks and roles. The role also takes care of setting up hourly backups (with Borg) and will import the latest backup when setting up the service. Because backups are separate, I can delete the last couple of backups if they've been compromised.
> It's obviously not as resilient as using the centralized equivalent, but it feels like a decent trade off.
The issue isn't that it cannot be done, it's that centralized services mean _I_ don't have to worry about it. I don't want to be a server admin; I just want to store my code in source control.
It was not always that way, they have made huge improvements on the install path over the last couple of years.
curl -s https://packages.gitlab.com/install/repositories/gitlab/gitl... | sudo bash
For EE:
curl -s https://packages.gitlab.com/install/repositories/gitlab/gitl... | sudo bash
If this is the case then the internet may end up more centralized than previous forms of media and communication. I hope that's wrong, but it seems to be happening right in front of us.
There's nothing wrong with using Gmail for email hosting if you have your own domain name, it's easy to then switch over. But if you use an @gmail.com email address and Google decides to ban you, you're screwed.
Same story with Facebook, there are quite a few people that I would possibly never be able to contact again if Facebook banned me or them. This isn't a new problem caused by Facebook though, in previous years there was the same problem with email, and before that, if someone changed their address or phone number you'd lose contact. There are actually people who I lost contact with who I regained contact through Facebook.
Anyway, my point is that centralisation isn't bad if it's painless to decentralise again. Git and Github are fine, at work we could switch to a self hosted solution or Bitbucket in a fairly trivial amount of time. Same for our work emails, we could switch form Gmail to another host with fairly minimal disruption. Centralisation with locked ecosystems, like Facebook, are not good.
You can loose control of your domain too. And if someone else snatches it up they could even read your newly incoming email. I'm willing to bet when gmail bans an account, they don't recycle it.
Anyway, my point is that centralisation isn't bad if it's painless to decentralise again.
I'd love to see GitHub (and GitLab) offer a custom domain name option which would proxy HTTPS and SSH clones via a company's custom domain (e.g. code.example.com) to GitHub's hosting. That way, if a company needs to move away from GitHub (or GitHub goes away), developer's references to some company's code is not stuck pointing to some stale github.com domain.Hosting such a proxy (and the repos) takes infrastructure, time, and experience to secure and make available, so from a user's perspective it's great if a company does this as a service as long as you provide the domain.
I do quite like the idea of using DNS instead of standing up proxies.
It's like there's a middle-ground between everyone building their own automobile, and there being only a single car manufacturer on the planet. So long as have you have a few players who are genuinely competing, and you have the option to switch between them without paying an excessive penalty, then it's a good thing that a certain subset of people are working hard on building better cars than you ever could tinkering away in your garage (although you should still be allowed to do that, if you so desire).
What this requires is for governments to provide a framework of standardisation, access-to-data, data-transferability, and antitrust enforcement that allows a healthy competitive environment to emerge and persist, without either allowing a monopoly (or a cartel) to evolve, or overburdening everyone with regulation.
It's a difficult balancing act, even in more traditional industries, and anyone who presents a too simplistic "more regulation!" or "less regulation!" answer to it isn't being honest. Tech presents additional challenges because it's newer, and because it's evolving rapidly. I think it will take many more decades for the necessary level of technical understanding to metastasise through policy-making and civil administration realms until you get effective control of tech markets, although laws like GDPR are an interesting start.
While not quite decentralized ownership, Wikipedia is at least a non-profit that everyone contributes donations to. Where's the Wikipedia for code? Where's the non-profit donation-based social network?
It's economics 101, really: division of labour and economies of scale. A company like Github can build and sustain capabilities that are flatly uneconomical for their customers to build themselves.
In terms of strategy, Github's lockin doesn't come from git. It comes from everything around it: issues, pull requests etc. This functionality can be replicated, but data has inertia. The more you have, the less you want to move it.
For an instructive parallel, consider how easy it is to use AWS Lambda with all of AWS's data-centric services.
Sorry, tangential thought, I agree with your main point, and the others are much tougher.
How so? Centralization is merely enforced by the government and incentivized by the system it exists in.
Eh, I have Gmail, but I barely use it.
Regarding DNS, that's only because the DNS provided by ISPs is being tampered with or runs downright awful.
What happens is people copy each other's behavior. X (friend of Y) starts using Facebook. Friend of X starts using Facebook as well. But X never looked into the alternatives (who has the time for that plus everyone is using Facebook); its only because of other people that they started using it. It is called the network effect [1] though we can thank the early adopters for feeding that hype. I see it as a sign of capitalism/optimization.