Future of post-open-source? Considering a "source-visible, non-runnable" license
by EGreg | 2025-06-30 17:01:25+00:00
I've spent the last decade building Qbix, a platform for decentralized social apps, complete with internal economies (QBUX), multi-user apps, and a plugin architecture designed for security, scalability, and sovereign communities. I've also built open source web3 smart contracts. I've contributed more lines to open source than most people on earth.

For those who are curious:

https://github.com/Qbix https://github.com/Intercoin

But now that I'm working on training autonomous AI agents to deeply understand and improve my codebase 24/7, I'm rethinking the entire point of open source in 2025.

So at Qbix we are considering a new direction:

Source-readable, but not self-hostable. i.e. "look but don’t run" — unless you’re a licensed franchisee.

We package our software into QBOXes -- attested, tamper-evident environments with no SSH access, running in trusted clouds (e.g., AWS). The core is installed with nix or Amazon AMIs. Any third-party packages are all version-pinned, and installed only by installer scripts that the box downloads from various endpoints and verifies they've been approved by M of N auditors. The client software only connects to authorized QBOXes. Our clients can choose which auditors to trust.

Why? Security and reliability.

After multiple WordPress sites of ours got pwned — thanks to widely-used plugins — I started seeing the plugin ecosystem itself as a dangerous attack vector. Too much surface area, no containment.

QBOX flips the model: Each plugin can run in its own domain/iframe, like in Sandstorm, using postMessage and a Powerbox-like API. This even protects against speculative execution attacks like Meltdown and Spectre. No plugin can crash or compromise the host app.

We’re also eschewing commodity hosting, which historically introduced more variables and support costs than it was worth. You want to run a QBOX? Great -- license it. You don’t? No worries — the source is open to auditors, not repackagers.

This also avoids what happened with Matt Mullenweg and WordPress forks: open source competitors out-executing the core devs.

In short:

Open source still builds trust, but the AI is my team now.

Contributors can file issues, even in plain English. The agents will handle the rest, including communication with the submitters.

I don't really care as much about GitHub stars, I care about building a reliable platform that people who pass our course can get licensed to run their own QBOXes in cloud environments, for others to use. They're essentially going to be "dumb pipes" and redundant infrastructure, all over the world. And we're going to be building distributed systems far beyond "blockchain" on them, after we get enough critical mass.

Those who don't pass our course, the people who just run a community and want to use the software, will pay those who pass our course and get licensed to run and maintain QBOXes in the cloud (set it and forget it basically).

I am even considering making source code available only to auditors, who can form a Self-Regulatory Organization and add/remove auditors, authorizing their public keys. Then any software that winds up in a customer's QBOX does so because M of N auditors they trusted signed off on it. In this way, they can extend their security boundary from their client apps to our QBOXes running on the server, and they can handle keys, third party APIs (including sending emails with gmail, making payments, etc.)

What do you think? Has anyone else explored auditable, non-runnable open source as a middle ground? Is it sustainable? Dangerous? Would love to hear HN’s take.