A thought I had — there's a decent sentiment in the general software development that a project is never really “complete;”^[1] at a minimum you need to keep up with dependency and platform churn to avoid the bitrot.

However, there's a significant difference here between source libraries and programs.^[2]

A source library utilizes other libraries that can be updated separately; at a minimum the language toolchain can be updated. If a source library is written in a fully platform independent manner, then it remains useful even in the face of platform churn because the underlying per-platform functionality is being updated. For a program, however, this requires the program distribution to be updated to distribute a version rebuilt with all of the new fixes and improvements.

Big/popular software today typically gets somewhat frequent updates with little more description than “fixes and improvements,” contributing to the feeling that all software needs constant maintenance. But I'd be willing to bet that a significant^[3] portion of such updates are absent of any actual changes by the team developing the program itself, but instead just shipping the “fixes and improvements” gained by updating their external dependencies. Even if all of their transitive dependency tree has wonderful changelogs, that's developer targeted, so there isn't really anything that they can say that would be actually relevant to the user who doesn't know or care^[4] how the program is built.

Discussion question: what makes a Rust library crate “complete” in your eyes? Authorial intent? A lack of significant^[5] issues over time? Stability? Does usage level have any impact in the analysis?

1. People mostly seem to agree that a project can be “finished,” though; the difference as I understand it is that “complete” is more than just “finished.” Some people would use the terms in the other parity, but general consensus does seem to me that a project can be at least one of the two. ↩︎

2. I'm including both a precompiled binary library object and executables as “programs” here for simplicity. Executables (as in something you would run an installer for) generally bundle any non-OS binary deps they use (is this Windows bias?), where binary libraries often haven't been linked the binary transitive dependencies yet, so the property I'm looking at is more obvious and prevalent in packaged executables, but it applies just the same to precompiled libraries, just on a somewhat smaller scale. Assuming their downstream actually updates the transitive dependencies and doesn't just use the copy bundled with the library distribution that were added to make things work out of the box. ↩︎

3. Conveniently omitting a definition for “significant.” If I understand statistical significance correctly, that's basically just a measurable effect, so even a single such occurrence could be considered “significant,” since these are discrete events and not samples of a continuous domain. ↩︎

4. You can argue that users should care more about the chain of providers that they are implicitly trusting, but the fact of the matter is that the vast majority of users don't, or consider the transitive trust derived from trusting the primary vendor to be sufficient. (Whether the primary vendor actually audits their web of trust sufficiently is yet another independent question.) ↩︎

5. This one is definitely a fuzzy continuous scale where people will draw the “line” differently. ↩︎

3 posts - 3 participants

Read full topic