Let's Talk Open Source - Prime Reacts

A wave of popular open-source libraries moving from permissive licenses to commercial terms is being framed less as a “rug pull” and more as a business survival move—because maintaining widely used software without reliable revenue has become unsustainable. The core issue isn’t whether users can keep running old versions (they can, under permissive licenses); it’s that the maintainers can’t keep shipping updates, security fixes, and documentation indefinitely for free.

Several high-profile projects—named in the discussion as AutoMapper, Mediator, and Mass Transit—are cited as examples of libraries switching licensing models. The reaction is split: some developers see the change as betrayal and respond by recommending forks, internal rewrites, or removing dependencies. Others argue the shift is predictable once the cost of maintenance, the risk of burnout, and the lack of enforceable “forever free” expectations collide. The argument centers on a simple distinction: once code is published under licenses like MIT, BSD, or Apache, the already-published version remains available under that license forever, so existing users aren’t stripped of what they already have. Forks work for that reason.

Where the conflict sharpens is around updates and operational risk. If a build pipeline automatically pulls “latest” versions, teams can accidentally move onto code that’s no longer under the license they expected—leading to compliance and legal headaches. The advice is blunt: pin dependencies to specific versions, upgrade intentionally, and treat security updates as a planned maintenance task rather than an automatic background process. The discussion also criticizes “internal repos” as a false safety net, noting that internal mirroring can still introduce breaking interface changes or surprise behavior.

For businesses using libraries that have switched to commercial licensing, the practical options are laid out. Teams can (1) keep running the last permissively licensed version until a security vulnerability or needed feature forces a decision; (2) pay for the commercial license; (3) replace the functionality by rewriting or forking—either by building a private fork that rolls the dependency into the codebase, or by creating alternatives. The rewrite path is treated as feasible for many libraries because the hard parts are often already solved problems, and AI tools can accelerate code generation. Still, the tradeoff is responsibility: once a team takes over maintenance, it owns future updates, edge cases, and ongoing support.

The conversation then broadens into open-source sustainability and contributor incentives. It argues that expecting maintainers to provide an SLA-like level of support forever is unrealistic, and that burnout is a predictable outcome when users treat volunteer labor as an entitlement. At the same time, it draws a line between users feeling “betrayed” and contributors who gave code under clear expectations—especially if contributor agreements or licensing terms complicate later monetization.

Finally, the discussion tackles why “Netflix-style” universal funding for open source is hard: measuring impact is gamed. A detailed example points to a prolific npm maintainer whose many related packages drive enormous download counts, illustrating how any metric based on usage can be manipulated by splitting projects into more repositories. The proposed workaround is direct support: pay the projects developers rely on through mechanisms like Open Collective, or fund maintainers directly rather than trying to automate fairness through a single system.

Overall, the message is pragmatic: open source remains valuable—users can copy, run, study, and modify code—but when maintainers change models, the burden shifts to organizations to plan for licensing, pin versions, and budget for either commercial licenses or internal maintenance. The freedom to keep using old code is real; the freedom to demand free ongoing maintenance is the part that no longer holds.