Hacker News new | ask | show | jobs
by ericfrederich 3168 days ago
I've said it before and I'll say it again... It makes zero sense to centralize something that was meant to be decentralized.

We need issues, pull requests, comments, milestones, wiki, etc... all to be decentralized. No reason this stuff cannot be modeled using existing Git objects.

GitHub, GitLab and BitBucket are extremely similar. Almost 100% overlap, you could use the lowest common denominator between the 3 and you'd still have 95% of the features.

7 comments

1. Businesses need a "halp everything is on fire" button that costs them $1000 a second but will fix EVERY issue, (virtually) guaranteed by SLA. Ultimately that is what these orgs provide; the hosting is kind of almost secondary to that.

2. Actually building real-world implementations of "Issues, pull requests, comments, milestones, wiki, etc..." requires top-tier engineer[ing] time and energy to build and maintain. The current Git-on-steroids-aaS approach provides a very successful way to fund that undeniable cost.

I think git-the-tool (i.e. the CLI tool) makes sense to be decentralized as it's at the core. If that tool were built around the idea of a central repository (like SVN), then you cannot escape that centralization (without using what are effectively hacks).

I don't think it is wrong to then choose to have a centralized workflow on top of it. There are tradeoffs for either one, so choose what works best for your team.

For example, I couldn't imagine trying to onboard new client employees to a project without having some sort of centralized single-point-of-truth repository. Getting them to grok GitHub (and friends) is hard enough, sometimes.

> We need issues, pull requests, comments, milestones, wiki, etc... all to be decentralized. No reason this stuff cannot be modeled using existing Git objects.

https://www.fossil-scm.org/ pretty much does this.

That is pretty interesting and does model those things in the same data store. But the data store isn't git objects, as far as I can tell...

"Fossil stores its objects in a relational (SQLite) database file"

Yeah, it fully replaces the whole version control tool.
What software aside from Git Appraise (decentralized code reviews) and Git Dit (decentralized issue tracking - alpha quality) do you know of that could be used to move more of what is kept in GitLab/GitHub/BitBucket databases into Git objects and Git tree in order to make Git decentralized again?
Sounds like you might like Fossil. [0]

I don't see git reaching beyond what it does right now, but a few others do, though they all involve a learning curve.

[0] https://www.fossil-scm.org

You could always use all three. That way, if one goes down, there are still two others ready to take its place.
> No reason this stuff cannot be modeled using existing Git objects.

That's the easy part.

The hard part is discovery and keeping stuff like teams and moderation when you decentralize it. Advancements in Blockchain-tech, IPFS and similar will make this viable soonish-ly, but I think we are not quite there yet from a technological standpoint.

How is blockchain related to this?
Didn't you get the memo? If you stamp enough buzzwords on everything, it magically works, regardless of their relevance to the application.
I see you got the memo that being dismissive of everything that contains buzzwords is still popular ;)

Both IPFS and blockchain are definitely applicable to decentralizing applications. E.g. DSound[0], a distributed version of Soundcloud is built with IPFS + a blockchain(not necessarily a fan of STEEM though). There could just as well be something analogous for Github, Bitbucket, etc..

[0]: https://steemit.com/music/@prc/introducing-dsound-a-decentra...

Blockchains allow for a distributed, mutable permissioned system that are required(?) for features like "Who is allowed to push to this named repository?".

You can also leave stuff like that out, but then you will end up with a system where everyone can only push to their own forks leaving us with a very splintered distributed system. To compensate we would need a much better system for distributed content discovery than anything I've seen so far.

You don't need a Blockchain for that. You just store the public keys of the allowed users on the repository itself.

Giving readable names to repositories is a possible use case, although I'd just use DNS.

Yeah, I guess you are right, a blockchain is probably not an absolute requirement for that. I think though, that decentralized maintenance of open source project would be a logical next step, and a blockchain-based system could certainly be useful there. This could help prevent a lot of stale/abandoned projects from dying where the only maintainers of a project leave it to rot and there is no one left to review PRs coming from the community.
How would the blockchain help there?
AFAICT, blockchain is the new hammer that is the solution to all of the world's problems.