The open-source business model for developer libraries

You wrote a React library. People use it. GitHub stars climb. npm downloads tick up. And then the hosting bill arrives, someone opens a feature request that would take three weeks, and you realize you've built yourself an unpaid job.

The open-source services market hit $49 billion in 2025, projected to reach $105 billion by 2032 (TechNews180). But most of that money flows to companies with 50+ engineers and enterprise sales teams. If you're a solo developer or a small team shipping a React library, the playbook looks different.

I built Tour Kit as a solo developer. Ten packages, MIT-licensed core, TypeScript-strict, the whole thing. Along the way I had to choose a business model that wouldn't alienate the developers I was trying to serve. Here's what I learned, and what I'd tell you if you were making the same choice today.

Three models that actually work for libraries

Developer libraries that generate real revenue in 2026 almost always use one of three approaches: open core, dual licensing, or managed SaaS. Each one makes different tradeoffs between adoption speed, revenue potential, and community trust. Sponsorship and donations exist too, but they aren't business models. They're tips.

Open core

You ship the core library under MIT or Apache 2.0. Everyone can use it, fork it, embed it. Then you build premium features on top and sell those under a proprietary license.

Open Core Ventures calls this "buyer-based segmentation": features that matter to individual contributors stay free, features that matter to managers and executives go behind the paywall (Open Core Ventures). GitLab does this with merge request approvals. SonarQube does it with branch analysis and security reports.

For a React library, the split might look like:

// Free (MIT) — the core developer experience
import { useTour, TourProvider } from '@tourkit/core';
import { TourStep, TourOverlay } from '@tourkit/react';

// Pro (proprietary) — team and business features
import { AdoptionDashboard } from '@tourkit/adoption';
import { SchedulingProvider } from '@tourkit/scheduling';
import { SurveyTrigger } from '@tourkit/surveys';

The hard rule: never move a free feature behind a paywall. As the Open Core Ventures team puts it, doing so "completely erodes trust." Once trust is gone in open source, it doesn't come back.

Dual licensing

You publish under AGPL or GPL. Anyone can use it for free in open-source projects. Companies that want to use it in proprietary software pay for a commercial license.

Dual licensing works when your library gets embedded inside other products. Databases, engines, SDKs. MongoDB ran this model for years before switching to SSPL.

But for a React UI library? Most of your users are already building proprietary apps. Telling them they need a commercial license just to use your tooltip component creates friction right where you need adoption.

There's also the React licensing cautionary tale. In 2017, Facebook shipped React under BSD + Patents. The Apache Foundation banned it. WordPress dropped React from Gutenberg. Facebook reversed course and relicensed under MIT. Restrictive clauses cause backlash even when the library is dominant.

Open-source SaaS

The entire codebase stays open source. Revenue comes from hosting a managed version.

Nevo David, the solo developer behind Postiz, runs this model and hit $14.2k per month in revenue. His philosophy: "Everything must be open-sourced. I charge only for cloud costs, never forcing developers to pay" (Indie Hackers).

The catch for library developers: your product runs inside someone else's app. There's no server to host. You can't offer a managed version of a React hook. This model fits tools with a backend component (analytics dashboards, CMS platforms, scheduling services) better than pure frontend libraries.

Why open core wins for most libraries

Open core is the right default for developer libraries, and it comes down to one thing: it aligns the incentive structure. The developer gets a complete, genuinely useful free tier. The business gets features that justify a purchase order. Nobody feels cheated.

As of April 2026, 96% of organizations maintained or increased their open source usage (Linux Foundation, 2025). Companies aren't afraid of open source anymore. But their procurement teams still need something to buy. Open core gives them that something.

The three-tier structure that works for most developer tools:

The segmentation question isn't "how hard was this to build?" It's "who benefits most from this feature?" If a solo developer needs it to ship a side project, it should be free. If a VP of Product needs it to justify onboarding spend to the CFO, it can be paid.

The counterargument: why some developers avoid monetization entirely

Not everyone should monetize, and the argument against it is stronger than open-core advocates usually admit. The moment you add a paid tier, you create a class system in your community that changes how people interact with your project. Feature requests get filtered through "is this free or paid?" Every API design decision carries commercial weight.

You spend time on license key validation instead of fixing bugs.

Some of the most impactful libraries in the React ecosystem are fully MIT with no paid tier. React Router, Zustand, TanStack Query. Their maintainers found other paths: consulting, full-time employment at companies that use the library, or they just maintain it as a passion project.

There's also the contributor friction problem. Dual licensing requires Contributor License Agreements. Open core means some PRs touch proprietary code that contributors can't see. Both create social awkwardness in what should be a collaborative space.

If your library is small in scope (a single hook, a utility function, a CSS-only solution) monetization probably isn't worth the overhead. But if you're maintaining a system with multiple packages, a docs site, integration tests, and user support, the "just do it for free" model has an expiration date.

The tooling that makes this possible in 2026

Two years ago, going from "MIT library on npm" to "actual business with license keys" required stitching together Stripe, a custom license server, and a lot of middleware nobody wanted to write. That friction kept most library authors from even trying to monetize.

That gap is closing. Polar.sh handles license key generation, GitHub repo access gating, and payment processing for a 4% + 40c transaction fee with no monthly costs. They've processed over $10 million in transactions and they're open source themselves (Apache 2.0).

GitHub Sponsors charges 0% for personal sponsorships and up to 6% for organization accounts. It won't replace product revenue, but it funds the gap between "I need $500/month for hosting" and "I need $5,000/month to work on this full-time."

The practical stack for a solo developer selling Pro features in 2026:

1. Core library on npm under MIT
2. Pro packages in a private npm registry or gated GitHub repo
3. Polar.sh or Lemon Squeezy for license key generation and payment
4. License validation as a build-time check (not runtime, never runtime)
5. GitHub Sponsors for community support on top

What we chose for Tour Kit (and why)

Full disclosure: I built Tour Kit, so this section is about my own decisions. Tour Kit is a younger project with a smaller community than React Joyride or Shepherd.js, and it doesn't have a visual builder, so take this with appropriate skepticism.

Tour Kit uses open core. Three packages are MIT-licensed and always will be: @tour-kit/core, @tour-kit/react, and @tour-kit/hints. They give you everything you need to build product tours: hooks, providers, positioning, highlighting, keyboard navigation, WCAG 2.1 AA accessibility.

Seven extended packages are proprietary and require a Pro license: adoption tracking, analytics, announcements, checklists, media embedding, scheduling, and surveys. These are features a solo developer building a side project doesn't need. They're features a product team onboarding 10,000 users per month does need.

The price is $99 one-time. Not per seat, not per month. One payment, lifetime access, all future updates.

Why one-time instead of subscription? Because the library runs in your bundle, not on my server. There's no ongoing cloud cost for me to cover. Charging monthly for code that ships statically felt dishonest.

The math works because the volume of React developers who need onboarding libraries is large enough that one-time purchases at $99 sustain development. If your library has a backend component or per-user scaling costs, subscription makes more sense. But for a pure frontend library, one-time licensing removes the "will they cancel?" anxiety and lets you focus on building.

What I'd do differently

I underestimated how much time license key infrastructure takes. We tested three different approaches before settling on Polar.sh for key generation and validation. Handling edge cases (team licenses, expired keys, offline validation) and building the checkout flow ate two full weeks. Use an existing platform. Don't build your own payment system.

I also waited too long to define the free/paid boundary. Every feature I built in the first six months went into the free tier by default. When I later moved to open core, I had to be very careful not to reclassify anything that was already free. Define your boundary early, even if you don't charge yet.

Five rules for monetizing a developer library

After testing different approaches with Tour Kit and watching projects like Shepherd.js, React Joyride, and Postiz navigate the same decisions, these are the rules I'd follow. Your mileage may vary.

1. The free tier must be genuinely complete. If developers feel like they're using crippled software, they'll resent you. The free tier should solve a real problem end-to-end.

2. Never move a feature from free to paid. Add new paid features. Never reclassify existing ones. Shepherd.js's switch from MIT to AGPL cost them community trust. React's BSD+Patents license cost Facebook an ecosystem revolt.

3. Price for the buyer, not the builder. A VP evaluating onboarding tools has budget. A junior developer learning React doesn't. Your pricing should reflect who's buying, not how many hours you spent.

4. Keep license validation out of the runtime. A network call to validate a license key during useTour() initialization is a performance bug your users ship to their users. Validate at build time or install time. Never at runtime.

5. Open source your marketing, not just your code. Publish your roadmap. Write about your pricing decisions. Developers trust what they can inspect, and that includes your business model.

FAQ

What is the best business model for an open-source developer library?

Open core is the strongest default for developer libraries in 2026. The core library stays MIT-licensed and free, while extended features (analytics, scheduling, enterprise compliance) are sold under a proprietary license. As of 2026, 96% of organizations maintained or increased their open source usage (Linux Foundation), making MIT-licensed libraries the standard entry point for enterprise adoption.

How much money can you make from an open-source library?

Revenue varies widely based on audience size and pricing model. Nevo David, a solo developer, earns $14,200 per month from Postiz using an open-source SaaS model (Indie Hackers). The global open-source services market reached $49 billion in 2025. For a niche React library, realistic targets range from $1,000-10,000 per month depending on the paid feature set and market size.

Should I use dual licensing for my React library?

Dual licensing (AGPL + commercial) works best when software is embedded inside other products, like databases or engines. For React UI libraries, most users build proprietary apps, so AGPL creates immediate friction. React's 2017 BSD+Patents controversy showed that restrictive licensing drives users away. MIT with open core is safer.

What platforms help developers monetize open-source projects?

Polar.sh charges 4% + 40c per transaction with no monthly fees and handles license keys, GitHub repo gating, and payments. GitHub Sponsors takes 0% on personal sponsorships. Open Collective provides fiscal hosting for community-funded projects. For license key distribution specifically, Lemon Squeezy and Polar.sh both integrate well with npm package workflows.

Is GitHub Sponsors enough to sustain a library?

GitHub Sponsors alone rarely covers full-time development. It works as supplementary income (hosting costs, domain renewal, minor expenses) but the 0% fee structure and tip-based nature mean revenue is unpredictable. For sustainable library development, combine Sponsors with a paid tier (open core) or managed hosting (SaaS) to create recurring, predictable revenue.

Tour Kit is an open-source product tour library for React. The core packages are MIT-licensed and free. Extended packages require a Pro license. This article reflects the author's own experience choosing a business model — your situation may differ.

Related articles

Thought LeadershipApr 11, 2026 · 11 min read

How AI will change product onboarding (and what won't change)

AI will personalize onboarding timing, content, and sequencing. But trust, accessibility, and user control still require human decisions. A developer's take.

Read article

Thought LeadershipApr 11, 2026 · 8 min read

Why the best onboarding software in 2026 is a React library

Code-first React libraries beat SaaS onboarding platforms on cost, performance, and control. Pricing data, bundle sizes, and architecture compared.

Read article

Thought LeadershipApr 11, 2026 · 7 min read

GitHub stars don't pay the bills (but they help)

A solo developer's honest look at what GitHub stars actually do for an open-source library. Real numbers on the gap between stars and revenue.

Read article

Thought LeadershipApr 11, 2026 · 10 min read

From 0 to 1000 GitHub stars: the Tour Kit playbook

How I grew a React product tour library from zero to its first 1,000 GitHub stars as a solo developer. Real tactics, real numbers, no paid ads.

Read article