Every time a developer pushes a commit, a meter starts running. The CI vendor counts the seconds, bills the account, and the project moves one step closer to a release. But those minutes often produce nothing: they burn on queue time, on cache misses, on retries after a flaky test. The bill still arrives. The vendor collects. And the maintainer who wrote the code under test, the person whose weekend made the build possible, sees none of it.

This is the quiet asymmetry at the heart of modern software development. Continuous integration has become as essential as the compiler, but the people who keep the ecosystem alive are paid in gratitude, not dollars. The vendors who sell the minutes are doing fine. The gap between the two is worth a closer look.

The Meter Runs While the Maintainers Clock Out

CI vendors price by the minute because minutes are easy to count. A build that takes three minutes costs three minutes of compute. But the meter does not distinguish between a minute spent compiling your code and a minute spent waiting in a queue because the shared runner pool is saturated. Queue time is billable. Cache misses are billable. Retries after an infrastructure hiccup are billable. The vendor's margin comes from selling time, not from selling successful builds.

Maintainers feel this most acutely on nights and weekends. A security fix lands on Saturday afternoon. The maintainer kicks off a CI run, watches it sit in the queue, then fail on an unrelated flaky test, then rerun. Each attempt drains the project's monthly allowance. By Sunday, the fix is in, but the project has burned three hours of compute for what should have been twenty minutes of work. The maintainer gets no compensation for that time, and the project's budget shrinks.

Consider a real example: the maintainer of an open source JavaScript library with a few thousand GitHub stars. The project runs a standard test suite across three operating systems and two Node versions, plus a linting step and a build step. On a typical weekday, there are about 30 builds. Each build averages four minutes of active compute, but with queue time and retries, the billed minutes often reach seven or eight. At a typical rate of $0.008 per minute, that works out to roughly $0.25 per build, or about $7.50 a day, $225 a month. Over a year, that's $2,700. For a project that receives maybe $50 a month in donations, the CI bill is a constant squeeze. The maintainer has to decide between paying out of pocket or asking for help.

Open source projects often rely on free tiers that are generous at first but shrink as usage grows. A project that starts with a few builds a day might stay within the free allotment for months. Then a popular release lands, contributions spike, and the build queue stretches. The project either pays up or slows down. The maintainer, who already donates their evenings, now has to decide whether to spend money on infrastructure that benefits thousands of users who contribute nothing back.

The funding tension is structural. CI vendors are businesses with revenue targets and investor expectations. Open source maintainers are volunteers with day jobs and limited patience for bureaucracy. The vendor can raise prices, tighten free tiers, or add surcharges for parallel jobs. The maintainer can only optimize, negotiate, or leave. Most choose to optimize, because leaving means abandoning users who depend on the project.

Per-Minute Billing: The Math That Favors Vendors

The per-minute model has a built-in bias: it rewards the vendor for inefficiency. A build that runs long, retries often, or waits in queue generates more billable minutes than a lean, cached, deterministic build. The vendor has no incentive to make builds faster or more reliable, because speed cuts revenue. This is not a conspiracy; it is just the shape of the pricing.

Queue time is the most obvious leak. When a project subscribes to a shared runner pool, builds line up behind other projects. The vendor's scheduler decides priority, often based on the plan level. A free-tier build can wait minutes while a paid build jumps ahead. The free-tier project still gets billed for the waiting time, because the meter starts when the job is submitted, not when it starts executing. Some vendors do not charge for queue time, but many do, and the distinction is rarely clear in the pricing page.

Cache misses are a quieter tax. CI systems cache dependencies to speed up builds, but caches expire, get invalidated, or fail to restore across platforms. A cache miss means the build redownloads and recompiles everything, turning a two-minute job into a ten-minute job. The extra minutes are billable. The vendor could design caches to be sticky and persistent, but that costs storage and engineering. The per-minute model makes that the user's problem.

Retry loops multiply the meter. A flaky test fails the build. The maintainer reruns the job. The rerun is a fresh billing event. If the test fails again, another rerun. Each attempt is a separate charge, even though the code did not change. Some vendors offer retry credits, but they are limited and rarely cover the full cost of a flaky suite. The vendor's revenue scales with failure, not with success. A project with a healthy test suite and stable infrastructure pays less than a project fighting flakiness, through no fault of the maintainer.

Open Source's Unpaid Backbone: The Bus Factor

The people who absorb these costs are often a single maintainer. The bus factor, the number of people who need to be hit by a bus before a project stalls, is one for many widely used libraries. One person holds the keys to the repository, the CI configuration, and the release process. That person is usually unpaid, or paid a token stipend from a foundation, or employed by a company that sponsors the project as a side task.

Burnout is the natural outcome. A maintainer spends their weekend triaging issues, reviewing pull requests, and debugging CI failures. The CI bill arrives with a line item for minutes that produced nothing. The maintainer has to explain to their spouse why they are spending money on a project that gives them nothing back. Eventually, the maintainer steps down, or the project goes dormant, or the bus actually hits.

Security fixes wait for weekends because that is when maintainers have time. A vulnerability is disclosed on a Tuesday. The maintainer is at their day job. The fix sits in a branch until Saturday. Meanwhile, the CI vendor bills for every failed attempt to reproduce the issue. The community wonders why the fix is slow, not realizing that the person who would fix it is also the person who has to pay for the compute.

Donations rarely match vendor revenue. A project with tens of thousands of stars might receive a few hundred dollars a month in sponsorship. The CI vendor serving that project bills thousands of dollars a year, most of it from the maintainer's own pocket or from a corporate sponsor's budget. The asymmetry is stark, and it shapes which projects survive. Projects with corporate backing thrive. Projects without it struggle to keep the lights on, not because the code is bad, but because the infrastructure costs money.

Who Pays for the Build? The Money Flow

The money flow in open source is bizarre. Corporations profit from free code, but the cost of building and testing that code falls on the maintainer. A company integrates an open source library, saves millions in development costs, and pays nothing back. The maintainer, meanwhile, pays for CI minutes out of pocket or from a small donation pool. The vendor's margins dwarf the project's income.

Vendor margins are the elephant in the room. CI vendors operate on compute that is cheap at scale, but they charge a premium for convenience. The margin on a minute of build time is high, especially for managed runners. The vendor's revenue per user is small, but multiplied across thousands of projects, it adds up. Open source donations, by contrast, are voluntary and sporadic. A project might get a one-time $500 grant from a foundation, then nothing for a year.

Contracts favor large enterprises. A big company can negotiate a volume discount, get dedicated runners, and have a support team on call. A small project gets a self-serve plan with no negotiation. The per-minute price is the same for everyone, but the enterprise can absorb it. The small project cannot. This creates a two-tier system where large corporations pay less per minute than individual maintainers, even though the maintainers are the ones creating the value.

Small projects get squeezed out of the ecosystem. A project that cannot afford CI is a project that cannot merge pull requests confidently, cannot ship releases reliably, and cannot attract contributors. The project dies, not because it lacks merit, but because the infrastructure costs too much. The community loses a useful tool, and the CI vendor loses a customer, but the vendor's business model does not care. There is always another project.

When the Bill Arrives: Real-World Friction

Startups feel the sting first. A small team starts with a free tier, hits the limit, and gets a surprise invoice for overages. The invoice is not huge, but it is unexpected, and it comes at a time when the startup is burning cash. The team cuts features, or moves to a cheaper vendor, or self-hosts. Each option has hidden costs.

Hobbyists abandon projects when the bill arrives. A personal project that runs a few builds a month might exceed the free tier after a busy weekend. The hobbyist, who has no budget, simply stops pushing code. The project goes stale. The maintainer loses interest. The community loses a potential tool. The CI vendor loses a tiny account, but the loss is invisible.

Self-hosting is the escape hatch, but it is not free. Running your own CI server means managing hardware, patching software, and handling outages. The ops burden is real, and it eats the time that the maintainer would rather spend on code. A self-hosted runner also lacks the vendor's convenience features, like automatic scaling and integrated caching. The trade-off between cost and effort is rarely discussed in the vendor's marketing.

Trade-offs are real and often ignored. A maintainer who self-hosts saves money but inherits a second job. A maintainer who stays on a vendor pays for convenience but watches the meter run on queue time. The industry has not converged on a better model. The per-minute pricing persists because it is simple to understand and easy to bill, even if it is unfair to the people who create the software.

The Hollow Promise of 'Free' Infrastructure

Free tiers are marketing, not charity. They exist to get a project hooked, to make it dependent on the vendor's workflow, and to convert it to a paid plan when usage grows. The free tier masks the true cost of CI, which is not zero. The cost is paid in queue time, in slower builds, and in the constant pressure to stay within the limit.

Usage caps trigger sudden charges. A project that runs a few builds a day might suddenly see a spike after a conference talk or a Hacker News post. The spike pushes the project over the cap, and the vendor charges for every minute over. The maintainer, who was not prepared, has to scramble to find money or cut back on builds. The vendor's pricing model punishes success.

Open source subsidizes vendor growth. The free tier is a loss leader, but the loss is borne by the maintainers who put up with the limitations. The vendor's valuation grows on the back of thousands of projects that pay nothing. The projects get a service, but the relationship is one-sided. The vendor does not contribute code, does not fix bugs, and does not share the revenue.

Transparency in pricing is rare. Vendors publish a rate per minute, but the fine print about queue time, cache misses, and retries is buried in documentation. The maintainer who reads the pricing page sees a simple number, not the complex reality of what gets billed. The hidden tax is real, and it is paid by the people who can least afford it.

What Maintainers Can Actually Do

Optimization is the first lever. A maintainer can reduce minutes by caching dependencies, splitting builds into parallel jobs, and avoiding redundant test runs. The goal is to make every minute count, so the meter runs for less time. This is not glamorous work, but it is the most direct way to cut costs.

Caching is the biggest win. A well-configured cache can cut build times by half, sometimes more. The trick is to make the cache reliable across platforms and branches. Vendors offer cache features, but they are not always easy to configure. A maintainer who invests in caching can save hundreds of dollars a year.

Negotiation is possible, even for small projects. Some vendors offer free tiers for open source projects, but the criteria are opaque. A maintainer can apply, cite the project's popularity, and ask for a waiver. The worst that can happen is a no. Some projects have successfully gotten free access by writing a clear request. However, it is important to remember that not all vendors will respond positively. The process can be time-consuming, and there is no guarantee of success. It is worth trying, but it should not be the only strategy.

Sponsorship is the sustainable fix. A project can ask users to sponsor the CI costs, either through a platform like GitHub Sponsors or through a direct request. The money is small, but it covers the meter. A project with a few hundred dollars a month can afford a reasonable CI plan. The key is to be transparent about where the money goes.

Pushing for per-build pricing is a longer shot, but it is worth trying. A per-build model charges a flat fee per successful build, regardless of how long it takes. This aligns the vendor's incentive with the user's, because the vendor wants the build to succeed quickly. Some vendors have experimented with this model, but it is not widespread. A maintainer who asks for it, in public, might start a conversation.

The broader fix is structural. The industry needs to recognize that open source maintainers are not free labor. They are the foundation of the software economy, and they deserve a share of the revenue that their code generates. Until then, the meter will keep running, and the maintainers will keep clocking out.

Alternative Pricing Models: A Path Forward

The per-minute model is not the only way to price CI. A few alternatives have been tried, with varying degrees of success. One is the flat-rate plan, where a project pays a fixed monthly fee for a certain number of parallel jobs, regardless of how many minutes they use. This gives maintainers predictable costs, but it can be wasteful if the project does not use the full capacity, and vendors may set the flat rate high enough to cover the heaviest users.

Another model is per-build pricing, where the vendor charges a flat fee per successful build, regardless of duration. This aligns the vendor's incentive with the user's, because the vendor wants the build to succeed quickly. However, it can be difficult for the vendor to set a fair price, and it may not account for the cost of failed builds or retries. Some vendors have experimented with this model, but it is not widespread.

A third model is resource-based pricing, where the vendor charges for the actual compute resources used, such as CPU-seconds and memory, rather than wall-clock time. This is more granular and can be fairer, but it is also more complex to understand and bill. It may also disadvantage projects that have long-running tests that are not CPU-intensive.

Finally, there is the cooperative model, where open source projects pool their resources and run their own CI infrastructure. This is the most radical option, but it has been done successfully by some communities. For example, the Debian project runs its own build infrastructure, and the Rust project uses a mix of self-hosted and cloud-based runners. The challenge is the initial setup and ongoing maintenance, but the long-term savings can be significant.

Each of these models has trade-offs, and none is perfect. But the fact that they exist shows that the per-minute model is not inevitable. Maintainers and the broader community can push for change by asking vendors for alternatives, supporting projects that experiment with new models, and being vocal about the unfairness of the current system.

Conclusion: A Call to Action

The per-minute billing model is broken for open source maintainers. It charges for time that produces nothing, it rewards vendors for inefficiency, and it leaves the people who create the software with the bill. But there are things we can do.

If you are a maintainer, start by optimizing your builds. Cache aggressively, split your test suite, and eliminate redundant steps. Then, be transparent about your costs. Put a line in your README that says, "This project needs $X per month for CI. Please sponsor us." You might be surprised by how many users are willing to help.

If you are a user of open source, sponsor the projects you depend on. Even a few dollars a month makes a difference. If you work at a company that uses open source, ask your employer to contribute to the projects you rely on. Many companies have open source sponsorship programs, and they are often underutilized.

If you are a vendor, consider offering alternative pricing models. Per-build pricing, flat-rate plans, and resource-based pricing all have their merits. Listen to your users, and be transparent about what you bill and why.

The fight for fair CI pricing is not over, but it is winnable. It starts with awareness, and it grows with action. Every minute counts, and every dollar helps. Let's make sure the meter stops running on the backs of volunteers.