So... what about using Gitlab (<a href="https://about.gitlab.com/gitlab-ce/" rel="nofollow">https://about.gitlab.com/gitlab-ce/</a>)? It's open source (MIT license), it's a (very polished) clone of Github's functionality and workflow, and it can be self-hosted.<p>Someone saying "please use Github" doesn't (usually) mean they only want, specifically, Github. It means they want a tool with visual forking and merge trees, a code browser that can easily reference different branches and tags, basic issue tracking in a way that can be linked to specific commits and merges, and so on.<p>Honestly, at the point that Mr. Wong mentioned "no need to
ever touch a bloated web browser" it felt more like ranting against ~these goddamn stupid casuals who can't even bother to use the command line!!~, not about actually bothering to even try and understand what the person was requesting.
The danger of a proprietary centralized service is directly proportional to how irreplaceable it is and how difficult it is to get relevant data back out. By this measure, GitHub poses very little threat.<p>Because it's DVCS, the code already exists on the author (and likely dozens of other users') machines. With the change of a remote GitHub as a source host can be effectively replaced.<p>When it comes to the non-source-hosting capabilities of GitHub, sure they're proprietary but they too can be replaced. GitHub has gained dominance in the open source community because it's very good at what it does. If it ceases to be the best place to host open source projects, people will stop hosting open source projects there.<p>That being said, the authors of awesome open source projects have zero obligation to put their stuff on GitHub if they don't like it. They just might miss out on contributions of members of the community who don't want to jump through extra hoops.
It's fine if he doesn't like Github, but the condescending attitude towards people that don't mind leaving the terminal isn't doing him any favors.
Seems like a logical extreme. Github is largely compatible with normal git. For instance, I've use other git services, like Bit Bucket, and not noticed much of a difference. While it is certainly for profit, it also offers some really useful tools that make hosting open source software and communicating with developers really easy. Github is useful for web developers in particular (I'm one) but I imagine other developer communities would benefit.<p>It seems like a hollow argument to malign Github just because it wrapped something useful in its own right (Git) with a set of tools that raise its usefulness enormously (Github). And if you end up having an issue with Git, if you've got a local checkout it's 100% Git compatible and you can migrate it anywhere you'd like.
The message here seems to be "No tooling is better than proprietary tooling".<p>Hosting on Github wouldn't diminish the ability for people to contribute to Unicorn via the same channels they do now. It would just make it more convenient for the many people who already use it.
For big projects like Linux or Python, they don't move to Github because they have their own system running for years. They just don't see the benefit and they find their existing mechanism effective. Many projects today still run on Bugzilla, mailing list and IRC.<p>For smaller projects the cost to migrate from older services like Google Code or even from Bitbucket to Github (or sometimes from Google Code to Bitbucket) is not trivia. I think one reason why Django still use its own system (Trac) rather than going for full Github is the difficulty to migrate old issues over.<p>So if the reason is "because we have a solid process in place" it is understandable. But actually, running your own system is also a lock-in but you just happen have full control of the system. You are lock in because you are still using that one software which may or may not continue to exist in a few years. If next decade you decided you don't want mailman to run your mailing list, instead you want to use MailFooBar, you will need to prepare migration. The only advantage is you control your stack, your data. Github can shut down next year all the sudden and you can lose everything (this is particularly true and dangerous for people whose software development cycle depends on small start-up services out there).<p>I think the attitude is a bit strong to potential contributors, even though I can see the reason why it's bad for an established project to consider any migration. It's a personal preference. If you are the main author and you don't want to move, you don't have to move. I don't have time to manage a full system. Heck, I don't have any open source code that is popular enough warrant me to think about running a mailing list or a buildbot farm. Github is perfect for me for just tracking and sharing code with the world.
Couldn't anyone choose to create a mirror on Github and do the busy work of shuttling patches back and forth? If the accessibility is important to them, can't they independently solve this issue?<p>Furthermore, if this is as important as implied, wouldn't that Github repo become an important source of progress for the project, without infringing in any way on Eric's desire to NOT use (or depend on) Github?
>>It absolutely sickens me to encounter users who seem to be incapable of using git without a proprietary communications tool.<p>What is the proprietary communication tool which seems a must for git to work?Are they referring to SSH?or Something else am not aware?
On the other hand if it was on Github at least know how I could find more information about what it is.<p><a href="http://bogomips.org/" rel="nofollow">http://bogomips.org/</a><p>"bogomips"<p>Cheers that's helpful.