Quantifying Nebraska

Adam Harvey

(he/him)

Rust Foundation

@a@lawngno.me

xkcd: Dependency (CC-BY-NC-2.5)

`xz`

National Atlas, via Wikimedia (PD)


$ grep axum Cargo.toml
axum = { version = "=0.7.5", features = ["macros", "matched-path"] }


$ pnpm ls @glimmer/component
devDependencies:
@glimmer/component 1.1.2


$ cat Cargo.lock | yq -p toml '.package[].name'
addr2line
adler
aead
aes
aes-gcm
ahash
aho-corasick


$ curl \
  https://crates.io/api/v1/crates/addr2line \
  | jq '.crate.repository'
"https://github.com/gimli-rs/addr2line"


$ cat Cargo.lock \
  | yq -p toml '.package[].name' \
  | wc -l
494

OpenSSF Scorecard

Aside: a brief rant

Also, it's worth noting that the current state of security scorecards doesn't necessarily capture all the risks. Yes, it's important to publish securely, have your artifacts be reproducible and match their source, and so on, but that does very little to address the human aspect of the supply chain problem space. Trust me, when I have maintained OSS projects, I already know that I don't have enough hours in the day, or reviewers, or testing, or whatever it might be. So, as important an exercise as this may be for you, and for us, it's important that we always consider the human on the other end.

Health factors

Issues
Pull requests
Number of maintainers
Commit author diversity

Anyway, assuming we accept that trying to score anything is an imperfect science, that we might just confirm our own biases, and that we should really only be doing it in our own context, let's reason through what we might want to think about when we're looking at a project. (four bullets; elaborate on each one) This is obviously overly simplistic. Not everything can be quantified, in spite of the title of this talk. But equally, we're not necessarily looking for an exact list at this stage. What we want is a shorter list of dependencies that a human could go investigate.

Shape of You(r project)

It's also important to remember that there are different shapes of projects. Some projects might have little recent activity because they're essentially finished. Some projects might only have one author because they were a singular labour of love. It's important to balance scale and recency: I think you get much more out of saying, say, there are a bunch of open tickets that have been opened recently that haven't been triaged or addressed than it is to just say there are a bunch of open pull requests from five years ago. Those might just reflect a project where a maintainer is sticking to a vision.

crates.io


https://github.com/rust-lang/libm: total 0.19382383904550238
	commit author diversity: 0.14563106796116504
	recent issues: 0
	open pull requests: 0.04819277108433735
	sponsorship requests: 0

Assume Insert good faith


github.com/mitsuhiko/insta: total 2.2573594430233936
(this maintainer accepts sponsorship on GitHub)
(this repository accepts sponsorship on GitHub)
	commit author diversity: 0.881578947368421
	recent issues: 0.6923076923076923
	open pull requests: 0.03347280334728033
	sponsorship requests: 0.65

What did I find? A mixture of things, which is why the human element is important. The highest scoring result according to the criteria I just laid out is a crate called insta, which is an increasingly popular snapshot testing library for Rust. It's mostly authored by one person, it has a lot of recent activity in issues that haven't been closed, and sponsorships are open for both the project and the maintainer. I happen to know that it's becoming much more popular quite quickly, so the issue explosion makes sense there. It's probably debatable to what extent it's a security risk, since it's a testing library, but if it's important to us, it feels like something that we should support.


github.com/sfackler/rust-openssl: total 1.9640399745254222
(this maintainer accepts sponsorship on GitHub)
(this repository accepts sponsorship on GitHub)
	commit author diversity: 0.5519686965028124
	recent issues: 0.7058823529411765
	open pull requests: 0.05618892508143322
	sponsorship requests: 0.65

Skipping down to the third place entry, here's one that I think is really interesting: the OpenSSL bindings for Rust. The majority of commits are by one author, the issue tracker is active with a mixture of support requests and actual issues, and again, both the maintainer and project accept sponsorships. This feels... fairly fundamental, right? I know crates.io doesn't directly depend on this crate — in fact, the shallowest place it appears in the dependency chart is three levels deep — but I also know that we have to make lots of TLS requests when crates are published, which is the key workflow on crates.io. So, if I had a bunch of budget and/or developer time available, this feels like a crate that might be good to offer help to.

Aside: what about the ecosystem?

What useful things can we do?

C.R.E.A.M

The obvious solution is generally donating money, especially if the maintainer and/or project accept donations or sponsorships. This may be extremely easy or extremely difficult, depending on where this money is coming from, corporate policies, and so on. There are also clearing houses like Tidelift, and ecosystem foundations that may provide donation opportunities, although since the point of this talk was to find the underserved dependencies in your graph, chances are they're going to have the same blind spots as you already have. (Incidentally, one useful additional scoring metric above would probably be "which projects are already receiving support from Tidelift?".)

Time

Another option that I think is often underused in the corporate world is in-kind donation: donating 5 or 10% of an IC's time to help with project tasks is actually huge for a lot of projects and maintainers. (I know that, personally, I am very time poor, and that's probably the form I would like help to take more often.) Project tasks here don't just mean writing code! My suspicion is that the actually most useful thing I ever did in FOSS was be one of the two people who triaged the firehose of PHP issues for a few years. Triage, documentation, community management, code reviews... these are all things an IC can help with.

Ask!

Numbers aren't actually everything

(sorry)

And, look, I'm going to undercut the entire premise of this talk by reiterating that a quantitative approach can only get you so far. What I want to do is help suggest ways that we can take things we already have, like SBOMs, lockfiles, and so on, and use them to find the components from Nebraska in our dependency graphs, but that's only one part of the problem. Like the vast majority of problems in tech, this is really a human problem in the end: finding these projects still — I believe — requires some level of intuition and experience with FOSS, and the only way to help them is to show up: by working, or by donating, or by just listening to the problems and trying to help.

Quantifying Nebraska

Adam Harvey

(he/him)

Rust Foundation

@a@lawngno.me

xz

Aside: a brief rant

Health factors

Shape of You(r project)

Assume Insert good faith

Aside: what about the ecosystem?

Aside: what about the ecosystem?

What useful things can we do?

C.R.E.A.M

Time

Ask!

Numbers aren't actually everything

(sorry)

Thanks!

@a@lawngno.me

`xz`