Introduction
AutoMapper is a popular open source object-to-object mapping library for .NET that has been a staple in developer toolkits for years. Jimmy Bogard, its creator, recently announced that AutoMapper will be going commercial.
While this move will enable him to provide better support and continuous improvements, not all teams will be able or willing to move to a paid solution. For these teams, this transition has significant real-world implications for their projects. In this blog, I’ll explore what they can do about it.
The Problem for Existing Users
AutoMapper’s impending commercialization raises uncertainty, particularly with regard to licensing and the cost to use the library. However, it’s important to understand that you should direct these concerns toward the future state of your project rather than the current state. There are a few reasons for this:
- AutoMapper is licensed under an MIT license, which is a perpetual, permissive, irrevocable license. This means that any version of the library that you downloaded under the MIT license will remain under this license. You should have no legal or financial concerns about using these versions.
- AutoMapper is mature. There was a one-year gap between the last two releases, and even minor releases often have a multi-month gap between. AutoMapper also has no active, unresolved Github issues as of this writing. With these factors in mind, you can trust that this is a fairly stable product that you can depend on for some time.
- AutoMapper solves a conceptually simple problem. While it will require a nontrivial amount effort to extricate it from your codebase, and significant planning to determine how and when this will happen, it will not require specialized expertise.
Migration Options
Despite the reassurance for existing users, some may still consider migrating away from AutoMapper to avoid future commercial licensing or to explore alternative solutions. I have provided some options below for migrating away from AutoMapper.
- Use A Different Library
A perfectly valid option is to find another library that does the same thing. This may work well for some teams, but I think this is going to be a worst-of-both-worlds approach when compared to writing your own mapping logic or forking AutoMapper.
The biggest concern is that there is no guarantee that the library you move to will not also go commercial sometime in the future. This obviously impossible to predict, but since mapping objects is such a core component to many applications it probably makes sense to use this chance to make it a part of your own codebase rather than outsourcing it to another FOSS library.
If you do move to another mapping library, here are some factors to consider:
– How similar to AutoMapper is the API and programming paradigm?
– Is the library licensed under a permissive license such as MIT?
– Is the code for the library well written and legible?
– Is the code for the library updated frequently?
– If not, are there active issues for it? - Fork the AutoMapper Code
An alterative to writing your own mapping code from scratch is forking the AutoMapper codebase and maintaining the fork yourself. As long as you fork an MIT-licensed version of AutoMapper you should be free to use and modify it for any purposes you require.
One major advantage to this approach is that your development team is already familiar with AutoMapper and its uses. Any new mapping solution requires retraining the development team. You also benefit from the years of institutional knowledge earned by those who developed and maintained AutoMapper, which could help you avoid many mistake in rolling your own solution. - Create Your Own Mapping Logic and Library
The approach that is most likely to be the best long-term investment for your code is to gradually migrate to your own mapping logic. As a reminder, AutoMapper solves a very simple problem at its core, that of mapping the properties of one object to another. While the implementation of any replacement is likely to be tedious, it is not a high-risk effort, can be done gradually, and ultimately your team will own the mapping library once it is complete.
Conclusion
The commercialization of AutoMapper marks a significant shift in the landscape of .NET object mapping libraries. While existing users can continue to use the software under its current license without legal concerns, exploring alternative solutions can provide peace of mind and potentially better performance or features.
If you would like help with this transition, you can contact the experts at Trailhead who will be happy to help!
