Dependency, from xkcd https://xkcd.com/2347/, licensed under CC BY-NC 2.5
Dependency, from xkcd https://xkcd.com/2347/, licensed under CC BY-NC 2.5

Last week brought a little bit of drama to the dotnet development community. The popular open source testing framework Moq briefly moved out of open source and into shareware without much warning. Daniel Cazzulino, the maintainer of Moq, has already indicated the next generation of Moq will have some form of commercial license. The way it was done was inelegant but the reason was all to common: Cazzulino decided he needed more financial support to continue. While I think he could have handled it better, I don’t blame him — we all have bills to pay. The lack of financial support for people who maintain key software is an understated risk in the modern software landscape. Every organization which builds or uses modern software is relying on a massive ecosystem of open source software (OSS). Most enterprises do zero to help those OSS teams who in turn rely on people who are basically volunteers.

What do we expect a volunteer team will do when they are looking at their own bank accounts and realizing the extra hours they put in for free are making other people money? What happens when they conclude that they can’t really support this free product and work a full-time job to pay the bills? What are they to do when they reach the back nine of middle age and discover their retirement prospects don’t look great?

This wasn’t the first time and won’t be the last time the volunteer maintainers of a product have stopped and said they need a viable revenue stream because food doesn’t magically appear in their fridge. The popular user management service Identity Server also was totally free: the maintainers funded themselves through sponsors/donations and charged for consulting services if you needed it. When they released version 5, it became closed source. Not quite as popular as Moq1, they had “only” 40 million downloads from Nuget. They were far more open about the process and even shared the fact that over three years they had only taken in about sixty thousand USD in sponsorships2. After paying project expenses and splitting it between two people, they got about nine thousand per year each. That is less than the cost of family health insurance in the US.

What are we, as users, to do when those volunteers suddenly move a product to a paid model3? What do we do when support ends for an OSS product that sits somewhere in the middle of our software supply chain? Rather than pay for it, we could take our own copy of the old code and maintain it ourselves, right? But, is that desirable? Is that managing our organization’s risk well?

It is not. Your team can clone the code, but your team doesn’t know the code. If you have to fix a problem in an open source cryptographic library, I promise that your team of web developers is not qualified to deal with it. Even for code that they are qualified to deal with, can they handle the volume? No, they can’t. Our projects often import more code from other people than we create ourselves.

I looked at a simple tutorial project for a website written using ReactJS. That tutorial depended on almost eight hundred open source products or sub-products. Real world projects will have many more dependencies. Most organizations can’t hire enough developers as it is, therefore we can assume we don’t have capacity to fix all this other code too. We need that open source community to help us realize our own goals.

Open source drives our own innovation. We need it as a check on what would otherwise be runaway software license costs. We need to support it, not as individuals pushing a few bucks here and there. We need to support it as organizations, as a matter of risk mitigation, and as a matter of sharing the cost of driving innovation. Few projects see donations reach a level that they even offset costs, let alone put food in anyone’s fridge.

So, what are users to do?

  1. Talk to your C-Suite — This might be talking to a wall, but you never know until you try. Come to them with a plan with dollar amounts, not just “we should look into this.” Show the c-suite how much you could be spending. Peace of mind creates its own return on investment.
  2. Sponsor/Donate — Many products already make it possible to donate/sponsor4 them yourself using something like Open Collective or GitHub Sponsors. If you use the software package manager NPM, you can see reports on how many products are looking for donations. But that kind of hat passing isn’t helping anyone buy a new mouse let alone pay any bills.
  3. Hire — If there’s a product you love and want to see maintained, is it really a radical idea to hire the maintainer(s) to maintain it so they get a steady paycheck?
  4. Do not complain when a product goes commercial— You’ve got bills too. In fact, don’t just skip the complaining, actively support them on social media and elsewhere.
  5. Protect yourself — Do make sure you have your own copies of the source code and applications you rely on. Don’t bank on the code and compiled applications always being available for download. The left-pad incident provides a cautionary tale that will help inspire you.

Conclusion

If you’re maintaining or considering starting an open source project, consider what happens if your project is successful. I discuss that in my prior article, “Software Licenses, Open Source, & You.” “Victim of their own success” describes many popular OSS products. That doesn’t mean they have to be. Because we all benefit from the support Open Source gives our organizations, we should make sure the people who provide it get supported in turn. I have been wondering about the value of creating better organizations to help advocate for and organize support5: what if we had open source fund raisers who did the donation drives so the maintainers don’t need to become experts in that too? Would that help or just become another pain in the butt? I don’t know, but I’m forever wondering about when the next project goes dark. Maybe something along those lines would help, maybe it would be just another talk shop. If you have an idea or want to discuss further, message me on LinkedIn, Discord, or Mastodon.

Further Reading

Turner, James. 2021. “Open Source has a funding problem”, Stack Overflow blog. https://stackoverflow.blog/2021/01/07/open-source-has-a-funding-problem/

Leonardo, Jim. 2022 “Software Licenses, Open Source, & You”, Jim’s Rules. https://www.jimsrules.com/2022/12/28/software-licenses-open-source-and-you

Special Acknowledgement

The article image this time comes from Randall Munroe’s xkcd web comic. This is another example of someone making something available for free. I enjoy his comics for their intersection of technology, science, and general nerdiness. I don’t want him to stop, so I buy every book he puts out. You can find those books here: https://xkcd.com/books/. That is a link to his own page, not an affiliate program that sends money my way. This site is built using Jekyll. I realized this past week I wasn’t actually contributing to them, so I added them to my list.

Notes

  1. Moq had 457 million downloads when I looked on August 10, 2023. Even if we assume five thousand downloads by every project using Moq, that’s still almost one hundred thousand projects using it. For the Identity Server numbers, the nature of the product means there would be fewer downloads per project that used it, so 457 million vs 40 million isn’t apples-to-oranges. ↩

  2. https://leastprivilege.com/2020/10/01/the-future-of-identityserver/ ↩

  3. What you should not do is launch into a tirade about how dare they, etc. Choose a constructive path. ↩

  4. My artificial distinction here: donation means one time or small. Sponsorship is a larger commitment — at least ten thousand USD per year sounds about right to be called a sponsor. ↩

  5. There are organizations such as the Apache Software Foundation and .Net Foundation, but these types of organizations are selective about what they support and don’t have a broad reach when it comes to pushing other organizations to support OSS. ↩