Модуль 8. Библиотечный сервис поддержки исследовательского ПО

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

Дополнительный довод дает сам ландшафт политик (модуль 5). Фонды – слабое звено, и внешнего требования работать с кодом почти нет. Это означает, что инициатива остается за организацией, и библиотека – естественный кандидат на роль инициатора. DFG прямо называет один из ориентиров: «разработка исследовательского ПО как услуга» (RSE as a service), а собственные инфраструктуры кода финансирует через программы библиотечных служб (модуль 5). Иначе говоря, в глазах фонда библиотека – полноправный институциональный участник этой работы; задача – соответствовать этому ожиданию.

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

Можно выделить три уровня поддержки, построенные по трем слоям артефактов (модуль 4):

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

Глубина поддержки конкретного объекта определяется его типом (модуль 3): проектному коду C4 достаточно базового уровня, предметному ПО C3 нужен продвинутый, инфраструктуре C1–C2 – экспертный. Сервис, таким образом, не применяет единый регламент ко всем обращениям, а сортирует их по типу и ведет на соответствующую глубину.

Работа с кодом требует распределения ролей. Библиотекарь и RDM-специалист берут на себя то, что близко к традиционной библиотечной компетенции: метаданные, идентификаторы, лицензии, депонирование, обучение, консультирование. Инженер исследовательского ПО (RSE) отвечает за инженерную часть: тестирование, контейнеризацию, рецензирование кода. Между этими ролями нужна связка, и библиотека может выступить координатором, направляющим исследователя к нужному специалисту.

Карвер и коллеги по итогам опроса исследователей показали, что запрос на обучение и поддержку устойчивой разработки велик, а предложение скудно; это пространство библиотека способна занять. Мулезон Сэнди и коллеги описали, как в научных библиотеках складываются компетенции поддержки научной коммуникации, увязанные с этапами исследовательского цикла, – и поддержка кода органично встраивается в этот набор. Ключевая компетенция, которую библиотеке предстоит освоить дополнительно, – понимание специфики кода: версий, зависимостей, окружений, форматов CodeMeta и CITATION.cff. Это не превращает библиотекаря в программиста, но позволяет вести предметный разговор с разработчиком и корректно курировать депонируемый код.

Чтобы прием кода на курирование был систематическим, нужны инструменты сбора сведений. Здесь полезны две практики.

Профиль курирования ПО (Software Curation Profile) – облегченный шаблон, по которому библиотечный куратор собирает у создателей и владельцев кода сведения, нужные для его сохранения: где проходят границы объекта, кто им владеет, каков контекст и каковы зависимости. Профиль снимает первую трудность приема: определить, где проходит граница объекта – только исходники или также конфигурации, окружения, документация. Заполненный профиль дает библиотекарю основу для выбора стратегии (модуль 3) и для оформления метаданных (модуль 4).

План управления ПО (software management plan, SMP) – документ, описывающий обращение с кодом на протяжении проекта, по аналогии с планом управления данными. DFG (модуль 5) не требует подавать SMP, но предлагает обосновывать в заявке принципиальные решения о типе кода, разработке, доступности и сопровождении; Helmholtz рекомендует разрабатывать шаблоны SMP. Библиотека может предложить такой шаблон исследователям своей организации, не дожидаясь требований фонда, – и тем самым перенести на код успешную модель планов управления данными.

Если организация принимает код в институциональный репозиторий, репозиторий нужно к этому подготовить. Рабочая группа FORCE11 сформулировала девять рекомендуемых практик для реестров и репозиториев исследовательского ПО (модуль 4): публичная политика приема, руководства для пользователей и для контрибьюторов, политика авторства, документированная и версионированная схема метаданных, условия использования, политика приватности, политика хранения и политика завершения жизненного цикла. Эти девять практик определяют чек-лист настройки.

На практике удобнее не строить все с нуля, а опереться на существующие инфраструктуры: интеграцию GitHub с Zenodo для архивирования и присвоения DOI, Software Heritage для сохранения исходного кода и получения SWHID (модуль 7). Роль библиотеки – настроить институциональную сторону этой интеграции (например, сообщество организации в Zenodo, в которое собираются депонируемые объекты) и встроить в процесс приема проверку обязательных полей: лицензия, идентификатор, цитирование, зависимости.

Обучение – наиболее масштабируемая часть сервиса. Структуру обучающей программы удобно строить по трем уровням поддержки: базовый курс по ядру категорий, продвинутый по воспроизводимости, экспертный по устойчивости. Образцом формата служит модель Carpentries – коротких практических семинаров по основам научных вычислений и работы с данными; те же принципы переносятся на обучение публикации кода. Практикум модуля 7 пригоден как основа базового курса: шаги 1–7 укладываются в двухчасовой семинар – при подготовленных учебных репозиториях и работе в песочнице Zenodo; правовую проверку реального кода в эти два часа включать не стоит, а приложения А–В содержат готовые раздаточные материалы.

Развитие сервиса полезно измерять в понятных показателях: число депонированных программных объектов с DOI, доля объектов с файлом CITATION.cff и лицензией, число проведенных консультаций и обучающих мероприятий. Такие показатели считают активность, и растут они легко – в том числе за счет лишних депозитов и идентификаторов, никому не нужных. Поэтому к ним стоит добавить показатели качества: долю записей с полными и валидными метаданными, разрешаемость выданных идентификаторов, точность ссылок на конкретные версии, долю выборочно проверенных объектов, которые удалось установить и запустить заново, число случаев, когда до публикации были сняты риски по правам или персональным данным, и подтвержденное повторное использование депонированного кода. Для самооценки охвата применима матрица «тринадцать категорий на шкалу R/E/N» (модуль 5): ею библиотека проверяет, насколько собственная политика и требования значимых для ее исследователей журналов и фондов покрывают категории рамки, и где остаются пробелы.

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

Сведем сказанное в последовательность шагов, с которой библиотека может начать.

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

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

Поддержка кода складывается в самостоятельный библиотечный сервис, родственный сервисам управления данными, но учитывающий специфику версий, зависимостей и окружений. Сервис строится по модели зрелости – от осведомленности к регулированию – и предлагает три уровня поддержки, построенные по слоям артефактов и соотнесенные с типами ПО. Он опирается на распределение ролей (библиотекарь, RDM-специалист, RSE), на инструменты приема (профили курирования, планы управления ПО), на настроенный по девяти практикам репозиторий и интеграцию с Zenodo и Software Heritage, на трехуровневое обучение и на продвижение политики. Дорожная карта из семи этапов позволяет начать с малого и наращивать охват.

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

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

1. Почему поддержку кода стоит выделить в отдельный сервис, а не растворить в поддержке данных?
2. Как три уровня поддержки соотносятся со слоями артефактов и с типами ПО?
3. Чем профиль курирования отличается от плана управления ПО и какую задачу решает каждый?
4. С каких этапов дорожной карты разумно начать и почему?

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