Ramblings of an aging IT geek
← Ramblings of an aging IT geek
news

when the thing you depend on gets bought

A reaction to a tooling vendor changing hands, and a sober look at what it actually means to depend on software someone else owns and can sell.

A newspaper-style collage of tech headlines

This month brought another of those announcements that lands as a one-line headline and then sits in the back of your head for a week: a tool I use every day is changing hands. I'm being deliberately careful with the specifics, because the version that reached me came through the usual mix of a vendor blog post, a few breathless threads, and the inevitable rush of people declaring the thing dead before the ink was dry. What I can say with confidence is the shape of it. A company that made a piece of developer tooling I rely on has been acquired, and the acquirer is large enough that the tool is now a line item in someone else's strategy rather than the whole company's reason to exist.

I've been here enough times that the feeling is familiar. The first reaction is mild dread. The second, and the more useful one, is to actually go and look at what I've quietly come to depend on.

the dread is mostly about momentum

When a small, focused company gets bought by a big one, the thing you lose first isn't usually the product. It's the momentum. The small company shipped because shipping was survival. The acquirer ships when it fits a roadmap that now also has to account for sales motions, overlapping internal products, and a reporting line three levels above the person who used to merge your pull requests.

Sometimes that's fine. Plenty of good tools have been bought and carried on improving, properly resourced for the first time in their lives. The honest answer is you don't know on day one, and anyone telling you they do is guessing with confidence. So rather than guess, I went and did the boring inventory.

A city skyline of glass office towers

the questions I actually ask

I have a short, unglamorous checklist for moments like this, and it has nothing to do with how I feel about the brand.

How deep is the integration? Is this a thing I invoke at the edges of my workflow, easily swapped, or has it grown roots through my build, my editor, my CI, and three scripts I've forgotten I wrote? Be honest about the roots. The tools that hurt to lose are never the ones you think.

What's the export story? Can I get my data and my configuration out in a format something else can read, today, without asking anyone's permission? If the answer is "there's an API", go and actually run the export. An export you've never tested is a hope, not a plan.

Is there a real alternative, and have I used it recently? Not "does a competitor exist" but "could I be productive on it by Friday". For a lot of categories the answer is now genuinely yes, and often the alternative is open source and a bit rougher and entirely under my control. That roughness looks a lot more attractive the week after an acquisition.

What does it cost me to stay versus to leave? Switching has a price, paid up front in a bad week of friction. Staying has a price too, paid slowly, in features that don't ship and prices that drift upward once the new owner has worked out how much they can charge. Neither is free. The mistake is pretending only one of them costs anything.

what I'm actually going to do

Nothing dramatic, and that's the point. I'm not ripping the tool out this week. It still works, it still does the job, and panic-migrating off a perfectly functional tool because of a press release is its own kind of expensive mistake. I've watched people burn a fortnight rebuilding around a worse replacement to escape a danger that never arrived.

What I am doing is shortening the leash. I've written down where the tool actually sits in my workflow, because the inventory itself was clarifying. I'd genuinely underestimated how much I leaned on it. I've run the data export, for real, and confirmed the output is something a competitor can ingest. I've spent an evening with the most credible alternative so that "we could move" is a thing I know rather than a thing I assume. And I've put a note in my calendar for six months out to look again, because the meaningful signal isn't the acquisition, it's what the new owner does in the two or three releases after the dust settles. Does the changelog keep moving? Do the maintainers who made it good stick around? Does the pricing page sprout a new tier with a suspiciously enterprise smell? Those tell you more than any launch-day blog post.

the longer lesson

This keeps happening because it's structural, not bad luck. Useful software gets built by people who care, attracts users, and at some point becomes worth more as an asset than as a going concern, and it gets sold. That's not villainy, it's just how the industry breathes in and out.

So the resilient position was never "pick tools that will never be acquired", because that list is empty. It's "depend on tools you could leave". Prefer open formats. Prefer things with an export that works. Prefer the boring, swappable integration over the deep, clever, sticky one, even when the sticky one is genuinely nicer to use day to day. Keep a rough idea of your exit for anything you'd actually miss.

I like the tool. I hope the new owners are good to it, and there's a decent chance they will be. But the version of me that's relaxed about this morning's headline is the one who already knew how he'd leave if he had to. That's the whole trick. You don't avoid the dependency. You just make sure it's a relationship you could end, and then you mostly never have to.