5 ms·

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 envisi

by sho_hn 15y ago

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.

scorpion032 15y ago
This centralization has occurred out of different people's individual choice and so it is quite different from any other centralized system.
- reinhardt 15y ago
  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.
gardarh 15y ago
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.
- mryan 15y ago
  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.
- sho_hn 15y ago
  > 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?
  - mryan 15y ago
    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.
  - deleted 15y ago
    [deleted]
  - flixic 15y ago
    GitHub Issues. Pull Requests (and their comments). And so on. How do you migrate this data? There's ALREADY some lock-in.
    - sho_hn 15y ago
      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 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.
- njharman 15y ago
  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.
  - drivebyacct2 15y ago
    >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.
    - deleted 15y ago
      [deleted]
    - njharman 15y ago
      They don't want to learn or use; svn, atlassian, bit bucket, etc. cause they are mentally locked into github
  - kisielk 15y ago
    The same argument could have been used for SourceForge back in its heyday. Times change.
    - njharman 15y ago
      It took long time and revolutionary tool, git, to disobey then. And yes incumbents fall, it just takes way more than Only being better.
  - patrickk 15y ago
    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-with-the-arrows-in-their-backs/ http://steveblank.com/2010/10/04/why-pioneers-are-the-ones-w...
zacharypinter 15y ago
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.

by sho_hn 15y ago

scorpion032 15y ago

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

reinhardt 15y ago
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.

gardarh 15y ago

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.

mryan 15y ago
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.
sho_hn 15y ago
> 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?
- mryan 15y ago
  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.
- deleted 15y ago
  [deleted]
- flixic 15y ago
  GitHub Issues. Pull Requests (and their comments). And so on. How do you migrate this data? There's ALREADY some lock-in.
  - sho_hn 15y ago
    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 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.
njharman 15y ago
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.
- drivebyacct2 15y ago
  >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.
  - deleted 15y ago
    [deleted]
  - njharman 15y ago
    They don't want to learn or use; svn, atlassian, bit bucket, etc. cause they are mentally locked into github
- kisielk 15y ago
  The same argument could have been used for SourceForge back in its heyday. Times change.
  - njharman 15y ago
    It took long time and revolutionary tool, git, to disobey then. And yes incumbents fall, it just takes way more than Only being better.
- patrickk 15y ago
  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-with-the-arrows-in-their-backs/ http://steveblank.com/2010/10/04/why-pioneers-are-the-ones-w...

zacharypinter 15y ago

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.