5 ms·

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 loc

by gardarh 14y 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 14y 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 14y 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 14y 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 14y ago
  [deleted]
- flixic 14y 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 14y 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 14y 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 14y 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 14y ago
    [deleted]
  - njharman 14y ago
    They don't want to learn or use; svn, atlassian, bit bucket, etc. cause they are mentally locked into github
- kisielk 14y ago
  The same argument could have been used for SourceForge back in its heyday. Times change.
  - njharman 14y 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 14y 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...

by gardarh 14y ago

mryan 14y 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 14y 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 14y 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 14y ago
[deleted]
flixic 14y 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 14y 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 14y 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 14y 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 14y ago
  [deleted]
- njharman 14y ago
  They don't want to learn or use; svn, atlassian, bit bucket, etc. cause they are mentally locked into github
kisielk 14y ago
The same argument could have been used for SourceForge back in its heyday. Times change.
- njharman 14y 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 14y 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...