Linux Foundation's 'Census II' of Open Source Libraries Urges Support, Security, and Standardization

"Much of the most widely used free and open source software is developed by only a handful of contributors," warns the Linux Foundation, in the executive summary for its massive new census of free and open source software application libraries. It was prepared in conjunction with Harvard's Laboratory for Innovation Science — and that's just one of its five high-level findings.

The census also notes "the increasing importance of individual developer account security," but also the persistence of legacy software, the need for a standardized naming schema for software components, and "complexities" around package versions. But there's also just a lot of data about package popularity, writes SD Times: The report, Census II, is a follow-up to Census I, which was conducted in 2015 to identify the packages in Debian Linux that were most critical to the operation and security of the kernel. According to the Linux Foundation, Census II allows for a more "complete picture of free and open source (FOSS) adoption."

"Understanding what FOSS packages are the most critical to society allows us to proactively support projects that warrant operations and security support," said Brian Behlendorf, executive director at Linux Foundation's Open Source Security Foundation (OpenSSF).
The census "aggregates data from over half a million observations of FOSS libraries used in production applications at thousands of companies," according to its executive summary. It argues that preserving FOSS will require this kind of data-sharing (about where and how FOSS packages are being used ) as well as coordination — including standardizing terminology — and of course, investment.

"The motivation behind publishing these findings is to not only inform, but also to inspire action by developers to improve their security practices and by end users to support the FOSS ecosystem and developers who need assistance." (It suggests companies companies could provide not just financial support but also the technical talent and their time.) The results take the form of eight Top 500 lists — four that include version numbers in the analysis and four that are version agnostic. Further, as mentioned above, we present npm and non-npm packages in separate lists... Although these lists provide valuable, important insights into the most widely used FOSS projects, it is important to also consider the level of security related to these projects. Therefore, in each list, we also include the "Tiered %" measure from the OpenSSF Best Practices Badging Program....

Shortlist

[kmoser]

Further, as mentioned above, we present npm and non-npm packages in separate lists..

Listing the npm packages that are *not* vulnerable would be a lot shorter than listing the ones that are.

This makes no sense to me

[bento]

How are there any "cargo" managed dependencies which are in this report. I find it difficult to believe that Rust is that widespread. I could believe that some things which are packaged for use with Rust, such as PCRE, need some attention and support, but obviously we're missing huge swaths of the dependency ecosystem because C/C++ don't really have a dependency tracking mechanism short of semi-manually digging through various autotools, cmake, or bazel build scripts trying to figure out what dependencies t

Re:

[i.r.id10t]

Since the previous census focused on Debian I imagine they are basing the data off the popularity-contest package, which reports up the chain what gets installed via apt/apt-get/synaptic/etc.

So I guess in theory the C/C++ library thing could be handled by determining which libs are being requested to be installed, and possibly how often or how many installed packages depend on them.

Unsure if other distros have the popularity-contest like package that provides package install info to a centralized location..

success of microsoft and apple APIs

[lkcl]

as someone who studied through reverse-engineering the Microsoft NT Domains Protocol from 1996-2000 it was with some frustration that i observed the practice of free software developers and packages lacking the coordination and committment to API compatibility that was clearly bludgeoned into both Apple and Microsoft developers from "top-down" decision-making (Steve, Bill).

DCE/RPC became MSRPC, on top of which COM and then DCOM was developed, and even now a 25-year-old Active-X component from a company that

Re:

[dowhileor]

i feel that COM came about when the web was that... interconnected set of standards about interactive connectivity... and not too much more. so when COM/DCOM interfaces rolled out, the environment was .."if you didn't want to know how this worked by now you just never wanted to..". An attempt at API standardization before it became a thing. and early on the closest thing logically to an interface standard were things like IPC, RPC, then what ever modules, as in linux (and bsd?) were beginning to look like a

Re:

[account_deleted]

Comment removed based on user account deletion

Re:

[dowhileor]

opinion. it is nature that makes code monolithic therefore you either have it all in front of you to figue what it does or you just have faith that it does what it was intended to do.

Re:

[account_deleted]

Comment removed based on user account deletion