How Should Open Source Development Be Subsidized? (techcrunch.com)

"Open source maintainers are exhausted and rarely paid," writes TechCrunch's editorial manager. "A new generation wants to change the economics."

An anonymous reader quotes their report: [Patreon] is increasingly being used by notable open source contributors as a way to connect with fans and sustain their work... For those who hit it big, the revenues can be outsized. Evan You, who created the popular JavaScript frontend library Vue.js, has reached $15,206 in monthly earnings ($182,472 a year) from 231 patrons... While Patreon is one direct approach for generating revenues from users, another one is to offer dual licenses, one free and one commercial... Companies care about proper licensing, and that becomes the leverage to gain revenue while still maintaining the openness and spirit of open source software...

Tidelift is designed to offer assurances "around areas like security, licensing, and maintenance of software," CEO Donald Fischer explained... In addition, Tidelift handles the mundane tasks of setting up open source for commercialization such as handling licensing issues... Open Collective wants to open source the monetization of open source itself. Open Collective is a non-profit platform that provides tools to "collectives" to receive money while also offering mechanisms to allow the members of those collectives to spend their money in a democratic and transparent way.
TechCrunch warns that "It's not just that people are free riding, it's often that they don't even realize it. Software engineers can easily forget just how much craftsmanship has gone into the open source code that powers the most basic of applications...

"If you work at a for-profit company, take the lead in finding a way to support the code that allows you to do your job so efficiently. The decentralization and volunteer spirit of the open source community needs exactly the same kind of decentralized spirit in every financial contributor. Sustainability is each of our jobs, every day."

Comments

Free is free.

[AHuxley]

You doing that after work. On weekends. For the community.
Work in your free time so the programs you support do one thing and do it well.
Dont have a lot of free time? Consider the work and support needed for the next systemd.... before starting a project.

Re:Free is free.

[lkcl]

You doing that after work. On weekends. For the community.

Work in your free time so the programs you support do one thing and do it well.

*NO*. this is extremely dangerous advice, for certain classes / types of projects: those with extreme complexity. you're no doubt familiar with the adages and articles that have made the rounds here on slashdot: the ones about attention span (how it takes 20 minutes to recover from interruptions), about information retention (the "7 things in your head" myth), and so on.

an article that *hasn't* made its way onto here in the 15+ years i've been on slashdot is the difference between, and purpose of, electrical and chemical neuron memory. electrical is the short-term "immediate" memory. it's what you lose if you get hit on the head. chemical memory is long-term retrieval and it's much more difficult to access ("it's on the tip of my tongue", "just sleep on it", "author syndrome" and so on).

what happens is that things that you can't recall and those things you're not recalling regularly are swapped over during sleep. it's why you can remember things if you're working on them regularly, and why if you're struggling to remember something you can do so the next day (it's also why not getting decent sleep before exams is not a good idea).

you should by now have the basics of why i'm posting this, but it's worth explicitly writing: certain kinds of complex tasks, which require *significant* information retrieval and cross-referencing, as well as creativity *and* engineering, are just far too much for any human being on the planet to achieve without ***FULL TIME*** focus.

reverse-engineering is one such task. it literally took me six to eight weeks in some cases to find a single bit amongst hundreds of packet replays, that one bit being responsible for whether it was possible to proceed to the next packet or not. that was six to eight weeks FULL TIME at 12 to 14 hours a day.

and that resulted in me going into serious, serious debt... which i'm still paying back, over 12 years later! why? well... was any fucking fucking fucker paying me to do that work? was anyone fucking well giving me money to do that work? no they fucking well weren't. and when that work was released under GPLv2+ licenses, what did people do? they went "oo thank you very much, i'll have that, it saves my business an absolute fortune"... completely failing to reward or compensate me for that work. some other free software projects actually even blatantly copied my work (used it as a template) and failed to give credit so it's not even *known* that i did that work.

several people in high-profile projects - myself included - have not been properly compensated for our work, and gone into serious, serious debt as a result. the gentoo developer who ended up with USD $40,000 of credit-card debt and had to get a job with *microsoft* of all companies. the GPG developer who ended up with USD $10,000 of debt despite the fact the GPG is one of *the* most widely-used security programs around!

the only reason why certain critical software projects (openssl for example) actually started to get funded a few years back was because of shellshock, heartbleed and other serious vulnerabilities. companies started to realise that they were making an absolute fortune but were spongeing off of peoples' expertise and not properly paying them to be able to do the work to fix even basic security vulnerabilities.

so no. it is NOT the case that everything can be broken down into the unix maxim "do one thing and do it well". certain classes of engineering projects simply do not succeed until they have reached a particularly high level of internal complexity (DCOM is one extremely good example, i won't go into details like i have in the past).

to imply that *all* free software projects can be broken down into small tasks that can be done "in people's spare time" is to completely misunderstand software engineering and to do free software