After banning adverts in command-line terminals, NPM floats idea of Patreon-style donations to open-source devs NPM, Inc., the overseer of the widely used npm JavaScript package registry, hasn't been particularly supportive of worker complaints, but the would-be enterprise biz wants to lend a hand to open source contributors. Following a software developer's recent experiment with ads delivered to the command line via npm-hosted …
I’m not sure I see the problem. If people want to contribute to free software they shouldn’t expect to be paid. Open source has taught us over and over that nobody is indispensable, if you don’t want to contribute for free then feel free to not contribute at all. If you’re truly indispensable someone will pay you to write the code commercially. Chances are someone else will step up though. I guess it’s nice to be able to reward someone, but that’s entirely possible already just by knowing their email address
Well, I see a problem. In fact, I remember an article on this five years ago.
https://mashable.com/2014/04/14/heartbleed-open-source/
Which was basically pointing out that heartbleed happened precisely because OpenSSL was being used by god alone knows how many millions of companies underpinning probably trillions of cash flowing around (it's embedded in the firewall we bought that runs our VPN's for instance) and yet none of the end user companies using it are paying for it and even when the end user companies are paying support on their firewalls then the companies your paying to aren't then paying anything for the open source projects their software is close to being a GUI for.
End result; OpenSSL had one full time staff member working on it at the point the whole Heartbleed saga kicked off.
Is that legal? Yes. Is it sustainable? Obviously not.
What's the solution? No idea. But this way of funding crucial projects is obviously not sustainable over the long term.
And that bug was fixed. Without payment to developers. Your example doesn't change in any scenario - if the code was internal, the bug would have existed and been fixed. If the FW companies were contributing the bug would have existed and been fixed. If they had been paying the FOSS devs the bug would have existed and been fixed. As it was they didn't contribute, the bug existed and was fixed.
Money doesn't change this story at all so the OP point stands. The whole point of FOSS is that the code is available so when a bug is found and a fix is needed then anyone and everyone can contribute and get it sorted. Sometimes people are motivated enough to hire devs to get it fixed quickly, but that's on them.
These two replies pretty much sum up the argument on both sides.
My take: the problem is the definition of 'free' - GNU FSF defined it as 'freedom' like the 'free press' - you still need to pay for your copy of the New York Times even though it's the 'free press' and that 'free' software (or 'free press') is more valuable that non-free software (or the non-free press). You can pay via ad-supported online access to 5 articles a month, or pay via a subscription, or pick it up for free in the airport lounge because the airline paid for it with a small part of your airfare, but paying is required at some point by someone because otherwise you will only end up with non-free press.
I'm happy to write this software 'for free' for other people who are hobbyists/students doing stuff 'for free' too - but once you start to use my software primarily for commercial gain, then yes, I expect to be given a small reward for that, or a slightly larger small reward if I also agree to improve/maintain it for you. Why? Because it's fair certainly, but more importantly, because this is a very economically efficient way of finding valuable work - the economy doesn't bear the cost of all the software written that people don't find useful, it only bears the cost of the useful software.
If we don't pay - the result will be only non-free software.
Frankly with things like firewalls that we end up spending a couple of thousand a year on for support I think that the manufacturers of the device could easily afford to give the openssl and other projects they are using £1 per device per month. Multiplied by a few thousand users it'd pay for ample support for important projects while still being a total steal in terms of value.
But then it wouldn't be FOSS, it would be paid for software with all the crap and politics that comes with. The whole point of FOSS is that nobody has more influence just because they pay more. They are free to pay their own devs to add code, and the community is free to reject those changes, forcing a company to fork the project. If the "community" was actually a business they wouldn't make those same choices.
You've completely misread my post. Part of the freedom of open source is that it doesn't get pushed in unpleasant directions just because someone is paying. Under the current system, everyone is free to hire and pay developers to implement features or fix bugs. Under a system where you pay directly to the project, the project then becomes a commercial software house and will protect their position to protect that income. That's about as far from OSS ideals as you can get without closing the source, and I've seen a LOT of instances where the paid code doesn't end up in the open repo but in a separate paid for closed source extension to the open repo.
There's more to free than money, and in the last few decades I've seen this play out a lot of times. The best and only solution is free, free and free in all senses of the word. Businesses can easily contribute by paying their own staff to contribute or hiring developers to contribute. Those developers might just be the ones working on the project, in which case that's a win-win.
"There's more to free than money, and in the last few decades I've seen this play out a lot of times. The best and only solution is free, free and free in all senses of the word."
No.
MY firsthand experience tells me it's simply against human nature. 90% of the time, it's Someone Else's Problem. The only way to make people care is to remove any degrees of separation: get their skin in the game (IOW, defeat the SEP field by making it THEIR problem). If nothing gets done, then someone gets desperate enough that their skin gets hurt less getting it done than letting it lie.
And for a business, the bottom line is about the only way to get their skin in the game (as anything else can be lawyered away).
Their skin in the game is their reputation and thier business. They don't need to be paying for something to feel the hurt of an issue. At that point, yes, they can, should, and usually do pony up directly for some contractors to fix the issues in the open source product. If they wanted to pay developers all the time, they'd do it in house and wouldn't share the code, and that certainly is human nature.
"NPM taught everyone that you can use a package manager to download and install software for free, so why would you pay for it?""
NPM was first released in 2010, apt was released in 1998, dpkg in 1994 (and I'm sure there was other package managers before that), so this bloke must have been a long way from any linux system to miss that.
Mind you, from what I've heard about npm (not used it myself), it's mainly used by people who aren't or shouldn't be allowed root access, so perhaps he'd never had access to apt/yum/etc before?
Dear Sir,
I am a CTO in one of my roles, a paid-for-developer in another of my roles and an OSS developer in yet another one of my roles.
it makes sense to use open source software from a business and developer's perspective, for many reasons.
However, as suggested already above, a company that gains from using OSS should also actively seek out the foundations / people behind the OSS and be prepared to pay these a royalty fee. What is the amount of royalties that you should be prepared to pay? Under the assumption that you have a Research & Design budget, you should aim to spend at least 10% of that on OSS. If there isn't an R&D budget, you should aim to spend at least 10% of your "vertical" (CTO, CIO, CFO, etc...) budget on OSS. (Why 10%? Simply because a charitable gift of 10% is accepted as a treshold in many religious contexts ;-) Not that I'm religious, mind! It's also a nice round number: dividable by 2 and 5. where 10b represents 2 (as in 2 people / organizations that profit from the charitable donation)...)
This would be for OSS that you use directly. E.g. Linux Foundation if you develop on Linux machines, OpenSSL if use encryption in your software. If you have an AWS server that runs Linux, Amazon should be paying the Linux Foundation of royalty fee, not you.
The royalty fee can be given in a number of ways: Money, hiring an OSS person and pay their wages, taking over the cost of infrastructure for an OSS, etc etc.
How to divide the royalty budget? Depends on how much you actively use each OSS, really... Yes, this requires some investigation at first, but the pay off is that the software you rely on will have a chance to be maintained in the future.
Now, honestly, I don't particularly care about how much / if at all OSS contributors are paid, however the open source software that is written as a whole should be funded.
It worked the same way in the music industry for years (before copyright kicked in): anybody could record songs from any songwriter or other artist. But you had to pay royalties to them, because it was their original art. Much like it kind of still works with books... You pay the publisher who pays the author.
Best regards,
Guus
Victims of own sucess, i do see a lot of the calls to donate to web based (especially front end stuff) libs to be a bit of wishful thinking, as there is at least 20 competeing libs for the same front end behaviour, and if what your adding to the eco system is not complex enough to require support or unique enough to offer a pro version then tough, as any of the big frameworks already have corporate backing.
To my mind we have a lot of devs who by luck author a popular widget, who mistake there popularity for a USP and dont get that its because its free, not because its better, or follows some philosophy. Sure it would be lovely if you have an install base of 1000000+ users and you got compensated each month, but even if you did you would be very lucky to get more than 0.1% contributing, and if you force it to payed for then someone will fork it, and people jump ship, so you kill your userbase in exchange for revenue.
Bottom line OSS development is like gambling, only bet what you can afford to loose, if all your time is taken maintaining something for free and you dont like that its time to step away and let the community take the reigns, if as a maintainer you dont accept contributions i would suggest that you dont understand opensource and have mistaken open for published source, most projects die as they are suffcient alternatives to fill the vaccum, and those that are truly useful get forked or adopted, open source darwinism in action and that in my book is a very good thing
Perhaps it would be best if platforms that offered tiny unmanaged open source libraries, especially the size of the Javascript libraries on NPM ceased to exist.
An application made out of these many tiny modules all written by different people, updated on different schedules, with the authors rarely having financial incentive to maintain their code, coordinate releases, or support "customers" makes for a very fragile application. The conflicts that show up due to interdependencies and conflicting dependency graphs between libraries can be extremely costly and can actually stop your upgrade path. We have a mono repository that is locked at node.js version 10.11.0 because a library we are using does not work on newer versions and to upgrade that library would require changing some other libraries and reworking some applications that have zero business case to touch. And this argument completely ignores the elephant in the room of the security concerns of software from hundreds of developers all running scripts on your system with no entity you chose to enter into a contract with being responsible for what all of those installation scripts and runtime code are doing to your computer.
And the existence of all of these "free" libraries gives the false impression of inexpensive software that will "start cheaply" but the initial savings of any project that actually lasts will likely end in significant technical debt and cost compared to having vendors that support their software and releases.
Contrast that to a possible model where an organization, such as NPM, had a subscription model for consumers and took responsibility for the packages from them and the release coordination so that even if independent freelance developers were creating the modules for NPM, NPM would ensure that the current release of packages (or a set of packages) work together, the security of the packages, and the maintenance of the package if the freelance developer lost interest due to a lack of compensation. I.e. like you can use Microsoft libraries in steady reliable releases where things rarely break and are trustworthy.
Is it the case that these "free" alternatives that hide the long term costs of using these libraries stops the business case for an organization setting up a subscription model, ensuring the quality of the software, and compensating those who contribute and agree to maintain their work?
Obviously none of my arguments apply to non library open source code or open source code that runs in its own process.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
