There has been another acquisition in the developer-tooling world this month, and like clockwork my feeds filled up with two camps: the people insisting nothing will change, and the people already drafting their migration plans. I have been in both camps in my career, sometimes about the same product, which tells you how reliable my instincts are here.
I'm being deliberately vague about which deal, partly because by the time you read this there will have been another one, and partly because the specific logos matter less than the pattern. A tool that a lot of us use every day, the sort of thing that quietly became part of how we work, now has a new owner with new priorities. The official blog post used the words "exciting" and "journey" and "continue to invest", which is the standard incantation, and means precisely nothing until proven otherwise.
What I want to write about isn't the deal. It's the uncomfortable audit it triggered: how did this one tool get so deep into my workflow that a press release could ruin my afternoon?
the dependency crept up on me
Nobody decides to become dependent on a vendor. It happens one convenience at a time.
You adopt the tool because it solves a real problem better than the alternatives. Then it grows a feature that replaces a second tool, and that's nice, one less thing to manage. Then it grows integrations, and your CI talks to it, and your editor talks to it, and your on-call runbook assumes it exists. None of those steps felt like a commitment. Each one was just the path of least resistance on a busy day. And then one Tuesday someone signs a deal and you realise you've built a small but load-bearing part of your working life on top of something you don't control and never did.
The honest reckoning, for me, came down to three questions, and I'll spare you the tidy list format because they're not equal:
The first is simply, what would actually break if this went away or got materially worse? Not "what would be annoying", but what would stop. For most of my tools the answer is reassuringly small. For one or two it was larger than I was comfortable with, and that's the useful signal.
The second is whether my data is mine. Can I get it out, in a format that's worth getting out, without writing a scraper at gunpoint? Export buttons that produce an opaque blob don't count. I mean: could I stand up an alternative and import my history, my config, my accumulated state, in an afternoon?
The third is the awkward one. How much of my dependency is the tool, and how much is my muscle memory? A lot of "I can't switch away from X" turns out to be "I cannot be bothered to relearn the keystrokes", which is a real cost but a very different one. It's worth separating the lock-in that lives in the product from the lock-in that lives in my own habits, because only one of those is the vendor's fault.
what acquisitions actually change
In my experience, and I've now lived through enough of these to have a pattern, the failure mode is rarely a dramatic shutdown. The thing you depend on almost never gets switched off the week after the deal closes. That would be too obvious, and it would torch the goodwill they just paid for.
What changes is slower and harder to argue with. The roadmap quietly reorients toward whatever the new owner sells. The free tier that hooked you gets a little less generous at the next pricing review. The small, beloved features that didn't move the metrics stop getting maintained, then stop getting fixed, then one day are gone with a deprecation notice and a suggestion to use the enterprise alternative. The team you trusted, the people whose taste was the actual product, start to drift off over the following eighteen months, because that's how long the retention packages tend to run. None of it is malicious. It's just gravity. Big organisations optimise for big-organisation things, and the qualities that made the tool lovable were often the qualities of it being small.
So the question isn't "will they ruin it". Sometimes they don't! Some acquisitions give a starved project real resources and it gets genuinely better. The question is "am I positioned to leave cheaply if they do". Those are different things, and conflating them is how you end up either complacent or paranoid, neither of which is much use.
what I'm actually doing about it
Not panicking, for a start. I've watched people rip out a perfectly good tool the day an acquisition is announced, switch to something worse out of spite, and lose a fortnight to it. That's an emotional decision dressed up as a principled one.
What I am doing is cheaper. I'm pulling a full export of my data out of the affected tool and storing it somewhere I control, so that "I could leave" stops being a theory. I'm writing down, in actual prose, what the tool does for me and what the two strongest alternatives are, so that future-me, deciding under pressure, has something better than a panicked search to work from. And where it's easy, I'm putting a thin layer of my own between me and the vendor: a script, a config format I own, an abstraction over the bits I'd otherwise have hardcoded. Not a heavyweight wrapper, just enough that switching the thing underneath is a config change rather than an archaeology project.
That last one is the real lesson, and it predates this acquisition by years. The tools I worry about least are the ones I integrated through a boundary I designed. The ones that bypass that boundary and reach directly into my workflow are the ones that can hurt me. An acquisition doesn't create that risk. It just sends you the invoice for it.
The tool I'm thinking about will probably be fine. Most of them are. But "probably fine" is a much more relaxing place to sit when you've already worked out what you'd do if it isn't. I'll keep using it tomorrow, same as today. I'll just be keeping a slightly closer eye on the changelog, and a current copy of my own data, because the cost of doing that is an afternoon and the cost of not doing it is occasionally everything.