Google presented a methodology for calculating and rating the importance of open source projects / ServerNews

Google has developed a system that allows you to assess the importance of certain open source projects. The company said that at the moment, many projects in this category are forced to fight for funding and a place in the market. However, they are used in many mission-critical systems.

Google, as part of the Open Source Security Foundation (OpenSSF), intends to make it easier to define the importance of a project. Authors of important projects can turn to OpenSFF for help and receive funding or the necessary infrastructure for the project.

To calculate the so-called criticality level, an algorithm is used that was proposed by the programmer Rob Pike. Its essence is in the use of ten weight coefficients, by which the final indicator is calculated in the range from 0 to 1. That is, from the minimum to the most critical.

Criteria include the age of the project, the number of individuals and organizations involved, user participation, and so on. It is permissible to add your own parameters to assess the level of criticality.

Once such projects have been identified, it is planned to provide them with the necessary resources to improve the performance of open source projects. A complete list of such projects is available here.

However, now only projects hosted on GitHub are taken into account. Therefore, there are some distortions in the rating. For example, the Top 3 C projects include Git and two versions of the Linux kernel at once – separately for the Raspberry Pi and the main branch. Among the projects in C ++, TensorFlow, Ceph and PyTorch are in the top three, and Elasticsearch, Apache Flink, and Spring Boot in Java. For JavaScript, the Top 3 includes Node.js, React Native and React, and for Python – SaltStack, Core Python, pandas. Well, in the case of Rust, these are Servo, Cargo and Clippy.

Note that this solution makes sense in a security context as well. Earlier it was reported that the number of attacks with substitution of open source code increased by 430%. And the point is not that open source software is worse than proprietary software, but only in the lack of opportunities for analyzing vulnerabilities at the development and debugging stage.