4 ms·

> while I do know that D. Richard Hipp, Daniel Stenberg, and Thomas Pornin will respond Will they, or if they do will they actually help with whatever need you

> while I do know that D. Richard Hipp, Daniel Stenberg, and Thomas Pornin will respond 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.

ghoward 4y ago
I've personally emailed two already and gotten responses about other things, so for those two, I know they will respond. And they were personal emails; I did not ask about business things. 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.
- malwrar 4y ago
  Interesting perspective, thanks for sharing it. I think I might consider something similar to this approach for a future project, as I too have been trying to decide what kind of relationship I want to have w/ dependencies.

ghoward 4y ago

I've personally emailed two already and gotten responses about other things, so for those two, I know they will respond. And they were personal emails; I did not ask about business things. 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.

malwrar 4y ago
Interesting perspective, thanks for sharing it. I think I might consider something similar to this approach for a future project, as I too have been trying to decide what kind of relationship I want to have w/ dependencies.