There's no obvious alternative right now. Someone should build one. It's not super easy. There are big and interesting political and technical questions... which GitHub conveniently sidesteps by just being a central server.
Indeed, we had this, in the form of NNTP and older news servers; those servers essentially exchanged copies of whatever was posted from around the Internet. If there were no news.ycombinator.com, there could still be a wide variety of servers that constitute “hacker news” around the world, that come to a general agreement on what the collection of posts should be. At any instant in time, not all servers will be 100% identical but for all practical purposes they would be.
>Indeed, we had this, in the form of NNTP and older news servers;
You're focusing on the technical aspects. The other forces are social and economics. Both of those lead to centralization.
Take your example of Usenet news groups. Yes, in a technical sense, it's decentralized but once you get economics/money involved, what happens? My ISP like Verizon doesn't carry all newsgroups (e.g. exclude newsgroups with large binaries.) Or another ISP may carry more newsgroups but the retention is 1 month instead of 1 year.
So the economics converges to an central entity like Deja News that emphasizes the archival of usenet posts. Then Google buys them (Google Groups). Google Groups is now "centralized" for finding very old usenet posts. Conceivably, any of us besides DejaNews could have archived the posts but we didn't spend the money on harddrives to store it whereas DejaNews did. Hence, we end up with a centralized archive.
When I had Verizon, their newsgroups feed was very poor. I therefore paid $10 extra to GigaNews because they had everything with multi-year retention. That's another "centralized" hub driven by economics.
Looking only at the usenet RFC technical specs for distributing news posts doesn't reveal how the economics makes centralization emerge.
As for github's centralization...
A lot of us want to host a public git repository. Hmmmm... if github didn't exist, what do we do? Pay for a VPS for $9/month plan and host git on that? What about extra bandwidth costs if it's a popular repo and lots of people are cloning it? That's a lot of ugly financial bookkeeping that we don't want to do since we'd rather just concentrate on programming. Wait -- there's an ABC company out there that lets me conveniently host a git repo there? For free? Sign me up!
That "ABC company" by way of economics and social dynamics has turned out to be Github and BitBucket. And since Github has been winning the mindshare, you get centralization. There is no irony in git-the-tool being distributed and github-the-focal-point being centralized.
I'm really interested in the future of distributed code collaboration. I just think it's not so trivial, and so it's very understandable that people have gravitated towards a semi-centralized model that already works.
Perhaps having something akin to a private NNTP server that requires authentication to post for each open source project, but is publicly viewable. These news servers could be configured to send IHAVE <article> to other news servers to increase visibility. There could be a newserver like gmane to aggregate the feeds from each of those private news servers.
If you could get an authentication system that could work across those news servers, then you could have a decent system for keeping up with and contributing to open source projects.
'Moderated' means that all postings to the newsgroup go to a mail
address (e.g. [email protected]) instead of appearing
in the newsgroup directly. The postings are then forwarded via
email to a moderator, or group of moderators, or even an automated
program, who decides whether to actually inject the article into
the newsgroup or to reject it as not meeting guidelines spelled
out in the group's charter.
Proper moderation for anything important would require cryptographic signatures and a solid federated PKI. Maybe the world is ready, this time. :)
As long as you have an actual living conversation, then an open model of development can work... which means it doesn't have to be perfect from the start, and you don't need a beautiful landing page, because you want to attract the hackers and crazy people.
You also want to encourage lots of forks and independent implementations, because if it turns into some big mega-repository with some big bloated thing that includes Scala, Erlang, Babel, Bootstrap, and who knows what other ungodly monsters, then it's just going to become a boring monstrosity.
So you'd start with inviting a few people and then encourage them to use their own servers and clients. Make sure everyone understands that the protocols are in flux because you're trying to figure out together what will work.
The conceptual simplicity of Git would be an inspiration. There are different implementations of Git... but we could be even more obviously amenable to that, by using standardized messaging formats for example.
I think plain text messages, as on Usenet and mailing lists, are the best. You don't have to agree on a Markdown/whatever complex thing. Attachments if you want to send other documents. Hacker News developed consensus formatting for links and footnotes, and we seem to get on fine without inline images and tables and all the other fancy nonsense.
(Just some random thoughts...)
There's a lot of good stuff in XMPP, too. As well as some pre-discovered dead ends.
The distributed/federated stuff is still alive, maybe more than ever. Git is a fantastic example. I push and pull repositories between computers all the time. Often over ad-hoc WiFi, even.
Usenet and all that stuff is beautiful to reminisce about, but we should keep in mind also that it was largely sponsored by universities, corporations, militaries, and internet service providers...
IRC is a great inspiration too. Nowadays people look at it and think "ew, no Unicode" or "duh, it's not even JSON," but considering its resilience, its simplicity, its adoption, it's an enormous, staggering success.
These beautiful projects that started as tiny little seeds by clever obscure Scandinavian hackers...
It's just all about starting a little thing, getting your friends in on it, and keepin' it hella real.
Since the bandwidth funding model has now bubbled down to the consumer marketplace, it seems like the conditions are right for a huge variety of services. Actually that was starting to happen before the web swallowed all other services. Don't get me wrong, the web was/is a great thing, but it severely dumbs down the range of protocol expression. The state of websockets in 2016 is a weak imitation of IRC or MUD capabilities more than 20 years ago (never mind adoption problems).
I guess that's a curse of being "good enough". The better has an uphill battle.
What I like about news readers is how they track new threads / messages. I could pick up where I left off. It encouraged longer term, more elaborate discussions, as opposed to posts that fall off the first couple pages like most web forums.
It's amazing to me that git's power to easily manage distributed software development been lost/forgotten with Github. You don't need a web interface to contribute code. Linux is doing just fine.
You just need git and some sort of communication tool to distribute patches, email being the most powerful, flexible, and ubiquitous I've seen.
I would say that having a private NNTP server (one requiring an account to post) would also work in lieu of email. In fact, it would be better than email because it would allow new members to easily browse list archives. At least gmane already does something like that for some mailing lists.
>Why did people set up systems that depended on the ability to download from GitHub, for instance?
Because if they didn't rely on github they'd have to rely on some other server subject to similar downtime?
Look for instance at how programmers deploy their applications (which are mostly web applications). Are those applications tied to operating system version somehow? Mostly. Are those programmers using this operating system's tools for software installation? Hardly. And why? Because it's not sexy enough, npm or gem are way sexier (despite apt-get or yum being much more mature and robust).
It really takes a long time to feel how and why the OS works and to work with the system instead of against it. Don't expect programmers with vast three years experience to understand their surroundings.
Because this is a bizarre argument. I accidentally make dependencies on specific variants of libraries because I don't immediately need to support other variants and lack examples and/or time to worry about theoretical portability.
I don't use OS specific packaging because it was intentionally written to be non-portable. My learning it is an irrational commitment to keep using an OS at the neglect of all others and even if its distributor changes (or can no longer honor) the conditions of our deal.
> I don't use OS specific packaging because it was intentionally written to be non-portable.
Only if you use it mindlessly. It's not really different to build a package for Debian, Red Hat, Slackware, or Gentoo (been there, done all of these). All it takes is to properly separate downloading sources and building things, which is a good engineering on its own. And guess what you get in exchange? Easy dependency installation, both for development and for deployment.
I hate the amount of garbage and noise created by this. But how many of the good tools we have today wouldn't have existed if people didn't just started coding?
It's full circle to your first phrase since if nobody was using nobody would write redundant/worse tools. Man I miss the time programming was only my hobby.
Also, I am a hobbyist programmer. I also know that git was created by Linus Torvalds, it's a DVCS (although Torvalds calls it an SCM), and it's based on a DAG (directed acrylic graph), which is a directed graph with no directed cycles, and excellent for modelling causal relations. I can explain to you the difference between a rebase and a merge. I know that git uses SHA-1 hashes to identify check-ins internally, as a data security feature. I know that checkins and other objects are stored in the .git folder at the repository's root directory. I know that these objects are garbage collected, although the frequency at which they are escapes me. I know that, despite common belief, git commits are immutable, but also that the git history is not. I know that git was inspired by BitKeeper, after the incident that caused the linux source to be moved away from that system, because Linux got fed up with tarballs and patches, and hates CVS with a fanatical passion. I know that git had three design goals: distributed, fast, and guarantees that you get the same bits out that you put in. And I've have several years of causal experience with git, using probably one tenth of its functionality.
I may not be able to recite git's internals at you, but I know it's features (to an extent), I know the tools, and I know the reasoning. And the functionality sure as heck isn't magic.
What I tell you back: you probably don't need it, you're just being very, very lazy, which will cost later in bugs in those dependencies, and it's not that easy to fix a bug in a dependency.
Additionally, it's not that difficult to make a package with that dependency. I routinely do so, both for things other people wrote and for my code. Sure, it's not as easy as adding a line in package.json, but there should be some friction in adding a library to a project, so the library would justify itself. Keeping many dependencies is very expensive in the long run, but short-term is somewhat beneficial. Look at how it works for Node.js and gems and Python packages: every library needs its own `map()' function implementation (or anything else similarly trivial), so typcial application requires few dozens of other libraries.
Personally, I use NPM because NPM does local versioning, so I will never end up in dll hell.
Also, NO, NEVER WRITE A PACKAGE THAT HAS EXPLICIT KNOWLEDGE OF A DISTRO PACKAGE MANAGER. If you do, you are being an asshole. If you want to depend on a distro specific package manager, document your dependencies, and just expect them to be there. Because not everybody uses your package manager.
People get so bizarrely bent out of shape over npm dependency quantity rather than ease of use.
The physicists are trying hard to reverse engineer it though.
"Bugs Everywhere is a “distributed bugtracker”, designed
to complement distributed revision control systems.
By using distributed revision control as a backend for
bug state, we gain several convenient features: ..."
Much like key servers allow people to determine authenticity in a somewhat-decentralized way, there ought to be a similar way of determining the “authentic” sites for various projects/people or the official places to log issues, etc. Then, the whole network can figure out where to find things, whether or not GitHub or something like it exists, and we can stop asking or expecting GitHub to provide every feature that we need.
As one commenter on the page put it, GitHub is a place for posting a sort of software résumé and is an “expected” way to determine what people have contributed to. Why? Git itself is decentralized; the whole point was supposed to be that somebody's code might be almost anywhere...and yet, an ecosystem of centralization emerged.
Similarly, when GitHub went down awhile back, all these things were affected. Why? Why did people set up systems that depended on the ability to download from GitHub, for instance?