3) try a pay tunnel approach, in which pre-built binaries of your GPL'ed source code are available for a name-your-price amount. Source code remains freely available at no cost at all times. (thanks to Radiohead's In Rainbows release for the inspiration)
4) try a modestly priced subscription approach. Try to be 100% clear that this is not a licensing system, but rather enables you (and others) to keep developing the software. [ EDIT: essentially, Patreon but hopefully without another 3rd party middleman. ]
Works for us at ardour.org (on the order of $200k this year, through a combination of donations, 3 and 4 above).
I can say, I have no problems building ardour and have many times before, but the last few updates I've decided to forgo that and just buy the prebuilt binaries. Ardour's given me a lot of value over the years when other options were out of reach and now that I can, having the option to pay a reasonable price or what I can or am willing or able to pay for it is an easy choice to make.
There's a lot of FOSS software i've used over the years that have helped me in times when I could never afford proprietary alternatives and as i've gotten older and made more money i've tried to go back and donate or buy prebuilt binaries of that software when I can.
Honestly, the existence of such software has helped me so many times in life when I would have either had to fork out unreasonable amounts of money or pirate things.
I wish open source maintainers and devs got more credit for the work they do. I bet it would be hard to figure out just how many lives have been enriched and bettered by their work.
> Patreon but hopefully without another 3rd party middleman
https://liberapay.com/ is a great 3rd party middleman / alternative to Patreon that doesn’t take a cut of payments (so arguably the best of all worlds).
They state that they use Stripe and PayPal as payment processors. Not clear to me why someone would want to use an additional layer, although it is nice that they take an additional cut of payments on top of the processor.
Those of us involved are not interested in such goals.
Also, we've received much more income than that. Ardour is more than 20 years old at this point, and generating revenue for more than 12 years.
Also, your estimation of how much a software engineer earns would be fairly humorous anywhere except a few major tech centers in a few western nations.
I, sort of, turned it around. We found something that needed doing, got financing for it and then decided to release it open source. It is not a big thing in the open source community, but it has helped a lot of people who don’t even use software. Among other things we have helped communities, NGOs and governments map rural water supply where this isn’t a sure thing to exist or be safe to drink, for more than 100 million people. Then this data is used to support investments at country or regional level to improve the situation.
The way I wish software development worked was that the norm was paying for the development itself, rather than for the resulting software. Meaning instead of paying for a license you either pay for the development of bug fixes and features you want, or bid towards a pool for them. I know bounty programs exist, but from what I understand they have not been terribly successful.
I've been personally thinking about such things recently and found Drew's article reassuring that not needing to think like a unicorn is OK. Having taken a step back from raising funding has been freeing. Witnessing what it can do to companies, I worried what it would do to my OSS ethos. Still, to make something people love takes effort and money can help a lot.
I've been interested in cuelang for a while but just haven't found a real use case for it. For validating incoming data, JSON Schemas tend to do the trick and are widely distributed, and for things like Kubernetes YAMLs I usually just edit the YAML itself. Keeps it simple. Any cool use cases I should check out?
I'm personally using Cue for representing DSLs for code generation.
Cue can be used to reduce the configuration size and boilerplate. You can 'cue import' your JSONSchema and remove repeat sections. Because Cue is assoc. / comm., the order you merge in does not matter.
'cue get go' enables you to import Go types into configuration automatically.
There work towards making Cue an language of translation for configuration / types. Something where you can get others from any of the supported (json, yaml, jsonschema, openapi, protobuf, golang)
The scripting layer just got an upgrade, to support "flow" based programming. Haven't looked at it myself yet, hoping to soon.
There are several projects in the DevOps world. A docker alum is up to something. Another group has Cue-ified CloudFormation: https://github.com/TangoGroup/cfn-cue I can see helm being replaced with a pure-Cue solution.
What I've run into as well is free software, where the source is available but the process of building it into something usable would take "months" of work, and the internal toolchain (old software versions, patched packages, etc) is only vaguely documented.
Effectively, it's a 'moat' around the business, and allows the business to get the best of both worlds: association with the open source community, and effectively proprietary software.
The actual business plan can then treat the software as an exclusive asset (not in a technical, legal, sense, but de facto for sure).
I'm not saying it's a bad model; it's probably one of the few that can provide a reliable income, and it gives outside developers a 'fighting chance' at accessing the value of the software.
Blender gets 135.000$/month through donations & sponsors
Godot hires 4 full time employees through donations
Krita got 4.200$ donation for this month (not sure about the other months)
Ardour seems to have 11.500$/month
etc.
I agree it is hard to reach a stable income through donations & sponsors but some open source project managed to do so, and I hope other will in the future.
There still room for many "Blender of XXX" (in the sense of a flagship FLOSS that is competitive with proprietary solutions).
I'd say Godot is well on the path of being the "Blender of Game Engines".
But there is still room for the Blender of Photo editing (Gimp is far behind Photoshop), the Blender of Vector/UX (inkscape is not on part with Figma/Illustrator), the Blender of Music (Ardour is nice but UX wise not as "modern" as Ableton or Bitwig), etc.
For someone who has some time + a strong commitment to pretty UX & clean architecture, I think there might be still my opportunities for donations & sponsors driven projects
How about a new type of licence. If you contribute to FOSS its copyleft, otherwise if you want to use it closed source its a copyright 10% revenue based commercial licence.
You don't need a new kind of license for this. You can dual-license a project as (A)GPL & commercial. Business-wise it's like a freemium model. The GPL option is friendly to FLOSS projects while avoiding being free-as-in-free-labor. Companies happily pay for a commercial license, because that's easier and safer for them than to think how GPL could work for them.
That's just a proprietary license with source code available, the same kind of thing that companies get mocked for "expecting free labor to help them make money" on HN.
That's not really FOSS, if I get it from someone else who did contribute to the project, which they can share with me under their FOSS license, then I just bypassed your commercial license legally.
You can catch that with a pass-on clause. The idea behind this is to stop commercially exploitation of your contribution to FOSS with intention to keep everything for themselves and keeping the FOSS philosophy for those who do care.
The problem with all of these kinds of FOSS-but-not-really is that, well, they're not really FOSS, only ostensibly so. Companies would have every right to use FOSS themselves, so it's not really the FOSS philosophy, it's something else. In that case, just make it source available or even proprietary, just don't call it open source.
side note: LGPL is not just suitable for open source projects, plenty use with commercial closed source too. But yes, that sounds like the dual-license model: if you don't like the terms of the open-source license, you can pay for other terms.
4) try a modestly priced subscription approach. Try to be 100% clear that this is not a licensing system, but rather enables you (and others) to keep developing the software. [ EDIT: essentially, Patreon but hopefully without another 3rd party middleman. ]
Works for us at ardour.org (on the order of $200k this year, through a combination of donations, 3 and 4 above).