15 ms·
I am not a supplier
- Juliate 4y ago« provenance » would be a more accurate name than « supply », as it englobes both software that’s actually supplied, and software available « as is » that’s being picked up.
- steve_gh 4y agoNeeded saying. Chapeau!
- bhickey 4y agoSome months ago after recoiling in horror from a vulnerability in rust I arrived at the grim realization that the "supply chain attack" problem is intractable in impure languages. When a transitive dependency can do anything it will inevitably do something. I don't expect to convert everyone (or anyone) to object capabilities and purity, but I do hope the experiences of the past year have put the fear of God into developers. We should aspire to build systems where a suddenly malicious or busted dependency can't knock over the whole tower.
- TAForObvReasons 4y agothe current fragility of the "software supply chain" stems from package managers and their perverse economic incentives, and this is just as true for "pure languages". Vendoring and auditing dependencies greatly reduces the attack surface area.
- bhickey 4y agoCan you elaborate on the incentives of package managers? The problem I see with Rust is that it's just really easy to add dependebcies in a way that is difficult in C++. I don't follow your point about purity. A dependency in a side-effect free language can't suddenly open a socket or access the file system. The attack surface is much smaller.
- busterarm 4y ago> A dependency in a side-effect free language can't suddenly open a socket or access the file system. A dependency can exploit your system deliberately, not just with side effects. If you're not strictly pinning all of your dependency versions, one malicious update that makes it to the package manager can ruin your whole world. Our package managers operate entirely on trust. Nobody is guaranteed to be checking to make sure some random package's maintainer isn't submitting malicious updates. As a community we're all lazy and basically hope that somebody else is invested enough to check everyone else's work. In the case of OpenSSL, we've found that some projects become so complex that almost nobody does for long periods of time.
- Hizonner 4y agoI think the thing that makes it more tractable in pure languages is that you at least get the chance to control the dependency's inputs and inspect all of its outputs, so it's theoretically possible to limit what it can do to you (depending on how you are using those outputs). I'm not saying it's usually practical, but it's at least conceivable. And there should be at least a few cases where it's actually practical. In an impure language, it can do any random thing to any random part of the whole system and you won't even get the chance to know what it is doing. Are there any truly pure package management systems out there, though? Haskell has Safe Haskell, which more or less guarantees that the actual Haskell code compiled through the normal path is pure (but not that the code is total, and total under resource constraints, which you also need). The build system itself is not pure, though, so you have no guarantee that a dependency's build scripts don't put Evil Things into your program outside of the actual language framework. Any others?
- remexre 4y agoIt sounds like Safe Haskell might be getting deprecated soon [0]; it sounds like it isn't used much in practice... [0]: https://discourse.haskell.org/t/deprecating-safe-haskell-or-heavily-investing-in-it/5489/ https://discourse.haskell.org/t/deprecating-safe-haskell-or-...
- 4y ago
- gizmo686 4y agoIts not intractable. You just need to take the concept of a software supply chain seriously. E.G, every version of every dependency you use (either directly or transitivly) needs to be audited and approved by a trusted supplier. This isn't nearly as bad as it sounds. You only need 1 trusted organization across the entire industry to certify a baseline of trusted software. Maybe a second organization to cover people who don't trust the first. The NSA, some other part of US cyber command, or a comparable agency from a different government are all natural choices; as they have a vested interest in protecting critical domestic infrastructure but no commercial interest in keeping their work proprietary. Since that infrastructure all runs the same software as the rest of industry, we all benefit.
- dragonwriter 4y ago> The NSA, some other part of US cyber command, or a comparable agency from a different government are all natural choices; as they have a vested interest in protecting critical domestic infrastructure NSA is not a natural choice, since they are an active threat that has a history of abusing trust in their defensive mandate to insert vulnerabilities into systems in pursuit of their offensive mission.
- lrhegeba 4y agoThen you can decide for your org to not trust them and perhaps use a different certifier. i would welcome them offering such a service instead of having none.
- voakbasda 4y agoTrust like this is transitive, so I would not trust any organization that placed such blind faith in the NSA. I hope your brave new world includes a requirement for orgs to disclose their software auditor, so my org can avoid trusting orgs like yours.
- Hizonner 4y ago> You only need 1 trusted organization across the entire industry to certify a baseline of trusted software. So it's not just bad, but impossible. Got it. More to the point, software "auditing" does not work reliably against deliberately malicious code written by competent actors, never has, and never will. It's too easy to slip in subtle back doors that reviewers won't notice, and at the same time too hard to keep up with the review workload.
- di4na 4y agoAuthor here. You do realise that the main source of dangerous vulnerability is low level infrastructure that do not come from these package managers ? The purity and capabilities sadly solve nothing when the source of the problem is the fact that NTP, OpenSSL, OpenSSH, the BGP daemon, the libc you run on, etc are all maintained and "fixed" and evolved by people that can barely pay for their food, even less for basic tests ? Like i love capabilities and i would love to have more, but the basic problem here is that the low level that you totally depend on for the capabilities to work cannot even be funded to work. Hell you do realise that Autoconf has not had a maintainer since 2012? If it was pwned and had injected backdoor in your software since then, we would have noone to fix it.
- asdfghjhgfderty 4y agononsense. autoconf didn't have a core developer. But it had many distro package managers. there's nobody adding code/fixing bugs, but there are plenty people reading and looking at diffs before packaging it in distros. then the js libs have neither core maintainers nor anybody at npm corp that cares about security or reading anything. the top comment is correct to care about those before system libraries.
- kelnos 4y agoI don't agree. When there's a problem in OpenSSL, OpenSSH, or libc, nearly every company with an online presence has as freak-out and rushes to patch. When there's a vulnerability or malware found in a python or npm package, 75% of the tech world does a quick audit (or not), shrugs, and goes on with their day.
- gsich 4y agoWhy the weak words? "reading", "looking" is not "understanding".
- pbhjpbhj 4y agoIANADev, but surely if they were going as deep as understanding patches they'd practically be a project maintainer rather than a package maintainer. Expecting package maintainers to have even reviewed diffs seems like high expectations. I wouldn't expect them to do more than the actual packaging. Weak words seem appropriate. I've hacked together a couple of packages for personal use but didn't even go so far at to look what language the code was in. I'm assuming a lot of packages from ppa-s are produced in an automated way with no code review, and depending on your distro that might also be true of some principal libraries.
- tsimionescu 4y agoCan you give some examples of such a pure language? Haskell is definitely not it, since you can always call unsafePerformIO anywhere to do anything. I would guess Idris has something similar, but maybe I'm wrong. Also, if a dependency actually needs IO (either a networking library, or a DB library, or just for logging purposes), the guarantees you're talking about again go out the window. And, moving to the more extreme scale, you can never be 100% sure that some dependency hasn't found a way to trick the compiler or runtime system into doing something it's not supposed to be possible to do, even if it consists of (ostensibly) pure code only.
- bhickey 4y ago> Can you give some examples of such a pure language? BPF and eBPF, though this feels unsatisfying.
- sethammons 4y agoHence why I check in vendor dependencies. It is wild to me that people pull fresh their dependencies on builds, trusting patch versions that really should have been major versions.
- lucasyvas 4y agoVendoring is an option, but if you place some trust in your registry a lockfile is totally fine.
- yencabulator 4y agoFunctional purity is the wrong abstraction to ask for, and doesn't protect you as such (consider a Haskell library that, very purely, asks to write to ~/.bashrc). Sandboxing modules is what you want, and that can be done with impure languages too. Sure, pure functional programming might make it easier, but as others pointed out, Safe Haskell and friends are very very far from mainstream. Meanwhile, Firefox compiles some C/C++ dependencies into wasm, and runs them in sandboxes.
- roxgib 4y agoHard to believe this even needed to be said, yet the FOSS entitlement continues unabated to this day. The post a few days ago from the developer of curl was pointed example of how bad this has become. https://daniel.haxx.se/blog/2022/12/30/an-m1-for-curl/ https://daniel.haxx.se/blog/2022/12/30/an-m1-for-curl/
- Waterluvian 4y agoProbably gonna be unpopular but I feel like I got the opposite message: Apple is using FOSS in a completely normal, completely legal way. But some people in the comments were upset that Apple wasn’t voluntarily donating to the project. That feels like entitlement.
- TAForObvReasons 4y agohttps://twitter.com/AppleSupport/status/1461330383425970180 https://twitter.com/AppleSupport/status/1461330383425970180 > Thanks for contacting us. To get help with this issue, please reach out to Curl: https://curl.se/gethelp.html https://curl.se/gethelp.html The original tweet was deleted. If this were a bug report related to the system distribution of curl on M1 macOS (apple's proprietary platform), it seems somewhat entitled that Apple would pass the support burden to the curl author without providing resources to debug on their proprietary platform
- Waterluvian 4y agoIf I publish a program to run on a Mac, Apple should give me resources for debugging issues?
- Hizonner 4y agoIf Apple includes your program as part of the software it sells along with the Mac, then Apple should be sending you well-tested pull requests for any problems its users find, not just giving you debugging resources.
- D13Fd 4y ago“I am not a supplier,” they say, while supplying things. I agree with the fundamental points here. Expecting things like they describe out of open source volunteers is absurd. But screaming “I am not a supplier” in this context is like yelling “I am not a driver” while driving a car.
- jFriedensreich 4y agono its not. its saying i am not an uber driver to the pretentious guy entering his car on wallstreet.
- ipsum2 4y agoIt's pretty clear from the article that the author defines supplier as being in a business relationship, using "supply chain" as the context.
- Hizonner 4y ago[flagged]
- williamcotton 4y agoThe word “supplier” has multiple meanings. The meaning in this case is derived from the context of the article. In a business context: “A supplier in a business is someone who acts as an intermediary between the manufacturer and retailer, ensuring that communication is forthcoming and stock is of sufficient quality.” This being a business relationship and not an intramural frisbee team implies contracts and money changing hands, does it not?
- D13Fd 4y ago> “A supplier in a business is someone who acts as an intermediary between the manufacturer and retailer, ensuring that communication is forthcoming and stock is of sufficient quality.” That’s not the definition used in the article at all.
- 4y ago
- andrewflnr 4y ago> So all your Software Supply Chain ideas? You are not buying from a supplier, you are a raccoon digging through dumpsters for free code. This got a genuine LOL from me. Bravo. I'm going to repeat my principle on the software supply chain issue: the responsibility for software security and other maintenance rests on those who deploy it. Deployments are the loci of harm from bad software, not projects. Secondarily, the weight of that responsibility should depend on the level of harm resulting and the level of benefit its owner receives. Whatever rules and conventions emerge from this fiasco, it needs to allow people to write software for fun, and even deploy it for fun as long as the damage is contained. And the people paying for maintenance need to be the ones making money from it.
- di4na 4y agoAuthor here. Yeah a friend quipped that when i explained to them i was writing this post, and i asked them if i could shamelessly steal it and use it. They agreed. So i ran away with it.
- deleted 4y ago[deleted]
- bee_rider 4y agoIt is a nice quip, but is it true? I think Free code is quite unlike garbage, in that most Free software devs do somewhat hope their code will be useful or enjoyable to somebody, right? Garbage is explicitly refuse, you don’t expect anyone will find it useful at all. The raccoons are a nuisance — we actually go to great lengths in some cases to make sure they can’t check out the garbage! People sifting through your garbage are probably up to no good. I think is hard to make an analogy between Free software and a physical thing because most physical things are finite and can’t be copied for free. Maybe Free software is more like a dance — you do your dance to for yourself, and to impress your friends maybe (or maybe as exercise, or some other motivation). You don’t mind if someone copies your dance. You might even help your friends learn it. But you clearly have no obligation to help strangers learn it, and no responsibility if they get hurt trying to do it.
- 4y ago
- chasd00 4y agoNPM needs a msg displayed in bold on every command that says “these packages may vanish at any time and may not even be what you’re expecting”. I think package managers presenting all packages as equally supported and vetted is part of the problem.
- themodelplumber 4y agoThere is an unseen alignment of incentives. The typical FOSS dev community wants its project to be taken seriously. They anticipate competition with other FOSS projects which are commercially backed in many cases. And "So-and-so Corp. couldn't do it without us" often proves a high standard of being taken seriously. Examples of that (I think I saw a few earlier today) are all over the place, even here on HN. The messaging idea is interesting but I wonder how wording like "may vanish at any time" would play into these software community goals of gaining qualitative legitimacy in the face of de facto intra-FOSS-world competition. It seems like a more creative method might be ideal. But this is mostly true if commercial adoption is seen as a goal, and many projects make it clear that they 1) don't gaf about that and 2) are ready to negotiate a higher standard if the negotiated outcome suits their yet-to-be-communicated needs. That's also not a very inviting model and it perpetuates a sort of harsh dichotomy around the issue of reliability and support in those cases. It's really unfortunate because this dichotomy also makes FOSS seem less reliable from the business perspective on the outside, which isn't necessarily desired either.
- quickthrower2 4y agoRemove node_modules from .gitignore (and make git handle doing that more graceful!)
- mesozoic 4y agoAnd the maintainer may change what the functions do randomly for any reason including they found it funny.
- bitwize 4y agoMost places I know that did node shit pulled their dependencies from an in-house Artifactory instance. Means no exotic libs -- or upgrades -- until you can get the new library or latest version vetted, at least in principle.
- rboyd 4y agotl;dr I really like your blog theme though so I cut+pasted it into my own blog but there's some kind of css issue. I msg'd you details. Take a look when you can, hopefully soon, I have a big post going live tomorrow.
- di4na 4y agoAuthor here Where did you message me ? I know i have all kind of problems with it but never had time to deal with it :D Also the TL;DR is the title :)
- xwowsersx 4y agolol I think they were giving a tl;dr by giving an analog to someone ripping off your css and expecting help from you. It's an example of how people who use your freely available software for their project behave. They come along, as you say, like a "raccoon digging through dumpsters for free code." But then they think they're entitled to think of you as a supplier and that you should provide support. That was the joke in "I have a big blog post going live tomorrow."
- rossta 4y agoLOL this was my favorite comment
- deleted 4y ago[deleted]
- shadowgovt 4y agoI like the position of this author and think it's quite correct, but FWIW the logical conclusion if we pull the lever all the way over to this line of thinking is that in the modern era, the FOSS ecosystem has failed as a business model and companies will be better off developing their cores in-house (with all the opacity and lock-in that implies), and the pendulum swings again. Fortunately, we need not pull the lever all the way in that direction. As with so many aspects of the open source ecosystem, the real most valuable element is trust.
- di4na 4y agoAuthor here. The difference is that FOSS is not a business model. It is far closer to infrastructure, which is usually supported by other means than business models. Things like community structures for common goods (regularly called government but not always). There is a different problem here, which I have chosen to not talk about here, but that is the problem of funding profitable software products. We simply... do not do that. We do not have the tools for that. But that is a different rant.
- shadowgovt 4y agoAgreed. What I'm thinking of specifically is the leftpad attack vector, where a trusted actor suddenly went malicious and broke the software many people were lying upon who didn't realize they were relying upon it (and weren't really in a position to be aware of the issues the author had encountered). If that happens too much, corporations re-evaluate rush and costs and start developing things in isolation and in-house. But I expect leftpad will be a rare event.
- di4na 4y agoI would note that the trusted actor did not went malicious. He did exactly what he was entitled to. If we follow the rules, the people that went malicious are all the trusted users and package repository that broke his intent. He was totally in the limits of his rights and the social contract of the licencing for FOSS. The fact we present these maintainers as "going malicious" is exactly what i am ranting against in this post.
- ChrisMarshallNY 4y agoTL;DR: > The fact you made your product depend on it is your responsibility. Not mine. Yup.
- er4hn 4y agoI completely agree with the primary point of the author, which i summarize as: don't ask me to meet your companies arbitrary requirements for code when we don't have a business relationship. Completely fair. However I don't think that is what software supply chain security is about. When you look at something like SLSA (slsa.dev) it's more about internal build systems. You are pulling code and dependencies from somewhere, that is cool. Now that it is in your environment how do you validate it matches what the upstream provider has? How do you secure your build environment? How do you prevent the outputs of builds, stored internally, from being tampered with? The most popular strategy to date has been "hope" as in "hope is not a plan". Where it sucks for OSS maintainers is you have companies coming in and continuing to try and apply hope internally and send prodding emails upstream to not rely on hope. That's bad and is not something worth OSS maintainers dealing with. Unless, you know, the company is offering money to do so.
- di4na 4y agoSo I went to check SLSA Version Controlled: On the maintainer side Verified History: On the maintainer side Retained Indefinitely: Can be both Two Person Reviewed: On the maintainer side Scripted Build: On the maintainer side, could be both but not the current model Build Service: Both i suppose Build as code: On the maintainer side Ephemeral env: User side Isolated: Both Parameterless: Both Hermetic: Both but mostly maintainer Reproducible: Maintainer side Available: Could be discussed but maintainer Authenticated: Maintainer Service Generated: Both Non-Falsifiable: both Dependencies complete: Both Security: Maintainer side Access: Not applicable Superusers: Both So SLSA mostly demand work from the maintainers, not the users.
- er4hn 4y agoThank you for reading through it and summarizing. I disagree with your conclusion however. It's not possible for someone to completely trace upstream dependencies in a SLSA compliant manner. No company can sanely expect that. What can be done is to say "we have some code from outside. How can we attribute it to upstream and make sure it has not been altered?" You can use signatures from the maintainers, version it, even reference a git commit. I don't think that anything additional from maintainers should be required, it's on the company to figure out how best to do so.
- skybrian 4y agoIt's fine not to be a supplier! I'm usually not. But in that case, why publish your code so that people will think you are a supplier? Better to publish it as a gist, a notebook, or some other way of sharing example code, not as a package where people who want to reuse code without adopting it will expect to find such things.
- di4na 4y agoBut i did write in big, capital letter that i am not a supplier in the licence, in the repo. See the last sentence.
- skybrian 4y agoI don't know where you publish your code. You did imply at some point that you're not just talking about yourself, though: > We are volunteers, writing code and putting it online under these Licences. And yes, we put it online for people to use them. But we do not get anything from it. Some people publish their code on npm or as crates or whatever. These packaging systems are designed to allow people to download and use your code without reading it. Worse, they can end up using the code indirectly, without reading it. Do you think they see your repo or the README or the license? So what I'm saying is that if you take no responsibility (which I support), you should stop doing that (if you are), because it confuses your message. Although there's no money involved, these packaging systems encourage consumer-like behavior.
- ssivark 4y agoAnd handicap all the sensible users who are willing to take responsibility for using those libraries? (in hobby projects, or otherwise) Sounds to me like a perversion of the intent of FOSS infrastructure.
- skybrian 4y agoMore users, more problems. People who just use your code without maintaining it don't benefit you. Often, FOSS infrastructure is part of the problem.
- jxcole 4y ago"everyone depends on their particular bolt, and we are all screwed." I love clever puns.
- itqwertz 4y agoKudos to the author, really needed to be said. I really liked the bolts and “screwed” play on words. Great article. As members of the tech community, we need to be careful of overwork and manipulation. I hold in high regard the numerous developers that maintain the libraries and packages that make my work possible. Unpaid labor is a huge problem in FOSS, people need to get paid. Get paid, don’t work for free.
- sweetjuly 4y agoMy (least) favorite instance of this is in the response to the Log4j vulnerability. Evidently some companies tasked people with ensuring that ""all of their suppliers"" had patched the issue and were in compliance. This lead to random open source projects, many of which could not possibly be vulnerable, being inundated with form letters demanding that the project meet ABC Corp's new security requirements. Most maintainers told them to kick dirt, but it was truly bizarre seeing people think they were in any position to make demands over a project that they aren't paying for.
- wildrhythms 4y agoMakes me wonder who the hell is in a position to write such a letter, and how the hell they got to that position obviously being clueless about security and their relationship with open-source projects like that.
- delfinom 4y agoPlenty of people in the world simply comply with handed down corporate directives rather than start discussions internally. Often it's scenarios like their unqualified boss who is the ceo's uncle's son may throw a fit somebody is challenging them. Or there's some checklist nazis in charge.
- efitz 4y agoI’m a security engineer at a big technology company. I’ve been a security engineer at several of these. I’m speaking for myself here, not for current or previous employers. When I say “software supply chain security”, I am reducing a complex concept to jargon, and am using terms that will evoke specific concepts in the people I work with. I’m not really talking to you; I’m talking to my leaders who are extremely business savvy but may not have the software development chops to understand how code we didn’t write got mixed in with code that we did write. I am NOT implying nor assuming that the original creator or maintainer of said software has any obligation to me. The 90% case for me, when I bring up this term in a software security discussion, is that I’m trying to impress upon an engineering manager that if they choose to use software that they didn’t write, that THEY own it from a security perspective. Depending on risk we might discuss monitoring for notifications of vulnerabilities in the code, or we might discuss first-party or third-party security code reviews, and/or forking depending on the security support level of the maintainer, and/or contributing back security patches that we develop in house. Or I might try to convince them not to take the dependency and write the code they need themselves. Or I might propose mitigations like isolation. Or all of the above. “Software we use but didn’t write ourselves” just doesn’t look professional or compelling in reports and documents and doesn’t lend itself to being reduced to an acronym like SSCS. As a security engineer, I depend a lot on the goodwill of folks like you who write and maintain open source software, and I most definitely do not take your work for granted. Best regards and Happy New Year!
- whatshisface 4y agoIf a good acronym is what we need, why not Outsourced For Free, or OFF-ware? ;)
- strogonoff 4y agoUsing other terms than “software supply chain security”—for example, “open-source ecosystem security”—could benefit status quo, even if (or especially if?) the recipient of the language is internal management. In the first case the problem is “I have subpar suppliers with poor security and I need to work around that”, in the latter case it’s “I build upon works that were voluntarily made available, often by craftspeople with limited resources”. It’s not a secret that words we use have associated baggage that colours our understanding of an issue even on unconscious level. Different connotations of the latter call for different, more humane attitude and perhaps provide an incentive to contribute, sponsor or donate—and vice-versa, using terminology from a world with transactional relationships to level with business types may in fact gradually infect our own outlook. Sure, a different language might sound less familiar to them, but perhaps there is a good reason for that—the dynamics are different, so the feeling of familiarity is false anyway.
- vivegi 4y agoAgree completely with the author. Even in the situations where there is a supplier-buyer relationship there is the maxim of caveat emptor, subject to terms of an explicit commercial contract. It is 100% the responsibility of the user of a library or FOSS artefact to do their due diligence before adding it as a dependency in their project. It is bonkers to demand the developer of an open source library to dance to my tune just because I am using their library gratis. It is open source! Create a pull request, fix the bug (or add the enhancement), compile, test and write to the devs with your solution, if you really care. People sitting on their pedestal and whining solves nothing (for themselves or the community). I am just thankful there are so many people who work for providing high quality FOSS software. Donate (or support those projects in other ways) if you are able to do so. Don't just be an entitled jerk.
- foobiekr 4y agoThe problem everyone who cares is wrestling with is that software teams in practice do no diligence at all.
- vivegi 4y agoI agree. What used to be called Build vs. Buy decision usually involved a calculation of costs. There are lifetime costs involved in both choices. If a dev team chose to use a FOSS library/product (pr even a commercial 3rd party library), that analysis isnt complete without an assessment of practices needed for maintaining it over the entire lifecycle of the product they are building. On the oft cited example of the FOSS developer who decided to delete their library/introduce a deliberate bug, the teams that were impacted had missed the step of validating and testing every minor version in their integration test environment. They should have also checked in the sources of all their dependencies to ensure a reproducible reliable build. If it was a commercial 3rd party library, it was quite common some decades ago for the customer to pay additional to secure the source code in software escrow, to protect against the smaller supplier shutting down/going out of business. FOSS gave a better alternative by sharing sourcecode freely so that this mechanism of paid software escrow becomes redundant and the user can directly use the source for any purpose they see fit. Failing to adopt these basics and complaining about what an independent developer should/shouldn't do sounds lazy. Fundamentally, this boils down to trust in the underlying assets and degradation of serious engineering practices. There are no easy shortcuts.
- marsupialtail_2 4y agoI sponsor OSS software I depend on and you should too!
- mickael-kerjean 4y agoThat's great but unfortunately you're the minority. 0.004% of users ends up giving something in my OSS project
- cc101 4y agoPutting the key idea last after building up the essentials is a common geek failure mode. It's a bad idea because it discourages readers from finishing. It leads directly to TL;DR.
- di4na 4y agoI put the tl;dr in the title. I can hardly lead harder with the conclusion
- dgudkov 4y agoIt's a very correct article. But here is a question: I run a software company and we're ready to pay for the FOSS we use in our product. Is there a convenient standard way to pay all the 50+ maintainers without having to spend years drafting individual contracts with each of them from a clean slate?
- eesmith 4y agoDepending on the FOSS you use, yes. Eg, https://tidelift.com/ https://tidelift.com/ . Is it more convenient to find commercial/proprietary vendors instead? Or to use warranty-less software and pay for your own staff to track changes and be ready to maintain the software yourself?
- di4na 4y agoI did mention it was hard to do isn't it. The other comment is right, vut tidelift is limited. There are foundations that cover whole ecosystems that may be of use. Other than that, no not really. It is infrastructure we have not built because it is easier to not pay than to think about it
- alexellisuk 4y agoAs the founder of OpenFaaS, the author doesn't know how true this rings - given all the myriad enterprise users of the community edition/OSS code. Even with smaller projects like K3sup, where I've seen defence contractors have k3sup references in their codebases and issue comments, go on to ask for changes, yet publicly stating they've never used it. We did pivot the business model in ~ 2019 to open core, and I've tried to apply that to future endeavours like inlets, with the latest "actuated" - self-hosted CI in microVMs - it's a SaaS, with no open source components. The common retort from users is "when we're in production, we'll pay for support / sponsor the project" - this literally never happens. I applaud the author for laying it out how it is - there is no business relationship, open source maintainers are not suppliers, but if you want us to become your suppliers, have procurement reach out. Because we may well be able to offer you a relationship that would be mutually beneficial.
- simne 4y agoDo You really want make money with OpenFaaS?
- tlocke 4y agoAs a maintainer of open source libraries, the steps I've been asked to take to secure the supply chain are: * Signing releases (requested by linux distributions) * Signing commits (actually I don't think anyone actually asked me to do that) * Authenticating myself with a physical security key. (requested by PyPI) I found these things easy to automate and they seemed worthwhile to do, and so I don't resent doing them. My sense is that these things are being gradually built in to tools and will become the default without any effort on the part of library maintainers. So hopefully you'll allow me to sneak in another point! Open source licences create relationships that in political theory would be called anarchism. In software anarchy, anyone's allowed to do anything (or not do anything) they like with their copy of the code. Software is what economists call a non-rivalrous good (ie, multiple people can enjoy it without affecting each other). Anarchy works well with non-rivalrous goods. In contrast, businesses are built around rivalrous goods (ie if you have it, I can't have it), and in this world anarchy doesn't work, and you have to view things through contracts and money. I think I'll stop there :-)
- _nalply 4y agoI agree with the term "anarchy" as long as other people don't take my human rights away.
- senko 4y ago> Authenticating myself with a physical security key. (requested by PyPI) Is that only for some packages? I publish a few obscure ones (not widely used) and get away with just a password.
- jimjimjim 4y agoWhere ever possible if I use an open source lib in a product I download it and store it locally (inside corp) for build servers to grab or bundle it in with the code in the product repo. There is zero reason why the build process needs to access any external domain. And if there is a new lib version or a problem/bug (depending on severity) then the product is retested with the new version before going out the door. Of course, I dont have to do web front end. That stuff just seems wrong
- seanhunter 4y agoI don’t follow the author’s logic at all. Just because you don’t have a business relationship with the end user doesn’t make you not a supplier. If you make software available to others to use, you are supplying the software to them. You are therefore very clearly a supplier. Pretending words don’t have any meaning doesn’t help to resolve the problem. The fact that you don’t have a business relationship changes the nature of your obligations to others - they are voluntary - and that in fact is at the heart of why software supply-chain is a problem. You have much more control over suppliers that you do have a business relationship with. As a community we have grown accustomed to moving at a pace that would not be supportable were it not for a network of volunteers around the globe maintaining and developing all manner of software and making it available as open source. It would be an enormous cost and reduce velocity significantly were that not the case, so I’m very greatful that they do this. During my career I have also made some small open source contributions myself. But that doesn’t make those people not suppliers.
- _nalply 4y agoWhat do you expect from FOSS "suppliers"?
- UncleEntity 4y ago> What do you expect from FOSS "suppliers"? That if it breaks I get to keep both pieces. Or I can fix it if I’m able. What I don’t expect is for them to intentionally break things and/or just pull the rug out from underneath everyone because “they’re well within their rights”. Sometimes being a dick is just being a dick. Too many people seem to think they have some right to make money by giving away their labor for free because people take them up on their offer of free labor. Don’t want to work for free then don’t work for free. Don’t want the richest corporations in the world using your software without contributing back then don’t offer it to them under a license where they can do this. Easy peasy.
- cuu508 4y ago> Too many people seem to think they have some right to make money by giving away their labor for free because people take them up on their offer of free labor. Can you point to some specific examples?
- fxtentacle 4y ago"you are a raccoon digging through dumpsters for free code" sounds like a great metaphor for inexperienced people using Copilot.
- bell-cot 4y agoOne analogy I've used a few times, with the suits: Supported software is a purebred dog that you paid an American Kennel Club-registered dog breeder thousands of dollars for. You got pedigreed papers, a warranty against early development of problems such as hip dysplasia, and bragging rights about all the blue ribbons in your dog's family tree. But in the end, there is no guarantee that the dog will actually work out well as your family pet. FOSS is a mutt that you got for free from the American Humane Society. The AHS promised that it's spay/neutered, up-to-date on its shots, and that their under-resourced veterinarian didn't notice any major problems in a real quick once-over. The mutt may actually have a better chance of working out as your family pet. But if you expect a purebred warranty, for a free mutt from the AHS, then people who know anything about dogs may start wondering about you.
- EdSharkey 4y agoThis is one of those important articles that Will have me thinking years down the line. This article is howling into the void for change. Can we change now? Please?? Successful open source providers need to morph themselves into vendors, that is clear. The process needs to be low friction for all parties (subscription model). The article hints that the success of that transformation to vendor is governed by the supplyee being able to continuously drive change/quality requests down to the supplier to get what they need out of the code. At first blush, I think: "to a package manager, attach: a credit card/subscription system, ticket tracker/change request system and the supplier's email/contact info". A system like that would mean, if you are a big megacorp, whenever one of your devs adds a package to their dependencies, and that package is from someone that wants to form a supplier relationship, the subscription request is automatically submitted to the accounting department for approval. Upon approval, money flows, and yucky details like seats and corporate rates can be negotiated by the accountants or legal. That would be an amazing improvement over the "labor of love" buy-me-a-coffee model we have today. I think the grumbling begins in such a system where a package was free/unencumbered and it suddenly become a paid one. Kind of feels like a rugpull especially for supplyees that ARE poor and ARE only raccoons rummaging through trash. Perhaps there are rules of how to appropriately rugpull that need to be in-effect. What I do not glean from the article is how money would necessarily transform an OSS developer into a supplier. Maybe the developer is an amateur supplier and will never get their shit together enough to truly meet the needs of the suppliee. Maybe they are a solo developer and die and leave the supplyee hanging. The license and copyright I think necessarily need to preserve the AS-IS nature of the software itself due to the power imbalance between supplier and supplyee. But then how do we handle issues of negligence and impropriety on the part of a supplier? In my mind it comes down to copyright. There has to be a socially acceptable weakening of copyright when a supplier turns bad or goes missing. Some arbiter (the package manager itself) can sever the subscription and give the supplier's copyright away so that it can find a new home. Such a system ultimately becomes corrupt and the suppliers will get screwed out of their labor though. I can't see how such a system can be made to work in the long term and AS-IS is the best we can do. Le sigh.
- lebaux 4y agoand I am not a rapper
- lucasyvas 4y agoAn interesting thought I had - maybe part of the problem is that certain project maintainers should not be packaging their software and simply release licensed source. For example, if I make neat-thing library and give it an MIT license, maybe I should not necessarily care about publishing it to a package registry (or in extreme cases, even versioning it). Let someone else become the supplier and productize it / support it / semantically version it. This sort of reminds me of how Linux distros operate (minus maybe the versioning part?). In this case authors can minimize their sight line to work only directly with those packaging their software instead of a million different companies. And even in that case, they can easily tell the supplier they can submit a patch or fork it. Presumably, the supplier/packager would be more of an organized entity and capable of creating a business model and having contracts with companies on one hand and authors on the other. This is an interesting idea to me. I think if every author moved to source dumping instead it would greatly change the dynamic. If I want to use it, I have to package it myself or pay some third party to do it. That is fair, not crazy onerous in at least some cases, and gets me - as a consumer of that code - closer to it and more responsible for its use. The supplier is then the first contact for security issues since they are delivering the software. They can fix it directly, upstream a patch, or try to convince the author to fix it. The most successful suppliers will be the ones that submit the most patches because authors will find them easier to work with. So my wild theory here is, if you have a super popular package, continue publishing the source and just totally stop publishing the artifact and see what happens. If it forks, I still see your package as being the upstream that everyone follows since it's actively being worked on. It will create an interesting situation where the delivery is split from the development.
- di4na 4y agoThe reality has not shown that though. There are a lot of packaging mechanisms and all of them have even more problems getting paid.
- Aissen 4y agoI don't understand, this paperwork machine should be the inflection point we need to finally pay open source maintainers: want supply chain security ? Pay $Xk per year per form you want me to fill. Multiply this by every company and no open source maintainer that wants to go full time should need another day job. What if I don't want to do full time open source ? Simple, pass these "form-filling" responsibilities to another friendly open source maintainer. No need to change licenses, ownership, etc.
- simne 4y agoI'm disagree with author, but must say, he talking about really important things. Yes, in freedom world, one have freedoms and rights, to choose irresponsibility, coding just for fun, etc. But right solution here, not to just think all same level of responsibility (or irresponsibility) but to consider right to irresponsibility, and just avoid to use code/data from irresponsible authors, if important. So I think, nearest time will appear some responsible's list (or irresponsible, read more). This is not easy, but, unfortunately, ALL MODERN WORLD built on reuse of ready made pieces of knowledge and technology. Share of reused pieces is huge. So we MUST make some database (accurate and actual), from which people could get info if some piece of software (data) is supported, or find supported alternatives. Who will pay for such database is hard question, from my exp, looks like this will slowly evolve from local (private) initiatives, to once country level or EU/OON wide db(s). Because, with current unknown state, risks extremely high. And other people also have rights and freedoms, and many of them making significant free contribution to overall wealth, so it is not honest to leave them without support at all.