The list of critical open source projects, components and framework is currently published as a spreadsheet.
I suggest that it's provided as a machine-readable file under source control in this repository. This can provide a mostly durable endpoint for people that need to access it for other purposes. It can also help with clarity and readability (the spreadsheet seems to mention other projects that didn't meet the initial criteria) and it can help formalize the governance process at least for releases (see #23) At the very least it can serve to decouple the eligibility/evaluation criteria from the actual list of software components.
It'd be great to consider publishing this list in, e.g., SPDX format. A key question is how to normalize the project names. I mention using the repology rules in #41. purl is another potential addition to the list. And, as mentioned in other issues, WikiData can be surprisingly helpful going from a "named package" to the specifics of what it is exactly (see this example for nano)
The list of critical open source projects, components and framework is currently published as a spreadsheet.
I suggest that it's provided as a machine-readable file under source control in this repository. This can provide a mostly durable endpoint for people that need to access it for other purposes. It can also help with clarity and readability (the spreadsheet seems to mention other projects that didn't meet the initial criteria) and it can help formalize the governance process at least for releases (see #23) At the very least it can serve to decouple the eligibility/evaluation criteria from the actual list of software components.
It'd be great to consider publishing this list in, e.g., SPDX format. A key question is how to normalize the project names. I mention using the
repologyrules in #41.purlis another potential addition to the list. And, as mentioned in other issues, WikiData can be surprisingly helpful going from a "named package" to the specifics of what it is exactly (see this example fornano)