6 ms·
It's absurd that so many open-source and / or free software projects are happy to host their public-facing development infrastructure with a private company run
by lfam 11y ago
It's absurd that so many open-source and / or free software projects are happy to host their public-facing development infrastructure with a private company running proprietary software.
- AndyKelley 11y agoWhy?
- chei0aiV 11y agohttp://mako.cc/writing/hill-free_tools.html http://mako.cc/writing/hill-free_tools.html
- manigandham 11y agoWhat's the alternative? Everyone running their own little proprietary stacks with none of the features or community or ease of use?
- lfam 11y agoWhy would a free software project leave GitHub just to run a proprietary "stack"? You could try one of the self-hostable free software alternatives listed here: https://en.wikipedia.org/wiki/Comparison_of_source_code_hosting_facilities https://en.wikipedia.org/wiki/Comparison_of_source_code_host...
- manigandham 11y agoself-hostable and free doesn't mean they're not proprietary. and my comment was more about the fact that github is just git (which is completely open) with some extra features. like the other comments have said, it's not really a big risk.
- lfam 11y agoI don't mean free as in price. I mean free as in freedom, and I mean proprietary as in non-free: https://en.wikipedia.org/wiki/Proprietary_software https://en.wikipedia.org/wiki/Proprietary_software
- tracker1 11y agoWith self-hosting you don't get the broader community... With node, for example, most modules have source on github and it's easy to fork, fix/enhance something and submit a PR... with everyone self hosting, how many logins do you have to create. I know, tracking, federation, etc... but it's much nicer only having a couple logins (google, fb, twitter, github) for most sites I access regularly.
- carussell 11y agoSSO is a separately solvable problem, and even so, I'm not sure it's a solution that needs applying here. It's not clear why any form of sign-on is needed—SSO or not. Almost everybody in this space is already using public-key crypto for authentication.
- tracker1 11y agoBut not for signing into the website, and adding notes for a pull request, or filing a bug/issue/feature request.
- deleted 11y ago[deleted]
- carussell 11y agoI don't even know why I bother trying to have discussions with GitHub users.
- tracker1 11y agoHow does public key crypto let me use multiple website, similar to github's, so that I can create a PR, and update/edit notes/comments on issues? It's a demonstrably broken experience in the browser. Having one key to rule them all, so to speak is far easier than having to sign into every project's own issue tracker. I understand the risks (ie: sourceforge), but have some level of trust in GH's founders.
- gkya 11y agoIt's easier than pull requests, to email a patch.
- mineo 11y agoTo be honest, I don't find this to be true. To email a patch, you usually have to * figure out if you can use git-request-pull or git-send-email * sign up for a mailing list (which, depending on the mailing list software the project uses, can take anywhere between a few seconds and annoyingly large amounts of minutes) * optionally figure out how to not receive the whole traffic of the ML or set up custom email filters * figure out if you have to CC the people responsible for the area of the code you're going to send a patch for (which might be written down in a wiki, some CONTRIBUTING file or somewhere else) * figure out if the project wants an extra cover letter for the patch series or not (and optionally search the man pages for how to write one). With GitHub, I just use [hub](https://hub.github.com/ https://hub.github.com/) or an Emacs package or plugins for other editors to * fork the repository * (without additional tools, I now have to add my newly created remote) * push to my own remote * create the pull request after reading CONTRIBUTING<tab> which so far has been the exact same workflow for every project I've seen (ymmv of course).
- gkya 11y agoIf I was going to email a patch to a project, - I would already be following the mailing list and/or the bug tracker, - I would already have read the relevant guidelines before starting to work on the tree, and - I would already have figured out to whom should I refer my patch. And no lock-in to git itself. The project can use git, hg, cvs, svn, darcs, rcs, sccs, whatever. I can, after obtaining the tree, create diffs to orig files and be done with it. If I was going to contribute to a project on github (which I did a few times), the above-mentioned are still relevant, if one wants to contribute to a projects, they should be familiar with it. Also, I would have to know how things work the github way. And because the github way is so mechanical, it becomes hard to enforce project rules. Then, the github web interface is score oriented: Commit numbers, release numbers, source tree layout in the face, source language statistics, search that can take me to other projects, profiles with contribution numbers, many other irrelevant stuff. It makes one want to "score", and "show off". It distracts from the actual goal of one's contribution: sharing.