January 18, 2025

.NET OSS Projects: Better to Re-license or Die?

The decision maintainers face when 'free' just ain't cutting it.

This week FluentAssertions, a popular open source library designed to make it easier to write assertions during unit testing, changed its license from Apache 2.0 to some commercial terms under the name of a new business entity, Xceed.

The net impact of this is that FluentAssertions now costs $129.95 per seat for commercial use for version 8.0 and later.

Naturally the .NET community was in uproar over this on /r/dotnet and in a few other places, like this comment from the “.NET Eventing Framework” thread which inspired “.NET Developers Begging for Ecosystem Destruction”

.NET users complaining about independent OSS to Microsoft

In this post we’re going to unpack two things:

  1. Impact of the FluentAssertions change and
  2. Broader questions about what .NET users would prefer: “re-license or die?”

FluentAssertions

We’re FluentAssertions users and we take a dependency on it inside the Akka.TestKit, the second largest “used by package” of FluentAssertions.

Largest packages that depend on FluentAssertions

We’re not impacted by this license change because we’re still using FluentAssertions 5.10 - we’ve never bothered upgrading because… It’s an assertions library. It’s a useful library - and I could replace it in 15 minutes using a substitute or just go back to using the built-in assertions in xUnit.

If you’re using a version of FluentAssertions from prior to 8.0, you’re still running on Apache 2.0. Just specify a version range in your Directory.Packages.props file that stays below 8.0 and you’re good to go.

Commercial Viability

FluentAssertions’ commercial offer won’t be viable in the long-run for the reasons I outlined in “ How to Build Sustainable Open Source Software Projects:”

The scaling laws around OSS projects will vary, significantly, depending on what the project does. I doubt you can build a sustainable business around something like a serializer - that’d need to be a project that is OSS by virtue of a big tech giant like Google or Microsoft. The problem with a serializer is that, while important, it’s in a space that has lots of great free solutions and it doesn’t really touch many different parts of the business. In other words, it’s a narrow-use case tool competing with lots of free alternatives (like JSON serialization.)

That applies equally well to an assertions library - sure, it might be popular and have a lot of downloads, but its substitution cost is low and what it does isn’t that high-value in the first place. Value is the real driver of commercial viability - popularity is not.

What Motivated the Change?

One thing that makes the change interesting, is the change in ownership of the package itself - the decision to “partner” with a .NET component vendor like Xceed, who as far as I know had never been involved with the project up until https://github.com/fluentassertions/fluentassertions/pull/2943 - that seems super out-of-the-blue to me.

It’s one thing if the original maintainers decide to commercialize and create their own entity: users are still dealing with the same people they’ve had a trusted relationship with all these years. But bringing some new unknown party into the equation who, presumably, wants a hand on the steering wheel? That’s another variable in its own right. I have no idea how that will play out long-term.

I have no idea if FluentAssertions had a sustainability problem or not prior to this change and if Dennis and the other maintainers want to pivot to doing full-time OSS work. That’s not clear to me - but either way, I hope it works out for them.

Lack of Communication

One thing I do know with 100% certainty: users have no right to bitch about FluentAssertions “not being communicative enough” when it comes to socializing this change in advance.

Daniel Cazzulino, the creator of popular .NET mocking library Moq, tried very hard to communicate and socialize his sustainability proposals for the library back in 2023:

Moq users read none of that.

.NET users would be really upset if they learned to read release notes

Daniel tried a lot harder than most to get feedback for a library that’s ubiquitous in the .NET ecosystem and heard nothing but crickets back. He mentions this in his August 15th post-mortem too: “SponsorLink: feedback and moving forward”

As I often say to my wife, kids, employees, friends et al: “incentivize the behavior you want to see.”

Well, that works in reverse too: Daniel did the right thing, his users didn’t fulfill their end of the bargain and weigh in, so he ran an experiment and got widely harangued for it. Other maintainers noticed.

So .NET users, if you want maintainers to communicate with you and get your feedback - make sure you’re actually listening and responding when they do.

Re-license or Die?

With the specifics out of FluentAssertions out of the way, here’s a question I would like to broadly level at .NET developers: if a maintainer is “done” doing uncompensated labor for other people - what would you prefer?

  1. Maintainer attempts to keep the project alive by re-licensing and charging money? Or
  2. Maintainer abandons the project.

If there’s a third option, it’s one of the other business models I described in “ How to Build Sustainable Open Source Software Projects” - but if a maintainer reaches a point where abandoning the OSS project is an attractive option, it’s too late for any of those. This is your binary choice: which would you prefer?

If a project goes commercial your options as a consumer are:

  1. Comply with the new license terms;
  2. Don’t upgrade - stick with the older FOSS version until CVEs and other maintenance issues catch up with you;
  3. Fork the project from a point in the commit history prior to the license change and use that instead - or hope someone else does this;
  4. Substitute to an alternative; and a special .NET option no other OSS ecosystem has
  5. Beg Microsoft to replace the project with its own implementation.

If a project gets abandoned you have all of the same options, sans option 1 as the original maintainer is now gone.

A Different Path: Prevention

I thought Sean Killeen had a great take in his post “My OSS ‘Social Contract’”:

But here’s the thing – if you’re not contributing your time or your money to an OSS project, your say in that project is exactly zero. And if you’re not responding to a major change with gratitude as you move away from the tool, or grace as you work through the issue, you’re not a member of that OSS project community, and aren’t acting as an OSS community member at all. You’re acting like a leech, which makes you part of the problem – and anyone invested in a solution would be best served by ignoring you entirely.

Full disclosure: Sean and his company are customers of Petabridge and directly fund our work on Akka.NET.

I’ll go a step further: most consumers of OSS treat open source components and infrastructure like they’re low-code solutions that will never require deeper attention. They will “just work” in perpetuity. Taking the tedious and careful yeoman’s work that goes into making OSS a friction-free experience for its users for granted is where the rot sets in.

If you want to prevent a project from getting abandoned or re-licensed a pro-active approach works best: try to sponsor it, buy a support plan, contribute to it, or at the very least: actually read communiques from the project’s maintainers themselves.

You’re not getting rug-pulled if you start getting charged for a project you’ve never contributed to or never-even paid attention to - you’re facing the consequences of ignoring the health of your software supply chain.

So, which do you prefer? Abandonment or re-licensing? Choose your own adventure in the comments.

Discussion, links, and tweets

I'm the CTO and founder of Petabridge, where I'm making distributed programming for .NET developers easy by working on Akka.NET, Phobos, and more..