People in your software supply chain
sethmlarson.dev
sethmlarson.dev
For example, in a project I am working on, I need a database, a way to talk over the Internet, and cryptography. Obviously, I know what database to use: SQLite (D. Richard Hipp). Obviously, I know what dependency to use for talking over the Internet: curl (Daniel Stenberg).
Cryptography is harder, but I finally settled on BearSSL (Thomas Pornin). BearSSL does not give me everything I want, however; since I want OPAQUE (a way for clients to not give their password to a potentially malicious server), I need that. BearSSL also does not give me a "KSF," or key-stretching function, which OPAQUE requires, though I can use Argon2i for that.
The reference implementation for Argon2i unfortunately seems dead, even though I know the names of the people who made it. I don't know if they will respond if I contact them, while I do know that D. Richard Hipp, Daniel Stenberg, and Thomas Pornin will respond. So in order to make sure I always have a point of contact with all of my dependencies, I am going to write Argon2i, BLAKE2b (needed by Argon2i), and OPAQUE myself.
Bad idea? Yeah, don't roll your own crypto. But I am studying hard, and I intend to get my crypto audited before publishing.
The end result, however, is very worth it: my dependencies will be well-known, and I know each of the authors personally, albeit through email.
And down the road, if I manage to make some money, I can kick some of it back to them in exchange for their previous help. In turn, they'll be happy to continue the relationship.
That's how Open Source works at its best: it depends on relationships, and on giving back to those relationships. I think that that is what this article is trying to say, and I whole-heartedly agree.
Will they, or if they do will they actually help with whatever need you have? You state you plan to build relationships, do you actually email these people and attempt to get to know them while using their library? Does knowing their real-life identities give you some sense of trust that stuff released by their online presence actually comes from them?
Honest questions, as the idea of getting to know every single person in the first layer of your dependency chain sounds bizarre and unsustainable to me. Maybe you have a different experience, but I personally have only experienced a sense of being filtered through a machine whenever I talk to people online who run popular things I make use of. Curious to know more.
The other, Daniel, has a great reputation and is employed by wolfSSL to work on curl among other things. That means that I could always pay for work through wolfSSL. But I am planning on establishing an email relationship, probably through asking questions as I learn how to integrate curl with my project. If he does not respond the way I would want him to, I'm going to have to find an alternative, and I will.
You are right that the idea of getting to know every single person in the first layer of a dependency chain is bizarre and unsustainable, but that is only because of current dependency culture. People just incorporate dependencies without thinking of the long-term consequences, and that makes it unsustainable since the consequences are unaccounted for. As long as they are unaccounted for, they will cause problems, and the problems make this idea unsustainable.
But I did not go about it like that. Instead, I sat down, designed my project (a VCS) beforehand and thought carefully about what I could write myself and what would be better to have dependencies on. So I carefully chose my dependencies, and I listed them before I even began.
And there were some requirements:
1. Have a person I could contact, preferably someone who I could pay should that be necessary.
2. Have no transitive dependencies, or all of their transitive dependencies are already satisfied by other dependencies.
3. Be written in C. (My project is in C.)
In the case of BearSSL, I would not have chosen it if curl wasn't able to work with it for TLS support because that would have been yet another dependency. But curl can work with BearSSL, so requirement 2 for curl was still satisfied, while BearSSL can still help with things like hashing files, generating keys, etc.
So you are right that the idea is unsustainable with how things are usually done, but I did things differently, and I did it differently because I wanted to avoid the problems you are alluding to.