4 ms·

I heard this point. A number of times. And I'm happy to send email patches to Linux or whatever project wants them that way. But GitHub PR UI is more convenien

I heard this point. A number of times. And I'm happy to send email patches to Linux or whatever project wants them that way. But GitHub PR UI is more convenient. At least for me and a number of other users. It also lowers the bar, making contributions more likely. The people that would have not contributed if there was no GitHub might be wrong, but the projects get more patches. That's it. Finally, youtube-dl is on GH, but if you send me a patch via email, I can just 'git am'. GitHub won't get in the way.

zAy0LfpBZLC8mAC 13y ago
First, I explicitly was not talking about sending patches, but about pull requests. You can actually write an email that says "please pull from git://foo.example/project topic-bar" or whatever, that is something quite different from sending mails with patches inside. Second, this is not in any way about github necessarily doing something wrong, but about its users doing something wrong in making it into a central quasi-monopoly. If you do offer non-proprietary ways for submitting patches, that probably goes a long way - but the way github is used by its userbase (that is, people just assume you have a github account, and don't invest in non-centralized solutions anymore because github is so easy, ...) leads to there being projects that don't have that option anymore, so I actually can not contribute, and in that way, github does get in the way. The problem is not so much the individual who happens to be hosting some project on github, the problem is the centralization and monopolization that happens when too many people do that. Also, yes, I do understand the individual motivation for using github, because it has some short-term advantages, but you maybe should not ignore the long-term consequences. The problem is that github's UI being more convenient does not technically depend on github's centralization (technically, github is completely unnecessary for solving the problem), but it is what github uses to build its monopoly. Let me sketch out a technically different solution that would be equally convenient with no risk of monopoly abuse: How about we define a machine-readable open format for pull requests, assign it a MIME type, and then just have git itself or some local git UI (of which there obviously could be multiple different ones, open ones as well as closed ones) registered for handling that MIME type on your system. Suddenly, you could simply use your existing mail account in order to send such a machine readable pull request via email to anyone at any other mail provider (probably with a single git command or UI mouse click?), and they could with a single keypress/click in the mail client start processing/reviewing the pull request. People could host their repos whereever they want, including on their own server, and among the providers possibly could be github, but there would be no risk of monopolization, everyone could use their preferred UI, their preferred git hoster, their preferred mail provider, ..., without that being a hurdle in any way whatsoever. Now, one reason why that does not get developed, I would suggest, is because "github is so convenient". My point is: There is nothing wrong with making things more convenient, but it would be a good idea to think about ways to make things more convenient _without_ building monopolies, if only because those tend to be highly inconvenient in the long run.

zAy0LfpBZLC8mAC 13y ago

First, I explicitly was not talking about sending patches, but about pull requests. You can actually write an email that says "please pull from git://foo.example/project topic-bar" or whatever, that is something quite different from sending mails with patches inside. Second, this is not in any way about github necessarily doing something wrong, but about its users doing something wrong in making it into a central quasi-monopoly. If you do offer non-proprietary ways for submitting patches, that probably goes a long way - but the way github is used by its userbase (that is, people just assume you have a github account, and don't invest in non-centralized solutions anymore because github is so easy, ...) leads to there being projects that don't have that option anymore, so I actually can not contribute, and in that way, github does get in the way. The problem is not so much the individual who happens to be hosting some project on github, the problem is the centralization and monopolization that happens when too many people do that. Also, yes, I do understand the individual motivation for using github, because it has some short-term advantages, but you maybe should not ignore the long-term consequences. The problem is that github's UI being more convenient does not technically depend on github's centralization (technically, github is completely unnecessary for solving the problem), but it is what github uses to build its monopoly. Let me sketch out a technically different solution that would be equally convenient with no risk of monopoly abuse: How about we define a machine-readable open format for pull requests, assign it a MIME type, and then just have git itself or some local git UI (of which there obviously could be multiple different ones, open ones as well as closed ones) registered for handling that MIME type on your system. Suddenly, you could simply use your existing mail account in order to send such a machine readable pull request via email to anyone at any other mail provider (probably with a single git command or UI mouse click?), and they could with a single keypress/click in the mail client start processing/reviewing the pull request. People could host their repos whereever they want, including on their own server, and among the providers possibly could be github, but there would be no risk of monopolization, everyone could use their preferred UI, their preferred git hoster, their preferred mail provider, ..., without that being a hurdle in any way whatsoever. Now, one reason why that does not get developed, I would suggest, is because "github is so convenient". My point is: There is nothing wrong with making things more convenient, but it would be a good idea to think about ways to make things more convenient _without_ building monopolies, if only because those tend to be highly inconvenient in the long run.