Which is not meant as backhanded flame of GitHub's product, by the way. Rather, as far as observations go, it can only speak to the opposite - given that everybody can roll their own, they may be doing something right. OTOH, I think it does call for vigilence on whether they're going to start adding lock-in systems, unless they have already.
With pjax and the "T" command github simply offers the best web interface for browsing source code (short of downloading it and using emacs) that I've seen. None of the others come close.
Really? It's easy: Add an additional service that doesn't store its data in git repositories and doesn't allow for that data to be exported easily. Then make it enticing by integrating it really well with the stuff you're already using. Now you're going to think twice about migrating away, because suddenly it's hard.
Not like it's rocket science, and it happens all the time when companies find themselves in a corner (obviously we're talking a hypothetic scenario here). Heck, it even happens with initial good intentions on all sides, because a well-integrated add-on may be a lovely thing by itself.
I really don't want to be panicmongering, but if you "can't really see a way" you're not cynical enough. Don't stop thinking at "it's a DSCM, we'll be safe". You're not using git, you're using GitHub. That's why you're there, right?
How do you migrate this data? There's ALREADY some lock-in.
FWIW, I was involved with putting together the git hosting infrastructure used by the KDE community (which I wrote about at length here: http://news.ycombinator.com/item?id=2972107), which incidentally was done only after negotiations with Shortcut AS - then the company behind GitHub competitor Gitorious.org - fell through, since we couldn't come to an agreement acceptable to both sides. Things like data export guarantees were part of our goals back then.
And there's more data you want to be able to export than you might think, too. For example, if you actually let accounts push directly to your repository, you very likely want to have logs of what account was used to push what data for liability reasons - that's data that's not in the repo, because push != commit. Rather, it's data coming from the infrastructure that handles authentication for you.
See comments in this thread "I find myself frustrated any time I run into an open source project whose git repo is not on github." and elsewhere.
Many developers at work don't know how, don't want to learn, and don't want to use any system that's not github.
Github has such a huge first to market advantage, it is/will be extremely hard for better solutions to ever get noticed.
paypal, ebay, (in some peoples opinion gmail and gsearch) all demonstrate this same effect.
And yes incumbents fall, it just takes way more than Only being better.
Huh? What on earth do you mean? You mean that they can't figure out that instead of going to the GitHub repo, copy and pasting into `git clone something.github.com` they need to clone a different URL? Sounds like your fellow employees are... uh... not that stellar.
I have always seen this as a testament to github's quality - if the switching cost to your users is a couple of shell commands, you better make sure you offer a good product!
I also keep my projects in a local gitosis repository, mainly so I'm not relying on github as part of my deploy flow.
GitHub's bug reporting API has no means of importing bugs from other systems, without losing all date and user information. Projects that have moved their issue systems over have the full expanse of issues all opened/resolved on the same date and by the same person, and are basically unreadable (sorry, comments with the original info in them don't count). Django in this case is keeping trac for issue reporting.
I've emailed github about this, and I got kind of a sleepy "no, we don't really do that, shrugs". I had an insight at that moment, that Github probably does this because they don't want big, ugly old projects moving their 8000 big ugly tickets into their shiny system (Edit: but they've just responded that they want to do this! so, great). My inspiration to move SQLAlchemy to github went to zero in an instant. Fuck that. Old projects and old history about projects matter. A lot.
Keeping issue reporting on Trac - AFAICT, Django hasn't solved the issue of coordinate changeset links from trac back to an external service like github. They still seem to have their SVN repo linked in trac. Though this could be solved, with a fair degree of tedium, by first converting all the SVN links in their bug reports to be the equivalent changeset id in git, then hosting a mirror of the git repo. I originally did this when we moved from SVN to mercurial.
according to https://code.djangoproject.com/wiki/DjangoBranches this is a git mirror that is synced with svn
Now they realised that github presence will raise number of contributors.
Jacob Kaplan-Moss (the other BDFL) wrote a bit about the changes in the core team over the last couple of years in his "Measuring the Django Community" review:
The core team has grown a lot in 2012: 33 partial committers and 28 full committers.
hey dowvoters i am not a troll, many python projects avoided github initially because github was powered by ruby, see it in context
chef, puppet,vagrant,heroku are of ruby origin but now loved by people from various technology backgrounds
> Lastly, all things being equal (which they are not as shown by the previous two issues), it is preferable to use and support a tool written in Python and not one written in C and shell.
Okay this pertains to Python itself but could easily have mattered to Django.
So; in summation pick the right tool for your team not due to some techno bigotry, which is what that PEP outlines.
Precisely and I was not saying otherwise. The Python team chose hg partly (but not only) because it is written with Python, just as the Django team could have decided to choose Bitbucket partly because it is written with Django. And they could have chosen hg partly because it is written with python, or chosen git (which they did), as both were supported by Bitbucket.
Whatever, I'm not saying they should have, just that they could, and that dogfooding is a valid point if it is not blindly overrated (i.e bigotry) but carefully considered.
Tiobe 2012 report
I understand not all pre-github projects have moved from sourceforge and google code, but even for newer projects people have biases for technology choices
This doesn't make any sense. Don't tell me that there are C# developers who don't use Google because they use Java.
Having said that, I am very glad they have moved. I think the previous Trac/SVN setup had more friction in terms of submitting, reviewing and accepting commits. Hopefully github will make this process more fluid.
Beyond the "key user" metric, the raw numbers also seem to lean in favour Github: there are 665 watchers on Github, 266 followers on Bitbucket; 56 forks on Github, 39 on Bitbucket.
So if you look at django-old's numbers: https://github.com/django/django-old
compared to Bitbucket's:
So the raw numbers are dramatically in Github's favour.
It all boils down to taste. I don't use HN because it's written in ARC - I come for the discussions.
This is an offical branch of Django on git, this github branch has been around for a while. The offical Django development is still on svn.
"Django uses Git (git) for managing its code."