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?
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.
>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.
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.
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 support@github.com.
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?
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.
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.
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.
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/
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:
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.
> 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.
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.
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.
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
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.
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).
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.
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.