4 ms·

The reason to ditch a specialized product after it is acquired by a large, old user hostile firm is because they have the ability to turn the heat up slowly. Th

The reason to ditch a specialized product after it is acquired by a large, old user hostile firm is because they have the ability to turn the heat up slowly. They can wait you out.

mschuster91 8y ago
> They can wait you out. Sure, but git repo hosting is a commodity, unlike, say, controlling the Java ecosystem. The full code and history is maintained on all developer machines (at least for the master branch), and the metadata like issues, PRs etc. can be easily migrated off to GitLab.
- zimablue 8y ago
  It's a commodity until they extend it with stuff that locks you in, like (to be fair) Gitlab is also doing eg. CI, hooks etc. The whole playbook has always been to quietly remove compatibility and take the most locking-in possible approach. (proprietary standards etc etc).
  - cannonedhamster 8y ago
    I swear we're not trying to lock you in we're just implementing feature X that's been requested for years. Yes it does break compatibility with Y, but while Y is stable it's outdated and not capable of doing X without too much work.
Voloskaya 8y ago
And if/when they do, you leave once the temperature is too hot. Doing it before is just premature optimization.
- fartcannon 8y ago
  You'll be too entrenched by then and your org will be too dependant. At that point, you'll use fancy mental gymnastics to justify the, for example, impossible to disable telemetry. Get out while you can.
- glomph 8y ago
  Frogs say the same thing.
Someone1234 8y ago
Microsoft have never been developer hostile. In fact that's their entire business strategy, keep developers happy and then make integrating with Microsoft's other products the path of least resistance. GitHub feeds into that. I'm certain we'll see a "deploy to Azure"-like integration soon.
- stephenr 8y ago
  > keep developers happy and then make integrating with Microsoft's other products The 'then' part of that sentence is the issue. It isn't then. Microsoft are about keeping developers on the Microsoft stack happy. Historically they don't want anyone using any other stack, so they don't want developers making things for other stacks.

The reason to ditch a specialized product after it is acquired by a large, old user hostile firm is because they have the ability to turn the heat up slowly. They can wait you out.

mschuster91 8y ago

> They can wait you out. Sure, but git repo hosting is a commodity, unlike, say, controlling the Java ecosystem. The full code and history is maintained on all developer machines (at least for the master branch), and the metadata like issues, PRs etc. can be easily migrated off to GitLab.

zimablue 8y ago
It's a commodity until they extend it with stuff that locks you in, like (to be fair) Gitlab is also doing eg. CI, hooks etc. The whole playbook has always been to quietly remove compatibility and take the most locking-in possible approach. (proprietary standards etc etc).
- cannonedhamster 8y ago
  I swear we're not trying to lock you in we're just implementing feature X that's been requested for years. Yes it does break compatibility with Y, but while Y is stable it's outdated and not capable of doing X without too much work.

Voloskaya 8y ago

And if/when they do, you leave once the temperature is too hot. Doing it before is just premature optimization.

fartcannon 8y ago
You'll be too entrenched by then and your org will be too dependant. At that point, you'll use fancy mental gymnastics to justify the, for example, impossible to disable telemetry. Get out while you can.
glomph 8y ago
Frogs say the same thing.

Someone1234 8y ago

Microsoft have never been developer hostile. In fact that's their entire business strategy, keep developers happy and then make integrating with Microsoft's other products the path of least resistance. GitHub feeds into that. I'm certain we'll see a "deploy to Azure"-like integration soon.

stephenr 8y ago
> keep developers happy and then make integrating with Microsoft's other products The 'then' part of that sentence is the issue. It isn't then. Microsoft are about keeping developers on the Microsoft stack happy. Historically they don't want anyone using any other stack, so they don't want developers making things for other stacks.