5 ms·

This "lock-in" you are speaking of is "building useful things that people voluntarily want to use, who then need these things so much that they don't want to le

This "lock-in" you are speaking of is "building useful things that people voluntarily want to use, who then need these things so much that they don't want to leave". Okay it's within your rights to define lock-in this way. But it seems odd to me to blame Github for this. The reason why switching costs are high is because alternatives aren't as good. What do you want Github to do? Stop buding useful things so that they're not better than alternatives? There was a time (before acquisition by MS) that Github was exactly like that. Gitlab was threathening to eat its lunch. But I can't say that those were better times.

atoav 4y ago
Lock-in is if the amount of work you need to put in to transfer your stuff to $competitor is big when you want to leave. When there is one company that maintains a rooms media tech rack with media switchers and DSPs of another company that only provides access to "certified" companies and the first company sits on the source code they programmed for you, so you have to run to them with any slight change of the system you use, because you neither own the source code, nor do you have access to the softwar used to program the devices, that is lock-in. Yeah you could swap out that media switcher with one from a more open company, but then you'd have to swap out 50k€ of other gear, that is "compatible" to that switcher (and to nothing else). I am sure github is making it totally easy to migrate all of what you do on their platform to e.g. gitlab. /s
- FooBarWidget 4y ago
  One way to reduce switching cost is by not making use of much of the value provided by $CURRENT_VENDOR. For example you can treat AWS as merely a virtual machine and object storage provider, and not making use of their managed databases, AI services, message queues, etc. When you need those latter things, you build them yourself on top of virtual machines and object storage. But of course, most people take one look at this calculation and decide that it's not worth it to build so much things yourself just so that you can easily switch to another cloud provider. They rightly view it as a waste of time. I've seen many companies who had the aspiration to be "multi-cloud" from the beginning and being able to switch to another provider with ease, and every time this aspiration fails due to business pressures. There's always something more important to do than building your own cloud-agnostic database orchestration system, or your own cloud-agnostic message queue. You're complaining that Github provides features. Yes making use of those features lock you in in the sense that it makes switching to another provider harder. But the world is not better when Github doesn't provide those features at all.
jraph 4y ago
> voluntarily want to use No. As an open source user, developer and maintainer, I'm in perpetuity forced to use GitHub because open source companies and projects choose GitHub because they believe GitHub is the place to be / they won't have a community if they are elsewhere (even if they'd otherwise be inclined to use something else). Which I believe is false, but it does not matter, GitHub succeeded in creating this social network with this network effect. > What do you want Github to do? Stop buding useful things so that they're not better than alternatives? I want open source infrastructure for the open source world [1]. GitHub could put their actions where their mouth is and be and actually open source company. [1] https://drewdevault.com/2022/03/29/free-software-free-infrastructure.html https://drewdevault.com/2022/03/29/free-software-free-infras...
- FooBarWidget 4y ago
  > I'm in perpetuity forced to use GitHub because open source companies and projects choose Frankly, calling this "forced" comes over to me as a selfish and entitled view of "freedom". Freedom is not unlimited or without conflict. Someone else's freedom to park at a spot means that you can't park there. Someone else's freedom to choose Github means that you can't choose it for them. > I want open source infrastructure for the open source world [1]. GitHub could put their actions where their mouth is and be and actually open source company. Okay. Great aspiration. But someone has to do it, and there must be sufficient political power from multiple parties to do it. Github owes you nothing. Unless you pay, in which case they owe you what is specified in the contract. The alternative is that either you build this open source infrastructure yourself, or you fund someone to do it. That seems to me like a much better use of your time than complaining that Github isn't doing it for free. There's a reason why such an open source infra that's superior to the Github ecosystem doesn't exist: because it's hard to build and it takes time and resources. Nobody owes the community this: the community has to be lucky that enough people happen to have the right scratch that they're itching for themselves.
  - jraph 4y ago
    > That seems to me like a much better use of your time than complaining that Github isn't doing it for free Advocacy, raising issues and awareness is one of the necessary steps towards such a thing. If I'm helping build such an infra / ecosystem, I want people to use it because they think it's the right thing, not because it's technically better. Now, of course it would be nice if it is technically better and that's also necessary. I also can't be everywhere. I'm already giving my time to other stuff, including in the open source ecosystem. "Build it yourself" is not an acceptable / sufficient answer to a raised issue if you think it is legitimate. It's only a way to dismiss it if you don't care. FWIW, there are good alternatives to GitHub, like codeberg.org / forgejo. Worth checking out. There, here's my second constructive contribution toward this goal in this thread.
saurik 4y ago
FWIW to me the biggest lock-in GitHub uses is not providing custom domain name / CNAME support for what is ostensibly otherwise a hosting platform. The result is that not only do github.com-infected repository URLs for your project end up in the .git/config of users who clone your repository, but they end up in .gitmodules for projects that use you as a submodule, various package manager configuration/lock files for projects that use you as a dependency, and in any number of automated build processes for distributions shipping your software to end users; even worse, because we are all developers and like looking at code a lot of times more than prose, github.com-infected repository URLs end up becoming the de facto home page even for projects that did go out of their way to buy a domain name and make a website. The reality is that, once your project has been on GitHub long enough, the "switching costs" are actually artificially high to move to any alternative--whether another hosting provider such as GitLab or attempting to self-host your own repository--as what you are effectively doing at that point is forking your own project more-so than merely changing out a backend provider, with the result that these alternatives can't just be a better tradeoff or even merely have slightly better functionality: they frankly have to be MUCH better to get over the barrier to entry that managing to entice such a large number of open source projects to re-federate under a domain name that Microsoft was able to just waltz in an buy presents to a project hoping to make any kind of change... it isn't as easy as "the alternatives aren't as good".

atoav 4y ago

Lock-in is if the amount of work you need to put in to transfer your stuff to $competitor is big when you want to leave. When there is one company that maintains a rooms media tech rack with media switchers and DSPs of another company that only provides access to "certified" companies and the first company sits on the source code they programmed for you, so you have to run to them with any slight change of the system you use, because you neither own the source code, nor do you have access to the softwar used to program the devices, that is lock-in. Yeah you could swap out that media switcher with one from a more open company, but then you'd have to swap out 50k€ of other gear, that is "compatible" to that switcher (and to nothing else). I am sure github is making it totally easy to migrate all of what you do on their platform to e.g. gitlab. /s

FooBarWidget 4y ago
One way to reduce switching cost is by not making use of much of the value provided by $CURRENT_VENDOR. For example you can treat AWS as merely a virtual machine and object storage provider, and not making use of their managed databases, AI services, message queues, etc. When you need those latter things, you build them yourself on top of virtual machines and object storage. But of course, most people take one look at this calculation and decide that it's not worth it to build so much things yourself just so that you can easily switch to another cloud provider. They rightly view it as a waste of time. I've seen many companies who had the aspiration to be "multi-cloud" from the beginning and being able to switch to another provider with ease, and every time this aspiration fails due to business pressures. There's always something more important to do than building your own cloud-agnostic database orchestration system, or your own cloud-agnostic message queue. You're complaining that Github provides features. Yes making use of those features lock you in in the sense that it makes switching to another provider harder. But the world is not better when Github doesn't provide those features at all.

jraph 4y ago

> voluntarily want to use No. As an open source user, developer and maintainer, I'm in perpetuity forced to use GitHub because open source companies and projects choose GitHub because they believe GitHub is the place to be / they won't have a community if they are elsewhere (even if they'd otherwise be inclined to use something else). Which I believe is false, but it does not matter, GitHub succeeded in creating this social network with this network effect. > What do you want Github to do? Stop buding useful things so that they're not better than alternatives? I want open source infrastructure for the open source world [1]. GitHub could put their actions where their mouth is and be and actually open source company. [1] https://drewdevault.com/2022/03/29/free-software-free-infrastructure.html https://drewdevault.com/2022/03/29/free-software-free-infras...

FooBarWidget 4y ago
> I'm in perpetuity forced to use GitHub because open source companies and projects choose Frankly, calling this "forced" comes over to me as a selfish and entitled view of "freedom". Freedom is not unlimited or without conflict. Someone else's freedom to park at a spot means that you can't park there. Someone else's freedom to choose Github means that you can't choose it for them. > I want open source infrastructure for the open source world [1]. GitHub could put their actions where their mouth is and be and actually open source company. Okay. Great aspiration. But someone has to do it, and there must be sufficient political power from multiple parties to do it. Github owes you nothing. Unless you pay, in which case they owe you what is specified in the contract. The alternative is that either you build this open source infrastructure yourself, or you fund someone to do it. That seems to me like a much better use of your time than complaining that Github isn't doing it for free. There's a reason why such an open source infra that's superior to the Github ecosystem doesn't exist: because it's hard to build and it takes time and resources. Nobody owes the community this: the community has to be lucky that enough people happen to have the right scratch that they're itching for themselves.
- jraph 4y ago
  > That seems to me like a much better use of your time than complaining that Github isn't doing it for free Advocacy, raising issues and awareness is one of the necessary steps towards such a thing. If I'm helping build such an infra / ecosystem, I want people to use it because they think it's the right thing, not because it's technically better. Now, of course it would be nice if it is technically better and that's also necessary. I also can't be everywhere. I'm already giving my time to other stuff, including in the open source ecosystem. "Build it yourself" is not an acceptable / sufficient answer to a raised issue if you think it is legitimate. It's only a way to dismiss it if you don't care. FWIW, there are good alternatives to GitHub, like codeberg.org / forgejo. Worth checking out. There, here's my second constructive contribution toward this goal in this thread.

saurik 4y ago

FWIW to me the biggest lock-in GitHub uses is not providing custom domain name / CNAME support for what is ostensibly otherwise a hosting platform. The result is that not only do github.com-infected repository URLs for your project end up in the .git/config of users who clone your repository, but they end up in .gitmodules for projects that use you as a submodule, various package manager configuration/lock files for projects that use you as a dependency, and in any number of automated build processes for distributions shipping your software to end users; even worse, because we are all developers and like looking at code a lot of times more than prose, github.com-infected repository URLs end up becoming the de facto home page even for projects that did go out of their way to buy a domain name and make a website. The reality is that, once your project has been on GitHub long enough, the "switching costs" are actually artificially high to move to any alternative--whether another hosting provider such as GitLab or attempting to self-host your own repository--as what you are effectively doing at that point is forking your own project more-so than merely changing out a backend provider, with the result that these alternatives can't just be a better tradeoff or even merely have slightly better functionality: they frankly have to be MUCH better to get over the barrier to entry that managing to entice such a large number of open source projects to re-federate under a domain name that Microsoft was able to just waltz in an buy presents to a project hoping to make any kind of change... it isn't as easy as "the alternatives aren't as good".