Proposal: Open Source Maintenance Fee for Verify #1731
Replies: 7 comments 11 replies
-
|
I think it could makes sense to start with a subset of paid/commerical projects to test the waters and if that doesn't make much of a difference, expand to other packages or add all projects under VerifyTests. It could also make sense to try out the different enforcement methods on the subset which could allow you to get feedback before expanding to more packages. |
Beta Was this translation helpful? Give feedback.
-
|
The difference between small and medium organizations feels a bit high. We fluctuate around 20 employees and depending on which side we land on, the price increases 4 times. |
Beta Was this translation helpful? Give feedback.
-
|
In short: I'm for it. If it helps you keep development sustainable it's more than reasonable to request a fee from orgs that make a profit from it. We'd be impacted by this at my organization. Here's how it would work:
Enforcement is annoying and I'd really rather not have to deal with it at first. Any development shop at a decent commercial enterprise is likely to care when licenses change. Announce the change everywhere you can, major version bump, release notes, readme. See how far that takes you first. If it's clear that things aren't aligned and you need to deal with bad actors, then I'm very willing to adopt it as a follow on step. |
Beta Was this translation helpful? Give feedback.
-
|
The idea behind only applying the maintenance fee to extensions that target a paid product is interesting, but does it just complicate the intention of the OSMF? Does it also introduce unintended incentives to use/not use certain extensions? If an organisation is targeting free/open source ecosystems, it may be unlikely to exceed the revenue threshold anyway. If an organisation did exceed the threshold, then it might be appropriate to share some of the revenue with the tools that are helping to generate that revenue. I think it may be simpler to administer for both maintainers and consumers if you leave it as full coverage. Perhaps you could provide an escape hatch by granting free licenses for free/open source projects? I've seen this used in other contexts, although it does come with an unremunerated maintenance overhead. |
Beta Was this translation helpful? Give feedback.
-
|
My org would unfortunately not be able to justify this cost and we'd have to fork or replace. I know that's not exactly helpful, but it is truthful. |
Beta Was this translation helpful? Give feedback.
-
|
Realized I hadn't given you feedback on a specific ask -- I think it should apply to everything, not just some plugins, even though that might help my org specifically avoid the fee. Verify is a tool/ecosystem that unlocks a ton of value. I think the value is in the whole thing, not in parts, and I think you'd sell yourself short by not recognizing that. I think it would end up the worst of all worlds if you only applied it to some plugins -- harder to explain, more cognitive overhead for people deciding whether it applies, confusion about whether the fee is per plugin, still take the "hit" for it being paid even if there are many circumstances in which it's not. I think if you're going to go this route -- which again, I respect -- I think you should fully commit and apply it to the whole ecosystem. You deserve to be able to maintain this software, and applying it to all the software will allow you to do that. |
Beta Was this translation helpful? Give feedback.
-
|
I'd like a little more clarification on employees. My organization has about 300 employees, but they are not in IT. Developers, or people that work with the code only number 3. So where would we fall? Also, while we are a pseudo government agency (water district), we are also not a for profit company. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
The Verify project is considering adopting the Open Source Maintenance Fee (OSMF), and we'd like to open it up for discussion before committing to anything.
Verify has been freely available since 2019. The source code will remain open and freely available under its existing license — what's being proposed is a Maintenance Fee for organizations that generate revenue from using it, not a change to the underlying license.
The reason this is being explored: the ongoing work of maintaining Verify — triaging issues, reviewing PRs, updating dependencies, responding to security reports, producing releases, and supporting the wider ecosystem of extensions — takes real, sustained effort. The Maintenance Fee model is one way to make that work more sustainable without restricting access for individuals or non-commercial users.
The rough shape of the proposal
Cost
The sponsorship levels are outlined on the VerifyTests GitHub Sponsors page and follow the recommended levels from the OSMF:
Required for organizations with annual gross revenue of at least US$10,000 that use Verify as part of revenue-generating activities. Also required for all government agencies.
Existing sponsors
Existing sponsorships are very much appreciated, and the recommended transition is:
Consulting exemption
Organizations that have engaged any of the core maintainers of Verify in consulting work could be exempt from the Maintenance Fee for 6 months from the final date of that work. The reasoning: those organizations would already be directly funding maintainer time, so requiring a separate Maintenance Fee on top would feel like double-dipping.
If this idea proceeds, details such as what counts as "core maintainer" and "consulting work" would be clarified before rollout. Feedback on whether this exemption makes sense, and how it should be scoped, is welcome.
Scope: which projects?
One thing explicitly not decided yet is whether the Maintenance Fee should apply to all projects under the VerifyTests organization, or only a subset.
One option under consideration is to limit the fee to extensions that target paid or commercial products — for example Verify.Bunit or Verify.SqlServer — on the reasoning that organizations using those extensions are already operating in a commercial context. The core Verify package and extensions targeting free/open-source ecosystems would remain fee-free under that model.
Feedback on this scoping question is particularly welcome.
Enforcement
A separate open question: should there be any technical enforcement of the Maintenance Fee, and if so, how?
The options range from purely honour-based (rely on the EULA and trust organizations to do the right thing) through to automated checks. One possibility for the latter is SponsorCheck, which verifies sponsorship status at build time.
A few principles regardless of which direction is chosen:
There are trade-offs in both directions — honour-based is friction-free but relies entirely on goodwill, while automated checks add reliability but also add complexity, potential for false negatives, and friction for legitimate users. Thoughts on the right balance here are welcome.
What would not change
Feedback wanted
Nothing here is locked in. Feedback from the community is welcome before moving forward — particularly from organizations that use Verify, but also from individual contributors and users. Concerns, questions, suggestions on the tiers, the timeline, the scope, enforcement, or the approach overall are all welcome. Please reply below.
For broader context on the model, see the Open Source Maintenance Fee site and its FAQ.
For OSMF specific questions i will be directing people to the above links or to their discussion forum https://github.com/orgs/opensourcemaintenancefee/discussions
Beta Was this translation helpful? Give feedback.
All reactions