Если основная часть разрабатываемого продукта состоит из самостоятельно разработанного кода, то, скорее всего, вы впустую тратите силы и средства, изобретая колесо заново. Однако в связи с тем, что на сайтах вроде GitHub доступно огромное количество проектов Open Source, выбрать подходящие может быть трудно. Чтобы убедительно обосновать выбор, можно оценить код кандидата с точки зрения характеристик его функционала и собственно процесса его создания (см. таблицу).
.jpg)
Продукт
Функциональность
Выбор начинается с оценки функциональности рассматриваемого проекта: требуется определить, достаточно ли ее для удовлетворения необходимых текущих и будущих потребностей вновь создаваемого продукта. Например, при выборе системы формирования очередей сообщений нужно уточнить, соответствует ли используемый протокол обмена сообщениями стандарту де-факто в отрасли и масштабируется ли система согласно ожидаемым требованиям. Не менее важно выяснить, не слишком ли спектр возможностей превышает планируемые потребности. К примеру, если вам нужна только компрессия данных, сохраняемых в файл, то, скорее всего, не нужна библиотека архивации, поддерживающая многочисленные форматы. Выбор небольшого точечного проекта имеет ряд преимуществ: уменьшение места, занимаемого системой, снижение зависимости от сторонних разработок, упрощение процесса установки и сокращение потенциальной поверхности для кибератак.
Если функциональность проекта с открытым кодом почти соответствует требованиям нового продукта, но нет проекта, который удовлетворяет им полностью, то можно воспользоваться имеющимся и доработать его. В этой ситуации нужно тщательно рассмотреть вопросы, касающиеся изменения и дополнения исходного кода (см. таблицу).
Лицензирование
Для сужения поиска надо выяснить, совместима ли лицензия [1] проекта с бизнес-моделью нового продукта, задачами и уже применяемым программным обеспечением. Если в продукте используются компоненты, распространяемые по лицензии GNU General Public License, то на ее условиях придется распространять весь код проекта. Это может быть нежелательным, если бизнес-модель продукта требует держать код в секрете. В этом случае лучше выбирать проекты с менее требовательной лицензией — например, Berkeley Software Distribution или Apache. Если ПО будет предлагаться в виде сервиса, то надо воспользоваться проектом, распространяемым по Affero General Public License. Еще пример: ПО, выпущенное по лицензии Mozilla Public License 1.1, нельзя компоновать с кодом, лицензируемым по GNU General Public License.
Нефункциональные характеристики
Далее следует выяснить, совместимы ли системные требования рассматриваемого проекта с продуктом, подходят ли архитектура процессора, операционная система, связующее ПО. Если, скажем, продукт работает в macOS, но планируется его вывод на рынок Windows, то нужны библиотеки с открытым кодом, поддерживаемые в обеих ОС. Затем надо уточнить, соответствует ли производительность открытого проекта ожидаемым требованиям. Это особенно важно при выборе базы данных или инфраструктуры анализа больших данных. Если производительность критична, не стоит полагаться на опубликованные характеристики — надо провести сравнительное тестирование на реальных нагрузках.
Популярность
Если проект популярен, то его обычно развивают много участников и тогда больше шансов получить на онлайн-форумах ответы на вопросы поддержки. Кроме того, выше вероятность продолжения эволюции проекта в случае, если его инициаторы утратят интерес или изменят направление развития. Оценить популярность можно по количеству звезд на GitHub, вопросам на StackOverflow с соответствующим тегом, запросам в Google и числу загрузок релизов.
Документация
Ответы на большинство вопросов относительно работы ПО можно получить, проанализировав его исходный код, но это весьма трудоемко, поэтому нужно оценить качество документации проекта — как технической (описание процедур инсталляции, сопровождения и др.), так и пользовательской (обучающие материалы, справочные руководства). В отношении большинства крупных проектов претензий обычно нет, но мелкие могут документироваться плохо. Попадаются, например, утилиты командной строки Unix без стандартной страницы руководства. Таких проектов лучше избегать, чтобы не тратить время на «вычисление» опций командной строки, а кроме того, пренебрежение интересами конечного пользователя может быть признаком наличия других проблем.
Исходный код
Теперь нужно проверить исходный код и его качество. Если разработку планируется адаптировать согласно требованиям нового продукта, то нужно выбирать проект, написанный на знакомом языке программирования. На качество кода нужно обратить внимание, даже если не планируется его менять: ошибки, уязвимости, узкие места производительности и трудности сопровождения могут негативно отразиться на работе. При этом не нужно разбираться во всех подробностях, чтобы получить объективное представление о характеристиках кода. Чтобы отбросить проблематичный проект, достаточно обратить внимание на файлы исходного кода: хорошим тоном считается, если они названы и размещены в каталогах в соответствии со стандартами используемого языка программирования. Должны присутствовать признаки того, что проект подвергается модульному тестированию, а в репозитории не должно быть посторонних вхождений, например объектных и исполняемых файлов. Хорошо, если методы или функции лаконичные и читаемые, идентификаторы имеют мнемонические названия, в коде достаточно комментариев, а его форматирование соответствует стандартам языка — отклонения могут свидетельствовать о скрытых недостатках.
Процедура сборки
Характеристики процесса сборки исполняемого кода важны по двум причинам. Проекты Open Source могут использоваться в форме двоичных библиотек, компонуемых с другим кодом, или в виде исполняемых файлов, работающих в текущей инфраструктуре. В этих случаях в какой-то момент может понадобиться выполнить сборку двоичного файла из исходного кода — для исправления ошибки или добавления новой функции. В крупных организациях обычно действуют правила, запрещающие использование двоичных файлов, загруженных из Интернета, и имеются процессы, позволяющие самостоятельно выполнять сборку проектов из исходного кода.
В любом случае имеет смысл проверить, насколько проста процедура сборки, задокументирована ли она, можно ли ее провести в среде разработки нового продукта, понадобятся ли малоизвестные инструменты, не поддерживаемая никем среда разработки или компилятор с экзотического языка программирования. Если выбирается проект, который станет критически важной зависимостью, перечисленные факторы надо оценивать так же тщательно, как и проект, который планируется использовать в качестве основы нового продукта.
Процесс
Даже если проект кажется идеально подходящим, нужно потратить время на изучение процессов его выпуска и управления — от них могут зависеть перспективы его применения в долгосрочной перспективе. Кроме того, здесь могут всплыть недостатки, оставшиеся незамеченными при исследовании проекта.
Разработка
При оценке качества процесса разработки проекта надо, в частности, выяснить, практикуется ли в нем непрерывная интеграция. Это просто определить по наличию соответствующих конфигурационных файлов (.travis.yml, Jenkinsfile) в каталоге проекта. Следует также уточнить, какие компоненты включены в конвейер непрерывной интеграции, предусмотрены ли статический анализ кода и модульное тестирование, выполняются ли сборка и проверка орфографии документации, подсчитывается ли тестовое покрытие, осуществляется ли контроль соблюдения стандартов кодирования, реализуется ли проверка зависимостей на актуальность. Ответы на эти вопросы можно получить, ознакомившись со значками на странице проекта в GitHub, хотя их наличие не всегда показатель качества проекта.
Фиксации кода
Важно обратить внимание на фиксацию кода в репозитории управления ревизиями. Отсутствие свежих фиксаций может означать, что при обнаружении ошибки или появлении новых требований они останутся без внимания. Исключение — стабильные проекты и лишь сохраняющие фиксацию (например, библиотеки функций численного анализа). Тревожным сигналом может быть присутствие фиксации только от одного или нескольких авторов — в этом случае существует риск, называемый «фактором автобуса» (если ведущий разработчик попадет под автобус, развитие проекта завершится). Надо подробно изучить несколько фиксаций: они должны иметь понятные метки и описания, а также ссылки на задокументированные проблемы, исправленные согласно стандартной процедуре. Должны быть свидетельства того, что изменения кода обсуждались и подвергались ревизиям.
Релизы проекта
Далее следует разобраться, насколько свежими являются последние релизы проекта и как часто они публикуются. Если речь идет о проекте в области современных технологий (скажем, библиотеки глубинного обучения), обновления должны быть регулярными, а в случае стабильных проектов должны присутствовать свежие релизы с исправлениями. В некоторых случаях частая интеграция новых релизов компонента Open Source в кодовую базу нового продукта может быть нежелательной ввиду рисков и дополнительного объема работы. Чтобы избежать проблем такого рода, можно обратиться к специальному каналу релизов, на котором выходят только заплаты и критические исправления. Также, чтобы свести к минимуму проблемы с интеграцией крупных обновлений, надо уточнить, предусмотрены ли в проекте релизы с долгосрочной поддержкой и соответствуют ли их сроки действия графику выпуска вашего продукта.
Каналы поддержки
Устранять проблемы в проекте с открытым кодом собственными силами — это крайняя мера. Как правило, для их решения обращаются на онлайн-форум, поэтому надо выяснить, имеется ли у рассматриваемого проекта подобный форум, список рассылки или чат, в котором можно задать вопросы. Следует разобраться, насколько быстро поступают полезные ответы, насколько участники форума дружелюбны и готовы прийти на помощь. Нередко качество самого проекта не соответствует качеству его поддержки. Например, у некоторых проектов с посредственным кодом может быть превосходная поддержка, и наоборот. Если требуется компонент для корпоративного продукта, в рамках которого вряд ли стоит полагаться на помощь энтузиастов в решении критических проблем, то стоит изучить качество платных услуг поддержки, которые могут предлагаться специализированными компаниями, в том числе для платных дистрибутивов на основе того же проекта.
Разрешение проблем
Рано или поздно в используемом проекте с открытым кодом могут обнаружиться ошибки, поэтому стоит выяснить, как его участники решают проблемы такого рода. Во многих проектах есть доступ к системе управления проблемами (GitHub Issue, Bugzilla, Jira), где можно в деталях уточнить соответствующие процедуры. Следует выяснить, насколько быстро разрешаются проблемы, много ли из них остаются открытыми в течение длительного срока и сбалансировано ли соотношение открытых и закрытых проблем с учетом количества участников проекта.
Внесение исправлений и улучшений
Со временем может понадобиться внести изменения в исходный код проекта — для исправления ошибки или реализации новой возможности. Здесь можно сохранить изменения только для своего продукта, однако их интеграция в проект Open Source способствует развитию проекта и стимулирует выпуск новых релизов, не говоря уже о соблюдении требований лицензии. Надо оценить, насколько просты процедуры внесения исправлений и доработки, уточнить наличие инструкции для участников. Если для продукта используются двоичные файлы проекта, то надо выяснить, легко ли будет провести сборку из исходного кода и тестирование. Полезно определить, насколько сложна процедура приемки изменений, и узнать, можно ли предоставить их удобным способом — например, посредством запроса на включение изменений (pull request) GitHub. Затем стоит выяснить, насколько регулярно в рамках проекта принимаются изменения от сторонних участников, поскольку некоторые организации выпускают проекты по лицензии открытого кода, но при этом ограничивают возможность внесения изменений в него третьими сторонами.
***
Все приведенные критерии выбора одинаково важны, и их нужно обязательно учитывать, чтобы избежать неприятных сюрпризов и издержек из-за замены одного проекта на другой. Таблицей можно пользоваться и для выяснения степени значимости различных критериев в разном контексте. В частности, критерии с цветовой маркировкой относятся к решающим факторам, влияющим на отсеивание проекта. Если проблемы обнаружились при проверке критериев из столбца с желтой маркировкой, значит, придется формировать собственные ресурсы для поддержки проекта с открытым кодом. А если принимается решение обеспечивать такую поддержку, то нужно уделить повышенное внимание вхождениям, отмеченным зеленым. Выполнение всех перечисленных проверок дает хорошие шансы наладить крепкие, долгосрочные и взаимовыгодные отношения с проектами Open Source, выбираемыми для создания нового продукта.
Литература
1. A. Morin, J. Urban, P. Sliz. A quick guide to software licensing for the scientist-programmer // PLOS Comput. Biol. — 2012. — vol. 8, N. 7. — P. 1–7.
2. A. Trockman, S. Zhou, C. Kastner, B. Vasilescu. Adding sparkle to social coding: An empirical study of repository badges in the npm ecosystem. In Proc. 40th Int. Conf. Software Engineering, 2018. — P. 511–522.
3. K. Yamashita, S. McIntosh, Y. Kamei, A. E. Hassan, N. Ubayashi. Revisiting the applicability of the Pareto principle to core development teams in open source software projects. In Proc. 14th Int. Workshop Principles of Software Evolution, 2015. — P. 46–55.
Диомидис Спинеллис (dds@aueb.gr) — профессор, Афинский университет экономики и бизнеса.
Diomidis Spinellis, How to Select Open Source Components. IEEE Computer, December 2019, IEEE Computer Society. All rights reserved. Reprinted with permission.
