Open source is a transformative model for building software. However, there are a few important problems with it, including but not limited to:

1. "Libre" has become synonymous with "no recurring license", meaning it's hard for vendors to make money from open source software in a scalable way.
2. As a result, "Open source businesses" are few and far between, except for development shops that provide services on top of platforms that other people have built for free, and service businesses like Red Hat. (Red Hat is the only sizeable open source business.)
3. Even if the cost to the end user is zero, the total cost to produce and support the software does not go down.
4. There is a diversity problem in open source, because only a few kinds of people can afford to give their time for free, meaning that open source software misses out on a lot of potential contributions from talented people.

I believe that the core product produced by a business can never be open source. In Red Hat's case, it's services. In Automattic's case, it's the Akismet and the WordPress.com ecosystem (WordPress itself is run by a non-profit entity). In Mozilla's case, it's arguably advertising. Even GitHub, which has enabled so much of today's open source ecosystem, itself depends on a closed-source platform. After all, they need to make money.

Nonetheless, having an open codebase is beneficial:

1. It gives the userbase a much greater say in the direction of the software.
2. It allows the software to be audited for security purposes.
3. It allows the software to be adapted for environments and contexts that the original designers and architects did not consider.

So how can we retain the benefits of being open while allowing for scalable businesses?

One option I've been thinking about combines the mechanics of crowdfunding platforms like Patreon with an open source dynamic. I call it market source:

1. End users pay a license fee to use the software. This could be as low as $1, depending on the kind of software, and the dynamics of its audience. (For example, $1 is totally fair for a mobile app; an enterprise intranet platform might be significantly higher.)
2. In return, users receive a higher level of support than they would from a free open source project, perhaps including a well-defined SLA where appropriate.
3. Users also get access to the source code, as with any open source codebase. Participants are encouraged to file issues and pull requests.
4. Accepted pull requests are rewarded with a share of the pool of license money. Rather than rewarding by volume of code committed - after all, some of the best commits remove code - this is decided by the project maintainers on a simple scale. Less-vital commits are rewarded with a smaller share of the pool than more important commits.
5. Optionally: users can additionally place bounties on individual issues, such that any user with an accepted pull request that solves the issue also receives the bounty.
6. The pool is divided up at the end of every month and automatically credited to each contributor's account.

For the first time, committers are guaranteed to be compensated for the unsolicited work they do on an open source project. Perhaps more importantly, funding is baked into the ecosystem: it becomes much easier for a project to bootstrap based on revenue, because it is understood by all stakeholders that money is a component.

The effect is that an open source project using this mechanism is a lot like a co-operative. Anyone can contribute, as long as they adhere to certain rules, and they will also receive a share of the work they have contributed to.

These dynamics are not appropriate for every open source project. However, they create new incentives to participate in open source projects, and - were they to be successful - would create a way for new businesses to make more secure, open software without committing to giving away the value in their core product.