In the past few days we got hit with pretty spooky announcements. Jimmy Boggard posted an article on his blog, stating that he will be commercializing both AutoMapper (yuck) and MediatR. People were thinking it's April Fools' joke, but he specifically stated it is not. He hasn't yet figured out the details of how he will approach that change and when will this happen, but it's going to happen.
Few hours later, another article was dropped - MassTransit is also going commercial, starting with version 9. In this case we have more specifics of the funding model - it is going to be a subscription-based model with monthly and annual options. Monthly cost will vary based on the business size, ranging from $400 to $1200 USD per month.
Few months ago, we also "lost" another OSS library, FluentAssertions. This popular asserting package is paid from version 8 onward. Moq, on the other hand, introduced analyzer into the library, called SponsorLink, that extracts your email address from IDE and checks whether the user is a sponsor on GitHub. If not, you are affected by few seconds of pause during build and a compiler warning.
What's happening with the open source libraries landscape? Are we going to see more and more popular third party packages go commercial? Is this uniquely .NET issue? Is this something we should be concerned about?
Everybody’s gotta make money
Should OSS always be free?
I don't think we should be surprised that devs who spend their precious time on a piece of software used for free by individuals and organizations, with millions of downloads worldwide are looking for a way to support themselves financially. Maintainers are providing an immense amount of value for free and the decision to be paid for your work is perfectly reasonable. We can argue about financing model, but I think we can all agree that working for free is just not sustainable. Especially when your work is used by large organizations, making loads of money thanks to it, while returning none of it to the author.
Decision to go commercial may encounter resistance from the dev and open source community and especially from the contributors of these projects, that also spend their time to provide value to everyone for free. Should they be compensated for their work and receive some percentage of revenue? It's not that simple.
Firstly, I want to say kudos to people contributing to OSS - you're doing a terrific job. However, those contributions were ussualy made to the software that's under permissive software licenses, like MIT or Apache License. And while you contributed to versions of packages that are still open source, there is nothing stopping the author or maintaner of the package, to make use of code you merged and create a new version under different license. Similarly, anyone who want may create a fork of the open version and try to maintain it on his own. It's very likely that such forks will spawn into existence and after some time it will clarify which of them are popular and gain most notoriety in the community. Also, we need to remember that what was open sourced and free, stays that way. We will still be able to use all the free versions of packages, but most likely won't receive any new features.
Finding the right approach
FluentAssertions decided to charge fixed annual price per developer in organization, MassTransit also chose subscription model based on company scale. What are the options to financially support projects maintainers and which are fair for both author and users?
The simplest form of funding are direct donations. Many authors try that, but it's not reliable source of income. FluentValidation's author, Jeremy Skinner, posted on X in 2023, that's he is getting $31 per month from donations, while his library has over 600 millions downloads...
Some authors earn money from organizations via consulting, resolving specific issues in their packages or implementing needed features, but it's also not consistent form of funding. Others are funded by major organisations like Microsoft, which started Microsoft's Free and Open Source Software Fund, that spends $12,500 USD quarterly on sponsoring OSS projects, but you need to get lucky to get on that list.
The most suitable option, in my opinion, is a mixed model with a free tier for hobbyists and personal projects, and a paid plan for organizations of sufficient size or income that use OSS projects. This way, author receives a steady income for their effort that is substantially larger than relying on GitHub sponsors or donations. This paid plan does not have to be an extraordinary amount of money, certainly not $130 USD per developer, which FluentAssertions wanted to charge for their library. It is a really helpful library for making your assertions descriptive, I've been happily using it in my projects, but it's almost the same price as Rider subscription. Charging reasonable prices can still add up to significant amount regularly delivered into maintainer bank account, if the tool is popular and widely used.
What to do now?
If you are using these libraries in your personal projects or at work, you might wonder what should you do now? How should you approach this transition in you dev life?
As I mentioned earlier, you can stay with current versions of packages, as they will stay free and open source. Most likely, this will be the default approach. Until the need to pivot to something else occurs, you can safely use free versions or possibly forks that someone decides to create and maintain - it will take time for best forks to emerge. If you don't want to bother with looking for alternatives, that's fine, just remember to not upgrade dependencies to paid versions by accident. Setting up a company-wide CI policy that checks builds for usage of paid dependencies might be a good idea.
But if you want to switch, here's some alternatives you can consider. Although I highly encourage you to think whether you really need those dependencies. Oftentimes we use it without giving it deeper thought, but we can certainly do without them.
Let's start with AutoMapper - if you haven't yet moved from it long time ago, you're already cooked. It had its time of glory, it has its narrow use case, but people are using it wildly. It brings multiple problems - implicit references making refactoring problematic, no way to step through code while debugging, moving compiler errors to runtime errors...
My suggestion is simple extension methods, mapping does not really require some fancy configuration. Having dedicated mapping extension methods is effective, gets the job done and you can easily debug it.
1public static class UserMappingExtensions 2{ 3 public static UserDto ToDto(this User user) 4 { 5 if (user == null) return null; 6 7 return new UserDto 8 { 9 Id = user.Id, 10 Name = user.Name, 11 Email = user.Email 12 }; 13 } 14}
If you really need an alternative mapping library, I can recommend Mapster - it is fast, lightweight mapping library that uses source generation so it's easier time debugging.
MediatR is a tougher nut to crack, but if you are using it simply to decouple your code (which I guess is true for majority of people), it's easy to implement similar solution on your own. You can create your own IRequestHandler interface and implement handlers with "single-class, single-use-case" principle in mind. Those handlers can be injected directly into your endpoint methods using [FromServices] decorator.
1public interface IHandler<TRequest> 2{ 3 Task Handle(TRequest request); 4} 5 6public record SaveTodoItemRequest(string Name, string Description); 7 8public class SaveTodoItemHandler : IHandler<SaveTodoItemRequest> 9{ 10 public async Task Handle(SaveTodoItemRequest request) 11 { 12 // save todo item to db 13 } 14} 15 16[ApiController] 17[Route("[controller]")] 18public class TodoItemController : ControllerBase 19{ 20 [HttpPost] 21 public async Task<IActionResult> SaveTodoItem( 22 [FromServices] IHandler<SaveTodoItemRequest> handler, 23 [FromBody] SaveTodoItemRequest request) 24 { 25 await handler.Handle(request); 26 return Ok(); 27 } 28}
If you are using pipeline behaviors, things get a little more complicated, but your handlers can inherit from base class that adds common behaviour like logging or exception handling. If you still want to use something similar to MediatR, consider Mediator or Wolverine libraries.
MassTransit is a message bus on steroids. Most probably, you're using it for some out-of-process communication. There are some alternative libraries that can support that - I'm thinking about Rebus or Brighter. Check them out and see if they are suitable for your use case.
If you're using message broker like RabbitMQ, maybe it's time to learn RabbitMQ.NET library directly and create your own abstraction for message-based communication. Think of it as a challenge and learn something in the process. You can never go wrong with getting insight of how things work under the hood.
The future of OSS
Will we see more and more popular packages going commercial? It's very likely given the value they provide. While it's sad to see projects that I have profoundly used during my developer journey swing that way, I can understand the rationale behind the decision. Maintaining an open-source project might feel like an obligation to the world once the project is successful. People use it for free and expect bugs to be fixed and new feature rolled out and so on.
Is this uniquely .NET issue? While this is certainly not happening in frontend world, because no library or framework lives long enough for the author to go commercial, it does not seem to be solely a .NET ecosystem issue. These things happen to the projects most widely used by companies or cloud providers, regardless of the the project technology. There are examples of this happening in other areas, like Elasticsearch, Docker, SonarQube or CockroachDB.
Is this the death of open source software? I don't think so, while some projects go commercial, the community will fork and maintain them or just straight up create something new from scratch. Nature abhors a vacuum and that's the same for tech world.