Six Months of OSMF in NPOI: What Worked and What Could Be Better
After 18 years of maintaining NPOI, a maintenance fee is helping turn widespread use into more sustainable support.
I have maintained NPOI for 18 years.
Like many open source maintainers, I did not start the project with a business model in mind. I wanted to build something useful, solve technical problems, and share the result with other developers. For most maintainers, that is how open source begins: curiosity, a practical need, and the satisfaction of seeing others benefit from your work.
But as a project grows, so do its responsibilities. A library that started as a personal interest can become a dependency in other people’s production systems. Compatibility issues, bug reports, release testing, and maintenance continue long after the initial excitement of creating it.
The question of funding often comes later, when maintaining the project has become a substantial, continuing commitment.
In April 2026, NPOI 2.8.0 introduced the Open Source Maintenance Fee （or OSMF), for official binary releases. Around six months later, the project is receiving roughly a little over $1,100 per month through its maintenance-fee and sponsorship channel.
That is meaningful support. It gives me a reason to take this model seriously, while also thinking carefully about how it could improve.
This article is about that experience: Why I adopted OSMF
- What seems to be working
- What still makes the model difficult for maintainers and users.
Before OSMF: Sponsorship and Paid Examples
NPOI already had a sponsorship program for at least 2 years before adopting OSMF.
One experiment was to make npoi examples available to sponsors through a $10-per-month sponsorship tier. The idea was straightforward: developers who benefited from the project could help support its maintenance and receive access to 100+ useful NPOI examples.
Unforunately, there was only 2 sponsors for these examples. I appreciate that support. However, my experience was that restricting access to examples had a very limited effect on funding.
Looking back, I think there was a mismatch between what organizations depended on and what I was asking them to pay for. They depended on NPOI itself. Examples were helpful, but developers could find alternative explanations, inspect the source, or work out a solution independently.
I cannot prove that this explains the results. Still, the experience made me question whether examples were the right place to connect commercial use with maintenance funding.
What Changed After OSMF
With NPOI 2.8.0, the funding conversation became more directly connected to the use of official binary releases.
Instead of simply inviting users to sponsor the project, OSMF introduced a maintenance agreement for qualifying commercial use.
During the months following adoption, more accounts began contributing, and monthly receipts became more substantial. The project now receives roughly $1,100 per month through the channel used for OSMF payments and sponsorships.
For a project that previously received relatively modest financial support, this is a useful change.
It does not mean NPOI is now fully funded. Nor does it mean every payment was caused by OSMF. Some supporters were contributing before the release, and the payment records do not distinguish every maintenance-fee payment from voluntary sponsorship.
Nevertheless, the improvement is real enough to make this a worthwhile experiment.
The Benefits of OSMF
1. It Connects Funding to Organizational Use
Traditional sponsorship often depends on an individual developer’s willingness to donate. OSMF gives organizations a concrete funding decision when adopting official releases, creating an opportunity to budget for the dependencies they use.
2. It Helps Fund Ongoing Maintenance
Compatibility fixes, testing, dependency updates, and release work require continuing effort. For NPOI, the period after adopting OSMF has brought more meaningful financial support for that work. More regular income can make maintenance easier to plan, even without fully funding the project.
3. It Preserves Access to the Source
NPOI’s source remains available under Apache License 2.0. The maintenance agreement applies to official binary releases, while users retain the option to compile independently. This preserves their ability to inspect, modify, and contribute to the code.
Where OSMF Could Improve
1. Payment Should Fit Corporate Procurement
One of the biggest practical challenges is the word “sponsorship.”
Get Tony Q.’s stories in your inbox
Join Medium for free to get updates from this writer.
A developer may understand GitHub Sponsors immediately. A finance department may see a payment category that does not fit its purchasing process.
Some organizations can purchase software or maintenance services but have no established procedure for sponsoring an open source project.
Even when the amount is small, the administrative work can be significant.
Projects adopting OSMF should make procurement information easy to find. Annual billing, invoices, supplier details, and a clear explanation of organizational coverage could help.
GitHub Sponsors can remain a convenient payment method. It should not become an unnecessary obstacle for organizations that need a different route.
Where a separate commercial agreement is offered, it should clearly state whether that agreement satisfies the maintenance obligation.
2. The Terms Should Be Clear Before an Upgrade
Many developers are accustomed to checking a repository’s license badge and assuming it describes everything they need to know.
The distinction between an open source license and an agreement covering official binaries is less familiar.
That creates a communication challenge.
A project should explain the arrangement consistently on its README, package page, release notes, and payment page. Developers should be able to identify the first affected version and find the applicable terms before upgrading.
Clear communication gives teams time to review the change and make a decision. Discovering a new obligation unexpectedly during an upgrade creates avoidable frustration.
3. Maintenance Fees Should Be Distinguished from Support Contracts
A recurring payment can create expectations. A user might assume that paying means their bug report receives immediate attention or that a requested feature will be implemented.
The OSMF model does not automatically provide those guarantees.
Projects should explain this before payment. A maintenance fee supports the project’s continuing work; a support contract may provide specific response times or other commitments.
Those arrangements can coexist, but their boundaries need to be clear. Otherwise, better funding could come with disappointed users and additional pressure on maintainers.
4. Maintainers Should Explain What Funding Makes Possible
Users do not need a detailed accounting report for every payment. But they should be able to understand how financial support benefits the project.
A brief periodic update could describe maintenance priorities, release work, testing improvements, or compatibility issues being addressed. This would help connect payment with the work that often remains invisible.
The reporting itself should be manageable. A funding model that creates too much administration can consume the time it was supposed to support.
My Assessment After Six Months
NPOI’s experience has given me a practical reason to continue exploring OSMF.
Receiving roughly a little over $1,000 per month is meaningful progress compared with the project’s earlier funding experience. It does not solve every maintenance problem, but it provides more financial support for work that has continued for many years.
The OSMF model still needs improvement around procurement, communication, scope, and expectations.
I believe those details deserve as much attention as the fee itself. An organization needs to understand the arrangement and be able to pay through a process its finance team accepts. A maintainer needs to receive support without taking on promises they cannot fulfill.
These first six months suggest that OSMF can help. The next step is to make it clearer, easier to use, and more dependable for everyone involved.
