Earlier quoted context omitted.
Could you elaborate?
Ffmpeg’s code is owned by hundreds of people, you’d have to get them all to agree to relicense.
So it is possible just hard.
Professional maintainers: a wake-up call
381–390 of 464 posts
Re: Professional maintainers: a wake-up call
#382I maintain a lot of open source projects, but IMO this is not the right approach. I think the [anecdote from @jbk]( https://news.ycombinator.com/item?id=29524103 ) about ffmpeg illustrates that. I also don't think the problem it solves gives the greatest benefit for the amount of work required. I think making it easier for companies to pay open source contributors is the right approach. For any company that builds so…
> I think making it easier for companies to pay open source contributors is the right approach.
Making it easier and making it a common habit. Companies need to realize, that paying maintainers/contributors pays off for them.
> I would love to see a tool that, given a pool of money, will collect dependencies from projects in any language (extensible), find the authors (git commit history, etc.), find where they accept contributions (extensible), and pay them, based on both computed and hand crafted weights.
Looking at https://flossbank.com/, this seems like just what you describe. I don't know how it works exactly, though.
Re: Professional maintainers: a wake-up call
#383Earlier quoted context omitted.
Why not change the license to a revenue share agreement with a cap on total amount of revenue? For example, if a company uses ffmpeg on their products and product generates a yearly revenue of 1m then they will pay you 1k. Current open source agreements do nothing to help smaller companies or the maintainers and honestly I find it stupid and destructive. Charge larger companies more depending on their revenue and let…
I really don't understand this mentality. This is what we've all been fighting for since the 90s. A free (as in beer) and open stack of software that anyone can pull off the shelf and use. So many commercial platforms rely not just on ffmpeg and vlc but also on nginx, php, python, nodejs, linux, mariadb, and everything else you can imagine. We also pay for some very niche things that are simply not available from the…
If my company was liable to have to pay out for each one of these projects we would be bled dry and our business would no longer be profitable.
To put that another way, your profit is derived entirely from arbitraging the value of open source software for your customers. If you were actually paying what the software is worth to you there'd be no money left. Effectively, you are taking some of the value of the work done by open source developers and keeping it for yourself rather than passing it on (that's not a criticism btw, it's how practically every "supplying goods" type business works.)
That's very unfortunate. You're not really creating much value, so I imagine your business is too small for anyone to worry about. In the case of something like YouTube that clearly that isn't the case though; they create far more value from the open source software they use. YouTube absolutely could afford to pay a fair fee for what they use. If nothing else, it protects YouTube from a problem like the log4j issue this conversation has arisen from.
Re: Professional maintainers: a wake-up call
#384Re: Professional maintainers: a wake-up call
#385Earlier quoted context omitted.
No, the companies are supposed to generate value for shareholders. They are supposed to have infinite financial growth and that is pretty much it.
That's how it is most of the time but I don't see how you can say it's "supposed to" be that way. It's pathological. Essentially it's a form of group sociopathy.
Most farms are also commercial and most of them still feed their cows and paint their barns even though in the very short abd short term it doesn't matter.
Edit: Same goes for basic politeness or being customer friendly. Can be very good for the stock price long term even if it doesn't matter in this quarters result.
Re: Professional maintainers: a wake-up call
#386Earlier quoted context omitted.
I really don't understand this mentality. This is what we've all been fighting for since the 90s. A free (as in beer) and open stack of software that anyone can pull off the shelf and use. So many commercial platforms rely not just on ffmpeg and vlc but also on nginx, php, python, nodejs, linux, mariadb, and everything else you can imagine. We also pay for some very niche things that are simply not available from the…
If my company was liable to have to pay out for each one of these projects we would be bled dry and our business would no longer be profitable. To put that another way, your profit is derived entirely from arbitraging the value of open source software for your customers. If you were actually paying what the software is worth to you there'd be no money left. Effectively, you are taking some of the value of the work do…
It's not even shared infrastructure like roads, since software is durable and the cost of use (and copy) is zero. Free and open source software is like science and technology. Like the modern wheel, candle, and cooking.
Plus some folks are tweaking and fine tuning it from time to time to be compatible with road 5.2 and with axle 3.1 and so on.
GitLab uses a delayed release (open core). Paying customers get the features first and months/years later they get into the free tier.
Re: Professional maintainers: a wake-up call
#387Earlier quoted context omitted.
I really don't understand this mentality. This is what we've all been fighting for since the 90s. A free (as in beer) and open stack of software that anyone can pull off the shelf and use. So many commercial platforms rely not just on ffmpeg and vlc but also on nginx, php, python, nodejs, linux, mariadb, and everything else you can imagine. We also pay for some very niche things that are simply not available from the…
If my company was liable to have to pay out for each one of these projects we would be bled dry and our business would no longer be profitable. To put that another way, your profit is derived entirely from arbitraging the value of open source software for your customers. If you were actually paying what the software is worth to you there'd be no money left. Effectively, you are taking some of the value of the work do…
The math probably doesn't check out. Paying 0.1% (1e-3) revenue for a core business dependency is a no-brainer (if you have reasonable margins). When you go from dozen to hundreds, you will not only bleed dry, you will be paying more than a fair share of what is needed to sustain/develop the dependencies.
When your software is used by billions (1e9), a adequate/fair share may be around 0.00001% (1e-7) with huge variability, but try paying 2c for your favorite logging library, 3c for gcc, 1c for task manager, 0.1c for a tool you never heard of ...
Re: Professional maintainers: a wake-up call
#388I maintain a lot of open source projects, but IMO this is not the right approach. I think the [anecdote from @jbk]( https://news.ycombinator.com/item?id=29524103 ) about ffmpeg illustrates that. I also don't think the problem it solves gives the greatest benefit for the amount of work required. I think making it easier for companies to pay open source contributors is the right approach. For any company that builds so…
> I think making it easier for companies to pay open source contributors is the right approach. Making it easier and making it a common habit. Companies need to realize, that paying maintainers/contributors pays off for them. > I would love to see a tool that, given a pool of money, will collect dependencies from projects in any language (extensible), find the authors (git commit history, etc.), find where they accep…
> Making it easier and making it a common habit. Companies need to realize, that paying maintainers/contributors pays off for them.
Definitely agreed.
> Looking at https://flossbank.com/, this seems like just what you describe. I don't know how it works exactly, though.
That looks ... related, but I _detest_ that it relies on injecting ads into package managers. It's also not extensible.
I think an open source tool would be preferable so that incentives don't get skewed by for-profit motives.
I would also prefer if the payments didn't go through a single company. Paying developers through GitHub Sponsors, Patreon, Flattr, or whatever their preferred mechanism is.
Re: Professional maintainers: a wake-up call
#389> Now is the perfect time for Open Source maintainers to become legible to the big companies that depend on them—and that want to get more out of them—and send them five-to-six figure invoices. Well, this is exactly what I've been doing around VideoLAN (VLC, x264) and FFmpeg for the last few years. In order to do that, I've created 2 official companies Videolabs and FFlabs (besides the non-profit orgs) and I've gone…
Change the license. Make it so that large companies have to pay, and small companies can still use it for free.
Re: Professional maintainers: a wake-up call
#390Earlier quoted context omitted.
> and I've gone through all the hoops to get paid (PO, billing, invoices, registering to large companies is a lot of paperwork, tbh, but well..) and we try and bill small to large companies that depends on those projects. I see an opportunity to create a "create-a-company"-as-a-service, to help tons of other maintainers to do this with ease.
Why not just have an intermediate company that handles the donation/support aspects? I mean, we already have Open Collective: https://opencollective.com/ and for other content creators the likes of Patreon also work out nicely. Two examples, off the top of my head: 1) Here's how Open Collective looks, for jMonkeyEngine (a lovely Java game engine that's also a bit underfunded and underutilized): https://opencollective…
Well not using Patreon or Open Collective is exactly what article also talks about.