Модуль 3. Типология исследовательского ПО

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

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

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

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

Таблица. Иерархия исследовательского ПО

Категория C1 включена для полноты иерархии. В терминах FAIR4RS это, как правило, уже не исследовательское ПО, а программное окружение исследования; на практике библиотечная поддержка здесь минимальна и ограничивается фиксацией версий в метаданных.

Сила модели – в ее наглядности и в прямой связи слоя с риском обрушения и с приоритетами сохранения. Проектный код (C4) обрушивается быстро, и для большинства таких объектов разумен облегченный режим – снимок версии с минимальными метаданными. Научная инфраструктура (C2), напротив, живет годами, и вложения в ее устойчивое курирование оправданны. Малвия-Тхакур и коллеги, построив каталог поддерживаемого научного ПО и разложив репозитории по слоям стека, эмпирически подтвердили продуктивность такого взгляда.

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

Хассельбринг и коллеги отказываются от единой иерархии и характеризуют код сразу по нескольким измерениям. Принципиально, что объект описывается по всем осям одновременно, а не относится к одной «ячейке»; основные оси – роль, зрелость и контекст разработки.

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

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

Контекст разработки – кто создает и поддерживает код: отдельный исследователь, исследовательская группа или проектный консорциум, распределенное сообщество, а иногда и внешний подрядчик. Контекст определяет модель управления (governance), процессы контроля качества и, что важно для библиотеки, распределение ответственности за сопровождение и сохранение.

К этим осям примыкает и способ распространения – как код доставляется пользователю: исходный код, пакет в репозитории пакетов (PyPI, CRAN), контейнер, веб-сервис, коммерческий продукт; он влияет на находимость и на то, какие действия по архивированию вообще возможны.

Четыре оси и их значения сведены в таблице.

Таблица. Оси многомерной категоризации исследовательского ПО

Если уровневая модель отвечает на вопрос «что это за ПО?», то многомерная – «зачем оно создано, насколько готово и кто его поддерживает?». Все эти вопросы существенны для выбора стратегии. Ограничение модели в том, что она задает набор характеристик, но сама по себе не подсказывает, как соединить их в решение.

Третье семейство моделей предполагает иной угол взгляда на код: не «какую функцию он выполняет», а «в каком виде он воплощен». Кох и коллеги на примере одного предметного пакета показали, что одно и то же ПО может существовать в нескольких формах одновременно: как исходный код с инструкциями по установке; как контейнер или зафиксированное окружение (Docker, Singularity); как веб-приложение, не требующее установки; как документация или программная статья (software paper). Каждая форма предъявляет свои требования к метаданным и свою стратегию сохранения: для контейнера нужно сохранить среду исполнения, для веб-сервиса – зафиксировать его поведение, для документации достаточно текста. Модель Коха и коллег построена на одном проекте и не проверена в других областях, но как инструмент для разговора о формах она удобна.

Джонс и коллеги дополнили картину со стороны идентификации. Они рассматривают код на нескольких вложенных уровнях: проект в целом (product) – конкретная версия (version) – вариант, адаптированный под определенную среду (variant) – конкретный установленный экземпляр (instance), с помощью которого получены те или иные результаты. Эта модель отвечает на вопрос, что именно становится объектом идентификатора (DOI) и цитирования. Без такого различения невозможно корректно присвоить постоянный идентификатор: одно дело – сослаться на проект в целом, другое – на ту версию, с помощью которой получены результаты статьи.

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

Хрупкость идентификации видна и на примере отдельных форм кода. Уоффорд и коллеги, проследив упоминания Jupyter-ноутбуков в астрономических публикациях 2014–2018 годов, обнаружили, что менее половины таких упоминаний вели к ноутбуку, который удавалось найти и открыть. Ноутбук – гибридный объект: он одновременно код, документ и иногда результат, и без постоянного идентификатора и фиксации окружения он быстро становится недоступным. Алноамани и Боргхи, опросив более двухсот исследователей, подтвердили, что под общим словом «ПО» скрывается множество разных форм – от инструментов сбора и очистки данных до средств анализа и визуализации, – и каждая форма требует своего решения о том, что и как идентифицировать.

Ряд авторов связывает типологические различия не с классификацией как таковой, а с практикой библиотечной работы. Эти рамки отвечают на вопрос «что библиотеке с этим делать».

Риос предложил «маршруты сохранения исследовательского ПО» (pathways of research software preservation) – по сути, типологию не форм кода, а стратегий его сохранения: от минимальной (архивировать исходный код как есть) через миграцию кода или среды до максимальной (зафиксировать вычислительное окружение целиком средствами эмуляции). Выбор маршрута зависит от роли кода, ожидаемого повторного использования и доступных ресурсов. Риос рассматривает курирование ПО как задачу развития сервиса в составе RDM-подразделения.

Шассанофф и Альтман концептуализировали «курирование ПО» (software curation) как библиотечную практику и предложили набор измерений курирования: виды деятельности, граничные условия, носители, документация, цели и сценарии. Код в их трактовке – не статичный самодостаточный артефакт, а динамичный, сетевой объект, зачастую глубоко зависящий от своего окружения. В развитие этого Шассанофф и коллеги по итогам кураторских стажировок предложили инструмент «профилей курирования ПО» (Software Curation Profiles) – облегченный шаблон, помогающий библиотечному куратору собирать у создателей и владельцев кода сведения, нужные для его сохранения. Этот инструмент снимает практическую трудность: определить, где вообще проходит граница объекта – исходники, конфигурации, окружения, документация.

Наконец, Ди Космо и коллеги описали реальный рабочий процесс кураторского архивирования кода во французском открытом архиве HAL совместно с Software Heritage. На этом примере видно, как библиотекарь-модератор оценивает депонируемый объект: что считать программным артефактом, какие метаданные и связи обязательны, как используются идентификаторы Software Heritage (SWHID) и как связываются между собой статья, данные и код. Это один из первых задокументированных примеров курирования ПО в универсальном репозитории, и в модуле 7 мы вернемся к нему как к образцу.

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

Историческая справка. Типологическое представление о коде заметно эволюционировало за десятилетие. В 2016–2017 годах основным был вопрос «является ли ПО самостоятельным научным объектом и как его идентифицировать и сохранять». В 2018–2020 годах сложились первые кураторские рамки и слоевое мышление, а также реальные репозиторные процессы. К 2023–2025 годам появились библиотечный стек C1–C4 и многомерные схемы категоризации. Сдвиг шел от вопроса «является ли код самостоятельным научным объектом?» к вопросу «какому типу кода какое курирование положено».

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

Таблица. Типология исследовательского ПО для библиотечной практики

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

Таблица. Дифференциация стратегий библиотечной поддержки по типам ПО

Логика таблицы – это логика триажа (распределения усилий по приоритету). Проектный код C4 встречается чаще всего и обрушивается быстрее всего, но и ожидания к нему скромнее: библиотеке достаточно дать исследователю шаблон README, чек-лист и автоматизировать депонирование снимка версии в Zenodo. Предметное ПО C3 требует более глубокой работы: помощи с тестированием, файлами CITATION.cff и CodeMeta, консультирования. Научная инфраструктура C1–C2 – область, где библиотека реже курирует объект напрямую и чаще выступает координатором, связывающим разработчиков с командами RSE и с реестрами.

Из всего модуля следует один принцип, к которому мы будем возвращаться: исследовательское ПО нельзя трактовать как монолитную категорию – ни в политиках, ни в повседневной работе. Скрипт анализа в Jupyter-ноутбуке и крупная библиотека научных вычислений требуют разного описания, разного цитирования и разного сохранения. Библиотекарь, получивший на курирование программный объект, начинает не с применения единого регламента, а с трех вопросов: на каком слое иерархии находится объект (C1–C4)? какова его роль и зрелость? в какой форме он представлен и что именно мы идентифицируем? Ответы на эти вопросы и определяют дальнейшие действия. Как мы увидим в модуле 5, действующие политики этого различения почти никогда не проводят – и в этом их слабое место.

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

Единой канонической типологии исследовательского ПО нет, и для библиотеки это нормально: задача не классифицировать исчерпывающе, а провести первичную сортировку. Три семейства моделей дополняют друг друга. Уровневые (Hinsen; Druskat et al.) располагают код по слоям C1–C4 и связывают слой с хрупкостью и приоритетом сохранения. Многомерные (Hasselbring et al.) характеризуют код по роли, зрелости, контексту разработки и способу распространения (последняя ось – дополнение составителя). Модели форм (Koch et al.; Jones et al.) описывают воплощение кода и уровни его идентификации. Кураторские подходы (Rios; Chassanoff, Altman; Di Cosmo et al.) переводят различия в библиотечные действия. Сведенные вместе, они дают рабочую рамку из трех измерений и логику триажа: разный уровень поддержки для разных типов ПО.

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

• Стек C1–C4 – четырехуровневая библиотечная классификация кода по месту в цепочке зависимостей.
• Многомерная категоризация – описание кода сразу по нескольким осям: роль, зрелость, контекст разработки, распространение.
• Модальность представления – форма воплощения кода: исходник, контейнер, веб-сервис, документация.
• Уровни идентификации – вложенные единицы кода (проект – версия – вариант – экземпляр), к которым может относиться идентификатор.
• Маршруты сохранения (preservation pathways) – стратегии сохранения кода: от архивирования исходника до фиксации окружения.
• Профиль курирования ПО (Software Curation Profile) – шаблон сбора у разработчика сведений о границах, владении, контексте и зависимостях кода.
• Триаж – распределение усилий по курированию в зависимости от типа и приоритета объекта.

1. Почему отсутствие единой типологии не мешает библиотечной работе с кодом?
2. На какой вопрос отвечает каждое из трех семейств моделей?
3. Чем проектный код C4 отличается от научной инфраструктуры C2 с точки зрения стратегии сохранения?
4. Что означает утверждение «код – не монолитная категория» применительно к практике курирования?

1. Подберите пять реальных программных продуктов и распределите их по слоям C1–C4. Для каждого укажите роль, предполагаемую зрелость и форму представления.
2. Для одного из объектов категории C4 и одного из категории C3 заполните мини-профиль курирования: границы объекта, владелец, контекст, зависимости.
3. Составьте проект памятки «Что мы предлагаем разработчику в зависимости от типа ПО» для вашей библиотеки.