Can Hosted Revenue Fund an Open-Source Business? Ghost's Eleven-Month Break-Even Test
Short answer: Managed hosting can fund open-source software when free adoption creates qualified demand for convenience and paid hosting generates enough contribution to finance both service operations and core development. Track conversion from active self-hosted use, support cost and hosting margin by cohort. Set a break-even deadline and do not treat downloads, stars or community activity as revenue.
Open source removes a software licence barrier. It does not remove the costs of development, security, documentation, support and infrastructure.
Hosting works because some users value installation, updates, backups and reliability more than they value operating the software themselves. The business fails when that paid convenience cannot carry the work enjoyed by free users.
Ghost's hosted funding model
Ghost was founded in 2013 by John O'Nolan and Hannah Wolfe as an open-source publishing platform organised through a non-profit foundation. Its core software could be self-hosted, while Ghost(Pro) provided a paid managed service.
Ghost's second-anniversary account says the team would have reached profitability at seven months but chose to hire two more people, reaching profitability at the 11-month mark in December 2014. At that time, a small team was operating both the open-source project and the hosting infrastructure.
Ghost now describes the model as a cycle in which open software attracts users, some pay for managed hosting, and the revenue funds further product work. Its public model explanation also states that revenue is reinvested into the product and community.
The early account does not publish cohort conversion, hosting gross margin or how Kickstarter funds were allocated by customer. Eleven-month break-even is therefore a result, not a benchmark another project can adopt.
My view is that open source should be treated as a distribution and trust choice, not a substitute for a commercial model. If free users do not create product improvement, reach or a qualified route to paid service, openness may be valuable socially but unfunded commercially.
Use the Open-Source Revenue Flywheel
The Open-Source Revenue Flywheel has five measurable links.
| Link | Measure | Failure meaning | |---|---|---| | Useful free product | Active installations reaching the core outcome | Adoption is superficial | | Community contribution | Code, issues, documentation or referrals accepted | Community cost exceeds value | | Hosting intent | Active users visiting or requesting managed service | Free use does not create paid demand | | Paid service | Activated hosting accounts and retention | Offer or onboarding is weak | | Reinvestment | Contribution funding core development | Hosting cannot sustain the project |
The flywheel works only when each link can be observed. Total downloads are especially weak because automated, abandoned and repeated downloads do not represent active users.
Define what remains free and what is paid
The open-source product should complete its promised core job. The paid service sells operation: installation, updates, security, backups, uptime, support and convenience. Do not intentionally cripple the free version simply to create hosting demand.
State licence, trade-mark and service boundaries clearly. An open-source licence may allow others to host or modify the code while your trade mark and managed service remain distinct. Licence choice, contribution agreements, data and consumer obligations vary by jurisdiction. Obtain qualified local legal advice before release and before accepting substantial external contributions.
The commercial offer should explain the operating work the customer avoids. “Support the project” can motivate some buyers, but durable pricing needs customer value beyond goodwill.
Measure qualified free adoption
Privacy and architecture may limit installation telemetry, and that constraint should be respected. Use lawful, transparent measures such as update requests, opt-in diagnostics, documentation journeys, community questions and hosting enquiries.
Estimate active installations using a documented method and acknowledge uncertainty. Then compare paid sign-ups from known free-user routes with other acquisition. Do not make invasive tracking the price of open source.
Interview both self-hosters and hosted customers. Self-hosters reveal which operating work they accept. Hosted customers reveal the point at which convenience, risk or time becomes worth paying for.
Calculate hosting contribution correctly
Hosting revenue must cover infrastructure, payment fees, support, abuse, backups, monitoring and incident response before it funds product development. Allocate shared engineering carefully; do not assign all core work to hosting merely because the service uses the software.
Calculate contribution by plan and usage cohort. A few resource-intensive customers can make an average account appear profitable until bills arrive.
Then identify the contribution available for the core:
Hosted revenue minus direct service cost minus hosted acquisition cost = contribution to core development and overhead.
The guide on [whether a business can make money](/business-finance/can-this-business-make-money/) helps turn this into a full operating forecast.
Worked example: OpenLetter Publishing
OpenLetter Publishing releases free newsletter software and sells managed hosting. These figures are illustrative.
It estimates 3,600 active self-hosted installations from opt-in update checks. In one month, 180 users visit the managed-hosting comparison, 54 start a trial, 32 activate and 24 pay £35. Hosted monthly revenue is 24 x £35 = £840 from the new cohort.
Across all cohorts, OpenLetter has 210 paying accounts at an average £38, producing 210 x £38 = £7,980 monthly revenue.
| Monthly hosted cost | Calculation | Amount | |---|---:|---:| | Infrastructure and backups | 210 x £8.50 | £1,785 | | Support | 92 hours x £26 | £2,392 | | Payments and abuse | fixed | £410 | | Hosted acquisition | fixed | £620 | | Total direct cost | | £5,207 |
Hosted contribution is £7,980 minus £5,207 = £2,773. Core development and foundation overhead cost £5,600 monthly, so the model has a £2,827 gap.
OpenLetter does not respond by weakening the free product. Support records show that manual migrations consume 51 hours. It prices migration separately at £220 and improves import documentation. Twenty migrations monthly produce £4,400 revenue and cost 20 x 1.4 hours x £26 = £728, contributing £3,672.
Total contribution becomes £6,445, covering the £5,600 core cost with £845. The paid boundary follows operational value, and the free software remains complete.
Set a break-even deadline and funding rule
Crowdfunding, grants, consulting or founder savings can finance the initial gap, but record how many months remain. Set a date by which hosting contribution must cover a defined share of core cost.
Hiring can intentionally delay break-even, as Ghost's account shows. That is acceptable when funded and tied to a measurable constraint. Recalculate the deadline after the decision instead of continuing to cite the original plan.
Do not allow restricted grant or campaign funds to cover uses they were not promised for. Accounting and tax treatment vary, so ask a qualified local accountant how to record advance funding, donations, subscriptions and service revenue.
Protect the project from the service
Managed hosting can pull development towards enterprise operations while community users need core improvements. Publish a product scope and review how engineering time is divided.
Community contributions also require review, maintenance and security work. Accept only changes you can support. A large contributor count is not automatically positive if permanent complexity grows faster than team capacity.
The [business-dependency guide](/operations/business-that-doesnt-depend-on-you/) can help document release, incident and moderation work so neither founder becomes the hidden infrastructure.
Run a 90-day funding test
In the first 15 days, define active adoption, trace current hosting enquiries and calculate contribution by plan. Interview ten self-hosters and ten hosted customers about the operating work behind their choice.
During the next 45 days, test one paid convenience, service or capacity boundary while keeping the free core intact. Track activation, service cost and retention. Use the final month to forecast when hosted contribution covers core costs under expected and downside cases. Continue, change the paid offer or secure an explicit alternative funding source before the runway expires.
Related guides
Frequently asked questions
Does open source mean I cannot charge for the software?
No. Many open-source licences permit charging for distribution, support, hosting or other services, but they impose conditions on use and redistribution. The exact rights depend on the licence. Customers may also obtain the code elsewhere, so a licence fee alone may be difficult to defend. Managed operation, support and commercial assurance can still carry value. Choose the licence deliberately and obtain qualified legal advice, especially if you combine code under different licences or accept external contributions. Do not describe software as open source if its licence does not meet that meaning.
What percentage of free users should buy hosting?
There is no universal percentage. Self-hosting difficulty, customer type, price, privacy and the denominator all change the result. Calculate the conversion required from your economics: core cost plus desired buffer, divided by contribution per hosted account. Then determine how many qualified active users must convert. A low percentage can sustain the project when contribution is high and free reach is large. Measure active, relevant users rather than downloads. Label outside benchmarks as indicative and replace them with your own cohort evidence.
Can consulting fund the open-source project instead?
Yes, but make the subsidy fully visible. Record consulting contribution, staff hours transferred and which product evidence the work produces. Consulting can deepen customer understanding and pay for development, while custom commitments can fragment the core. Set a capacity limit and a date by which the project must support itself or remain intentionally subsidised. Price bespoke work separately and preserve ownership and licensing clarity. Tax, employment and intellectual-property treatment varies by structure and country, so obtain qualified local professional advice.
Should hosted customers receive features self-hosters do not?
They can receive service-specific capabilities such as automated backups, managed delivery, support and operational dashboards. Withholding the core product may undermine the open-source promise and community trust, depending on the model. State the boundary clearly. Some projects use an open core with proprietary extensions, while others keep all software open and charge only for operation. Practitioners disagree about which approach is healthier. My view is that paid differences should follow genuine service cost and buyer value rather than making the free product deliberately unreliable.
How should I count community contributions financially?
Value accepted work at the cost it actually saves, then subtract review, coordination, security and future maintenance. A patch that would have taken an employee ten hours but requires eight hours of review saves little. Documentation, testing and referrals can be valuable even when code is not. Do not record volunteer work as cash revenue. Track contribution type, acceptance rate and permanent maintenance burden. Also establish clear authorship and licence terms. Qualified legal advice is prudent when contributions become material.
What happens if another company hosts my open-source product?
Assume capable competitors may do so when the licence permits it. Compete through operation, trust, support, product knowledge and community relationship rather than surprise. Protect trade marks and customer data appropriately, and follow the licence yourself. A competitor can validate demand while pressuring price. Model that scenario before choosing hosted revenue as the only source. Trade-mark, licence and competition rules vary by jurisdiction, so obtain qualified local advice on what others may offer and how you can describe official services.
Comments (0)