Why Miton is not fully open source

I love open source. Miton exists because generations of people published code, documented strange edge cases and maintained the unglamorous foundations underneath modern software. The repository is licensed under AGPLv3 because inspection, modification and reciprocal contribution are real product values, not a badge for the footer.

But I do not believe that every part of Miton should be free of a commercial boundary. More importantly, I do not believe an ambitious product becomes sustainable merely because its source is available.

Open source is a distribution and collaboration model. It is not a staffing plan.

Miton is also heavily LLM-developed. I am not trying to hide that behind vague language about “AI-assisted workflows”. Models produce a substantial amount of the code, tests, documentation and analysis involved in building the product. I set the direction, make the product and licensing decisions, demand evidence, and remain accountable for what ships under the Miton name.

That approach changes what a very small team can attempt. It does not make the product self-maintaining. Models do not hold long-term responsibility for a security response, notice that a contributor is burning out, negotiate a disputed product boundary or promise to support three operating systems next year. They can accelerate the work. They cannot be the organisation that stands behind it.

The work does not end when the code is published

An agentic workspace has a long tail of responsibility. Somebody has to reproduce the Windows bug, test the Linux package, review a security report, update the model catalogue, explain a routing decision, maintain the documentation and decide which of three reasonable pull requests preserves the product’s direction. Somebody has to be accountable when an operating-system update breaks signing on a Friday evening.

Community contributions can make all of that work better. They cannot guarantee that the work will be done next Tuesday.

Jellyfin offers a useful and unusually candid example. It is a genuinely free, volunteer-only media project, and its team has chosen that model deliberately. In its 2023 call for developers, the project said its core contributor base was at most about 30 active people across the server, web interface and every client. Some apps had only one or two people working on them, and requested work had stalled or been abandoned when nobody had the time to take ownership.

In May 2026, Jellyfin’s own project update described burnout across its development and administration team. Support demand, abuse and a flood of poor AI-authored submissions had already delayed client and server improvements. This is not a failure of Jellyfin, nor an argument that its principles are wrong. The team’s honesty is admirable. It is evidence that large, popular software creates operational work faster than goodwill can reliably absorb it.

The wider ecosystem says the same thing. GitHub describes maintainer burnout as a major software supply-chain risk and an enormous funding gap even after $100 million had moved through Sponsors. Its writing on the next generation of maintainers connects longevity to succession, compensation and real paths into leadership—not simply a larger pile of issues marked “help wanted”. The Apache Software Foundation likewise funds governance operations, project tooling and community infrastructure because healthy projects need more than source code.

The lesson I take from these projects is not “close the repository”. It is that maintenance, leadership and continuity need an explicit economic home.

Low pricing is the point

Miton’s intended v1 packaging separates the workspace licence from model spend. You bring the hosted providers or local models you want. Miton does not need to turn a token allowance into a mystery margin, and it does not become more profitable when the workspace wastes your context on an oversized model.

The intended Pro price is low on purpose: currently $10 AUD a month or $199 AUD once, subject to the v1 licence and release gates. That is not pricing engineered for amazing riches. It is an attempt to fund a small, dedicated team that can keep showing up.

Heavy LLM development is one reason Miton can aim for a modest price. It reduces the labour required to explore, implement and verify a broad product. It does not reduce that labour to zero, and it adds real costs of its own: model access, evaluation, review, integration and the discipline to reject plausible output that is wrong. Customers should benefit from the leverage without being sold the fiction that software now looks after itself.

A paid team can own the boring promises:

• releases for macOS, Windows and Linux with the same standard of care;
• timely security response and a person accountable for the decision;
• model, provider and operating-system changes followed as they happen;
• documentation that matches the product people actually install;
• issue triage, contributor review and a coherent product direction;
• enough organisational memory that one exhausted maintainer is not the entire continuity plan.

If Miton earns more than it costs to sustain, good. Surplus buys time, resilience and the ability to hire people who are excellent at work the market routinely expects volunteers to donate. But the purpose of the price is durability. It lets customers pay for a maintained creation engine while keeping their model relationship and model bill independent.

Open where trust requires it; commercial where continuity requires it

There is no morally perfect boundary that can be discovered from a licence selector. Too closed and users cannot verify the safety claims of a tool allowed near their files. Too open without a funding model and the project may quietly depend on a few people spending their evenings keeping everybody else’s infrastructure alive.

Miton’s current repository is AGPLv3. The development build contains the implemented beta surfaces, but public access is not open yet. The beta will be delivered as a signed desktop download with automatic updates. The exact v1 commercial boundary remains qualified until its licence and release gates are complete. The principle guiding that boundary is already clear: the parts people must inspect, trust and improve should remain meaningfully open; the paid product should finance the continuous integration, polish, support and ownership that turn source code into dependable software.

That means accepting some tension. People should be able to understand how Miton handles their work and contribute to it. A commercial competitor should not be able to take the team’s labour, remove the obligation to contribute back and sell the result as a closed service. Customers should not have to wonder whether the maintainer answering a security report can afford to keep doing so.

I would rather state that tension plainly than pretend “open source” dissolves it.

Miton is meant to last. A modest licence is how we give the people responsible for that promise a fair chance to keep it.