[Themaintainers] [EXTERNAL] Re: XKCD comic on maintenance

[Don Goodman-Wilson]

The chief difficulty with software dependencies is we only have information for one direction of flow: We know that if A depends on B, and B depends on C then A depends on C, and we can do this for all of A’s direct and indirect dependencies. We can, in otherworldly, readily identify what A depends upon. The problem is that we can’t—even theoretically!—find out what projects depend on C. Which is to say, we have no systematic mechanism for tracking down and identifying all those small, unrecognized, but critical dependencies and making sure they are well-funded and maintained. We only find out when one of them breaks, as they do from time to time (cf. `left-pad` and `event-stream`). In fact, for privacy reasons, this is considered a feature. I see this as a significant failure of the current way we do software dependencies.

Don GOODMAN-WILSON
Maintainerati Board
web: maintainerati.org
twitter: @DEGoodmanWilson
cal: calendly.com/degoodmanwilson/
On 19 Aug 2020, 16:49 +0200, Edward Summers <ehs at pobox.com>, wrote:
>
> > On Aug 18, 2020, at 9:59 PM, Sims, Benjamin Hayden <bsims at lanl.gov> wrote:
> > Related to Andy’s point, not a lot of modern infrastructures have embraced layers of abstraction as enthusiastically as computing has. The idea behind layers of abstraction is to hide complexity behind simpler interfaces, which makes it possible to think of software as a “stack” of components (and consequently as a Jenga-like construct as depicted in the cartoon). So part of me wants to say that weird dependencies might be better hidden, and hence more surprising, in software. But on the other hand there are plenty of examples of hidden dependencies in old-school infrastructure. I’m not sure they follow the same stack-like structure though, so the cartoon might look a little different. I’m curious if any of the software developers/maintainers on the list have some perspective on this.
>
> Actually, in some ways I think dependencies are *more* legible in software than they usually are in "old-school" infrastructures. From makefiles to pom.xml to package.json, software builds need to explicitly list these dependencies, and the dependencies tend to be actionable. I feel like these lists are largely understudied from an infrastructure perspective--but I'd love to be corrected if people know of some research.
>
> Also, i'd be interested to hear if people have found there to be "real world" or non-computational equivalents to these dependency lists for the research, for example accounting ledgers, supply chain data, etc?
>
> //Ed
> _______________________________________________
> Themaintainers mailing list
> Themaintainers at lists.stevens.edu
> https://lists.stevens.edu/mailman/listinfo/themaintainers
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.stevens.edu/pipermail/themaintainers/attachments/20200819/423bf916/attachment-0001.html>