Proposal: Open Source Maintenance Fee for Verify

[SimonCropp]

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

• Targeted for rollout in September 2026, giving roughly four months of lead time.
• Applies to organizations that generate revenue, and government agencies, when using Verify's official binary releases.
• Tiered based on organization size, with a single subscription covering all products and uses within that organization.
• Payment via GitHub Sponsors, which supports monthly billing, annual billing, and invoicing.
• A major version bump will be done at release time on any package that requires the OSMF, so consumers see a clear signal in their package manager.

Cost

The sponsorship levels are outlined on the VerifyTests GitHub Sponsors page and follow the recommended levels from the OSMF:

• Small Organization (fewer than 20 employees): $10/month
• Medium Organization (20 to 100 employees): $40/month
• Large Organization (more than 100 employees): $60/month

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:

• Individual sponsors should stop their personal sponsorship and let their employer know that, if the employer meets the requirements, the employer should now be sponsoring rather than the individual. The Maintenance Fee is designed to be paid by organizations, not individuals out of pocket.
• Organization or company sponsors should move to the tier that applies to them based on their size.

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:

• No phone home. Any form of runtime telemetry or "phone home" mechanism is off the table and will not be considered.
• Escape hatch. Whatever option is chosen will include an escape hatch so it can never block productivity — for example, an opt-out flag or override for cases where a check produces a false negative or the user simply needs to keep working. The working assumption is that most people are doing the right thing, and the enforcement mechanism should not punish them when something goes wrong.

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

• The source code stays open and freely available under its existing license.
• Individuals and non-revenue-generating organizations (excluding government agencies) would not be required to pay.
• All existing and future versions would remain available to paying organizations while their sponsorship is active.
• CI usage, forks, contributions, and local development would be unaffected.

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

[radmorecameron]

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.

[SimonCropp]

@radmorecameron out of curiosity, what extensions to Verify are you using?

[radmorecameron]

I was using the Playwright extension but I'm no longer working on the project that was using it 🙂

[Skleni]

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.
Also, you might want to clarify how "employees" are counted. Just the number of people being employed? Full-time equivalent? What about interns?
This might feel very specific, but in our case these questions would make a difference.

[SimonCropp]

clarify how "employees" are counted. Just the number of people being employed? Full-time equivalent? What about interns?

if people are part-time u can count the % part they work to the count. yes interns count

i will clarify that in the above terms.

the price increases 4 times.

i think it is important to qualify "4 times" here. we are talking the difference between 33c and $1.33 per day. from my perspective, if a dependency was not providing significantly more value than $1.33 per day, then i would question if that is a dependency we should even take.

[SeanKilleen]

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:

• I'd note the license change (which should come with a major version bump)
• I'd raise to the team
• We'd have a discussion on whether we get $480/year of value from the tool, or whether it's worth spending $x in dev-time to move away from it
• We (almost certainly) decide to adopt the tool
• I make GitHub sponsorship the same day to unblock our update path.

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.

[SimonCropp]

i fleshed out my thinking https://github.com/SimonCropp/SponsorCheck/blob/main/docs/WhyBuildTimeVerification.md

thoughts?

[AndrewTriesToCode]

Hi @SimonCropp I maintain a small popularish multi-tenant library for .NET and have been following OSMF and your discussion here. I’ve got a few GitHub sponsors. Some come and go, may one timers, and a few loyal monthly sponsors.

I think that build time checks are the most likely thing that people will tolerate in the .NET open source / enterprise ecosystem.

It’s a tough space. Even if they want to sponsor, corporate red tape gets in the way. It’s so frustrating because I’ve seen the dumb stuff companies will pay for if it’s slightly more visible to their customers.

[SeanKilleen]

@SimonCropp I read the proposal. I appreciate you writing it up.

My point is mostly that if you degrade the experience of good actors in order to attempt to shrink the number of uninformed actors, you will lose good (paying) actors if unnecessary friction occurs. I would first establish who that group of good actors is, which also allows you to give specific warning on build-time changes, explain reasoning, and create a direct line for feedback if things break. These groups will be customers now in a sense, and they will absolutely see themselves as customers (however limited it may be), because they are paying for a good. People who are going to do the right thing by default don't appreciate being lumped in with the rest of folks who won't.

So if you're going to proceed with this, I think the key is minimizing friction through incredibly clear communication on exactly what steps customers need to take if things break. I think you have a solid plan, but I propose moving in these stages to avoid any risk of alienating good actors who are going to pay for your software vs remove the dependency.

To be clear: still 100% in support of you changing licenses and being compensated for your important work.

[SimonCropp]

@SeanKilleen

the friction you are concerned about is a build error, where it explicitly gives you the msbuild property to use to disable the error. it is the least friction way i can think of for ensuring people see the changes.

if you degrade the experience of good actors

Again it is a single build error that is trivial to disable.

I propose moving in these stages to avoid any risk of alienating good actors who are going to pay for your software vs remove the dependency

i am moving in stages. thats was me advertising this discucssion and the plan is. the final point is switching on the build notification. that is for people who have not seen it on social media, not read the comms in the readme

. I would first establish who that group of good actors is

i have no idea how to achieve this.

I think the key is minimizing friction through incredibly clear communication on exactly what steps customers need to take if things break.

all that is done.

People who are going to do the right thing by default don't appreciate being lumped in with the rest of folks who won't.

"People who are going to do the right thing by default " can see the build notification and still do the right thing. and the build notification clearly explains how to easily disable it.

[SeanKilleen]

@SimonCropp I think you're mistaking my feedback for argument. I'm not telling you that you are wrong or trying to have a debate with you 👍. I'm providing feedback on how I think people who are paying for the software are going to perceive it. Those people are not necessarily me; just based on my experience in dealing with dev shops of various quality.

It sounds like you feel confident that this will not cause the issues I'm concerned about. Great!

Again it is a single build error that is trivial to disable.

Hopefully so, because if it takes a dev a non-trivial amount of time to make that change and get it through the process, meanwhile a whole team is raising concerns about not being able to build the solution, an alarm bell goes off that says "I should remove this dependency; it's not worth this mess."

---

In reality, probably a non-issue for most. In our specific case if that happened, RenovateBot would create a PR with the latest package, the build would fail in that PR in our CI, we'd check it out, have discussion to sponsor, make the sponsorship change, update that PR and merge it, so very little chance of a breaking issue for our team in particular.

[ValdisThomann]

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.

[ProbablePrime]

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.

[SimonCropp]

is the level of $$ that is the issue?

[SeanKilleen]

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.

[randellhodges]

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.