14 ms·

There is no “software supply chain”

252 points by xena 4y ago

gjvc 4y ago
The word these thought leaders are looking for is "provenance", which is not marketing-friendly and they are too scared that this will have people reaching for the dictionary or worse, ignoring them, so they resort to existing terms.
- jacques_chester 4y ago
  Provenance is fine. People use it, particularly in narrow settings around the literal provenance of software assets. I have been in this space for a while and I have come across zero arguments that "provenance" should be ditched due to dictionary obstacles.
  - gjvc 4y ago
    You won't have come across those arguments. They are had by marketing types.
    - int_19h 4y ago
      Why would marketing even care about any of that?
arberx 4y ago
The author is taking the term too literally. Try explaining software packaging and distribution to a non-technical person. Using analogies like "software supply chain" helps people better frame a problem/concept in their heads.
- mind-blight 4y ago
  Agreed. There are some interesting points made in the last third of the article, but the rigid interpretation in the beginning doesn't add anything to them. If the author scraped the title and just focused on how they are large companies attempting to force their will on open source maintainers to protect their supply chain, they'd have a stronger piece.
- 3np 4y ago
  I think the author is rather raising the issue that this analogy gives people false expectations since they take it too literally. I don't think this post would have been made (and certainly not frontpaged) if this was just semantic pedantry.
- worik 4y ago
  Not just "too literally" but outright incorrectly. "A supply chain is a network of individuals and companies who are involved in creating a product and delivering it to the consumer. Links on the chain begin with the producers of the raw materials and end when the van delivers the finished product to the end user. " https://www.investopedia.com/terms/s/supplychain.asp https://www.investopedia.com/terms/s/supplychain.asp The exchange of money, guarantees, quality assurance... None of it is required.
  - nrmitchi 4y ago
    Further, the apparently requirement for "money to change hands" falls flat on it's face. The last node in the supply chain for virtually any real-world product is "human beings extract the material from the earth in some way/shape/form". No human being paid "the earth" money for this, yet it is a fundamental component of supply chains (and, recently, a fundamental component of many supply chain issues). "The earth" also doesn't offer any guarantees or quality assurance. Attempting to interpret these processes as requirements to be part of a "supply chain" excludes the core foundation of traditional supply chains.
  - ectopod 4y ago
    It's investopedia. The exchange of money is taken as read. You might as well say that a vendor of exotic fish not mentioning water is proof that the fish don't need it.
    - worik 4y ago
      I am used to investopedia. The exchange of money is not "taken as read"
- vngzs 4y ago
  I mostly agree with the article, but the title is downright wrong. Even a relatively literal read of the words "supply chain" is reasonably appropriate, even for FOSS. Wikipedia's current definition for supply chain is: > In commerce, a supply chain refers to the network of organizations, people, activities, information, and resources involved in delivering a product or service to a consumer. There's nothing in that definition that necessitates a formal agreement, support commitment, etc.
rtsdumdftub 4y ago
so publish on your own platform then? don't expect to get to publish on someone else's platform then not play by their rules regarding how published material is handled.
jacques_chester 4y ago
This article is hyperbole. Everyone involved knows that it's an imperfect metaphor, but that is in the nature of metaphors. Referring to the metaphor as "dehumanizing" is just silly.
verisimilitudes 4y ago
>You still cannot disable pull requests on a GitHub repository. >I just want to publish software that I think is neat so that other hobbyists can use and learn from it, and I otherwise want to be left the hell alone. Don't use GitHub. I don't. Random dipshits aren't even aware of me. >To continue the inclusive nature of open source, we need to be able to trust a wide range of identities, but still with verified integrity. This implies a federated model for identities, perhaps similar to how we support federated SSL certificates today Oh yes, of course Google supports TLS-flavoured snake oil to match the TLS snake oil. I'm shocked MicroSoft is extending open source after embracing it so well, shocked. I'm now recycling a previous comment of mine on this topic: Companies used to have employees write code, rather than stitch together random garbage written by random dipshits who could be tricked into using loose licenses. That's one cause for concern. The only reason open source receives support is because it helps corporations defang Free Software and get gratis labor. All of this new security theatre is always about trust and reputation, and not trusting those disgusting lone programmers such as me or other silly things; it's always really about doing anything but truly auditing that yucky code.
pid-1 4y ago
This sort of term is made up by c suites for c suites, arguing about semantics is rarely productive and I'm inclined to believe that's the case here. I also think this battle is lost as GH and others will always yeld to the needs of folks that atually bring money to their business. "Pure hobbist FOSS" mantainers likely need to start a Wikipedia ish non profit for software hosting or think about something else.
- jacques_chester 4y ago
  Maybe Github and repository maintainers care about society at large. If the bet could be objectively settled I'd happily stake my entire savings on the question, because I've already talked to the folks making those decisions.
  - Terretta 4y ago
    I'd hazard an inability to imagine oneself as "not the main character", to recognize that a majority likely have other priorities, causes a sizable share of debates on HN. It's the opening question in PG's essay linked today.
- msla 4y ago
  > This sort of term is made up by c suites for c suites, arguing about semantics is rarely productive and I'm inclined to believe that's the case here. That's the point of the article, yes. It's about the mismatch of expectations and behaviors between C suite, which expects every business to do its duty on pains of lawsuit, and hobbyist FOSS programmers, who don't see themselves as in business and who have less than zero duty to FrobnitzWare/Invisible Corporation kabushiki gaisha LLC Limited AG despite the fact that August Corporate Personage decided to base Essential Business Processes on their work. I mean, fundamentally, the programmers are in the right, in that the company cannot, in point of fact, rely on a contract it never drew up or got anyone to sign, but the companies will do the legal equivalent of holding their breath and stamping their feet and this is something people will, every so often, write blog posts about. Heck, maybe, just this once, a blog post will inform some C suite suits about the power gradient here (corporations: none, rando programmers: quite a bit, in fact) and maybe nudge some of them to, maybe, not make software that collapses when left-pad's author has another Big Idea.
lesuorac 4y ago
The could be a supply chain though. I had a running joke at a place I used to work that I should just quit and start my own US based company that "sold" open-source software so that it'd have a US-flagged company behind it. IMO easy way to branch out to commercial instead of just government contracts would be to audit the source code. Probably save a few companies from a left-pad incident (or worse) since they'd have to pull from my servers (or cache mine) and I'm smart enough to recognize that updating leftpad to be nothing would not be helpful to any client
- yardie 4y ago
  > start my own US based company that "sold" open-source software so that it'd have a US-flagged company That is the business model for Redhat, Ubuntu, SUSE, and other GNU/Linux companies. You can download it for free or pay a subscription to have emails and phonecalls answered.
  - danjoredd 4y ago
    You can download Red Hat for free, but you won't be able to use it without registering. Rocky Linux has done a good job of making a free Red Hat though. Been using it for my RHCSA recently
    - supernovae 4y ago
      Developer RHEL doesn’t cost any money. RHEL is based on Centos Stream and Stream comes from Fedora.
  - lesuorac 4y ago
    The difference is really I wouldn't be developing any of the software. I'm literally selling things you can get off of say GitHub. Although I'd probably need to not be completely blunt about it. It'd just be mostly an open secret where any of the dev teams would know that's exactly what I'm doing (and any sort of LICENSE file would make it dead obvious) but to procurement and whatnot it just looks like you're funneling money to me in exchange for some software.
- 4y ago
mikewarot 4y ago
The author of an open source project usually makes NO guarantees and assumes no liability. They've tossed a blueprint into the world. When you decided to use it, you took on all of its technical debt and design decisions as your own. You can't fault the author if you use it in an environment they didn't have, or didn't intend it to be used in, or in a manner that wasn't intended. They left an artifact, they did NOT make an agreement to support it. If someone makes a mistake in a book, there's no obligation for the author to correct it. If someone misunderstands the ideas and goes on to do some horrible deeds using it as justification, it's not the author's fault. Open source software is, for the most part, an unsupported gift economy. It isn't commercial, and it certainly isn't a chain... there's no delivery to be had... something was tossed over the wall, and it may never happen again. We Tims have been waiting for the next episode of Hello Internet for a while now... it may never come. That is also the nature of open source software.
- j-bos 4y ago
  We the Tims accept this fact and stand waiting.
- danjoredd 4y ago
  RIP Hello Internet. Cortex is great, but it just isn't the same. Grey always said he would probably take the Irish Exit on that show, and that's exactly what he ended up doing
- hinkley 4y ago
  This is a historically narrow view of the situation. We are all living in a post-war era. That war was over whether and how much of the software in the world should be locked up behind proprietary licenses and paywalls. To win the war, Open Source had to produce software that was less awful than the proprietary software it was trying to unseat. It did. Companies went out of business or adapted. Now everyone is trying to pretend that the choice all along was between someone else's software and making your own. That wasn't the choice, and it's revisionist history to claim otherwise. A war was one, territory was occupied, and the 'treaty' at the end of that war was "make stuff that isn't awful", which is being peeled away layer by layer. The above is the opening to my thesis as to why SaaS is now trying to eat Open Source: FOSS is abdicating responsibility for quality, and so the only way to get quality is to harass FOSS authors who think we are ungrateful whiners, or pay for improvements on the backs of paying customers who just want software that works, not to be told to put up or shut up. The only sane way to defend against the re-privatization of FOSS software is to stop treating your users like they need to grow up and realize that you're deflecting. Unless authors accept that you have an ethical responsibility that comes with occupying a corner of the collective consciousness, it's going to be walled gardens everywhere you look. We aren't paying people to 'steal' your code. We're paying people to act like professionals.
yardie 4y ago
I've heard of software pipelines and software dependency but this is the first I've ever heard of software supply chain. I don't think the metaphor is apt. Dependencies are fungible you can branch, tag, freeze, lock, etc whatever your requirements are and continue trucking along. Physical Supply chains are not that at all. In some cases you literally cannot go back to the previous revision ever again.
- jacques_chester 4y ago
  Physical supply chains are full of fungible products such as wheat, pork bellies or gold. Such products are what the word "fungible" was first used to describe.
- Tangurena2 4y ago
  After the Log4J vulnerability, people started using the term "software supply chain". I think this comic demonstrates the "problem": https://xkcd.com/2347/ https://xkcd.com/2347/
zokier 4y ago
> There is no formal agreement between a maintainer and its downstream users. But there usually is, that is what software licenses are for, with typical statements like > THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT
- hot_gril 4y ago
  Maybe the annoyance comes from releasing software with no license.md or a license that says "DO WHATEVER THE F--- YOU WANT WITH THIS S---" then getting a bunch of corporates saying it's not properly licensed while a bunch of "free as in freedom" people are complaining that the license isn't free as in freedom enough.
  - hot_gril 4y ago
    (In which case, I propose a new slogan, "don't tread on my crap.")
    - peteradio 4y ago
      "I dare you to use this."
  - hedora 4y ago
    The WTFPL is FSF-approved enough for me: http://www.wtfpl.net/faq/ http://www.wtfpl.net/faq/
    - hot_gril 4y ago
      Big corps can't use WTFPL-licensed software, at least the one I work at.
zokier 4y ago
I do feel its indicative that most of the authors issues stem from GitHub, the facebook of foss, big social media for coders. If you don't want to engage with the social trends and aspects of the ecosystem (which is perfectly understandable) then GH seems particularly poor choice of platform to publish your software on. I feel the author would have far better chance of "to be left the hell alone" if they chose literally any other platform.
- nyanpasu64 4y ago
  Not the author, but I wouldn't say it's just (or even primarily) Github's pull requests or "critical security advisory" that's the problem here. PyPI requiring 2FA for maintainers of popular software has had more real-world impact (one maintainer took down and recreated their project, erasing old releases), and Google calling for deanonymizing (doxxing) maintainers of open-source software is more terrifying. I'd argue that the problem isn't that "software supply chains do not exist", but "you using a program or library without pay does not and should not mean the software's author is now responsible for fulfilling your use cases and paperwork requirements".
- colinsane 4y ago
  iliana is an active Mastodon/Activity Pub user, so surprisingly apt metaphor and probably a fair assessment.
wongarsu 4y ago
If you want a software supply chain that includes formal agreements, use Java or C#, or maybe C++. Those ecosystems have plenty of vendors who will sell you libraries, including phone support and liability. So far enterprises are the only ones willing to pay for their "software supply chain", if you want this kind of "solution" just use what they use.
- bob1029 4y ago
  The sensitive nature of our business forced the equation for us. We are basically a pure Microsoft shop because it makes survival of audits feasible. 100% of our B2B clients are already doing business with them, so the conversation is fairly simple.
awinter-py 4y ago
interesting points xie is making: 1) it's not a supply chain bc no money is changing hands, 2) therefore no contracts or enforcement, 3) many market participants are hobbyists I think this speaks to the fundamental weirdness of the information economy -- it's highly deflationary, with some extreme cases where hobbyists outperform paid software companies Hobbyists + open groups beat companies in cases where IP concerns makes the software worse, like if they're making something a saas that should be a 100-line library. And also in cases where everyone in industry needs a thing and they're happy to have a great standard free one rather than paying three shitty vendors. I don't know this, but I think a chunk of major OSS projects are maintained by people at big companies or universities. (Postgres may have been associated with fujitsu for a while, guido van rossum + linus torvalds parked in various companies, some fraction of kube committers are at bigcos or corporate-backed CNCF). I have nadia eghbal's 'building in public' on my list to read, guessing she knows the answer to this question.
0xbadcafebee 4y ago
"I just want to publish software that I think is neat so that other hobbyists can use and learn from it, and I otherwise want to be left the hell alone. I should be allowed to decide if something I wrote is “done”. The focus on securing the “software supply chain” has made it even more likely that releasing software for others to use will just mean more work for me that I don’t benefit from. I reject the idea that a concept so tenuous can be secured in the first place." K. The rest of us are gonna keep using the phrase though.
hot_gril 4y ago
Am I missing some background? Author gives out software "WITHOUT WARRANTY" and can just ignore PRs etc. Why is the author complaining?
- falcolas 4y ago
  > "WITHOUT WARRANTY" Liability disclaimers are a legal grey area. Even the US pulls aside some developers at customs because of their work on OSS projects. Imagine what some of the least tolerant countries do.
  - hot_gril 4y ago
    Yeah, but that doesn't seem to be the complaint here. It's more about GitHub's workings.
- q-big 4y ago
  > and can just ignore PRs This complaint is in my opinion rather specific to GitHub (and could thus likely be solved by switching to a more repository provider, or hosting the repository oneself), but not being able to disable PRs at your own repositories is like having a blog hosted by a provider that does not offer the option to disable blog comments.
  - hot_gril 4y ago
    Eh, sounds like a really minor annoyance. It's clear that the PRs aren't your own content, unlike comments which you're sorta responsible for moderating or else you'll often end up with vile stuff all over your family-friendly blog post.
    - q-big 4y ago
      > It's clear that the PRs aren't your own content, unlike comments which you're sorta responsible for moderating. I see this differently: you have some own content * a blog post * a Git repository that is hosted by some provider. "Everybody" can add their own "scribblings" next to it: * comments * PRs In both cases it is clear that these "scribblings" are not your own content. Why do you thus make the difference that in one case one is some kind of responsible for moderating, but not in the other case?
numbsafari 4y ago
When, for example, Google open sources their client libraries, it absolutely is a supply chain issue for their customers. The people working on those projects for Google aren’t doing it as a hobby. Their customers might not be paying them directly for those client libs, but they sure as heck are being billed at some point.
marssaxman 4y ago
> A package repository might deem your software “critical”, adding requirements to publishing updates that you might not want to or be able to comply with. I discovered last week that Github no longer allows you to push changes via https, and thus I have not yet published a minor fix for an insignificant piece of open source software I have been lackadaisically maintaining for the last eight years. Perhaps some day I will get around to jumping through their new security hoops... or perhaps I won't. In this case nobody is likely to care, but it makes me think these kinds of organizations ought to be extremely cautious about introducing extra friction to the workflows of people who are giving away their time for free.
- TheRealPomax 4y ago
  Not sure I understand how having an ssh key is "jumping through hoops" though...? Presumably you already have one set up (even if you don't, it's literally just a few seconds of work to create a new one), so just add the public key to your account's SSH keys list, and done. Update your remote urls from https to the git@github.com:yourusername format and push whatever you want to push. Or, heck, if no build is required: why use git at all, just use github itself. You can edit, create PRs, on new branches, all without ever needing your own desktop. Perfect for small code changes (especially typo fixes).
- XorNot 4y ago
  Pushing via HTTPS is the only way I use GitHub, so I find this claim questionable. It's working fine for me.
  - marssaxman 4y ago
    Huh! I wonder why your experience is different. I get this error: remote: Support for password authentication was removed on August 13, 2021. remote: Please see https://docs.github.com/en/get-started/getting-started-with-git/about-remote-repositories#cloning-with-https-urls for information on currently recommended modes of authentication.
    - 4y ago
otikik 4y ago
I respectfully disagree with the author. Once you put stuff on someone else’s servers, they can do whatever they want to the package as long as it doesn’t break the license. That includes marking the package as critical or even making a fork the canonical repo. If you want that kind of control, you need to become your own package provider. Or distribute your code with a more restrictive license.
ineedasername 4y ago
This is just nitpicking over the fact that a specific metaphor doesn’t map 1-to-1 with the target domain. No metaphor does, that’s not the point of using one. The metaphor in this case is pretty straightforward as are its limits, and it doesn’t appear to be causing confusion with people misidentifying attributes of the metaphor that don’t map to the software domain. (And to boot: there are actual software supply chains with a traditional supplier/vendor relationship…)
- q-big 4y ago
  > The metaphor in this case is pretty straightforward as are its limits, and it doesn’t appear to be causing confusion with people misidentifying attributes of the metaphor that don’t map to the software domain. One of the central points that the author makes is that this is in his opinion not true, and he provides evidence for this.
__derek__ 4y ago
The post's definition of 'supply chain' is wrong, and it leads to confusion. If I forage for mushrooms and give them to a local chef, I'm part of the supply chain for that night's dinner, even without money changing hands or quality guarantees. That said, to opt out of companies' supply chains, stop publishing software with permissive licenses.
- JohnFen 4y ago
  I'm certainly not going to stop publishing software with permissive licenses. I'll just adhere to the disclaimer I include with that software: I provide no warranty that it is fit for any particular use. Use it as you will, but don't expect any guarantee that I'll support whatever needs your supply chain has.
  - __derek__ 4y ago
    That's the current state that the author considers untenable, right?
    - JohnFen 4y ago
      My read of TFA is that author is complaining that companies are trying to push responsibilities onto FOSS authors that don't belong with the FOSS authors. He includes complaints about Github there, but those are easily resolved by not using Github. I believe that the author and I are on the same page here, generally. Have I misunderstood his essay?
- cbm-vic-20 4y ago
  Or license your work under GPL, which is kryptonite to most businesses. The mega-globo-corp I work for makes commercial license deals with some open source software vendors who dual license their software with GPL and a commercial license.
  - __derek__ 4y ago
    Right. GPL is an example of a non-permissive license.
lrvick 4y ago
I do software supply chain security consulting for several high risk companies and largely agree with this post that we must stop expecting devs to have any responsibility for code they produce. The responsibility is on those that consume it. This will sound pretty harsh, but if your company chooses to use open source code that does not have capable, paid, full time professionals reviewing it for security and quality, then your company is signing up for that responsibility. If you make no reasonable attempt at vetting your supply chain and harm comes to users as a result, then IMO you should be liable for negligence just like a restaurant serving food with poisonous ingredients. Broadly normalized negligence is still negligence. This should not be controversial, but it is. Washing hands in hospitals was once controversial too but those advocating for it had irrefutable evidence on their side. The medical industry did not want to pay the labor cost of hygiene, and we are seeing the same in the software industry. https://www.nationalgeographic.com/history/article/handwashing-once-controversial-medical-advice https://www.nationalgeographic.com/history/article/handwashi... Ask yourself if it cheaper to fully review, sign, compile, and maintain third party OSS code or to write something in-house focused on your needs on top of the standard library. Pick one. Both are real options. Some of my clients actually do (or pay others for) security review of every single NPM dependency they use in prod. If you can not afford to review 2000 dependencies then you can not afford 2000 dependencies. Find a leaner path. Companies must stop expecting others to do their software review job for them. OSS devs already wrote the code for free because, ostensibly, it was fun. You are an ass if you ask them to do anything that is not fun, for free, to make your company safer or more money. Such actions make it not fun anymore, and make them stop entirely. I do not know why companies have code review policies for code written by peers, but if the code is 2 million lines of NPM dependencies essentially copy/pasted from randos on the internet it is suddenly okay to ship straight to prod and give said randos full control of the data or property of millions of people. We need to start calling this out as the negligence that it is.
- ahtihn 4y ago
  > Ask yourself if it cheaper to fully review, sign, compile, and maintain third party OSS code or to write something focused on your needs on stop of the standard library yourself. Why stop at the standard library? What about the rest of the language toolchain? Compilers, interpreters. What about the OS?
Crontab 4y ago
> The author of an open source project usually makes NO guarantees and assumes no liability. That's pretty much true of commercial software as well.
r3trohack3r 4y ago
There are several forms of OSS and it seems people often conflate them. There is: * "open source as a reference" * "open source as a line item" * "open source as a funnel" It seems like our industry favors line item OSS. Personally, I think the other two are far more useful. Line item OSS productizes a high-value project inside a company and releases it publicly for no charge. The goal of open sourcing is generally to steer the industry in a direction compatible with your company's architecture. Often times companies are trying to: * Cultivate engineering talent trained on their architecture that they can hire in the future * Increase maturity of their software stack by exposing it to environments outside their current architecture * Recruit maintainers to drive down the cost of maintaining an internal pattern * Cultivate an ecosystem of plugins and modules they can rely on for future engineering projects * Cultivate good will in the developer community as a recruiting/dev-rel tactic * etc. Line-item OSS projects typically carry a high cost, they don't just become successful when you push to a public repository. These projects require devrel presence to meet 3rd party engineers where they are (conferences, blogs, documentation, branding, logos, news aggregator sites, etc.). They require maintainers to mentor 3rd party engineers through pull requests and issues. You have to navigate community building with codes of conduct, boards, foundations, etc. This all requires salaried employee's time. This high cost raises the bar for contributing to the commons: the return has to cover the salaried time spent on open sourcing the project. If the return doesn't cover your investment, ROI is negative and you're expecting companies to contribute for charity. What's worse is that failing on a line item OSS project often results in the opposite of what you want: a perception that your company is bad at OSS or not a great community participant. Every line item OSS project is a high-cost bet carrying risk to your reputation. Open source as a reference, in contrast, is closer to publishing a conference paper. You describe how you are doing something, publish the source code as a reference, and call it a day. No community building. You don't commit to merging random PRs. You don't commit to fielding questions on issue trackers. It's a statement that what you are doing is working for you, that other engineers might benefit from similar patterns, and a jump start for motivated engineers to figure out how to apply the pattern themselves. You're contributing to the commons under a permissive license for the cost of a conference road show and a "cleanup" of the code to ensure you aren't leaking anything sensitive in your SCM history. I feel a lot more software would make it into the commons if we normalized this form of OSS. "Open source as a funnel" is probably the most sustainable OSS model IMH(umble)O. "OSS funnel projects are associated with a vendor that sells services and products in that ecosystem. The services are particularly useful for companies building on top of OSS. If you are a small-ish org, every dependency you're bringing in is a pretty big risk. You have to have internal talent capable of maintaining the entire software stack. "OSS as a line item" and "OSS as a reference" do not give you any guarantees from the project. The maintainers aren't your employees and they owe you nothing. You often have no way to pay maintainers to solve your problems. A show stopper bug in those projects can bury your company. In contrast, "OSS as a funnel" has a vendor you can reach out to for consulting/contracting services to elastically scale out your engineering org for bugs in the stack. In the Node.js ecosystem, NearForm is a great example IMHO. They are maintainers on a pretty large catalogue of software (i.e. fastify). You can bring that into your architecture knowing that, if you end up blocked on a bug your team doesn't have the expertise to solve, you have a vendor you can reach out to and pay to solve your problem. Sometimes line item OSS projects foster an ecosystem of vendors which in turn checks the OSS as a funnel box. For example, with GraphQL and React, you can't pay Facebook but someone out there will take your money to solve your problems. I do consulting/contracting in the Node.js space and, when I bring modules into my client's architecture, having a vendor associated with the module is front-of-mind for me. I know I'm not leaving them with technical debt they have no way out of if something goes sideways. They always have me and they have a 3rd party vendor they can reach out to as well.
kazinator 4y ago
> You still cannot disable pull requests on a GitHub repository. A package repository might deem your software “critical”, adding requirements to publishing updates that you might not want to or be able to comply with. Google even wanted to disallow anonymous individuals from maintaining critical software and wanted to police the identities of others. That's just whining from people who host their stuff on other people's servers and sites. If other people package your software into a bigger system and then later improve their standards so that the bar is above your stuff now (e.g. you break it left and right with careless, untested changes, or whatever, whereas downstream is doing actual QA) that's downstream's prerogative. You don't have to do anything; they can fork your stuff and develop it themselves, or stick with the old version from you that worked, ignoring the newer releases.
- LtWorf 4y ago
  The problem is that they don't fork it. Instead they harass you.
  - kazinator 4y ago
    People should give that a good try; maintaining forks sucks. In the past I've forked at the sign of any resistance. I have a fork of GNU Awk called Enhanced GNU Awk (egawk). https://www.kylheku.com/cgit/egawk/about/ https://www.kylheku.com/cgit/egawk/about/ It has a let construct for lexical variables. Chances are it's not packaged for your favorite OS, so you'd have to build it yourself. The next thing on the plate for that project is to support the GNU C preprocessor line annotations so that if Egawk is handed preprocessed code, it will report errors against the original file and line number.
khana 4y ago
JohnFen 4y ago
> I just want to publish software that I think is neat so that other hobbyists can use and learn from it, and I otherwise want to be left the hell alone. Me, too. Which is why I pretty much abandoned the formal "OSS" world and don't use Github and the like. I still make software, I still provide a free license for anyone to use it, and I'll even maintain it for as long as it interests me. But it's a hobby, not a job. If someone uses my software commercially, it's on them to make sure that it's properly maintained. They have the source, they can do it.
gumby 4y ago
There's a business opportunity here for making a "slow copy" of npm (or PyPI or whatever): start with a copy and then just only upgrade packages after you've checked the changes. You could sign and manage the BOM, perhaps even ensuring that $BIG_ENTERPRISE only got the versions they had asked for no matter what request they make (oh, sorry for the dev trying to get their job done -- go ask IT).
ChrisMarshallNY 4y ago
In my case, I basically never use anyone else's code, unless there's a real need for it, and if I'm quite confident in its veracity. I also take full Responsibility and Accountability for that code, when it is running in my execution thread. The result of this policy, is that I have written almost every single dependency that I use. It has garnered me a lot of sneers from the "in crowd." I don't particularly care. WFM. YMMV. [EDIT] Also, I like this: my name is always spelled lowercase and is pronounced /ɪliˈɑnə ɛˈtiːn/. please consider making the internet a weirder place today note: if you send me unsolicited email based on my github profile: i will screenshot it and share in my discord server we will make fun of you you will not receive a response*
- wbobeirne 4y ago
  I'm not trying to be flippant, but where do you draw the line of "never use anyone else's code"? You're writing that software using an operating system and editor someone else wrote. You're compiling it with software someone else wrote. If you're deploying it to users, it's hosted on someone else's code and will be run by someone else's code in that runtime.
  - tomjakubowski 4y ago
    OP claims responsibility for code when it is running in my execution thread. That seems to be the boundary. So no need to write their OS, though maybe their own interface for making syscallz.
  - ChrisMarshallNY 4y ago
    I know. That's the classic argument that I get. Basically "what about..?" Like I said, I know what works for me. I'm not gonna argue about it. I do know that some find my stance offensive, which I don't actually understand. I'm not attacking anyone. I'm just saying how I do it, in my own work. I write lots of packages that I integrate into my own work. Each package is a standalone project, with tests and docs. Because they are written and maintained by a single person, I know that some folks believe this makes them "worthless," but not to me. It's the way that I work, on my own stuff. I'm not competing with anyone here, so I fail to see the problem. If I'm just some clueless old boomer, making a hash of things, then God bless my little heart, and I'll just be tilting at windmills, over here.
asimpletune 4y ago
So fwiw I think the whole concept of the "software supply chain" actually stems from "supply chain" attacks. It's kind of like once that turn of speech entered the fray, suddenly there was a software supply chain (for OSS).
Waterluvian 4y ago
If you want or need support or maintenance for my project in your business, offer me cash. If your first thought is, “hah, as if finance would ever green light that…” then I encourage you to fork it and tell your manager it will cost your company two to three times as much to do it yourself. I think both are perfectly valid options. Just make informed decisions and in doing so, demonstrate business competence.
- eastbound 4y ago
  I sell both my software as OSS, and as commercial software with a delivery through a corporate appstore. Companies are happy to pay.
_8j50 4y ago
I must disagree. Software supply chain is very different than supply chain of physical goods, but, it is still a chain of supplies in the form of software code. Looking at it strictly from an open source perspective is having too narrow of a focus. If I purchase O365 licenses from a reseller and they buy it from Microsoft, that's a supply chain. If I have an embedded system that has a proprietary OS made by a 3 person company who use a proprietary firmware from other vendors, that is a supply chain. The npm example is a good example of a convoluted and unreliable supply chain. OSS is an example of a supply chain that is by design unreliable, the suppliers disavow all responsibility to support or guarantee its features. OSS supply chain being unreliable does not mean the supply chain does not exist, it just means you have to compensate for the unreliability yourself. The real life equivalent would be sourcing materials from guys standing at a street corner selling stuff that "fell off a truck" or "made in their garage".
franciscop 4y ago
The author is being even too polite IMHO, since there IS a "contract" (legal working agreement, or license) when involving open source. And it CLEARLY stipulates, usually even in capital letters, exactly what the author is conveying in the article! That the software is "as-is" and you should not expect -let alone demand- anything from authors. Anything beyond that is good will from open source authors, which historically has varied wildly from project to project. I fully agree with the author though; it was even funnier when NPM sarcastically blamed me for losing my password on the reset screen, since it was THEM who lost their users passwords and force-reset them all, so now I had to reset my password, forced to use 2FA and being mocked while doing all of that ONLY to be able to share my work for free with the world. I was very, very close to say fuck NPM I'm out, unfortunately they have a de-facto monopoly.
thenerdhead 4y ago
I personally like the metaphor (but then again I work on a major package manager). I like to think of it this way... - we download code - from the internet - written by unknown individuals - that we haven't read - which we execute - with full permissions - on our trusted devices - where we keep our most important data (someone wrote this that I found in the SSC space) Given a supply chain attack can happen at many of those steps above, but is also extended to source code, build systems, and production services, it's a great metaphor for visualizing the complex "software supply chain".
bern4444 4y ago
I've seen the case made that engineers who develop FOSS don't want to be paid for their work specifically because once they accept payment they feel a stronger obligation to maintain the software and respond to issues from those paying entities rather than focusing on the issues they want to or generally doing work as they see fit. We all use FOSS - its one of the most unique aspects of software engineering compared to other industries IMO. The world would literally not have advanced nearly as far without it. I'm incredibly grateful to work in a field that views FOSS maintainers so well and thankful to the FOSS for all the incredible and fun technology I get to use everyday.
SergeAx 4y ago
In fact, it's just as simple as that: every package today has a license. If the license says that the author has no responsibility and liability for it - so it is. If the package has no license - you cannot use it in commercial software anyway.
goodpoint 4y ago
168 comments and nobody pointed out the role of Linux distributions...
hushpopote 4y ago
V

252 points by xena 4y ago

gjvc 4y ago

The word these thought leaders are looking for is "provenance", which is not marketing-friendly and they are too scared that this will have people reaching for the dictionary or worse, ignoring them, so they resort to existing terms.

jacques_chester 4y ago
Provenance is fine. People use it, particularly in narrow settings around the literal provenance of software assets. I have been in this space for a while and I have come across zero arguments that "provenance" should be ditched due to dictionary obstacles.
- gjvc 4y ago
  You won't have come across those arguments. They are had by marketing types.
  - int_19h 4y ago
    Why would marketing even care about any of that?

arberx 4y ago

The author is taking the term too literally. Try explaining software packaging and distribution to a non-technical person. Using analogies like "software supply chain" helps people better frame a problem/concept in their heads.

mind-blight 4y ago
Agreed. There are some interesting points made in the last third of the article, but the rigid interpretation in the beginning doesn't add anything to them. If the author scraped the title and just focused on how they are large companies attempting to force their will on open source maintainers to protect their supply chain, they'd have a stronger piece.
3np 4y ago
I think the author is rather raising the issue that this analogy gives people false expectations since they take it too literally. I don't think this post would have been made (and certainly not frontpaged) if this was just semantic pedantry.
worik 4y ago
Not just "too literally" but outright incorrectly. "A supply chain is a network of individuals and companies who are involved in creating a product and delivering it to the consumer. Links on the chain begin with the producers of the raw materials and end when the van delivers the finished product to the end user. " https://www.investopedia.com/terms/s/supplychain.asp https://www.investopedia.com/terms/s/supplychain.asp The exchange of money, guarantees, quality assurance... None of it is required.
- nrmitchi 4y ago
  Further, the apparently requirement for "money to change hands" falls flat on it's face. The last node in the supply chain for virtually any real-world product is "human beings extract the material from the earth in some way/shape/form". No human being paid "the earth" money for this, yet it is a fundamental component of supply chains (and, recently, a fundamental component of many supply chain issues). "The earth" also doesn't offer any guarantees or quality assurance. Attempting to interpret these processes as requirements to be part of a "supply chain" excludes the core foundation of traditional supply chains.
- ectopod 4y ago
  It's investopedia. The exchange of money is taken as read. You might as well say that a vendor of exotic fish not mentioning water is proof that the fish don't need it.
  - worik 4y ago
    I am used to investopedia. The exchange of money is not "taken as read"
vngzs 4y ago
I mostly agree with the article, but the title is downright wrong. Even a relatively literal read of the words "supply chain" is reasonably appropriate, even for FOSS. Wikipedia's current definition for supply chain is: > In commerce, a supply chain refers to the network of organizations, people, activities, information, and resources involved in delivering a product or service to a consumer. There's nothing in that definition that necessitates a formal agreement, support commitment, etc.

rtsdumdftub 4y ago

so publish on your own platform then? don't expect to get to publish on someone else's platform then not play by their rules regarding how published material is handled.

jacques_chester 4y ago

This article is hyperbole. Everyone involved knows that it's an imperfect metaphor, but that is in the nature of metaphors. Referring to the metaphor as "dehumanizing" is just silly.

verisimilitudes 4y ago

>You still cannot disable pull requests on a GitHub repository. >I just want to publish software that I think is neat so that other hobbyists can use and learn from it, and I otherwise want to be left the hell alone. Don't use GitHub. I don't. Random dipshits aren't even aware of me. >To continue the inclusive nature of open source, we need to be able to trust a wide range of identities, but still with verified integrity. This implies a federated model for identities, perhaps similar to how we support federated SSL certificates today Oh yes, of course Google supports TLS-flavoured snake oil to match the TLS snake oil. I'm shocked MicroSoft is extending open source after embracing it so well, shocked. I'm now recycling a previous comment of mine on this topic: Companies used to have employees write code, rather than stitch together random garbage written by random dipshits who could be tricked into using loose licenses. That's one cause for concern. The only reason open source receives support is because it helps corporations defang Free Software and get gratis labor. All of this new security theatre is always about trust and reputation, and not trusting those disgusting lone programmers such as me or other silly things; it's always really about doing anything but truly auditing that yucky code.

pid-1 4y ago

This sort of term is made up by c suites for c suites, arguing about semantics is rarely productive and I'm inclined to believe that's the case here. I also think this battle is lost as GH and others will always yeld to the needs of folks that atually bring money to their business. "Pure hobbist FOSS" mantainers likely need to start a Wikipedia ish non profit for software hosting or think about something else.

jacques_chester 4y ago
Maybe Github and repository maintainers care about society at large. If the bet could be objectively settled I'd happily stake my entire savings on the question, because I've already talked to the folks making those decisions.
- Terretta 4y ago
  I'd hazard an inability to imagine oneself as "not the main character", to recognize that a majority likely have other priorities, causes a sizable share of debates on HN. It's the opening question in PG's essay linked today.
msla 4y ago
> This sort of term is made up by c suites for c suites, arguing about semantics is rarely productive and I'm inclined to believe that's the case here. That's the point of the article, yes. It's about the mismatch of expectations and behaviors between C suite, which expects every business to do its duty on pains of lawsuit, and hobbyist FOSS programmers, who don't see themselves as in business and who have less than zero duty to FrobnitzWare/Invisible Corporation kabushiki gaisha LLC Limited AG despite the fact that August Corporate Personage decided to base Essential Business Processes on their work. I mean, fundamentally, the programmers are in the right, in that the company cannot, in point of fact, rely on a contract it never drew up or got anyone to sign, but the companies will do the legal equivalent of holding their breath and stamping their feet and this is something people will, every so often, write blog posts about. Heck, maybe, just this once, a blog post will inform some C suite suits about the power gradient here (corporations: none, rando programmers: quite a bit, in fact) and maybe nudge some of them to, maybe, not make software that collapses when left-pad's author has another Big Idea.

lesuorac 4y ago

The could be a supply chain though. I had a running joke at a place I used to work that I should just quit and start my own US based company that "sold" open-source software so that it'd have a US-flagged company behind it. IMO easy way to branch out to commercial instead of just government contracts would be to audit the source code. Probably save a few companies from a left-pad incident (or worse) since they'd have to pull from my servers (or cache mine) and I'm smart enough to recognize that updating leftpad to be nothing would not be helpful to any client

yardie 4y ago
> start my own US based company that "sold" open-source software so that it'd have a US-flagged company That is the business model for Redhat, Ubuntu, SUSE, and other GNU/Linux companies. You can download it for free or pay a subscription to have emails and phonecalls answered.
- danjoredd 4y ago
  You can download Red Hat for free, but you won't be able to use it without registering. Rocky Linux has done a good job of making a free Red Hat though. Been using it for my RHCSA recently
  - supernovae 4y ago
    Developer RHEL doesn’t cost any money. RHEL is based on Centos Stream and Stream comes from Fedora.
- lesuorac 4y ago
  The difference is really I wouldn't be developing any of the software. I'm literally selling things you can get off of say GitHub. Although I'd probably need to not be completely blunt about it. It'd just be mostly an open secret where any of the dev teams would know that's exactly what I'm doing (and any sort of LICENSE file would make it dead obvious) but to procurement and whatnot it just looks like you're funneling money to me in exchange for some software.
4y ago

mikewarot 4y ago

The author of an open source project usually makes NO guarantees and assumes no liability. They've tossed a blueprint into the world. When you decided to use it, you took on all of its technical debt and design decisions as your own. You can't fault the author if you use it in an environment they didn't have, or didn't intend it to be used in, or in a manner that wasn't intended. They left an artifact, they did NOT make an agreement to support it. If someone makes a mistake in a book, there's no obligation for the author to correct it. If someone misunderstands the ideas and goes on to do some horrible deeds using it as justification, it's not the author's fault. Open source software is, for the most part, an unsupported gift economy. It isn't commercial, and it certainly isn't a chain... there's no delivery to be had... something was tossed over the wall, and it may never happen again. We Tims have been waiting for the next episode of Hello Internet for a while now... it may never come. That is also the nature of open source software.

j-bos 4y ago
We the Tims accept this fact and stand waiting.
danjoredd 4y ago
RIP Hello Internet. Cortex is great, but it just isn't the same. Grey always said he would probably take the Irish Exit on that show, and that's exactly what he ended up doing
hinkley 4y ago
This is a historically narrow view of the situation. We are all living in a post-war era. That war was over whether and how much of the software in the world should be locked up behind proprietary licenses and paywalls. To win the war, Open Source had to produce software that was less awful than the proprietary software it was trying to unseat. It did. Companies went out of business or adapted. Now everyone is trying to pretend that the choice all along was between someone else's software and making your own. That wasn't the choice, and it's revisionist history to claim otherwise. A war was one, territory was occupied, and the 'treaty' at the end of that war was "make stuff that isn't awful", which is being peeled away layer by layer. The above is the opening to my thesis as to why SaaS is now trying to eat Open Source: FOSS is abdicating responsibility for quality, and so the only way to get quality is to harass FOSS authors who think we are ungrateful whiners, or pay for improvements on the backs of paying customers who just want software that works, not to be told to put up or shut up. The only sane way to defend against the re-privatization of FOSS software is to stop treating your users like they need to grow up and realize that you're deflecting. Unless authors accept that you have an ethical responsibility that comes with occupying a corner of the collective consciousness, it's going to be walled gardens everywhere you look. We aren't paying people to 'steal' your code. We're paying people to act like professionals.

yardie 4y ago

I've heard of software pipelines and software dependency but this is the first I've ever heard of software supply chain. I don't think the metaphor is apt. Dependencies are fungible you can branch, tag, freeze, lock, etc whatever your requirements are and continue trucking along. Physical Supply chains are not that at all. In some cases you literally cannot go back to the previous revision ever again.

jacques_chester 4y ago
Physical supply chains are full of fungible products such as wheat, pork bellies or gold. Such products are what the word "fungible" was first used to describe.
Tangurena2 4y ago
After the Log4J vulnerability, people started using the term "software supply chain". I think this comic demonstrates the "problem": https://xkcd.com/2347/ https://xkcd.com/2347/

zokier 4y ago

> There is no formal agreement between a maintainer and its downstream users. But there usually is, that is what software licenses are for, with typical statements like > THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT

hot_gril 4y ago
Maybe the annoyance comes from releasing software with no license.md or a license that says "DO WHATEVER THE F--- YOU WANT WITH THIS S---" then getting a bunch of corporates saying it's not properly licensed while a bunch of "free as in freedom" people are complaining that the license isn't free as in freedom enough.
- hot_gril 4y ago
  (In which case, I propose a new slogan, "don't tread on my crap.")
  - peteradio 4y ago
    "I dare you to use this."
- hedora 4y ago
  The WTFPL is FSF-approved enough for me: http://www.wtfpl.net/faq/ http://www.wtfpl.net/faq/
  - hot_gril 4y ago
    Big corps can't use WTFPL-licensed software, at least the one I work at.

zokier 4y ago

I do feel its indicative that most of the authors issues stem from GitHub, the facebook of foss, big social media for coders. If you don't want to engage with the social trends and aspects of the ecosystem (which is perfectly understandable) then GH seems particularly poor choice of platform to publish your software on. I feel the author would have far better chance of "to be left the hell alone" if they chose literally any other platform.

nyanpasu64 4y ago
Not the author, but I wouldn't say it's just (or even primarily) Github's pull requests or "critical security advisory" that's the problem here. PyPI requiring 2FA for maintainers of popular software has had more real-world impact (one maintainer took down and recreated their project, erasing old releases), and Google calling for deanonymizing (doxxing) maintainers of open-source software is more terrifying. I'd argue that the problem isn't that "software supply chains do not exist", but "you using a program or library without pay does not and should not mean the software's author is now responsible for fulfilling your use cases and paperwork requirements".
colinsane 4y ago
iliana is an active Mastodon/Activity Pub user, so surprisingly apt metaphor and probably a fair assessment.

wongarsu 4y ago

If you want a software supply chain that includes formal agreements, use Java or C#, or maybe C++. Those ecosystems have plenty of vendors who will sell you libraries, including phone support and liability. So far enterprises are the only ones willing to pay for their "software supply chain", if you want this kind of "solution" just use what they use.

bob1029 4y ago
The sensitive nature of our business forced the equation for us. We are basically a pure Microsoft shop because it makes survival of audits feasible. 100% of our B2B clients are already doing business with them, so the conversation is fairly simple.

awinter-py 4y ago

interesting points xie is making: 1) it's not a supply chain bc no money is changing hands, 2) therefore no contracts or enforcement, 3) many market participants are hobbyists I think this speaks to the fundamental weirdness of the information economy -- it's highly deflationary, with some extreme cases where hobbyists outperform paid software companies Hobbyists + open groups beat companies in cases where IP concerns makes the software worse, like if they're making something a saas that should be a 100-line library. And also in cases where everyone in industry needs a thing and they're happy to have a great standard free one rather than paying three shitty vendors. I don't know this, but I think a chunk of major OSS projects are maintained by people at big companies or universities. (Postgres may have been associated with fujitsu for a while, guido van rossum + linus torvalds parked in various companies, some fraction of kube committers are at bigcos or corporate-backed CNCF). I have nadia eghbal's 'building in public' on my list to read, guessing she knows the answer to this question.

0xbadcafebee 4y ago

"I just want to publish software that I think is neat so that other hobbyists can use and learn from it, and I otherwise want to be left the hell alone. I should be allowed to decide if something I wrote is “done”. The focus on securing the “software supply chain” has made it even more likely that releasing software for others to use will just mean more work for me that I don’t benefit from. I reject the idea that a concept so tenuous can be secured in the first place." K. The rest of us are gonna keep using the phrase though.

hot_gril 4y ago

Am I missing some background? Author gives out software "WITHOUT WARRANTY" and can just ignore PRs etc. Why is the author complaining?

falcolas 4y ago
> "WITHOUT WARRANTY" Liability disclaimers are a legal grey area. Even the US pulls aside some developers at customs because of their work on OSS projects. Imagine what some of the least tolerant countries do.
- hot_gril 4y ago
  Yeah, but that doesn't seem to be the complaint here. It's more about GitHub's workings.
q-big 4y ago
> and can just ignore PRs This complaint is in my opinion rather specific to GitHub (and could thus likely be solved by switching to a more repository provider, or hosting the repository oneself), but not being able to disable PRs at your own repositories is like having a blog hosted by a provider that does not offer the option to disable blog comments.
- hot_gril 4y ago
  Eh, sounds like a really minor annoyance. It's clear that the PRs aren't your own content, unlike comments which you're sorta responsible for moderating or else you'll often end up with vile stuff all over your family-friendly blog post.
  - q-big 4y ago
    > It's clear that the PRs aren't your own content, unlike comments which you're sorta responsible for moderating. I see this differently: you have some own content * a blog post * a Git repository that is hosted by some provider. "Everybody" can add their own "scribblings" next to it: * comments * PRs In both cases it is clear that these "scribblings" are not your own content. Why do you thus make the difference that in one case one is some kind of responsible for moderating, but not in the other case?

numbsafari 4y ago

When, for example, Google open sources their client libraries, it absolutely is a supply chain issue for their customers. The people working on those projects for Google aren’t doing it as a hobby. Their customers might not be paying them directly for those client libs, but they sure as heck are being billed at some point.

marssaxman 4y ago

> A package repository might deem your software “critical”, adding requirements to publishing updates that you might not want to or be able to comply with. I discovered last week that Github no longer allows you to push changes via https, and thus I have not yet published a minor fix for an insignificant piece of open source software I have been lackadaisically maintaining for the last eight years. Perhaps some day I will get around to jumping through their new security hoops... or perhaps I won't. In this case nobody is likely to care, but it makes me think these kinds of organizations ought to be extremely cautious about introducing extra friction to the workflows of people who are giving away their time for free.

TheRealPomax 4y ago
Not sure I understand how having an ssh key is "jumping through hoops" though...? Presumably you already have one set up (even if you don't, it's literally just a few seconds of work to create a new one), so just add the public key to your account's SSH keys list, and done. Update your remote urls from https to the git@github.com:yourusername format and push whatever you want to push. Or, heck, if no build is required: why use git at all, just use github itself. You can edit, create PRs, on new branches, all without ever needing your own desktop. Perfect for small code changes (especially typo fixes).
XorNot 4y ago
Pushing via HTTPS is the only way I use GitHub, so I find this claim questionable. It's working fine for me.
- marssaxman 4y ago
  Huh! I wonder why your experience is different. I get this error: remote: Support for password authentication was removed on August 13, 2021. remote: Please see https://docs.github.com/en/get-started/getting-started-with-git/about-remote-repositories#cloning-with-https-urls for information on currently recommended modes of authentication.
  - 4y ago

otikik 4y ago

I respectfully disagree with the author. Once you put stuff on someone else’s servers, they can do whatever they want to the package as long as it doesn’t break the license. That includes marking the package as critical or even making a fork the canonical repo. If you want that kind of control, you need to become your own package provider. Or distribute your code with a more restrictive license.

ineedasername 4y ago

This is just nitpicking over the fact that a specific metaphor doesn’t map 1-to-1 with the target domain. No metaphor does, that’s not the point of using one. The metaphor in this case is pretty straightforward as are its limits, and it doesn’t appear to be causing confusion with people misidentifying attributes of the metaphor that don’t map to the software domain. (And to boot: there are actual software supply chains with a traditional supplier/vendor relationship…)

q-big 4y ago
> The metaphor in this case is pretty straightforward as are its limits, and it doesn’t appear to be causing confusion with people misidentifying attributes of the metaphor that don’t map to the software domain. One of the central points that the author makes is that this is in his opinion not true, and he provides evidence for this.

__derek__ 4y ago

The post's definition of 'supply chain' is wrong, and it leads to confusion. If I forage for mushrooms and give them to a local chef, I'm part of the supply chain for that night's dinner, even without money changing hands or quality guarantees. That said, to opt out of companies' supply chains, stop publishing software with permissive licenses.

JohnFen 4y ago
I'm certainly not going to stop publishing software with permissive licenses. I'll just adhere to the disclaimer I include with that software: I provide no warranty that it is fit for any particular use. Use it as you will, but don't expect any guarantee that I'll support whatever needs your supply chain has.
- __derek__ 4y ago
  That's the current state that the author considers untenable, right?
  - JohnFen 4y ago
    My read of TFA is that author is complaining that companies are trying to push responsibilities onto FOSS authors that don't belong with the FOSS authors. He includes complaints about Github there, but those are easily resolved by not using Github. I believe that the author and I are on the same page here, generally. Have I misunderstood his essay?
cbm-vic-20 4y ago
Or license your work under GPL, which is kryptonite to most businesses. The mega-globo-corp I work for makes commercial license deals with some open source software vendors who dual license their software with GPL and a commercial license.
- __derek__ 4y ago
  Right. GPL is an example of a non-permissive license.

lrvick 4y ago

I do software supply chain security consulting for several high risk companies and largely agree with this post that we must stop expecting devs to have any responsibility for code they produce. The responsibility is on those that consume it. This will sound pretty harsh, but if your company chooses to use open source code that does not have capable, paid, full time professionals reviewing it for security and quality, then your company is signing up for that responsibility. If you make no reasonable attempt at vetting your supply chain and harm comes to users as a result, then IMO you should be liable for negligence just like a restaurant serving food with poisonous ingredients. Broadly normalized negligence is still negligence. This should not be controversial, but it is. Washing hands in hospitals was once controversial too but those advocating for it had irrefutable evidence on their side. The medical industry did not want to pay the labor cost of hygiene, and we are seeing the same in the software industry. https://www.nationalgeographic.com/history/article/handwashing-once-controversial-medical-advice https://www.nationalgeographic.com/history/article/handwashi... Ask yourself if it cheaper to fully review, sign, compile, and maintain third party OSS code or to write something in-house focused on your needs on top of the standard library. Pick one. Both are real options. Some of my clients actually do (or pay others for) security review of every single NPM dependency they use in prod. If you can not afford to review 2000 dependencies then you can not afford 2000 dependencies. Find a leaner path. Companies must stop expecting others to do their software review job for them. OSS devs already wrote the code for free because, ostensibly, it was fun. You are an ass if you ask them to do anything that is not fun, for free, to make your company safer or more money. Such actions make it not fun anymore, and make them stop entirely. I do not know why companies have code review policies for code written by peers, but if the code is 2 million lines of NPM dependencies essentially copy/pasted from randos on the internet it is suddenly okay to ship straight to prod and give said randos full control of the data or property of millions of people. We need to start calling this out as the negligence that it is.

ahtihn 4y ago
> Ask yourself if it cheaper to fully review, sign, compile, and maintain third party OSS code or to write something focused on your needs on stop of the standard library yourself. Why stop at the standard library? What about the rest of the language toolchain? Compilers, interpreters. What about the OS?

Crontab 4y ago

> The author of an open source project usually makes NO guarantees and assumes no liability. That's pretty much true of commercial software as well.

r3trohack3r 4y ago

There are several forms of OSS and it seems people often conflate them. There is: * "open source as a reference" * "open source as a line item" * "open source as a funnel" It seems like our industry favors line item OSS. Personally, I think the other two are far more useful. Line item OSS productizes a high-value project inside a company and releases it publicly for no charge. The goal of open sourcing is generally to steer the industry in a direction compatible with your company's architecture. Often times companies are trying to: * Cultivate engineering talent trained on their architecture that they can hire in the future * Increase maturity of their software stack by exposing it to environments outside their current architecture * Recruit maintainers to drive down the cost of maintaining an internal pattern * Cultivate an ecosystem of plugins and modules they can rely on for future engineering projects * Cultivate good will in the developer community as a recruiting/dev-rel tactic * etc. Line-item OSS projects typically carry a high cost, they don't just become successful when you push to a public repository. These projects require devrel presence to meet 3rd party engineers where they are (conferences, blogs, documentation, branding, logos, news aggregator sites, etc.). They require maintainers to mentor 3rd party engineers through pull requests and issues. You have to navigate community building with codes of conduct, boards, foundations, etc. This all requires salaried employee's time. This high cost raises the bar for contributing to the commons: the return has to cover the salaried time spent on open sourcing the project. If the return doesn't cover your investment, ROI is negative and you're expecting companies to contribute for charity. What's worse is that failing on a line item OSS project often results in the opposite of what you want: a perception that your company is bad at OSS or not a great community participant. Every line item OSS project is a high-cost bet carrying risk to your reputation. Open source as a reference, in contrast, is closer to publishing a conference paper. You describe how you are doing something, publish the source code as a reference, and call it a day. No community building. You don't commit to merging random PRs. You don't commit to fielding questions on issue trackers. It's a statement that what you are doing is working for you, that other engineers might benefit from similar patterns, and a jump start for motivated engineers to figure out how to apply the pattern themselves. You're contributing to the commons under a permissive license for the cost of a conference road show and a "cleanup" of the code to ensure you aren't leaking anything sensitive in your SCM history. I feel a lot more software would make it into the commons if we normalized this form of OSS. "Open source as a funnel" is probably the most sustainable OSS model IMH(umble)O. "OSS funnel projects are associated with a vendor that sells services and products in that ecosystem. The services are particularly useful for companies building on top of OSS. If you are a small-ish org, every dependency you're bringing in is a pretty big risk. You have to have internal talent capable of maintaining the entire software stack. "OSS as a line item" and "OSS as a reference" do not give you any guarantees from the project. The maintainers aren't your employees and they owe you nothing. You often have no way to pay maintainers to solve your problems. A show stopper bug in those projects can bury your company. In contrast, "OSS as a funnel" has a vendor you can reach out to for consulting/contracting services to elastically scale out your engineering org for bugs in the stack. In the Node.js ecosystem, NearForm is a great example IMHO. They are maintainers on a pretty large catalogue of software (i.e. fastify). You can bring that into your architecture knowing that, if you end up blocked on a bug your team doesn't have the expertise to solve, you have a vendor you can reach out to and pay to solve your problem. Sometimes line item OSS projects foster an ecosystem of vendors which in turn checks the OSS as a funnel box. For example, with GraphQL and React, you can't pay Facebook but someone out there will take your money to solve your problems. I do consulting/contracting in the Node.js space and, when I bring modules into my client's architecture, having a vendor associated with the module is front-of-mind for me. I know I'm not leaving them with technical debt they have no way out of if something goes sideways. They always have me and they have a 3rd party vendor they can reach out to as well.

kazinator 4y ago

> You still cannot disable pull requests on a GitHub repository. A package repository might deem your software “critical”, adding requirements to publishing updates that you might not want to or be able to comply with. Google even wanted to disallow anonymous individuals from maintaining critical software and wanted to police the identities of others. That's just whining from people who host their stuff on other people's servers and sites. If other people package your software into a bigger system and then later improve their standards so that the bar is above your stuff now (e.g. you break it left and right with careless, untested changes, or whatever, whereas downstream is doing actual QA) that's downstream's prerogative. You don't have to do anything; they can fork your stuff and develop it themselves, or stick with the old version from you that worked, ignoring the newer releases.

LtWorf 4y ago
The problem is that they don't fork it. Instead they harass you.
- kazinator 4y ago
  People should give that a good try; maintaining forks sucks. In the past I've forked at the sign of any resistance. I have a fork of GNU Awk called Enhanced GNU Awk (egawk). https://www.kylheku.com/cgit/egawk/about/ https://www.kylheku.com/cgit/egawk/about/ It has a let construct for lexical variables. Chances are it's not packaged for your favorite OS, so you'd have to build it yourself. The next thing on the plate for that project is to support the GNU C preprocessor line annotations so that if Egawk is handed preprocessed code, it will report errors against the original file and line number.

khana 4y ago

JohnFen 4y ago

> I just want to publish software that I think is neat so that other hobbyists can use and learn from it, and I otherwise want to be left the hell alone. Me, too. Which is why I pretty much abandoned the formal "OSS" world and don't use Github and the like. I still make software, I still provide a free license for anyone to use it, and I'll even maintain it for as long as it interests me. But it's a hobby, not a job. If someone uses my software commercially, it's on them to make sure that it's properly maintained. They have the source, they can do it.

gumby 4y ago

There's a business opportunity here for making a "slow copy" of npm (or PyPI or whatever): start with a copy and then just only upgrade packages after you've checked the changes. You could sign and manage the BOM, perhaps even ensuring that $BIG_ENTERPRISE only got the versions they had asked for no matter what request they make (oh, sorry for the dev trying to get their job done -- go ask IT).

ChrisMarshallNY 4y ago

In my case, I basically never use anyone else's code, unless there's a real need for it, and if I'm quite confident in its veracity. I also take full Responsibility and Accountability for that code, when it is running in my execution thread. The result of this policy, is that I have written almost every single dependency that I use. It has garnered me a lot of sneers from the "in crowd." I don't particularly care. WFM. YMMV. [EDIT] Also, I like this: my name is always spelled lowercase and is pronounced /ɪliˈɑnə ɛˈtiːn/. please consider making the internet a weirder place today note: if you send me unsolicited email based on my github profile: i will screenshot it and share in my discord server we will make fun of you you will not receive a response*

wbobeirne 4y ago
I'm not trying to be flippant, but where do you draw the line of "never use anyone else's code"? You're writing that software using an operating system and editor someone else wrote. You're compiling it with software someone else wrote. If you're deploying it to users, it's hosted on someone else's code and will be run by someone else's code in that runtime.
- tomjakubowski 4y ago
  OP claims responsibility for code when it is running in my execution thread. That seems to be the boundary. So no need to write their OS, though maybe their own interface for making syscallz.
- ChrisMarshallNY 4y ago
  I know. That's the classic argument that I get. Basically "what about..?" Like I said, I know what works for me. I'm not gonna argue about it. I do know that some find my stance offensive, which I don't actually understand. I'm not attacking anyone. I'm just saying how I do it, in my own work. I write lots of packages that I integrate into my own work. Each package is a standalone project, with tests and docs. Because they are written and maintained by a single person, I know that some folks believe this makes them "worthless," but not to me. It's the way that I work, on my own stuff. I'm not competing with anyone here, so I fail to see the problem. If I'm just some clueless old boomer, making a hash of things, then God bless my little heart, and I'll just be tilting at windmills, over here.

asimpletune 4y ago

So fwiw I think the whole concept of the "software supply chain" actually stems from "supply chain" attacks. It's kind of like once that turn of speech entered the fray, suddenly there was a software supply chain (for OSS).

Waterluvian 4y ago

If you want or need support or maintenance for my project in your business, offer me cash. If your first thought is, “hah, as if finance would ever green light that…” then I encourage you to fork it and tell your manager it will cost your company two to three times as much to do it yourself. I think both are perfectly valid options. Just make informed decisions and in doing so, demonstrate business competence.

eastbound 4y ago
I sell both my software as OSS, and as commercial software with a delivery through a corporate appstore. Companies are happy to pay.

_8j50 4y ago

I must disagree. Software supply chain is very different than supply chain of physical goods, but, it is still a chain of supplies in the form of software code. Looking at it strictly from an open source perspective is having too narrow of a focus. If I purchase O365 licenses from a reseller and they buy it from Microsoft, that's a supply chain. If I have an embedded system that has a proprietary OS made by a 3 person company who use a proprietary firmware from other vendors, that is a supply chain. The npm example is a good example of a convoluted and unreliable supply chain. OSS is an example of a supply chain that is by design unreliable, the suppliers disavow all responsibility to support or guarantee its features. OSS supply chain being unreliable does not mean the supply chain does not exist, it just means you have to compensate for the unreliability yourself. The real life equivalent would be sourcing materials from guys standing at a street corner selling stuff that "fell off a truck" or "made in their garage".

franciscop 4y ago

The author is being even too polite IMHO, since there IS a "contract" (legal working agreement, or license) when involving open source. And it CLEARLY stipulates, usually even in capital letters, exactly what the author is conveying in the article! That the software is "as-is" and you should not expect -let alone demand- anything from authors. Anything beyond that is good will from open source authors, which historically has varied wildly from project to project. I fully agree with the author though; it was even funnier when NPM sarcastically blamed me for losing my password on the reset screen, since it was THEM who lost their users passwords and force-reset them all, so now I had to reset my password, forced to use 2FA and being mocked while doing all of that ONLY to be able to share my work for free with the world. I was very, very close to say fuck NPM I'm out, unfortunately they have a de-facto monopoly.

thenerdhead 4y ago

I personally like the metaphor (but then again I work on a major package manager). I like to think of it this way... - we download code - from the internet - written by unknown individuals - that we haven't read - which we execute - with full permissions - on our trusted devices - where we keep our most important data (someone wrote this that I found in the SSC space) Given a supply chain attack can happen at many of those steps above, but is also extended to source code, build systems, and production services, it's a great metaphor for visualizing the complex "software supply chain".

bern4444 4y ago

I've seen the case made that engineers who develop FOSS don't want to be paid for their work specifically because once they accept payment they feel a stronger obligation to maintain the software and respond to issues from those paying entities rather than focusing on the issues they want to or generally doing work as they see fit. We all use FOSS - its one of the most unique aspects of software engineering compared to other industries IMO. The world would literally not have advanced nearly as far without it. I'm incredibly grateful to work in a field that views FOSS maintainers so well and thankful to the FOSS for all the incredible and fun technology I get to use everyday.

SergeAx 4y ago

In fact, it's just as simple as that: every package today has a license. If the license says that the author has no responsibility and liability for it - so it is. If the package has no license - you cannot use it in commercial software anyway.

goodpoint 4y ago

168 comments and nobody pointed out the role of Linux distributions...

hushpopote 4y ago