Do You Have an Open-Source Exit Strategy?

Last week, I learned about the sudden end of the life of SpecFlow, a well-known Behavior-Driven Development testing tool for .NET.

Since I personally used to work on projects using SpecFlow, and because I recorded paid content on my YouTube channel about it in the past, I covered the story in a new video.

It made me think of the importance of an exit strategy when using open-source libraries for a project.

What Is an Open-Source Exit Strategy?

When adding a dependency, we should already think about the exit strategy. What if the library isn’t actively developed?

What if the maintainers go down a path that doesn’t suit our project anymore? Or what if they unexpectedly change the license as they did with FluentAssetions?

There are different options:

  • Fork the project and maintain it yourself: This option is probably straightforward but a lot of work.
  • Migrate to a different library: This option is likely also a lot of work. Maybe search & replace and generative AI could help, but it’s still a considerable effort in most cases.
  • Gradually phase it out. Instead of migrating to another library in a big effort, you keep the old library and migrate as you go. This takes a lot longer but does not use as many resources in a single process.
  • Write a custom replacement. If no other good option exists, you might want to implement your own solution. Depending on the scope, this could be a viable option for smaller libraries.
  • Relay on standard features. Sometimes, a historically developed application uses dependencies for features that make their way into the platform. Examples are Newtonsoft.JSON for .NET, or Lowdash for the JavaScript world. You can migrate off the dependency and use native platform features.
  • Stay on the old version. Use the latest available, stable, and open-source licensed version of the library and stay there. There is a potential risk if you don’t implement or receive security updates, but it is the option with the least effort.

What Do All Those Exit Strategies Have in Common?

They are risks. I highly recommend thinking of potential exit strategies for the open-source dependencies you have in your project. It’s great to have a strategy in case something suddenly changes - for example, as SpecFlow did.

Claudio Bernasconi
Claudio Bernasconi
I'm an enthusiastic Software Engineer with a passion for teaching .NET development on YouTube. I write articles about my journey on my blog, and author the Blazor Basics series for Progress Telerik.