I still find it terribly ironic that a free DSCM wound up at the heart of such a massive drive toward proprietary centralization. I think a lot of people envisioned things heading in a rather different direction.

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.

It is ironic, but I find myself frustrated any time I run into an open source project whose git repo is not on github.

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.

The big benefit about DSCM is by definitions that they are in fact very portable so I don't think this is an issue. I can't really see how github could ever lock in their customers, if their product becomes inferior to others the switch will always be very painless.

> I can't really see how github could ever lock in their customers

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?

GitHub Issues. Pull Requests (and their comments). And so on.

How do you migrate this data? There's ALREADY some lock-in.

Well, to be fair, I think pulling out Issues is quite doable via the API right now. Like I said, I'm not after panicmongering; I just advocate a healthy dose of critical thinking. As in, did you check you could pull out Issues via the API before comitting to the service, and did you make sure the service vendor is committed to offering that API going forward? If you're actually on a paid plan, if you actually intend to make your livelyhood depend on the vendor, do you have any hard guarantees on that in the contact? And so on.

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.

That's a good point. My comment to the parent just reflects my (rather limited) use case for git - off-site storage for git repos. If you use other Github-specific features like Issues, it does indeed become more difficult to switch.

They're already locked in.

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.

Whether first mover advantage exists at all is extremely debatable. Those who coined the phrase originally have backed away from it:

http://steveblank.com/2010/10/04/why-pioneers-are-the-ones-w...

The same argument could have been used for SourceForge back in its heyday. Times change.

It took long time and revolutionary tool, git, to disobey then.

And yes incumbents fall, it just takes way more than Only being better.

>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.

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.

They don't want to learn or use; svn, atlassian, bit bucket, etc. cause they are mentally locked into github

Exactly. If it ever becomes necessary to move away from github, it can be done in seconds by adding a new remote and pushing.

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.

This centralization has occurred out of different people's individual choice and so it is quite different from any other centralized system.

More to the point, even if decentralization is not widespread now, it's a great insurance that will come handy when GitHub stops being such a compelling choice.

Big problems with older projects that want to move to GitHub.

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.

We have an early alpha program if you want to import your tickets to GitHub. We helped move Parrot (and a few others) over. Contact [email protected].

sounds great. Will there be an open API ? I'm not in a hurry, I'll wait til it's up for real. It just needs to accept timestamps for all tickets/comments/updates and allow the owners of tickets/comments/updates to be github names (which might be a thorny security issue).

looking at djangoproject.com they still use svn, the github repository also does not contain any of the release branches. has there been any announcement about a migration to git?

according to https://code.djangoproject.com/wiki/DjangoBranches this is a git mirror that is synced with svn

to answer my own question, https://groups.google.com/forum/?fromgroups#!topic/django-de... has more details, for now indeed only trunk is migrated, at least release tags would be nice to migrate over.

It seems GitHub is certainly king now... But how long will it last? I feel that Version Control is such a great market that surely some significant challengers will appear in the next few years. Thoughts?

They'll have to invent something really new or have an uphill battle, because GitHub now relies a lot on network externality. In simple words, it is the effect that you chose a popular network for the number of projects on it. I do submit bug reports to projects on BitBucket and GitHub, and not to private bugzillas/tracs (I'm tired of registering and confirming every time.)

I think if a new 'leader' in version control systems starts to make ground, github could easily adapt and support it. The github magic isn't just git, it's the network and collaboration tooling around your code.

GitHub makes very easy to collaborate to projects. I think that what makes them different than others such as BitBucket.

I can't find it right now, but some time ago I've read in a darcs vs git comparison that depending on orders of patches git can sometimes yield two different results. Perhaps in future correctness in huge procjects will be an issue.

How many source code bases are larger and have more authors than the linux kernel?

I know that Facebook had a number of issues trying to migrate to git. Many of these issues came from storing big blobs and mountains of code. There are code bases bigger than the linux kernel, they are often proprietary though.

I recall Facebook's git issue revolving around the fact they store all their code in one repo, too.

You mean like Linux?

Microsoft's come to mind.

This is incredibly awesome. Very excited about this. Hopefully we'll see more cool stuff getting merged in via pull requests.

Nice, really happy about this. Hopefully our patches will finally get to go through. If you're in Europe and working with Django have a look at our Job openings, http://djangogigs.com/gigs/1182/

Interested in the history of the project...was it simply on SVN all this time? Or were there other issues that held up its migration onto Github?

For long time core devs wanted to use support the common denominator (svn) and let users choose their frontend (hg-svn, git-svn, svk).

Now they realised that github presence will raise number of contributors.

I stopped following Django more than a year ago but lack of contributors was never an issue; quite the contrary. A bigger problem was the unresponsiveness of the (tiny) core team to the occasional contributors providing patches and raising bugs, often left open for months and years. Hopefully things move faster now with more devs being entrusted with the commit bit.

I hope it will too. Particularly now that Adrian Holovaty is back as a more active BDFL.

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:

http://jacobian.org/writing/django-community/django-communit...

The core team has grown a lot in 2012: 33 partial committers and 28 full committers.

This is great!, Now just waiting for the announced python 3 support in the next version (1.5) and were all set!

Why can't Opens Source Orgs roll an independent repo hosting server with something like GitLab (gitlabhq.com)?

What for?

good to see django on github

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

I didn't see your original comment but if it was just "good to see django on github", you were downvoted for not adding anything to the conversation. Your edit is better.

Your conjecture that GitHub was initially avoided by people who don't use Ruby because it's written in Ruby is pointlessly divisive and quite silly.

If anything, it was avoided because Git was not in Python.. But yeah.

From PEP-0374 [0]:

> 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.

[0] http://www.python.org/dev/peps/pep-0374/#why-mercurial-over-...

Note that this is python-core - which has an obvious python bias for a variety of reasons, and also doesn't pertain in any way to github (see the fact they self-host HG). In actuality, having HG be written in python has helped python-core write plugins and resolve other issues.

So; in summation pick the right tool for your team not due to some techno bigotry, which is what that PEP outlines.

> in summation pick the right tool for your team

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[0]. 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.

[0] https://code.djangoproject.com/wiki/DjangoSuccessStoryBitbuc...

Especially since hg exists, is extremely similar to Git and arguably has a better UI.

I don't have any damning evidence to win a lawsuit :) but would still make a attempt to give empirical evidence

Tiobe 2012 report http://www.tiobe.com/index.php/content/paperinfo/tpci/index....

https://github.com/languages

Javascript is 9th and Ruby in 11th for popularity on tiobe but take first and second rank on github open source projects

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

> many python projects avoided github initially because github was powered by ruby

This doesn't make any sense. Don't tell me that there are C# developers who don't use Google because they use Java.

It would make sense a little bit if GitHub was open source.

What took so long?

I can't speak for any of the core Django team, but as a user of Django I am glad that they took their time with this one. IMO github 'won' the social coding and source hosting battle a while ago, but I am glad that the Django team don't immediately jump to the new hot thing. There are a lot of things to consider with such a move, and moving too quickly would be a disservice to Django users.

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.

Interesting. I didn't know Django was on SVN until now. Why didn't they choose Bitbucket? I think it could have been as productive as Github.

From following the discussion, the impression I got was that more core developers and contributors were using Github.

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.

Just an addendum to the Github numbers, I hadn't realized Adrian Holovaty had renamed the previous Github repository to django-old, replacing it with the brand new repository (with the SVN history, etc).

So if you look at django-old's numbers: https://github.com/django/django-old

Watchers: 4,030

Forks: 753

compared to Bitbucket's:

Followers: 266

Forks: 39

So the raw numbers are dramatically in Github's favour.

Couldn't ignore the irony. Github is a Rails application.

All the Pythonistas I know are very pragmatic WRT programming languages and frameworks. I see no real difference between Rails and Django - they both solve very similar problems in very similar ways. And they are both, certainly, good enough. I can have long discussions about the merits of buildout (I call it Python's Maven), but it's much more for practicing the almost-lost art of debate than for anything else.

It all boils down to taste. I don't use HN because it's written in ARC - I come for the discussions.

And Git is not Python either. What's your point?

Misleading title, I've flagged this.

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.

"GitHub migration done!" https://groups.google.com/forum/?fromgroups#!topic/django-de...

It looks official: https://code.djangoproject.com/

"Django uses Git (git) for managing its code."

Ah OK. Whoops my bad.