Модуль 2. Исследовательское ПО

Прежде чем выстраивать практики курирования, нужно договориться о предмете. Здесь нет единственно верной формулировки, и расхождения между определениями содержательны – в них видно, какие свойства кода разные сообщества считают существенными.

Наиболее цитируемое определение предложила рабочая группа FAIR4RS. Грюнпетер и коллеги понимают под исследовательским ПО «исходный код, алгоритмы, скрипты, вычислительные конвейеры (workflows) и исполняемые файлы, которые были созданы в ходе исследовательского процесса или для исследовательских целей». В этом определении важны два момента: акцент на исследовательском происхождении или назначении и широта перечня форм – от отдельного скрипта до конвейера обработки.

Немецкий научный фонд (DFG) в своих рекомендациях по обращению с исследовательским ПО  использует близкую формулировку, но добавляет функциональный аспект: код применяется «для сбора, анализа, симуляции, обработки, представления или использования данных наблюдений и измерений либо оцифрованных текстовых, изобразительных, кино- и звуковых источников, предметов и т.п., для построения научных моделей, управления научными приборами или оптимизации процессов». DFG подчеркивает, что определение охватывает самые разные проекты, различающиеся по предмету, тематике и качеству, и что к исследовательскому ПО обычно примыкают сопутствующие элементы – техническая документация, руководства пользователя, параметризация, планы управления, цифровые лабораторные журналы.

Сообщество Helmholtz определяет исследовательское ПО лаконично – как «код (исходный код вместе с документацией, параметрами и рабочими процессами), разрабатываемый или повторно используемый в ходе исследовательской деятельности», – и сразу формулирует нормативный тезис: код есть «самостоятельный продукт исследовательского процесса», который, подобно другим методам, должен документироваться, публиковаться и признаваться.

В руководстве мы используем расширенное определение, согласующееся с библиотечным подходом Друската и коллег: исследовательское ПО – это любой программный код (включая скрипты, библиотеки, фреймворки и приложения), созданный, модифицированный или используемый в ходе научного исследования, независимо от его роли.

А роль может быть троякой: код бывает конечным результатом (например, опубликованный пакет, реализующий новый метод), инструментом (скрипт, с помощью которого получены результаты другой работы) или инфраструктурным компонентом (библиотека, на которую опираются десятки проектов). Эта тройственность ролей понадобится нам в модуле 3 при построении типологии.

Здесь нужна оговорка, важная для курирования. Сами авторы FAIR4RS проводят границу: компоненты, которые используются в исследовании, но созданы не в ходе него и не с ясным исследовательским намерением – операционные системы, универсальные языки, библиотеки, пакеты, – они предлагают считать не исследовательским ПО, а программным окружением исследования, добавляя, что граница может проходить по-разному в разных дисциплинах. Расширенное определение с этой границей расходится сознательно и по практической причине: библиотеке приходится описывать и фиксировать не только исследовательский объект, но и то, от чего он зависит. Поэтому в дальнейшем полезно различать два режима работы. Программный объект, созданный в исследовании или для него, курируется как самостоятельный результат: ему присваивают идентификатор, оформляют лицензию, метаданные и цитирование. Компоненты общего окружения фиксируются как зависимости и сведения о среде – в файле зависимостей и в метаданных объекта, – но самостоятельными объектами курирования не становятся.

Соблазнительно встроить код в уже отлаженные процессы работы с данными: завести для него те же поля метаданных, тот же тип записи в репозитории, тот же порядок депонирования. Баркер и коллеги, формулируя принципы FAIR4RS, подчеркивают: уникальные свойства кода – исполняемость, составная природа, непрерывная эволюция и версионность – потребовали не прямого переноса принципов FAIR с данных, а их пересмотра и расширения. Обращаться с кодом как с данными – значит упустить его существо.

Различие можно описать через противопоставление объекта и агента. Данные – это объект: они хранят информацию, их можно прочитать, скопировать, процитировать. Код – объект и агент одновременно: он не только описывается и хранится, но и выполняет операции, в том числе над данными. У этой двойственности есть прямое следствие для курирования: сохранить код как текст недостаточно – нужно сохранить его способность работать, а значит, и окружение, в котором он работает.

Второе различие – в жизненном цикле. Набор данных фиксируется на момент публикации: он не меняется сам по себе. Код развивается непрерывно, существует во множестве версий и веток, и вопрос «какую именно версию мы описываем и цитируем?» становится содержательным. Из этого вырастает и проблема гранулярности идентификации, к которой мы вернемся в модуле 4.

Сведем различия между данными и программным обеспечением в систему. Таблица сопоставляет их по восьми параметрам; ниже каждый параметр прокомментирован.

Таблица. Сравнение программного обеспечения и данных как объектов открытой науки

Таблица описывает типичные различия, а не сущностную границу: данные тоже бывают динамическими и версионируемыми, а без схем, сведений о происхождении и программ обработки бывают бесполезны. Поэтому объектом курирования нередко оказывается связка данных, кода, параметров и вычислительного окружения.

Онтологический статус. Уже разобран выше: данные хранят информацию, код производит над ней операции. Практический вывод – описание кода должно фиксировать не только то, что он представляет собой, но и то, что он делает: входы, выходы, выполняемую функцию.

Жизненный цикл. Данные, как правило, статичны после публикации, код динамичен. Поэтому для кода недостаточно одной записи – нужна модель, связывающая проект в целом с его конкретными релизами.

Гранулярность идентификации. У данных естественная единица – набор данных или файл. У кода несколько единиц, вложенных друг в друга: проект, конкретная версия, вариант для определенной среды, установленный экземпляр, с помощью которого получены те или иные результаты. Прежде чем присваивать идентификатор, нужно решить, что именно идентифицируется.

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

Воспроизводимость. Для данных доступ к файлу, как правило, означает возможность их использовать. Для кода доступ к исходнику – необходимое, но недостаточное условие: чтобы получить тот же результат, нужны работающее окружение и совместимые зависимости. Различие между «исходный код доступен» и «программа работает» проходит через все дальнейшие модули.

Лицензирование. Данные обычно публикуются под лицензиями семейства Creative Commons или специализированными открытыми лицензиями на данные. Для кода применяются лицензии, одобренные Open Source Initiative (OSI): MIT, Apache-2.0, GPL и другие. Различие не формальное: лицензии на код регулируют не только копирование, но и модификацию, распространение производных произведений и совместимость с другим кодом (см. модуль 4 и приложение Б).

Стандарты метаданных. Для данных сложились Dublin Core, DataCite, DDI. Для кода нужны схемы, способные описать его специфику: CodeMeta, формат файла цитирования CITATION.cff, словарь schema.org/SoftwareApplication. Привычные библиотечные схемы здесь недостаточны.

Цитирование. Набор данных обычно цитируется через свой DOI. Для кода вопрос сложнее: сослаться нужно на ту версию, с помощью которой получены результаты, и для этого достаточно идентификатора версии (version DOI). Идентификатор проекта в целом (concept DOI) нужен тогда, когда речь намеренно идет о развивающейся программе, а не о конкретном релизе. Машиночитаемый файл цитирования полезен, но условием корректной идентификации не является. Подробно эта схема разобрана в модуле 4.

Хинсен ввел понятие «обрушения программного обеспечения» (software collapse): программа перестает работать не потому, что в ее собственный код внесли изменения, а потому, что изменилось ее окружение – обновились библиотеки, на которые она опирается, сменилась версия языка или операционной системы. Чем выше «этаж», на котором живет код, тем он уязвимее – проектный скрипт, опирающийся на десяток внешних пакетов, обрушивается быстрее, чем базовая вычислительная библиотека.

Масштаб проблемы измерим: Мангул и коллеги, проанализировав сетевую доступность 36 702 программных инструментов из области омиксных наук, опубликованных в 2005–2017 годах, и проверив возможность установки на отдельной случайной выборке инструментов, обнаружили, что около половины не проходят простой установки, а заметная часть не устанавливается вовсе. Пир и коллеги, повторно проверив код из архива одного из политологических хранилищ, обнаружили, что часть исследований не воспроизводится из-за устаревания кода. Из этих наблюдений авторы выводят идею «активного сопровождения» (active maintenance): сохранение работоспособного кода – не разовое депонирование, а длящаяся задача.

Для библиотеки отсюда следует принципиальный вывод: сохранить код – не то же самое, что сохранить его файл. В зависимости от типа объекта и ожидаемого повторного использования стратегия сохранения варьируется от минимальной (архивировать исходный код с метаданными) до максимальной (зафиксировать и сохранить вычислительное окружение целиком, например в виде контейнера или образа виртуальной машины). Эту шкалу стратегий мы детализируем в модулях 3 и 7.

Если код так похож на полноправный научный объект, почему бы не положить его в тот же институциональный репозиторий, что и статьи с наборами данных? Карлин и коллеги показывают, что на практике так почти и не делают: большинство репозиториев даже не предусматривают программное обеспечение как самостоятельный тип научного результата. Причина глубже: существующие схемы описания и типовые институциональные репозитории не приспособлены к специфике кода – в них нет полей для зависимостей, для связи между версиями, для фиксации совместимости окружений. Запись о программе в таком репозитории описывает ее как статичный документ, теряя ровно то, что делает код кодом.

Отсюда – двойная задача для библиотек и RDM-служб. Во-первых, освоить специализированные форматы и инфраструктуры: CodeMeta и CITATION.cff для метаданных, Zenodo и Software Heritage для архивирования и идентификации, реестры исследовательского ПО для находимости. Во-вторых, научиться различать типы программных объектов, чтобы не применять к скрипту те же требования, что к зрелой библиотеке, и наоборот. Решению второй задачи посвящена следующий модуль.

Исследовательское ПО – это код, созданный или используемый в исследовании, в роли результата, инструмента или инфраструктуры. Оно не сводится к разновидности данных: код одновременно объект и агент, «живет» во множестве версий, зависит от вычислительного окружения и требует не только доступа, но и работоспособности окружения. По восьми параметрам – от онтологического статуса до цитирования – код систематически отличается от данных. Его хрупкость описывается понятием «обрушения ПО» и измеряется эмпирически. Привычные библиотечные схемы и репозитории не приспособлены к этой специфике, что и формирует запрос на специализированные практики курирования.

Ключевые термины

• Исследовательское ПО (research software) – код (скрипты, библиотеки, фреймворки, приложения), созданный или используемый в исследовании; может быть результатом, инструментом или инфраструктурой.
• Объект и агент – двойственная природа кода: он и описывается/хранится, и выполняет операции.
• Обрушение ПО (software collapse) – утрата работоспособности кода из-за изменений в его окружении, а не в нем самом.
• Зависимости – внешние библиотеки, версии языка, ОС и компиляторы, необходимые для запуска кода.
• Активное сопровождение (active maintenance) – понимание сохранения работоспособного кода как длящейся задачи, а не разового акта.

1. Сравните определения исследовательского ПО у FAIR4RS, DFG и Helmholtz. Что общего и в чем смысловые акценты различаются?
2. Почему фразу «исходный код доступен» нельзя считать синонимом «программа воспроизводима»?
3. Перечислите восемь параметров, по которым код отличается от данных, и приведите для трех из них практическое следствие для курирования.
4. Что такое «обрушение ПО» и какие эмпирические данные подтверждают его распространенность?

1. Выберите любой опубликованный научный пакет (например, на GitHub) и определите его роль: результат, инструмент или инфраструктура. Обоснуйте выбор.
2. Откройте запись о программном продукте в любом институциональном репозитории и проверьте, какие из специфичных для кода полей (версия, зависимости, окружение, связь версий) в ней присутствуют, а какие отсутствуют.
3. Составьте короткую (на полстраницы) служебную записку для руководства библиотеки, объясняющую, почему код нельзя описывать теми же средствами, что и наборы данных.