[bob1029]

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.

[p5a0u9l]

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.

[bob1029]

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.

[p5a0u9l]

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.

[goseeastarwar]

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.

[Existenceblinks]

> 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.

[indymike]

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.

[bob1029]

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.

[indymike]

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.

[gfody]

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.