| ▲ | cube00 3 days ago |
| > The tools we use to build software are not secure by default, and almost all of the time, the companies that provide them are not held to account for the security of their products. The companies? More like the unpaid open source community volunteers who the Fortune 500 leech off contributing nothing in return except demands for free support, fixes and more features. |
|
| ▲ | ants_everywhere 3 days ago | parent | next [-] |
| > More like the unpaid open source community volunteers who the Fortune 500 leech off contributing nothing in return except demands for free support, fixes and more features. People who work on permissively licensed software are donating their time to these Fortune 500 companies. It hardly seems fair to call the companies leeches for accepting these freely given donations. |
| |
| ▲ | 48terry 2 days ago | parent | next [-] | | > People who work on permissively licensed software are donating their time to these Fortune 500 companies. They can use the software as they like, that's what the license is for. I don't recall a license or contract where I have to care about their problems, however. If they depend on my software and it makes their product blow up in their faces and they're losing more money per minute than I'll ever make in my lifetime? Sucks to be them. I'll handle support or fixes when I very well feel like it, I'm off to play Silksong. They can, of course, fix this attitude problem of mine by paying me. | |
| ▲ | michaelmrose 2 days ago | parent | prev | next [-] | | No. People should be expected to be aware of the dynamics on which their fortunes depend. This is true of individuals and its certainly true of giant companies with thousands of employees. | |
| ▲ | JensRantil 3 days ago | parent | prev | next [-] | | It's not just time. A lot of devs simply don't have the experience of dogging into third party sourcing code or understanding how one contributed to open source. | | |
| ▲ | ants_everywhere 3 days ago | parent [-] | | By "a lot of devs" do you mean devs at these companies? If so I think this is a good point. It's easy to see from any one open source project's perspective how a little help would go a long way. But it's really hard to see from the perspective of a company with a massive code base how you could possibly contribute to the ten gajillion dependencies you use, even if you wanted to. People will say things like "Why doesn't Foo company contribute when they have the resources?" But from what I've seen, the engineers at Foo would often love to contribute, but no team has the headcount to do it. And acquiring the headcount would require making a case to management that contributing to that open source project is worth the cost of devoting a team to it. | | |
| ▲ | em-bee 2 days ago | parent | next [-] | | it's really hard to see from the perspective of a company with a massive code base how you could possibly contribute to the ten gajillion dependencies you use, even if you wanted to counterpoint: you don't need to actively contribute to all upstream projects, but you do need to be prepared to maintain, fix, or replace any dependency you have. if you can't do that, you should pay someone to do it. if you can't do that either then you should not be using the dependency in the first place. yes, it can happen that you underestimate the resources needed for that, or that a project you use looked very stable and supported, but suddenly you can't find anyone who has the knowledge to fix the issue you have, but then that's simply bad luck. it can happen with company backed projects too. you need to deal with that. have no sympathy if you can't. | |
| ▲ | trolleski 2 days ago | parent | prev [-] | | jUsT uSE AI, dUh? |
|
| |
| ▲ | 2 days ago | parent | prev [-] | | [deleted] |
|
|
| ▲ | tanepiper 3 days ago | parent | prev | next [-] |
| Author of the article here - holistically this isn't just about NPM dependencies, it's the entire stacks we work with. Cloud vendors provide security, but out of the box they don't provide secure platforms - a lot of this is left up to developers, without security experts - this is dangerous - I have 25 years of experience and I wouldn't want to touch the depths of RBAC. SaaS products don't enforce good security - I've seen some internally that don't have MFA or EntraID integration because they simply don't have those as features (mostly legacy systems these days, but they still exist). I'm also an open-source author (I have the most used bit.ly library on npm - and have had demands and requests too), and I'm the only person you can publicly see on our [company github](https://github.com/ikea) - there's reasons for this - but not every company is leeching, rather there is simply no other alternative. |
| |
| ▲ | ants_everywhere 3 days ago | parent | next [-] | | > Cloud vendors provide security, but out of the box they don't provide secure platforms - a lot of this is left up to developers, without security experts - A lot of the spread of Shai-Hulud is due to s having overly broad credentials on NPM, GitHub and elsewhere. It's not that NPM doesn't support scoped credentials, it's that developers don't want to deal with it so it's not the default. There's no reason why, for example, a developer needs a live credential to publish their package when they're just hacking on code. This is related to the `curl | bash` pattern. Projects like NPM want to make it easy to get started and hard to reach a failure case so they sacrifice well-known security practices during the growth phase. | | |
| ▲ | pixl97 3 days ago | parent [-] | | I mean quite often access based errors are very opaque, I mean it is for good reason, but when you're new to something it's one of those things that leads you to give up. You want to write code, not spend 3 hours figuring out why your token doesn't work. Security things will get hacked on later, but again it will cause all kinds of problems because the ecosystem wasn't built for it. | | |
| ▲ | ants_everywhere 3 days ago | parent [-] | | > quite often access based errors are very opaque Yes they are, and it's hard to design good scopes especially when the project is new. A better default might just be to have the write permission expire much more quickly than the read permission. E.g. the write token might be valid for an hour and the read token might be valid for 90 days. | | |
| ▲ | danudey 2 days ago | parent [-] | | Two things I really wish literally any company would ever do with their systems when you have a permissions-based token: 1. Show me all the permissions that that token has been granted but has never used 2. Show me all the permissions that that token has tried to use but does not have I would gladly accept the ability to turn on an audit mode for a given token, service account, etc., run the thing I'm trying to run, and then go look at the report to see what permissions I can remove - or, even better, have a giant "Create role from this profile" that lets me create a custom set of permissions based on all of the permissions I've used. Google Cloud does have a thing where it shows you all the service accounts you have with "overly broad permissions", but it seems to be just "here are all the SAs with 'owner' access" so far. It didn't catch the service account we had that just needed to publish one file to one bucket but had been made a Storage Administrator with full read/write/update/delete access to every form of storage in Google Cloud. |
|
|
| |
| ▲ | _heimdall 3 days ago | parent | prev | next [-] | | That's interesting. I take issue with companies that claim a level of security that doesn't match what they ship, but I never expect them to tell me how to do my job well. I expect a company to put their current product in as good of a light as they can. They're going to over promise what it can do and show me the easiest "Getting Started" steps as they can. Its up to me to dig deeper and understand what they actually do and what the right solution is for my project. | |
| ▲ | fergie 3 days ago | parent | prev [-] | | > a lot of this is left up to developers, without security experts - this is dangerous Although I see where you are coming from, dismissing unaudited libs as dangerous is slightly missing the point. In fact, the world is a safer place for their existence- the value lost by security exploits is insignificant compared to the value protected by the existence of the libs they exploit. Also, I suspect that you could replace "value" with "lives" in the previous sentence. |
|
|
| ▲ | giantg2 3 days ago | parent | prev | next [-] |
| I remember joining my company right out of college. In the interview we started talking about open source since I had some open source Android apps. I asked if the company contributed back to the projects it used. The answer was no, but that they were planning to. Over a decade later... they finally created a policy to allow commits to open source projects. It's been used maybe 3 times in it's first year or so. Nobody has the time and the management culture doesnt want to waste budget on it. |
| |
| ▲ | MrGilbert 3 days ago | parent | next [-] | | > Nobody has the time I'd erase that part entirely, as it is not true, from my point of view. My day, as has every other person's day, has exactly 24 hours. As an employee, part of that time is dedicated to my employer. In return, I receive financial compensation. It's up to them to decide how they want to spend the resources they acquired. So yes, each and every company could, in theory, contribute back to Open Source. But as there is no price tag attached to Open Source, there is also no incentive. In a highly capitalized world, where share holder value is more worth than anything else, there are only a few companies that do the right call and act responsible. | | |
| ▲ | watwut 3 days ago | parent | next [-] | | > In a highly capitalized world, where share holder value is more worth than anything else, there are only a few companies that do the right call and act responsible. It is not just that. In a well functioning theoretical free market, no one is going to have time either. The margins are supposed to end up being tight and the competition is supposed to weed out economic inefficiency. Voluntary pro-social behavior is a competitive disadvantage and an economic inefficiency. So, by design, the companies end up not "having time for that". You need a world that allows for inefficiency and rewards pro-social behavior. That is not the world where we are living in currently. | | |
| ▲ | Ajedi32 3 days ago | parent | next [-] | | Working an honest job is pro-social behavior, and it is rewarded. So is quitting your job to work on a side project that ends up being valuable enough for others to pay for. It's just that giving code away for free operates outside that reward structure. | | |
| ▲ | watwut 2 days ago | parent [-] | | First, in your breakdown, there is literally no space for unoaid volunteer work wich is topic of the thread. Second, working job is about earning money not about helping others. | | |
| ▲ | Ajedi32 2 days ago | parent [-] | | Regardless of why you do it, working an honest job does help others. Money is the reward you get for that behavior. My point is if you explicitly choose to work for free you're opting out of that reward structure. It seems odd to do that and then turn around and complain that "the world where we are living in" isn't rewarding you for your work. |
|
| |
| ▲ | FuriouslyAdrift 2 days ago | parent | prev [-] | | Basically... Japan |
| |
| ▲ | giantg2 3 days ago | parent | prev [-] | | If your finite time at work is filled with business work, then there is no time left to do the open-source work. Seems true to me from an IC and delivery perspective. Company staffing and resource allocation could create the time to do it, but they don't. |
| |
| ▲ | rkagerer 3 days ago | parent | prev | next [-] | | That's such a self-harmful policy. I have a small business and I've been really supportive to both open source and small, paid-for commercial libraries and building blocks that I rely on. Also advocated this successfully at clients I've consulted with. We do a lot of technical vetting before adopting any particular dependency (vs. building out our own) and it just makes sense that we strive to foster the continued existence and excellence of our tools. Considering the incredible value companies get from open source, I have trouble understanding why they wouldn't throw some cash or idle cycles their way. Seemed to work out for the likes of Google while they were undergoing rapid growth. | |
| ▲ | bonoboTP 3 days ago | parent | prev | next [-] | | That's fine. There's no requirement to "contribute back". Respect the license terms and don't go demanding anything unless you have a support contract and don't expect that you can get a support contract. It's fine to just use something as long as you also don't harass the maintainer as if they owed you something. | | |
| ▲ | cap11235 3 days ago | parent [-] | | The annoying part is that often without a corporate policy for contributing, you are doing the work anyway because you need XYZ from the software, just that it lives in a private fork that will never get upstreamed as a result of policy. |
| |
| ▲ | tedggh 3 days ago | parent | prev [-] | | Most developers don’t work for software companies. So when you are not shipping software as a product you and your department are usually a liability. This is important to understand because it helps you frame your approach to upper management as a developer or c-suite as a director of engineering when it comes to talk about budgets. In my experience, most non tech corporations will be ok with allocating budget for open source projects, they already do it in other types of non profit domains. But you need to make a case that goes beyond the ethical reasons or personal motivations. |
|
|
| ▲ | grafmax 3 days ago | parent | prev | next [-] |
| Technology is insecure all the way down to the hardware. The structural cause of this is that companies aren’t held liable for insecure products, which are cheaper to build. So companies’ profit motives contribute to this mess not just through the exploitation of open source labor (as you describe) but through externalizing security costs as well. |
| |
| ▲ | stingraycharles 3 days ago | parent [-] | | Isn’t all this stuff with Secure Enclave supposed to address these kind of things? It’s my take that over the past ~ decade a lot of these companies have been making things a lot better, Windows even requires secure boot these days as well. | | |
| ▲ | acdha 3 days ago | parent | next [-] | | They’re not the same problems. The Secure Enclave protects things like your biometrics, hardware-backed keys (e.g. on a Mac, WebAuthn and iCloud Keychain), and the integrity of the operating system but not every bit of code running as your account. That means that an NPM install can’t compromise your OS to the point that you can’t recover control, but it means the attacker can get everything you haven’t protected using sandbox features. That’s the path out of this mess: not just trying to catch it on NPM but moving sensitive data into OS-enforced sandboxes (e.g. Mac containers) so every process you start can’t just read a file and get keys, and using sandboxing features in package managers themselves to restrict when new installs can run code and what they can do (e.g. changing the granularity from “can read any file accessible to the user” to “can read a configuration file at this location and data files selected by the user”), and tracking capability changes (“the leftpad update says it needs ~/.aws in this update?”). We need to do that long-term but it’s a ton of work since it breaks the general model of how programs work we’ve used for most the last century. | | |
| ▲ | felixgallo 3 days ago | parent [-] | | it's not clear that the solution to this problem is to create several additional layers of barn doors. | | |
| ▲ | acdha 2 days ago | parent [-] | | That doesn’t make sense: it’s like arguing that it wasn’t useful to have boat design switch to compartmentalization in addition to trying to avoid hitting things. You can spend a lot of effort trying to ensure bad code never arrives but unless that’s perfect you also want to think about how to make it less catastrophic. | | |
| ▲ | felixgallo 2 days ago | parent [-] | | the proposed idea does not reduce the attack surface or make anything easier or less catastrophic. | | |
| ▲ | acdha a day ago | parent [-] | | You might want to reread more carefully. Using the OS security features to restrict what the code you just installed can do prevents immediate attacks and gives you a chance to notice suspicious activity. If the only way to read a file is for the package to request permission and a scope, that gives you a chance to notice it (huh, why does tiny-color need ~/.GitHub?) and also serves as a triage cue for scanning pipelines to flag updates, especially minor ones, which increase the scope of the requested permissions. Using OS features to restrict access to sensitive data similarly gives you another chance to detect a compromise because a denied operation to, say, read your wallet by an app which doesn’t need to is both highly visible and unambiguous. | | |
| ▲ | felixgallo a day ago | parent [-] | | I can read, thank you. The specific problems are that your 'prevent immediate attacks' and 'gives you a chance' are both doing significantly more work than you'd like to admit. A large project can use hundreds of npm packages, with the total dependency tree in the thousands. Your choices are to either give them infinite dialog fatigue on every single npm update, or make security-weakening tradeoffs. And if you ever let any of the packages create a new window and draw to it, that's game over. Even without malicious dialogs, users will continue to make bad choices, and 99.9% of all non-developer users and 99.8% of all developer users will accept or even broaden insecure defaults when prompted. The problem is coming from inside the house. |
|
|
|
|
| |
| ▲ | snickerdoodle14 3 days ago | parent | prev [-] | | Not really, those technologies are basically designed to be able to enforce DRM remotely. Secure Enclave = store the encryption keys to media in a place where you can't get them Secure Boot = first step towards remote attestation so they can remotely verify you haven't modified your system to bypass the above Advertising rules the world. | | |
| ▲ | brookst 3 days ago | parent [-] | | How is that different? Is there such a thing as secure hardware that can prevent supply chain attacks (by enabling higher layers to guarantee security) and secure hardware that prevents copying data (by enabling higher layers to guarantee security)? | | |
| ▲ | snickerdoodle14 3 days ago | parent [-] | | Sure. Malware tends not to have physical hands that can touch the machine and any buttons attached to it. Physical ownership should be true ownership, but they're taking that away from you. |
|
|
|
|
|
| ▲ | ricardobeat 3 days ago | parent | prev | next [-] |
| I find this perspective harmful to OSS as a whole. It is completely fine to release free software that other companies can use without restrictions, if you desire to do so. It is not meant to be a transaction. You share some, you take some. It’s also ok to release paid free software, or closed software, restrictive licenses, commercial licenses, and sell support contracts. It’s a choice. |
| |
| ▲ | sarchertech 3 days ago | parent [-] | | Just because you can do something doesn’t mean you should. There’s also lot of pressure for devs not to use licenses that restrict use by large companies. Try adding something to your license that says companies making over $10 million per year in revenue have to pay, and half of the comments on show HN will be open source warriors either asking why you didn’t use a standard license or telling you that this isn’t open source and you have brought dishonor to your family. | | |
| ▲ | ricardobeat 3 days ago | parent | next [-] | | > Just because you can do something doesn’t mean you should. This implies some kind of fairness/moral contract in a license like MIT. There is none. It’s the closest thing to donating code to the public domain, and entirely voluntary. There are plenty of standard licenses with similar clauses restricting commercial use, no need to create a custom one. But indeed, the truth is that a restrictive license will massively reduce the project’s audience. And that is a perfectly fine choice to make. | | |
| ▲ | sarchertech 3 days ago | parent [-] | | > This implies some kind of fairness/moral contract in a license like MIT. The license tells you what you are legally allowed to do. It doesn’t supersede basic concepts of fairness. The average person would say that if you directly make millions of someone else’s work, the fair thing to do is to pay that person back in some way. Calling someone a leech is just saying that they aren’t following the the accusers model of fairness. That’s all. There’s no legal definition. We say things like “my company screwed me over when they fired me right before my RSUs vested” despite that being perfectly legal. | | |
| ▲ | ricardobeat 3 days ago | parent [-] | | > someone else’s work It is not “their” work anymore (IP rights discussions aside) once they published with an unrestricted license. That’s the point. You do it expecting nothing in return, and do it willingly. Expecting “fairness” is a misunderstanding of the whole spirit of it. | | |
| ▲ | brookst 3 days ago | parent | next [-] | | Semantic games with “their work”. An artist who sells a painting can still call it their work, even if someone else owns it. And I suppose the collector who bought it could also call it their work, though that phrasing isn’t usually used. It comes about because “work” is overloaded to mean both the activity of creating and the product/result of that activity. | | | |
| ▲ | sarchertech 3 days ago | parent | prev [-] | | >expecting nothing in return Let’s ignore that no one contributes to open source expecting nothing in return. I can help someone out expecting nothing in return. Then if my situation changes and I need help, but they look at me and say “sorry your help was a gift so I’m not going to return the favor even though I can”. That person is a dick. The problem is you are taking the act of applying a permissive license as some kind of ceremony that severs open source software from all normal human ideas of fairness. You may view it that way. Most people don’t. It’s perfectly reasonable to put something out in the world for other people to enjoy and use. And yet still think that if someone makes a billion dollars of it and doesn’t return anything they are displaying bad manners. | | |
| ▲ | Chris2048 3 days ago | parent [-] | | > I can help someone out expecting nothing in return. Then if my situation changes It sounds like you did expect something in return, conditional on your circumstances. Maybe it's good-will or something, but some kind of social insurance in any case. | | |
| ▲ | sarchertech 2 days ago | parent [-] | | This is partly getting into questions about whether “pure” altruism is even possible, e.g., is an anonymous donation truly selfless if you do it because it makes you feel good. But in the example above it’s entirely possible that you helped someone out with no expectation of being paid back. Let’s say you’re rich and the person you helped is a chronic drug addict. You have no expectation of every needing help and no expectation that the person you helped will ever be in a position to help you. Let’s say I give a homeless person a dollar. He turns around and uses that dollar to buy a lottery ticket and wins 100 million dollars. Years later, I’m homeless and the former homeless guy walks past me and gives me a lecture about how I should have put conditions on my donation. In that situation there was no reasonable expectation for anything except as you said maybe good will.
But of course open source developers also expect good will. |
|
|
|
|
| |
| ▲ | nemomarx 3 days ago | parent | prev | next [-] | | Sidestep this debate with one trick - use the GPLv3. No company large enough to have a legal team will be able to use it, you're still squarely within the various definitions, and the FSF basically has to approve. As a bonus maybe you can get some proprietary software open sourced too. | | |
| ▲ | fleebee 3 days ago | parent | next [-] | | Is there a real reason not to use AGPL? The fact that it makes Google very uncomfortable[1] is a great selling point to me. [1]: https://opensource.google/documentation/reference/using/agpl... | | |
| ▲ | nemomarx 3 days ago | parent | next [-] | | For the purposes of me being facetious, it's less infectious than v3. but yeah it would have the same impact on large corps I think | | |
| ▲ | em-bee 2 days ago | parent [-] | | it's less infectious than v3 putting aside the argument about how infectious the GPL is in general, the the current AGPL is based on the GPL v3. it adds additional requirements. so how can it be less infectious than the GPL v3? |
| |
| ▲ | SAI_Peregrinus 2 days ago | parent | prev [-] | | AGPL is arguably an EULA, not just a copyright license. |
| |
| ▲ | JTbane 2 days ago | parent | prev [-] | | Companies are happy to use GPLv3 as long as they can put it behind a proprietary SaaS. |
| |
| ▲ | marcosdumay 3 days ago | parent | prev | next [-] | | > telling you that this isn’t open source Are you talking about promoting some software as open source when it's in fact not? Because yes, there's something wrong with that, you shouldn't do it, and people will rightfully react loudly if you try. People don't complain about proprietary software honestly communicated as that. | | |
| ▲ | sarchertech 2 days ago | parent [-] | | This is exactly the kind of thing, I’m talking about. Open source has mostly been captured by large corporations because purists refuse to recognize the gradient between proprietary and completely free. If I license my software as MIT but with an exception that you can’t use it for commercial purposes if you make more than $100 million a year in revenue, that’s a lot closer to open source than proprietary. We should be normalizing licenses that place restrictions on large corporations. I think the world would be a much better place if we just changed the definition of open source to include such licenses. We don’t even really need to change the definition because normal everyday use of the term would already include them. | | |
| ▲ | marcosdumay 2 days ago | parent [-] | | Open source is open source. There exists no gradient there. If your software isn't open source, don't claim it is. You are free to try to normalize your licensing preferences. Even better if you have a nice name for them that don't try to mislead people into thinking they are something they clearly aren't. > I think the world would be a much better place if we just changed the definition of open source to include such licenses. You are free to think that. I'm quite certain it's not correct, but nothing stops you. Anyway, you can make a positive change on the world you actually live on by being honest and clear about what your license does, and communicating why you think it's a good thing. Again, it's a huge plus if you get some nice name that can actually mean the thing your license is. > normal everyday use of the term would already include them Normal and everyday use of "open source" does absolutely not include the licenses you are talking about. |
|
| |
| ▲ | watwut 2 days ago | parent | prev [-] | | The most likely and common result of releasing an open source project is that everyone ignores you. If they notice, you may get a question about license once in a while which you can ignore. |
|
|
|
| ▲ | theknarf 3 days ago | parent | prev | next [-] |
| Npm is owned by Github, which is owned by Microsoft. They could have put more tooling into making npm better. For example; pnpm require you to "approve-builds" so that its only running scripts from dependencies you decide on, and Deno have a bunch of security capabilities to restrict what scripts can and can't do. There is always going to be supply chain attacks, and the biggest package repositories are going to be hit the most. But that doesn't mean that Microsoft couldn't have spent more on building better tooling with better security settings on by default. |
|
| ▲ | tcoff91 3 days ago | parent | prev | next [-] |
| 20 of the packages were from Crowdstrike |
| |
| ▲ | JanneVee a day ago | parent [-] | | I'm dumbstruck that Crowstrike exists with George Kurtz still at the helm. There is no accountability at all. Kurtz was CTO of McAfee when their update caused back in 2010. Why does these things keep following him? |
|
|
| ▲ | thayne 2 days ago | parent | prev | next [-] |
| In the case of npm though it is run by a very wealthy company: Microsoft. But also, most OSS Software is provided without warranty. Commercial companies should either be held accountable for ensuring the open source components are secure or paying someone (either the maintainer directly, or a third party distributor) to verify the security of the component. |
|
| ▲ | watwut 3 days ago | parent | prev | next [-] |
| Per survey I read, majority of open source is created by people who are paid for it. The unpaid volunteer working full time on something is effectively a myth. |
| |
| ▲ | josephg 3 days ago | parent | next [-] | | I’ve contributed a huge amount of opensource code over my career - almost all of it entirely unpaid. I don’t know the statistics, but I know many other people who have done the same. I think there are a lot of high profile opensource projects which are either run by corpos (like React) or have a lot of full time employees submitting code (Linux). But there’s an insanely long tail of opensource projects on npm, cargo, homebrew etc which are created by volunteers. Or by people scraping by on the occasional donation. | | |
| ▲ | watwut 3 days ago | parent [-] | | npm was a company for years now. It was initially created as a volunteer one person project, then they create company 10 years ago and eventually sold to Github which was sold to Microsoft. It has spent more time being developed as a paid thing then by unpaid volunteers doing it on the side. | | |
| ▲ | josephg 3 days ago | parent [-] | | I'm not talking about npm. I'm talking about the 3.1 million libraries hosted on npm. And the ~150k libraries available in rust's cargo, 187k ruby gems, 667k pip packages, and so on. For every React ("brought to you by facebook") there are thousands of tiny projects made for free by volunteers. | | |
| ▲ | watwut 2 days ago | parent [-] | | I have some there, two of them made on the clock on the job. For others I am 100% ok with them being used in the scope of the license. I would find it incredibly absurd if someone called users "leeches" for using these things. |
|
|
| |
| ▲ | bonoboTP 3 days ago | parent | prev | next [-] | | There are some mammoth projects where that's true, but the FOSS ecosystem has a very long tail where quite important and powerful libraries are maintained by individuals in their free time. "unpaid volunteer working full time" also doesn't sound like something that someone would believe. Full time and unpaid rarely go together. | |
| ▲ | austin-cheney 3 days ago | parent | prev | next [-] | | I don’t think that is correct. VS Code developers and the TypeScript team is paid by MS. Core of React is paid by Meta, or was. Java language is paid by Oracle as is the LiberaSuite and MySQL. Most of the Linux foundation projects, which includes Node are volunteers. Most of the Apache foundation software is from volunteers. Most NPM packages are from volunteers. OpenSSL is volunteers. There is also a big difference between the developers who are employees on salary versus those that receive enough donations to work in open source full time. | | |
| ▲ | watwut 3 days ago | parent | next [-] | | > Linux foundation projects, which includes Node are volunteers. The survey found that specifically linux code is dominated by people who are paid for it. > Most of the Apache foundation software is from volunteers. Large Apache project specifically are backed by companies per Apache rules. Each project must have at least three active backing companies. They contribute the most of the code. | | | |
| ▲ | izacus 3 days ago | parent | prev | next [-] | | Most of those "voluneers" are also developing those projects as part of their paid job in a form of company contribution back to OSS though. | |
| ▲ | 3 days ago | parent | prev [-] | | [deleted] |
| |
| ▲ | clbrmbr 3 days ago | parent | prev | next [-] | | It depends on the domain. There are a lot of critical utilities in the systems space maintained by volunteers. The “xz” compression library was one recent infamous example where an exhausted volunteer maintainer was social engineered into a supply chain attack that briefly compromised OpenSSH. Not a lot of applications being maintained by altruists, but look under the hood in Linux/GNU/BSD and you fill find a lot of volunteers motivated by something other than money. | | |
| ▲ | Arch-TK 3 days ago | parent | next [-] | | It briefly compromised the custom patched Debian version of OpenSSH. The issue had nothing to do with OpenSSH itself. | |
| ▲ | izacus 3 days ago | parent | prev [-] | | Yes, but even in those domains those projects are minorities and in many examples they make it effectively impossible to legally fund or contribute to them from the side of corporations. | | |
| ▲ | graemep 3 days ago | parent | next [-] | | Why is it legally impossible to fund or contribute? Do they turn down contributions from paid developers? Do they refuse donations or just have no no mechanism for accepting them? Do they not have any form of commercial services or licence? I think there are very few projects that do not accept support in any form. | | |
| ▲ | izacus 3 days ago | parent [-] | | In most cases they need to be able to issue a commercial invoice in a region compatible with company accounting. For a lot of single developers that's not a thing they're ready or able to do. Those that can, usually have companies established as a revenue source for their OSS project. | | |
| ▲ | pessimizer 3 days ago | parent [-] | | > In most cases they need to be able to issue a commercial invoice in a region compatible with company accounting. The need for this invoice is because companies cannot justify irrational spending. The have no process for gift-giving. There is almost nothing that will make spending on OSS not irrational, unless you're paying for specific bugfixes or customization work. You can't issue an invoice for nothing. How much would the invoice be for? edit: that being said, please continue to make up any pretense to get OSS contributors paid if that's working for anyone. |
|
| |
| ▲ | xrisk 3 days ago | parent | prev [-] | | Yeah I’m not buying it. If the corporations wanted to, they would. |
|
| |
| ▲ | cube00 3 days ago | parent | prev | next [-] | | I'd be keen to see that survey given how many projects I see with so few GitHub sponsors that I can't see how you'd derive a full time wage. | | |
| ▲ | graemep 3 days ago | parent [-] | | A lot of FOSS is developed by people who do it as part of their paid employment, that is what the GP is referring to, not Github sponsorship (which is tiny by comparison). |
| |
| ▲ | rs186 3 days ago | parent | prev | next [-] | | Which survey? | |
| ▲ | davedx 3 days ago | parent | prev [-] | | Post the survey please, that's an extraordinary claim |
|
|
| ▲ | psunavy03 3 days ago | parent | prev | next [-] |
| Well? If you license software the way most FOSS products are licensed, that's a natural result. It is literally putting up a sign saying "free beer." You can't give permission for them to use the stuff for free and then accuse them of "leeching." If the expectation is contribution in kind, that needs to be in the license agreement. |
|
| ▲ | austin-cheney 3 days ago | parent | prev | next [-] |
| Consider how many JavaScript developers are completely unemployable without that free software. It might be greater than 95%. That’s why business needs this stuff, because otherwise they might actually have to invest in training. |
| |
| ▲ | pavel_lishin 3 days ago | parent [-] | | > Consider how many JavaScript developers are completely unemployable without that free software. Can you say more about this? | | |
| ▲ | austin-cheney 3 days ago | parent | next [-] | | How many JavaScript developers in the workforce can write original applications without some colossal framework and an army of NPM packages? In 15 years of doing that work those people do not exist, at least statistically, and hiring does not encourage their selection. Most people doing this work, both in person and online, are extremely sensitive about this. It’s a hard reality to accept that if this free software went away most people doing the work wouldn’t be able to qualify their income in any significant way to their employer. | | |
| ▲ | tcoff91 3 days ago | parent | next [-] | | I think that ultimately it’s the fault of the web platform. With just a bit of retraining those engineers that could not be productive without a ton of npm packages could ship an iPhone app written in Swift. JS’ standard library is abysmal. | | |
| ▲ | austin-cheney 3 days ago | parent [-] | | This sounds like blaming the victim. How do you on one hand call these people engineers, as if they are engineering something, and then on the other hand blame everything else for their inability to perform? That is weird. Its just a software platform. Would you really blame society for being too harsh if doctors, lawyers, police, teachers cannot do their jobs? It is weird to see so many people blame the web platform for hostility when its so much less challenging than it used to be. The most common cause of these frustrations I encountered while working in JavaScript is that developers are educated in something that looks like A, but JavaScript is not A, there is no training for JavaScript/Web, so therefore JavaScript/Web is hostile. As a self-taught developer that never made sense to me. | | |
| ▲ | tcoff91 2 days ago | parent | next [-] | | The web is not an application platform, it’s a document rendering platform that has been hacked together to be an application platform. Without libraries it’s incredibly hard to be productive building applications. It’s only with dependencies that the web becomes an acceptable application platform. Look at how much JS it takes to implement a material-ui textfield that automatically grows and shrinks. Building a date picker is a pain in the ass. Making sure those things follow all the arcane aria standards to be accessible is difficult. There’s no good reason why everyone should have to rebuild their own date picker. Without libraries the web is the hardest application platform to use by far if you are trying to build actual apps and not just websites with content. | | |
| ▲ | austin-cheney a day ago | parent [-] | | > Look at how much JS it takes to implement a material-ui textfield that automatically grows and shrinks. I would do that with CSS. > Building a date picker is a pain in the ass. Making sure those things follow all the arcane aria standards to be accessible is difficult. If you want to display a visual calendar then yes, mostly. However, if instead you make date picking relative to now then it becomes very simple. It’s just adding or subtracting numbers from Date.now(). You can even produce date spans super easily. I understand where you are going. When everything starts from a visual UI perspective the code is just an implementation detail except that it’s dense. If instead you start at from the implementation perspective of how it really works at the lowest level then everything just appears step by step. Nobody starts building beautiful skyscrapers from the visual exterior first. No, they lay the foundation, a boring slab of concrete around some grounding poles. |
| |
| ▲ | marcosdumay 3 days ago | parent | prev [-] | | I dunno. Would you blame doctors if they were unable to perform in a single hospital and had a verifiably good track record anywhere else? | | |
| ▲ | jlaternman 2 days ago | parent [-] | | If in the other hospitals they were able to rely on the expertise of others, but in that single hospital they could not hide their lack of deep knowledge and that led to deaths? I think the answer of that analogy is obvious—though I realise it is an analogy, not directly comparable. |
|
|
| |
| ▲ | pavel_lishin 3 days ago | parent | prev [-] | | I mean, you're right about that - but how many construction workers could build a house without having access to pre-cut lumber, pre-sharpened tools, nailguns, power equipment, pre-cast nails, etc., etc? | | |
| ▲ | austin-cheney 3 days ago | parent [-] | | My neighbor works construction and my son did for a while. They were working on the new Texas Instruments silicon prefab. The people that do the actual work with their hands are expected to do just about everything. We are talking about advanced metal work in a place with liquid nitrogen and harmful chemical agents. The actual engineers just walk around to validate the work conforms to the written plans. That is why these large engineering companies prefer to hire only from labor unions in a location that is extremely anti-union, because the union has the social resources to validate the candidates in ways the employer does not. Even in that environment there are more experienced people who are 10x producers. | | |
| ▲ | em-bee 2 days ago | parent [-] | | that's an interesting point about unions in the US. if true. because in europe (at least in austria and germany, but i suspect it's the case in most countries) unions do not do any validation of their members. having a job in an industry IS your validation to be a union member. the union then negotiates work conditions and pay on your behalf. figuring out whether you are qualified is the companies job. |
|
|
| |
| ▲ | user34283 3 days ago | parent | prev [-] | | It boils down to him feeling superior to web developers, who are far beneath him and couldn't possibly program with other tools. | | |
| ▲ | austin-cheney 2 days ago | parent [-] | | Actually, its the opposite. When you are no longer compatible to the workforce because you don't want waste all your time on the same basic literacy things over and over you start to feel extremely inferior when you cannot get a job. But the fact the concerns of superiority come up so repeatedly just serves to illustrate how much insecurity is baked into the workforce. Confident people don’t worry about high confidence in other people. |
|
|
|
|
| ▲ | keybored 3 days ago | parent | prev | next [-] |
| Fool me once, shame on you. Fool me repeatedly again and again, then? |
|
| ▲ | raisaguys 3 days ago | parent | prev | next [-] |
| [flagged] |
|
| ▲ | delduca 3 days ago | parent | prev [-] |
| This. |
