"Sometimes magic is just someone spending more time on something than anyone else might reasonably expect." -Teller
Postel picked up the role of number coordinator because it needed to be done.
Using his work as-is from upstream is just the path of least resistance. If nobody picks up dhcpd maintenance companies will have no problem carrying forks and more than likely the open source community will quickly converge around a future implementation.
This isn’t comparable to some sole manufacturer or anything like that. It’s similar instead to someone publishing blueprints for basic things and everyone using them because of time saved because redoing them from scratch is tedious and wouldn’t have much of a point.
Yes, they could change. But that would be something that had to be chosen, it's not automatic. I'm reminded of openssl: while it wasn't even unmaintained, it was "undermaintained" to the extent of critical security holes, and both the effort to fork it and simplify and the effort to replace with modern from-scratch versions have been a bit fraught.
(Perhaps the real rule as to who the "maintainer" of something like this is "who has to panic when a security hole is reported")
Sure all the big companies that relied on dhcpcd will rewrite it. But still the loss of one opensource project has a major impact on the economy. You mention the part of time saved by the company. Sure, but that goes longer than that.
For instance, in Android, since Android 6, they stopped using dhcpcd and decided to use their own DHCP client. 5 releases later, Android's DHCP client still don't support storing leases (or any feature that has less than 20% usage really). Sure that's just one packet, but the most user-deployed OS in the world has an additional RTT when connecting to WiFi, because of using internal DHCP client rather than a FLOSS-driven one.
Let's do back of the napkin computation: This adds like 0.5s when connecting. I'd say that personnally I'm connecting manually to WiFi (and thus wait for WiFi to connect) maybe once a week. K, worldwide I'd say once a month. There are 3B active Android devices. I'd say mean salary in those 3B is 1USD/h. If my computation is correct ( ((3*1000*1000*1000)*0.5*12)/3600 ), that makes a society cost of Android NOT using dhcpcd of 5M$ per year.
Now, let's go to the mirror successful part of dhcpcd, still at Google. Chromebooks are using dhcpcd as their DHCP client. Considering what happened on Android, I'll assume that if Chromebooks weren't using dhcpcd, they wouldn't use leases either. There are maybe 100M Chromebooks worldwide, but they are mostly centered in the US where salary is higher, but Chromebooks are mostly for students, so let's make it 5USD/h. But on a Chromebook you connect "manually" to WiFi every day (every time you open your laptop pretty much). That means that the existence of dhcpcd is a gain for society of 25M$ per year ( ( ((100*1000*1000)*0.5*365)/3600)*5 ).
So, yes, if nobody picks up dhcpcd maintenance, companies will have no problem carrying on. It doesn't mean that we, as a society wouldn't have lost a lot.
PS: I'm definitely not trying to put a price on Roy Marple's life. But if someone would try, it would be incredibly high.
> Sure all the big companies that relied on dhcpcd will rewrite it.
Unlikely. dhclient works just fine and carrying a fork of dhcpd will work just fine.
You’re missing my point. When you work on open source and end up with millions to billions of users, everything you do ends up having a huge monetary impact (guess how much Roy’s bugs have cost the economy in lost time). However, that’s just a side effect of software, not you being some unsung hero.
Tons of people need software that does X. Once one or two people have an open source solution to X, people can just use that and move on. That’s a good thing but it doesn’t mean that those one or two people are critical to anything. If they quit, fail, whatever, downstream dependencies will just swap and move on.
But, my favorite Internet history book of all time is "IPng: Internet Protocol Next Generation" edited by Scott O. Bradner and Allison Mankin. It's about the development of what would become IPv6, and each chapter is written by a different engineer who was involved in the process. Some chapters were written for the book, and some chapters were publications/reports from the process.