2347: Dependency

Explain xkcd: It's 'cause you're dumb.
Revision as of 22:54, 17 August 2020 by JBYoshi (talk | contribs) (Add transcript.)
Jump to: navigation, search
Dependency
Someday ImageMagick will finally break for good and we'll have a long period of scrambling as we try to reassemble civilization from the rubble.
Title text: Someday ImageMagick will finally break for good and we'll have a long period of scrambling as we try to reassemble civilization from the rubble.

Explanation

Ambox notice.png This explanation may be incomplete or incorrect: Created by A PROJECT SOME RANDOM PERSON HAS BEEN THANKLESSLY MAINTAINING SINCE 2013. Please mention here why this explanation isn't complete. Do NOT delete this tag too soon.
If you can address this issue, please edit the page! Thanks.

Software design from the late 2010s onwards focused on a model of re-usability and modularization, creating micro-services which were the logical extreme of such a conclusion. While in theory, such a system may sound good for developers who would need to write and maintain many fewer lines of code, systems which are highly optimized are also highly susceptible to rapid changes. For example, the famous left-pad incident in Javascript's npm left many major and minor web services which at some level or another depended on it unable to build. A disgruntled developer unpublishing 11 lines of code was able to break everybody's build, because everyone is using it.

The current model of libraries and open-source development (topics which Randall has addressed extensively in the past) relies heavily on the free and continued dedication of unpaid hobbyists. Though some major projects such as Linux may be able to garner enough attention to build an organization around it, many smaller projects, which are in turn reused by larger projects, may only be maintained by one person, either the founder or another who has taken the torch. Maintaining libraries requires both extensive knowledge of the library itself as well as any use cases and the broader community around it, which usually is suited for maintainers who have spent years at the task, and thus cannot be easily replaced. Thus, there are many abandoned projects on the internet as people move on to greener pastures. Far from the days of backwards compatibility, that's usually not a problem, unless a project happens to be far down the dependency chain, such as illustrated in the example, in which case there may be a minor crisis down the road for both the developers and the users down the chain.

Transcript

Ambox notice.png This transcript is incomplete. Please help editing it! Thanks.

[A tower of blocks is shown. The upper half consists of many tiny blocks balanced on top of one another, labeled:]

All modern digital infrastructure

[The blocks get progressively larger leading down the image, leading to a single large block on top of which everything else is placed. This is balanced on top of two sets of blocks, one of which consists of a single tiny block placed on its side. This one is labeled:]

A project some random person in Nebraska has been thanklessly maintaining since 2003