Three Dependencies, Three Different Endings

In the last couple of years, three dependencies we rely on have each changed their licensing under us. Not all at once, and not for any reason connected to how we use them, but often enough now that it's stopped feeling like a coincidence and started feeling like a pattern worth naming. Each time it happened, it forced the same question: does this still earn its place, or is it time to move on. The answers came out differently every time.

The one we haven't left

Duende IdentityServer is our identity authority, handling auth for every customer, every internal app and all our integrations. We're still on the Community licence, so we're not paying anyone right now. It's a genuinely good product. It's also a hangover from an older VM setup we've since moved away from. We don't think we'd reach for it if we were starting fresh today, not because it's bad, but because it's not the natural fit for an Azure-native app.

We've got a direction we like for replacing it, but no committed scope or timeline for actually doing it. That's not us dodging the question. There's real work to do there before it's a project we would consider, rather than a preference. We'd rather say that honestly than accidentally announce a migration that might land, or might end up being something entirely different.

The one we're walking back on

AutoMapper is a different story entirely. We installed it early, and we went hard on it. Maybe a little too hard. We used it everywhere for years, but slowly, as the architecture matured, we noticed we weren't leaning on it the way we used to. The mapping logic it was hiding turned out to be simple enough in most places, that writing it directly was clearer than routing through a package that was doing reflection under the hood.

Then AutoMapper 15.0 switched to a commercial licence, and free use stopped at that version. Which made us ask the question a bit earlier. We're now working through removing Automapper entirely and all new code now follows a new pattern. The old mappings get replaced rather than extended whenever we touch them.

The one that was barely a decision

FluentAssertions is the smallest story of the three. When its licensing changed, we moved to Shouldly. It does almost everything we needed, and the syntax is close enough that AI made the migration super easy. There wasn't much to deliberate. Some decisions are genuinely that simple.

What actually ties these together

None of this is really about open source maintainers needing to get paid, though that's part of the backdrop. It's about how often we ask ourselves whether a dependency still deserves the place it has in the codebase, and how the answer changes depending on how deeply it's woven in. A dependency sitting behind one clean interface is easy to reconsider. One threaded through your data layer for years is a decision you keep re-making by default, whether you notice or not.

If a dependency isn't earning its keep, or was never embedded deeply enough to be expensive to remove, you move on, no drama required. If it's genuinely doing something hard and doing it well, you keep it, licence or no licence. IdentityServer is the one we'll end up actually paying for. Even there, if we move on, it's about fit, not fault.

We're honest enough to admit none of these reviews would have happened on this timeline without a licence forcing the question. We're quick to scrutinise any cost that shows up on the accounts, far less quick to scrutinise the well-maintained dependency that's been quietly doing its job for years and costing nothing.

That's the harder question. When do you actually go and challenge something against its competitors, versus when do you leave the status quo alone because it's still earning its keep. Tweet us on X with #intutobuild and tag us @intutohq.

Authored by Aaron Leggett, Principal Product Architect at Intuto. Photo by Castorly Stock.