В целом, вопрос о том, как померять сложность довольно любопытен. Более того это не просто бесцельное любопытство, он обладает и практической полезностью: если бы у нас был бы критерий, то на этапе проектирования программы мы могли бы оценивать разные проекты и сравнивать их по сложности. Или после, оценивая разные подходы к решению, мы могли бы выбирать самый простой.

Сия статья, как бы там не писали анонимы выше, не претендует на изобретение финального критерия. Она просто берёт какой-то критерий, и показывает нам результаты применения этого критерия. Статья -- это в большей мере исследование критерия сложности, а не сложности опенсорц проектов. Все критицизмы выше -- это результат того, что в переводе акценты оказались смещены.

Скажем есть принцип DRY (Don't Repeat Youself[1]), но некоторые говорят, что DRY для сосунков, и правильнее следовать принципу WET (Write Everything Twice) -- Кармак как-то агитировал в эту пользу, говоря о том, что писать обобщённую реализацию на двух примерах использования, это кошмар и приводит в конечном итоге к невозможности дальнейшей поддержки, вот когда есть две реализации функции, и нужна третья, вот на трёх примерах уже можно.

Критерий, который статья описывает, по-сути, заявляет что WET проще, чем DRY. Но ситуация ведь сложнее DRY в некоторых случаях упрощает жизнь, с DRY реализацией динамического массива, например, я могу быть уверен что вне вызовов метода этого массива всегда выполняются инварианты "arr->len <= arr->size", "arr->buf != NULL" и "для любого i (0 <= i < arr->len) arr->buf[i] -- не UB". Это очень упрощает жизнь. (Хотя и усложняет тоже: если на стеке любого потока есть стековый фрейм любого из методов динамического массива, то все гарантии коту под хвост, любой из вариантов может быть нарушен в это время).

Короче, сложность -- это сложно, но такие статьи радуют: люди пытаются померять сложность, может когда-нибудь кто-нибудь и придумает, как её померять хорошо. Впрочем, мне кажется, что эта статья слишком простую модель психики программиста использует, уровня правила 7+-2[1]... Мне кажется, занятно было бы попытаться определить "сложность" как функцию символа кода, которая говорит о том, сколько инвариантов программисту надо держать в голове, чтобы написать следующий символ, не совершив ошибку. Ну, типа если я написал "(7+", то дальше должен быть аргумент совместимый с операцией +, первым аргументом которой является целое число, и ещё потом надо не забыть закрыть скобочку. Возможно при этом результатом сложения должно быть число, на которые накладываются ограничения типа 0<=x<=len, иначе будет ошибка выхода за границы массива. Затем сверху ещё требования к алгоритмической корректности кода, и бла-бла-бла... И если бы такую функцию определить, а затем ещё научится считать программно, то после этого можно было бы попробовать проинтегрировать эту функцию по всему коду, и получить оценку сложности программы, которая действительно будет отражать насколько сложно работать с таким кодом. Или может не будет отражать, но пока не посчитаешь для конкретных программ, не поймёшь.

[1] https://ru.wikipedia.org/wiki/Don%E2%80%99t_r...
[2] https://ru.wikipedia.org/wiki/%D0%9C%D0%...