<story><title>Finding Critical Open Source Projects</title><url>https://opensource.googleblog.com/</url></story><parent_chain><item><author>hn_throwaway_99</author><text>As others have mentioned, while this may seem like a good idea, the results are often bizarre, and it&amp;#x27;s not hard to see why - the metrics and algorithm are here: &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;github.com&amp;#x2F;ossf&amp;#x2F;criticality_score#criticality-score&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;github.com&amp;#x2F;ossf&amp;#x2F;criticality_score#criticality-score&lt;/a&gt;.&lt;p&gt;That algorithm seems unnecessarily complicated and includes somewhat dubious metrics when, in my mind, the only thing that really &amp;quot;counts&amp;quot; when it comes to &amp;quot;criticality&amp;quot; are &amp;quot;how many other things use&amp;#x2F;depend on me&amp;quot;, and there are much easier ways to determine this:&lt;p&gt;1. For languages with a common package repo, how many other packages depend on me? With NPM, for example, it&amp;#x27;s pretty easy to figure out how many other packages depend on a given package.&lt;p&gt;2. For &amp;quot;top level&amp;quot; projects, look at downloads.&lt;p&gt;My guess is just looking at either (or both) of those metrics would give you better results.</text></item></parent_chain><comment><author>mbakke</author><text>One cool feature of functional package managers such as Nix and Guix is that the dependency graphs are entirely transparent and can be inspected programmatically.&lt;p&gt;I wrote a script that lists the number of dependents for each package in Guix by traversing the package graphs:&lt;p&gt;&lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;gist.github.com&amp;#x2F;mbakke&amp;#x2F;f354272666fbef09c5229f7b853778f1&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;gist.github.com&amp;#x2F;mbakke&amp;#x2F;f354272666fbef09c5229f7b85377...&lt;/a&gt;&lt;p&gt;Running it takes about 16 seconds on my laptop, and piping to &amp;#x27;grep -v bootstrap | sort -rn | tail -n 20&amp;#x27; gives:&lt;p&gt;&lt;pre&gt;&lt;code&gt;  16695 guile
  16692 ld-wrapper
  14686 pkg-config
  14512 perl
  14444 ncurses
  13135 readline
  13133 zlib
  13022 libffi
  12470 xz
  12448 libunistring
  12433 openssl
  12353 bash
  12050 libxml2
  12016 gettext-minimal
  11950 tar
  11942 bzip2
  11896 expat
  11857 tzdata
  11850 net-base
  11846 python-minimal
&lt;/code&gt;&lt;/pre&gt;
(GCC, glibc and binutils are missing for complicated reasons, but should be up there with Guile)&lt;p&gt;By changing (all-packages) on line 26 to:&lt;p&gt;&lt;pre&gt;&lt;code&gt;  (fold-packages (lambda (package result)
                   (if (string-prefix? &amp;quot;python-&amp;quot; (package-name package))
                       (cons package result)
                       result))
                 &amp;#x27;()))
&lt;/code&gt;&lt;/pre&gt;
We get the most popular Python projects:&lt;p&gt;&lt;pre&gt;&lt;code&gt;  6672 python-setuptools-scm
  6667 python-nose
  6662 python-pyparsing
  6662 python-more-itertools
  6661 python-wcwidth
  6660 python-py
  6660 python-pluggy
  6660 python-atomicwrites
  6657 python-six
  6593 python-mock
  6587 python-appdirs
  6586 python-lxml
  6584 python-filelock
  6584 python-distlib
  6583 python-sortedcontainers
  6580 python-hypothesis
  6577 python-elementpath
  6576 python-xmlschema
  6575 python-pytest
  6303 python-libxml2
&lt;/code&gt;&lt;/pre&gt;
This approach misses &amp;quot;end user&amp;quot; packages such as browsers and QEMU, but provides some insight into high value targets.&lt;p&gt;For end user packages, Debians &amp;quot;popularity contest&amp;quot; can be useful:&lt;p&gt;&lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;popcon.debian.org&amp;#x2F;&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;popcon.debian.org&amp;#x2F;&lt;/a&gt;</text></comment>
<story><title>Finding Critical Open Source Projects</title><url>https://opensource.googleblog.com/</url></story><parent_chain><item><author>hn_throwaway_99</author><text>As others have mentioned, while this may seem like a good idea, the results are often bizarre, and it&amp;#x27;s not hard to see why - the metrics and algorithm are here: &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;github.com&amp;#x2F;ossf&amp;#x2F;criticality_score#criticality-score&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;github.com&amp;#x2F;ossf&amp;#x2F;criticality_score#criticality-score&lt;/a&gt;.&lt;p&gt;That algorithm seems unnecessarily complicated and includes somewhat dubious metrics when, in my mind, the only thing that really &amp;quot;counts&amp;quot; when it comes to &amp;quot;criticality&amp;quot; are &amp;quot;how many other things use&amp;#x2F;depend on me&amp;quot;, and there are much easier ways to determine this:&lt;p&gt;1. For languages with a common package repo, how many other packages depend on me? With NPM, for example, it&amp;#x27;s pretty easy to figure out how many other packages depend on a given package.&lt;p&gt;2. For &amp;quot;top level&amp;quot; projects, look at downloads.&lt;p&gt;My guess is just looking at either (or both) of those metrics would give you better results.</text></item></parent_chain><comment><author>outsomnia</author><text>Github&amp;#x27;s downloads don&amp;#x27;t tell you when FAANG added your project to their internal project tree, which is then deployed in hundreds of millions of devices.</text></comment>