4 ms·

> We need to start moving away from them, not move more projects to them. It seems this topic comes up quite frequently on HN. Unfortunately, while it sounds g

> We need to start moving away from them, not move more projects to them. It seems this topic comes up quite frequently on HN. Unfortunately, while it sounds great in theory, no one ever has a practical way of doing this. The main problem here is the user experience. When using GitHub I can find an open source project, copy the URL, pull it down, make changes, push and click a button for a pull request. A little bit convoluted but overall it's a very simple workflow. Now try decentralizing away from GitHub. If you have to add any steps then you increase friction likely lowering the UX and making adoption harder. Now, if you can figure out a way to decentralize a service while maintaining the same level or less friction from the centralized version then you have a real winner and things can start happening. Until that happens the idea of decentralizing things is just going to remain a pipedream. In my opinion, of course. I love the idea of decentralizing things like GitHub I just can't imagine a good UX way of doing it.

mgbmtl 9y ago
I think that works for smaller projects, but for larger projects that require more coordination, have heavy c-i running, etc, I don't think it makes as much of a difference. However, there are some alternatives for larger projects: 1- make sure your community has a business model (donations or other forms of funding) for core infrastructure, 2- self-host a Gitlab instance :-) It doesn't completely take care of decentralisation, but nothing stops from having multiple instances and some c-i duct tape. Github can also make a good mirror.
roblabla 9y ago
There's git-appraise[0] which decentralizes issues and PRs by putting them as objects inside of git. It also features a webui[1] [0] https://github.com/google/git-appraise https://github.com/google/git-appraise [1] https://git-appraise-web.appspot.com/static/reviews.html#?repo=23824c029398 https://git-appraise-web.appspot.com/static/reviews.html#?re...
- david-cako 9y ago
  This is actually the one good way of handling it IMO. Decentralizing git without losing the UX benefits of using a site like github is done by handling it like torrents and packaging everything into the repo/technology itself. The Linux kernel is already part of the way there, it's just the "local client" aspect that's missing, along with a focus on actually making it intuitive and fully integrated into git itself. The repo itself should contain all of the bookkeeping, and git should host a local UI (web and CLI) that allows you to interact with it as you would with github, rather than the send-mail rituals, the relative difficulty of following development on mailing lists, and the "here's how to set up one of 20 different email clients to send mail as plain-text". Imagine get_maintainer.pl and send-mail being replaced with a built-in pull-request-like interface that is disseminated to everyone that pulls from the remote. That's what git-appraise is trying to accomplish. The traditional mailing-list-based development is tried and tested, but at risk of displaying my appy app iPhone youth naïveté, it's really inconvenient IMO.
  - tenken 9y ago
    I think you just described the Fossil dvcs.
snakeanus 9y ago
Sure, the UX might get slightly worse (early on at least) for some users but we are talking about programming related services. I do not think that having to use a well defined and popular standard protocol with the client of their choice in order to create a pull request or an issue would make contributing to a project difficult for a computer scientist. Instead, I would argue that not having the ability to just send a mail/post to a mailing list/newsgroup by using my favourite SMTP/NNTP client without creating any form of account in a property service and without clicking buttons in a slow js-ridden web interface in order to create an issue or post a pull request is a bad UX. > copy the URL, pull it down, make changes, push and click a button for a pull request All of these (except clicking a button for a pull request) are possible just with git, they are not really github nor centralised-only features. > Until that happens the idea of decentralizing things is just going to remain a pipedream. I find sending an email and using NNTP with the client of my choice a lot easier than using a forum and a lot easier than using the github issue/pull request interface. Thus I would argue that this happened many years ago.
bsder 9y ago
> Now try decentralizing away from GitHub. If you have to add any steps then you increase friction likely lowering the UX and making adoption harder. Attempting to justify GitHub as a "win" because git is unwilling to fix its brain-damaged user interface is called "damning with faint praise", at best.
tscs37 9y ago
IIRC Gitlab has some issue on implementing federated Pull Requests, which would allow users to run their own Gitlab instances but still interact with Gitlab-proper repositories as normal.
fagnerbrack 9y ago
"Now, if you can figure out a way to decentralize a service while maintaining the same level or less friction from the centralized version then you have a real winner and things can start happening." Ethereum
gkya 9y ago
There are marketing buzzwords, irrelevant in the open source community.

mgbmtl 9y ago

I think that works for smaller projects, but for larger projects that require more coordination, have heavy c-i running, etc, I don't think it makes as much of a difference. However, there are some alternatives for larger projects: 1- make sure your community has a business model (donations or other forms of funding) for core infrastructure, 2- self-host a Gitlab instance :-) It doesn't completely take care of decentralisation, but nothing stops from having multiple instances and some c-i duct tape. Github can also make a good mirror.

roblabla 9y ago

There's git-appraise[0] which decentralizes issues and PRs by putting them as objects inside of git. It also features a webui[1] [0] https://github.com/google/git-appraise https://github.com/google/git-appraise [1] https://git-appraise-web.appspot.com/static/reviews.html#?repo=23824c029398 https://git-appraise-web.appspot.com/static/reviews.html#?re...

david-cako 9y ago
This is actually the one good way of handling it IMO. Decentralizing git without losing the UX benefits of using a site like github is done by handling it like torrents and packaging everything into the repo/technology itself. The Linux kernel is already part of the way there, it's just the "local client" aspect that's missing, along with a focus on actually making it intuitive and fully integrated into git itself. The repo itself should contain all of the bookkeeping, and git should host a local UI (web and CLI) that allows you to interact with it as you would with github, rather than the send-mail rituals, the relative difficulty of following development on mailing lists, and the "here's how to set up one of 20 different email clients to send mail as plain-text". Imagine get_maintainer.pl and send-mail being replaced with a built-in pull-request-like interface that is disseminated to everyone that pulls from the remote. That's what git-appraise is trying to accomplish. The traditional mailing-list-based development is tried and tested, but at risk of displaying my appy app iPhone youth naïveté, it's really inconvenient IMO.
- tenken 9y ago
  I think you just described the Fossil dvcs.

snakeanus 9y ago

Sure, the UX might get slightly worse (early on at least) for some users but we are talking about programming related services. I do not think that having to use a well defined and popular standard protocol with the client of their choice in order to create a pull request or an issue would make contributing to a project difficult for a computer scientist. Instead, I would argue that not having the ability to just send a mail/post to a mailing list/newsgroup by using my favourite SMTP/NNTP client without creating any form of account in a property service and without clicking buttons in a slow js-ridden web interface in order to create an issue or post a pull request is a bad UX. > copy the URL, pull it down, make changes, push and click a button for a pull request All of these (except clicking a button for a pull request) are possible just with git, they are not really github nor centralised-only features. > Until that happens the idea of decentralizing things is just going to remain a pipedream. I find sending an email and using NNTP with the client of my choice a lot easier than using a forum and a lot easier than using the github issue/pull request interface. Thus I would argue that this happened many years ago.

bsder 9y ago

> Now try decentralizing away from GitHub. If you have to add any steps then you increase friction likely lowering the UX and making adoption harder. Attempting to justify GitHub as a "win" because git is unwilling to fix its brain-damaged user interface is called "damning with faint praise", at best.

tscs37 9y ago

IIRC Gitlab has some issue on implementing federated Pull Requests, which would allow users to run their own Gitlab instances but still interact with Gitlab-proper repositories as normal.

fagnerbrack 9y ago

"Now, if you can figure out a way to decentralize a service while maintaining the same level or less friction from the centralized version then you have a real winner and things can start happening." Ethereum

gkya 9y ago

There are marketing buzzwords, irrelevant in the open source community.