Framing questions

[boris]

I thought of some framing questions for what I’m interested in running tests on.

Can maintainers get paid for long term maintenance & upgrades without building a business?

The without building a business basically means that the maintainers don’t need to figure out a business model, don’t need to setup a company, or related items.

That is, they get paid time from their supporters to “buy their own time” that they can allocate to maintenance and upgrades to the code.

They CAN also eg do freelance work or consulting even on the codebase — but at a base line they feel like they have enough paid time to work on the software.

Will individuals and businesses support maintainers directly in a recurring fashion?

This is movement building and alignment.

Can we set up a system where maintainers get paid over time? and the core expectation is “keep this software going”.

For movement building, this is also championing businesses of all kinds to fund their upstreams.

And individuals to support the software they want to use / see in the world.

Can the “bounty” model be evolved to use recurring funding over time instead?

We’ve been wanting this for projects Fission supports, and also are proposing it for grant funded projects that are bounty style.

That is — a bounty is some functionality and as soon as it is done the bounty is awarded. We are proposing that instead, this should be paid out over a minimum of a year to encourage maintenance, adoption, and usage, where delivered code keeps working.

Gating the community

Our working model is that code is permissively licensed. The code bits are non-rivalrous and there is zero cost to copy the bits, so it’s a public good.

But maintainer time is rivalrous — whether it’s responding to bug reports or feature requests, writing docs, and so on.

And actual maintenance over time, even without new feature additions.

Should community channels — eg an issue queue or feature roadmap — be gated to only supporters?

This would then also be a benefit of what supporters get in exchange for support: maintainer time on their discussions.

Growing maintainers & non code contributions

Might a maintainer grow support in such a way that more maintainers — and also non code contributions from docs to issue triage to even promotion — can be added to the project?

Should scope start with single maintainer projects? Are there any nuances with multiple maintainers being supported?

[chadkoh]

@boris

Can we set up a system where maintainers get paid over time?

I think this is a fascinating question. I also like your exploring on what parts of the whole process/value props could be gated

It reminded me about the seven revenue models:

• Production
• Markup
• Fee-for-service
• Commission
• Advertising
• Subscription
• Licensing

Open source has tried licensing and fee-for-service. I can’t think of examples, but there might be others.

Of course, those above are just for online services, and open source/public goods has other models. The OpenSource Collective identifies them as:

• Volunteers
• Devs in-house
• Open core
• Dual licensing
• Services & consulting
• Donations

I would also add:

• government funding (via taxation or gambling)
• grants
• bounties and “contests”

Other types of revenue models:

• arbitrage (like currency trading)
• selling behavioural data
• insurance

I am probably missing some others. Anyways, I feel like there is a matrix in here that could be drawn up, one where we might be able to find the hidden area where “revenue dragons” be. Unfortunately I am not sure what the axes should be.

The point is, having something of a democratic subscription/insurance model where you fund something for a year which gives you voice in how it turns out is an interesting twist. But it really puts the value prop on that voice when the real utility is access to the good, which is free. You would have to be very motivated to want your voice heard, but not so motivated that you just fork the project and hire your own team to make it the way you want it.

Another shower thought, but mission/movement funding, which is generally donation drives (thinking of things like Red Cross, MSF, etc)… they also have revenue volatility problems, and need to manage the money that comes in only when there is some sort of disaster — store it for later when it can be spent… I suppose OpenCollective could do that, but we cannot rely on Heartbleed-induced funding.

Here is a somewhat cynical question: are all the failures of opensource infra properly communicated in the media? I am not advocating the spreading of FUD, but I am wondering if there is an opportunity in closing the gap in understanding of the dependency problem? @jessmartin and @danversf have 4 strategies for increasing dev hours/maintenance efficiency. What if that depends on knowledge of the problem?

A dependency tree:

maintained software
↓
developer hours
↓
monetary support
↳ sense of responsibility/mission
↳ understanding of the problem
↳ appreciation for the work
↓
Communicating the problem

That is simplified but hopefully it gets the point across.

Okay, a lot of stuff in this comment… apologies for rambling. Tear it up!

[boris]

@chadkoh

Here is a somewhat cynical question: are all the failures of opensource infra properly communicated in the media? I am not advocating the spreading of FUD, but I am wondering if there is an opportunity in closing the gap in understanding of the dependency problem? @jessmartin and @danversf have 4 strategies for increasing dev hours/maintenance efficiency. What if that depends on knowledge of the problem?

Yes, sort of.

My main thinking: get maintainers paid … for the work they are already doing. Not extra work, or rather, the extra work is a) voice for the contributors and potentially b) actual access to scarce maintainer resources beyond code, as what you “get” plus c) good feelings that you are supporting your dependencies and they won’t go stale / go away.