We just finished recording a new episode of the Sustain podcast. A question that came up was:
for companies that profit off of open source software, how much should they giveaway/donate to the dependencies they rely on?
cc @RichardLitt
We just finished recording a new episode of the Sustain podcast. A question that came up was:
for companies that profit off of open source software, how much should they giveaway/donate to the dependencies they rely on?
cc @RichardLitt
One full time developer salary would be a good start.
Later, when an open source project bucket fills from multiple companies, the overflow capacity could be poured to other upstream projects, or redirected. This requires Open Source folks to set some upper limit on their requirements. The Cost of Living is a good approach to estimation of such minimal viable requirements.
Growing capacity by fundraising and trying to bring own costs down will help get more people covered to maintain masterful pieces of code that wonāt survive outside heads of maintainers otherwise.
Another approach is to calculate the current expenses of your dependencies and decide the percentage you would be willing to cover (1%, 10%, ā¦).
Here is the issue to expose the API to make this possible for projects registered on Open Collective.
Thank you for the great feedback @abitrolly
Thanks for bringing this question up. There is a big difference between what companies should give donate and the amount that they actually donate .
Itās naive for open source maintainers to assume that companies will suddenly start paying for a resource that they have been extracting from for free. Of course, there are companies like Microsoft and Google that give financial resources to select projects, but I donāt think thatās something that open source developers should expect.
Itās better for open source developers to proactively create a monetization road map once companies start depending on their projects. The monetization roadmap can be daunting, especially for projects that begin as hobbies.
The main reason why Eric and I started the Sustain Our Docs podcast is because we both wanted to explore sustainable monetization models for open source projects.
Whatever the amount, the most important factor is transparency: it should be easy to figure where the money comes from and what it was used for. It is otherwise close to impossible to figure out how much money will make a difference for a given Free Software project.
My 2cts.
In many cases it might be better to fund their staff helping with the project than contributing cash. Fix bugs, close issues, add codeowners, improve docsā¦ it takes a lot of work to turn cash into engineering time, and a company is already doing that
Perhaps free software foundations and projects could learn a lot from other foundations: what works is to advertize precisely what you need the money for.
2 cts.
I love that podcast!
There was a tweet years ago that laid out like six or eight different scenarios for monetizing open source, and for each one it pointed out what you had to do in addition to programming to make it work. Wish I could find it again, I thought it was a great model of the possible maps.
Not sure of the tweet but we put together a list of 30+ revenue streams for open source projects, mostly applications in the international development space. You are right, they require activities beyond code. Further, they require organizational structures that can legally enter into contracts and accept funds. Foundations can provide some, but not all, of these requirements. Start on page 26:
Whoa, great resource!
Nadia Eghbal, the author of āWorking in Public,ā created a comprehensive list of the different ways open source maintainers can financially sustain their projects. GitHub - nayafia/lemonade-stand: A handy guide to financial support for open source
Thank you for putting it together Justin!
Without you, the podcast wouldnāt exist.
Nice! Another great resource!
Bringing it back around to the topic ā¦ do you work at a company that uses open source software? How much do you think your company should give to the community?
I work at a charitable foundation (also a limited liability company, based in Aotearoa New Zealand) with terms of reference that state āuse and build Free and Open Source Software unless there is nothing available for a specific taskā. We all work remotely, and havenāt found any requirements we canāt fill with FOSSā¦ so thatās all we use.
We participate on a ad hoc basis in many of the FOSS communities whose software we use, and we develop quite a lot of software, all of it FOSS licensed (leaning strongly towards Copyleft). We sometimes use hosted versions of FOSS applications (like Kanboard and Mautic) to help sustain them, but we also contribute to projects in kind, by submitting bug reports and fixes, writing documentation, and promoting their work (e.g. on our own Mastodon, used by our global learner and educator community).
I think the best thing we can do to āgive backā to FOSSā¦ is to use it. And we can make life harder for those building proprietary software (by not using their wares), as theyāre the real problem.
Seems to me, the right way to make FOSS (not mere OSS) sustainable is to demand that governments acknowledge the degree to which much FOSS is critical digital infrastructure and needs to be funded the same way as critical physical infrastructure. Depending on corporate support is losing proposition. It puts power in precisely the wrong hands, that of corporations. Embracing them is an own-goal.
Appreciating Nadiaās project on the different ways open source maintainers can financially sustain their projects, I created a version that was aimed at research projects that were looking to sustain themselves - a research-project-centric view, rather than a maintainer-centric view: GitHub - danielskatz/sustaining-research-projects: sustainability models for research software projects. But otherwise, very similarā¦ I had hoped more differences would develop over time.
This is a question that @DuaneOBrien cares about too.
There are ways to quantify the:
value a project brings in an
For the record: