Hacker News Reader

Comment by dsign | Hacker News Reader

We kind of need this yesterday... what's the point of having a decentralized git if the issues are centralized at Github? (which, not to make too fine a point of it, is owned by Microsoft). Even if you host your own Gitlab, there is always that day when the hard drive of the server fails and the ops have to spend a weekend restoring backups while changing hosting company because who crashes the hard-drive of an expensive VPS anyway...

I hope Radicle gets a lot of funding and tons of adoption.

View on HN

We use Github and we are not that interested in the decentralized aspects of git itself.

The low-friction UX and integration of issues/PRs/code makes it lightyears easier to ramp new developers than if I had to sit down and also explain Jira & Jenkins to them. The fact that git is centralized or decentralized crosses our minds precisely zero times per week.

In the absolute worst case where Microsoft somehow loses everyones' issue/PR/project data (assuming non-enterprise cloud hosted account), we could still rebuild with whoever has the latest master copy on their local. Presumably, one of our developers must have made the latest commit so this should work out always. We have a process where we include the issue numbers in our commits, so it would be possible to reconstruct a large portion of these with inference across commit history. Personally, I trust Microsoft to safeguard our business data more than I trust our 7 person team w/ a $2000/m AWS budget.

Ultimately, I think the objective of making all things around your source control technology look & talk like your source control technology is a huge mistake. Issues and code are completely orthogonal things that intersect in very narrow ways. These intersections are hugely valuable, but we are not interested in aligning the planes of functionality.

this is naïve. the problems being addressed do exist, independent of whether this particular solution will work. that’s great that the status quo is working for you, but it’s silly to then assert that progress cannot be made.

Well maybe our "naive" approach might be worth investigating. Because we put so little time into ridiculous missions like "distributed issues because git is also distributed", we are able to focus more on the product, customers, and processes. You know, things that actually drive business value and pay out everyones' bonus checks at the end of the year.

We have actually considered doing a complete in-house implementation of the things that GitHub handles, because we do already have an in-house management system that integrates with GitHub's API. But, we realized that we would then be in the business of maintaining what is effectively the GitHub product for a market size of 1 customer.

i’m saying it’s ok to be pragmatic and fully accept that you are Microsoft’s target demographic. they’re solving the annoying bits so you can focus on what’s important to you.

but, that’s not the end of the story. there may likely be gains found with new innovations.

companies like github are not incentivized to revolutionize “what works”. they’re incentivized to get you to rely increasingly on their services. and as long as that works for you, great!

i’m just saying, don’t discount efforts made to make github obsolete.

The nerds (I say that will all due respect) will fight your stance on this until the end of time, but of course you're correct. There have been discussions of distributed GitHub since the day the website launched, but the concept will never take off. 99.99% of developers understand the tools are a means to an end, not the thing worth focusing on.

> and pay out everyones' bonus checks at the end of the year

Yes. This is understated. Poor(financially) developers need to make money with lowest resistance(cost). Then, when you have enough for yourself and family, you can help or join rebels to fight for whatever you think is right.

Disclaimer: I love Github. From a commercial development standpoint (ie. my day job), it's fantastic.

BUT: What a lot of developers, myself included, feel like is the source control in git is great. The project management tools (issues, actions, etc...) require centralization of certain processes, that for some projects (open and closed source), don't fit well. Sometimes the 'how it works' is a bad fit. Other times, it's where it has to be to work. For example, running CI on a container on Azure from actions. Yes you can move where it runs. But for some projects, localhost is where that should happen. I'm really happy to see people working on this, because it will be just as transformative as git and Github has been.

I argue that centralization of certain processes is the entire point. How the hell are you going to manage a complex software project if everyone has a different version of the issues pertaining to it? Simply seeing an issue comment instantly update in GitHub as I am scrolling through has saved me tons of aggregate hours in wasted time on changing requirements.

First, I'm not arguing :-), just sharing. If I'm using fossil, I just do. Fossil is built by the people behind sqlite, and issues, wikis, etc... all of the pm stuff is baked in. Tickets that are referenced in check-ins are synced. This improves on github: if another dev has worked on a ticket and their branch hasn't merged yet, the ticket update is visible. Fossil also allows for heirarchal management structures, and so on. Incidentally, fossil's timeline is incredible.

Not saying that fossil is going to replace git/github. Probably not, but there are ways to solve simple information management problems that don't require a centralized, subscription service. By eliminating that, you open the door to much innovation... In the meantime, I've got a pull request or two to review over on Github.

i think fossil has the better architecture and it would probably take off if the baked in webapp were as polished as github. somebody should fork fossil and make a github clone.

I always find it comically ironic how the industry basically centralized a version management system (git) that was inherently designed to be decentralized. "Git is so great! Let's add these higher level project management features but let's do it in a centralized model!"

the industry aggressively seeks centralization. One browser always ends up taking huge amounts of market share. A small number of sites end up being hubs for large amounts of activity. We then spend forever trying to put the toothpaste back in the tube - federated social networks and chat, stuff like this.

I don't think that's any more ironic than it is to point out that LLVM is backend agnostic, yet we always end up hooking it up to backends that lock the end result to a specific architecture. It's not ironic; it's the advantage of the design.

In git's case, its decentralized nature ends up being an advantage because it decouples centralization from the VCS itself, which has allowed the centralized aspects of code and project management to evolve independently and be tuned to specific use cases.

I think the centralization comes from convenience. Building a good, decentralized UX is a lot harder than making a centralized one (evidence: almost every attempt at P2P networks.)

Physical infrastructure itself needs to be federal. I believe that’s the most economical solution. But it could be virtually decentralized.

Can't you just serialize all issues into the repository and then write scripts/hooks to sync them in/out of textfiles in the repo?

This was attempted multiple times in the past. None succeeded, in large parts because at a fundamental level issues are a synchronisation point, making issues part of the repository adds overhead and complexity but doesn't really give you anything, and furthermore it increases complexity for reporters.

Pagure does something like that: https://pagure.io/pagure

All the issues, wiki, PR review are stored in Git as well. You still need a Pagure instance (that you can self host if you want) to provide the web ui, but you can easily just clone the repo and put it to a different instance, keeping all your metadata.

I’ve used git-bug[1] successfully in the past for something similar but more ergonomic.

1: https://github.com/MichaelMure/git-bug

I know of an attempt to implement an approach to track issues and code in a decentralized manner with SIT[0]. Unfortunatlely the project seems to be dead.

[0] https://github.com/sit-fyi

Reply on news.ycombinator.com