I completely understand why this all happened (centralization is just so easy and convenient; federation is hard), and it was probably inevitable in its timeframe, but I also wish it wasn't so. It's not quite what we imagined when we made the leap to dscms in the early aughts.
All the good stuff is still in there, though, and it's still as possible as ever to do different things, so it's not a bleak situation.
For example, if GitHub ever started using a very proprietary application, I would just switch over to using regular git, and I'm guessing many others would too.
I'm all in on git in a way that I might not have been without GitHub making it so huge. Without GitHub, we'd probably all be using git at home but SVN at the office.
GitHub then took the server-side bits of git, and effectively built a web-based interface with social features on top. Git itself is still very much a decentralized tool (just add a new remote and off you go), only the social GUI is centralized.
It would be cool if somebody could build "Github over P2P" (I guess with a bit of blockchain, because hype). At that point the entire stack would be fully decentralized.
Well hot dog.
And it uses LISP for scripting? Nice.
Interesting approach to saving state, too.:
One only needs the address of the latest input, the "head", to be able to recover the whole log. The owner of a machine uses an IPNS link to point to the head of the list, and the name of this link is then the name of the machine also.
Thanks for sharing that. Definitely going to give it a whirl this weekend.
The other thing that seems to be lacking, from a quick reading of the docs, is a way to generate pull requests (or "patches" in Rad terms) from a branch, and then merge them on another branch. Obviously you can do it manually in git, but GH is definitely a superior experience.
It's a matter of perspective. My first thought when reading the docs was, "All someone needs to do is slap a GUI on this baby. Good thing the designers made a simple CLI that it could interface with."
They've already done most of the heavy lifting. At this point a GUI is trivial to add. "Terminal–first" doesn't imply "terminal-only". In fact, quite the opposite. I wouldn't be so quick to assume that they don't envision a GUI at some point-- Why not contribute to the project and get the ball rolling?
The patch command [0] has a propose subcommand that describes what you're talking about. It generates a patch from a commit (on any branch, I presume). This can be applied however you see fit. And the checkout subcommand even lets you generate branches from patches similar to GH. What seems to be missing?
> The patch command [0] has a propose subcommand that describes what you're talking about.
Yeah but in the tutorial it says it will fail to work if you are on a different branch from master - I took it to mean that the patch command can only target the same branch it was generated on. If that's the case, obviously the maintainer can then do the manual merge-and-delete routine; I'm just saying that on github it's a one-click operation.
One thing that seems clear is that there needs to be a standard interchangeable format for storing PRs and issues, so that it's not just the point of origin that's decentralized, but the data itself (in case the maintainers vanish).
I'm not really sure how to go about that sort of thing either myself or as a community effort but I'd appreciate any advice from the HN community.
I use Artemis for issue tracking, and that uses maildir (a widely supported standard). I compose issues with Emacs message-mode and render them to HTML using mhonarc.
Uh, thanks but no thanks. I thought we had learnt that the honor system does not scale.
Linus didn't want to achieve a change in workflow of kernel development, he just made a tool to make which would ease the pain, Linux development was decentralized since forever.
I still wonder if Larry McVoy feels sore that git basically destroyed BitKeeper and became what it did. “It could have been me” and all that...
Tickets and the wiki are stored as part of the repo and don't depend on a completely separate web interface.
I prefer Gitlab for a multitude of reasons but since all the action takes place on Github, my Gitlab account just serves as a repo mirror.
As an example I think SourceHut is mostly based around email (which it provides a Web UI for) https://sourcehut.org
It's possible many people have forgotten, or are to young to remember, how the ecosystem worked pre-Github. There was sourceforge, which wasn't quite the disaster it is today, but also not very good. But mostly I remember every project using different, often hand-rolled systems. PRs had to be sent in by mail. Every project had their own conventions of where to send patches, what formats to use, what additional information to provide etc.
Just try figuring out how to get a patch into Debian, which is still where most projects were ca. 2005. I won't wait.
I never contributed to OSS pre-Github. These days, I routinely send in a patch for smaller things I encounter a few times per week. Over time, I have also started becoming a more involved contributed to two projects. I doubt this would have happened without the flat learning curve that Github provides.
I wouldn't be surprised if both the number of contributors and total contributions to OSS have soared by a factor like 5x even above just the growth in OSS usage, and Github is the obvious reason for it.
Hypothetically, and, currently, only hypothetically:
If Microsoft is still of the old spirit, then what we see now, would be the biggest "Embrace, Extend, Extinguish" coup, they have ever done.
It won't happen now, it won't happen tomorrow. For that, this would be too big of an effort. But Microsoft is trying big to win back the hearts of "The Community" and "The Market". As people, especially developers, have gotten more clever about the computers, since the advent of the web has made it possible, to live in IT without "getting shown" and "taught" by "Big Daddy" type companies, since all and everybody is much more self-organizing these days, there is much more competition to MS, that has been in the past. So they try to get it back, what they have lost.
* VSCode, is very sweet and candy, with lots of bells and whistles, major software companies writing plugins for it (the most active being Microsoft). As a programmer's text editor it sits right at the core of every development. VSCode, especially, is attractive to people outside of MS Windows (they might use VisualStudio). I am talking about web- and "App" developers. Mostly frontend or mobile. * By buying Github, they bought the "source of all sources". They won't ever own the code, but as long as they own the popular infrastructure, everybody is playing on their grounds. The next step, in two years, or so, may be the need for a MS account to log into Github. They integrate it.
Out of curiosity, what else did MS buy in the last years, that would fit into this pattern?
I share your concerns, but I've also long had the feeling that both NPM and Maven are a security disaster in the making.
Having the dependencies being published from the same place that stores the actual code, gives me a little hope that things will improve from the security and design perspective.
So far I believe that Maven and NPM have failed to deliver on that front.
The dependencies being resolved from the code store provides a decent mechanism to resolve that issue.
But as long as it's being done on closed software, it's going to be hard to move towards a standard.
There are a lot of moving parts to this and it's impossible to distill it down to a single sentence or even paragraph.
Or if you are looking for self-hosted git servers: