Модуль 5. Политики исследовательского ПО

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

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

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

Этот эффект хорошо виден на нескольких примерах. После введения в журнале Cognition обязательной политики открытых данных доля статей с заявлением о доступности данных выросла, по оценке Хардвика и коллег, примерно с четверти до четырех пятых – правда, далеко не все выложенные данные оказались пригодны к повторному использованию. В журнале Management Science после введения в 2019 году политики раскрытия данных и кода Фишар и коллеги полностью или в основном воспроизвели – там, где данные и совместимое ПО были доступны, – свыше девяноста пяти процентов статей, но почти у трети работ часть данных оказалась недоступна рецензенту. На уровне издателя Хрынашкевич и коллеги описали единую рамку политик данных Springer Nature с четырьмя типами политики по нарастанию требований – пример того, как крупный издатель задает стандарт сразу для множества журналов. Эти кейсы поддерживают одну идею: политика повышает прозрачность, но разрыв между доступностью и реальной пригодностью к использованию сохраняется без проверки артефактов.

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

Чтобы получить межинституциональную картину, был проведен направленный качественный контент-анализ тридцати документов, прямо посвященных исследовательскому ПО. Критерий включения: документ содержит явные требования или рекомендации, специфические для исследовательского ПО. Выборка целевая, с максимальной вариацией случаев внутри четырех страт: журналы (8 документов), университеты и научно-исследовательские организации (9), фонды (4), инфраструктурные инициативы (9). Малый размер страты фондов обусловлен объективным дефицитом таких документов. Организации без формализованной политики намеренно оставлены в выборке и помечены звездочкой: само отсутствие политики – тоже результат.

Каждый документ закодирован по тринадцати категориям артефактов (модуль 4) по трехуровневой шкале: R (обязательное требование), E (рекомендация), N (не упоминается). Граница между R и E определялась по модальности формулировки: «code availability is required for publication» кодировалось как R, «we strongly encourage» – как E. Кодировки выверены по публично доступным версиям документов (срез – июнь 2026 г.); критерии опциональных схем (например, значков ACM) кодировались по модальности самой схемы, а для составных руководств кодировалась полная версия документа (для Netherlands eScience Center – архивная версия руководства, DOI 10.5281/zenodo.4020565). Полная матрица кодирования тридцати документов по тринадцати категориям приведена в приложении Г; здесь разберем обобщенную картину.

Ограничения метода следует оговорить сразу. Корпус собран из документов разного жанра: институциональных политик, руководств по разработке, требований сервисов и сводов принципов. Три документа – FAIR4RS, принципы цитирования FORCE11 и Рекомендация ЮНЕСКО – представляют собой своды принципов, а не институциональные политики, и кодированы по тем категориям, которые частично из них и выведены; их коды следует читать как соотнесение с исходной рамкой, а не как измерение независимого источника. Полный перечень документов с версиями, адресами и датами обращения не приводится; кодирование выполнено одним кодировщиком, независимая перепроверка кодов не проводилась. Поэтому сравнения между типами организаций носят описательный характер и не переносятся на все политики соответствующих секторов или стран.

 Для этих трех строк коды фиксируют не требования документа к сторонним организациям, а то, как категории рамки соотносятся с принципами: R присваивается, когда принцип сформулирован в документе как обязательный, E – когда практика упоминается или подразумевается как желательная. При таком чтении, например, архивирование и указания по цитированию у FAIR4RS получают R по принципам A2 и R1.2, хотя сами эти принципы требуют сохранности метаданных и сведений о происхождении, а конкретных инструментов – архива или файла CITATION.cff – не предписывают. Это следствие принятой операционализации, а не утверждение о том, что свод FAIR4RS требует именно этих инструментов.

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

Таблица. Обобщенный профиль покрытия категорий по стратам

По степени покрытия категории делятся на три группы, и это деление с тремя слоями артефактов из модуля 4 совпадает лишь отчасти. Ядро (LIC, PID, ARC, DOC, VCS, CIT) упоминается в большинстве документов – это базовые требования идентификации, лицензирования и архивирования. Средняя группа (VER, DEP, TEST, REV) тоже упоминается часто, но преимущественно как рекомендация, а не обязательное требование, – переход к обязательной норме здесь не завершен. Периферия (META, CONTR и особенно CONT) покрыта слабее всего, причем структурированные метаданные занимают пограничное положение (16 из 30) и от средней группы отделены условно; ни в одном из тридцати документов контейнеризация не закреплена как обязательная.

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

Инфраструктурные инициативы дают наиболее полное покрытие. Сообщества rOpenSci, PyOpenSci, Software Sustainability Institute и рабочая группа FAIR4RS покрывают от десяти до двенадцати категорий из тринадцати. Это закономерно: такие организации по своей природе создают стандарты и своды лучших практик.

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

Университеты и научные организации демонстрируют полярную картину. Организации с развитой политикой в отношении кода – Netherlands eScience Center (13 из 13), Helmholtz (11 из 13) и GFZ Potsdam (10 из 13) – сопоставимы с лучшими инфраструктурными документами. Организации без такой политики – Stanford (1 из 13), Max Planck (2 из 13) – почти не затрагивают код. Промежуточных случаев практически нет, что позволяет предположить: принятие формальной политики в отношении ПО – пороговое событие, требующее определенной институциональной зрелости (наличия команд RSE, понимания специфики кода на уровне руководства). Немецкоязычные организации (DLR, GFZ, Helmholtz) выделяются на общем фоне – вероятно, под влиянием требований DFG и активности сообщества de-RSE.

Фонды – самое слабое звено. Из четырех фондов в выборке лишь DFG имеет детальный документ (10 из 13). Wellcome Trust, NSF и ERC/Horizon Europe упоминают код почти исключительно в контексте данных; контейнеризацию не затрагивает ни один фондовый документ, а зависимости требует только DFG. Йенсен и Кац, опросив международные фонды, зафиксировали разнородную картину: единых формальных требований к коду нет, формы поддержки различаются от фонда к фонду, хотя приоритеты во многом сходятся (навыки, устойчивость и заметность ПО).

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

Монолитная трактовка кода. Двадцать девять из тридцати документов не дифференцируют требования в зависимости от типа ПО – скрипт анализа, крупная библиотека и инфраструктурный компонент подпадают под одни и те же формулировки. Единственное исключение – DLR Software Engineering Guidelines, где введены четыре класса применимости (0–3) с разными требованиями, но и там дифференциация основана на критичности кода для результатов, а не на типологии как таковой. Это прямо подтверждает тезис модуля 3: рамка, различающая типы ПО, в политиках пока отсутствует, и здесь у библиотеки есть содержательная роль.

Рекомендательный потолок. Между рекомендацией и обязательным требованием сохраняется устойчивый разрыв. В страте фондов из 18 ненулевых кодировок (R + E) лишь 6 обязательны. Похожая ситуация у ряда университетов: ARDC, например, упоминает двенадцать из тринадцати категорий, но все – как рекомендации, без механизмов контроля исполнения. Организация признает важность практик, но не создает рычагов, которые заставили бы их соблюдать, – и это возвращает нас к разрыву «политика – практика».

Три документа стоит разобрать подробнее – они представляют разные типы организаций и разную институциональную логику.

Кейс 1. DFG: фонд, который связал код с грантом

Немецкий научный фонд – единственный из крупных фондов с детальной рекомендацией по обращению с исследовательским ПО (покрытие 10 из 13). Документ встроен в международный контекст: DFG присоединился к Research Software Alliance (ReSA) в 2023 году и опирается на Амстердамскую декларацию о финансировании устойчивости исследовательского ПО, на принципы FAIR4RS и на Рекомендацию ЮНЕСКО.

Структурно документ состоит из четырех частей. Руководящие принципы разработки формулируют пять ориентиров: следование стандартам разработки сообразно назначению кода; обеспечение качества с опорой на FAIR4RS и инженерные рамки; доступность и документирование как условие прослеживаемости результатов; цитируемость и пригодность к повторному использованию; устойчивость через планы сопровождения и, при необходимости, концепции «закрытия» проекта. Информация для заявителей переводит принципы в требования к заявке: план управления ПО (software management plan) подавать не обязательно, но принципиальные решения о типе кода, процессе разработки, доступности и сопровождении нужно описать и обосновать; отдельно оговариваются управление версиями, обеспечение качества, прозрачное использование чужого кода с соблюдением лицензий и – что существенно – требование при цитировании указывать автора, URL или DOI и номер версии. Документ требует заранее урегулировать права и авторство инженеров-разработчиков и поощряет участие в сообществах. Указания по экспертизе предписывают рецензентам оценивать разработку кода как самостоятельное научное достижение. Развитие структурных условий обращено к организациям: DFG призывает создавать сервис «разработка исследовательского ПО как услуга» (RSE as a service), менять исследовательскую культуру, вырабатывать стандарты и развивать инфраструктуры.

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

Кейс 2. Helmholtz: код как самостоятельный продукт исследования

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

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

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

Кейс 3. JOSS и инфраструктурные инициативы: рецензируется сам код

Journal of Open Source Software (JOSS) – пример журнала нового типа, где объектом публикации и рецензирования выступает само программное обеспечение, а не статья о нем. JOSS покрывает двенадцать категорий из тринадцати. Автор подает полный программный пакет; рецензенты в открытом процессе проверяют, что код устанавливается и работает, что есть README и инструкции по установке, тесты, лицензия и метаданные. Сопоставимую логику реализуют инициативы рецензирования пакетов – rOpenSci и PyOpenSci, – где экспертную оценку проходит сам код. Среди университетских и инфраструктурных образцов выделяются Netherlands eScience Center с его руководством по разработке (покрытие 13 из 13), а также TU Delft с институциональной политикой исследовательского ПО. Эти кейсы задают верхнюю планку: на них видно, как выглядит политика, доведенная до полного покрытия артефактов и подкрепленная процедурой проверки.

Результаты анализа складываются в несколько практических ходов. Аудит и сопоставление с образцами: матрицу «тринадцать категорий на шкалу R/E/N» библиотека может применить как инструмент самооценки – проверить, насколько собственная институциональная политика и требования ключевых для ее исследователей журналов и фондов покрывают категории рамки, и где есть пробелы (чаще всего это META, CONT, CONTR). Продвижение планов управления ПО: дефицит фондовых требований означает, что библиотека может не дожидаться внешнего предписания, а сама инициировать планы управления кодом по образцу планов управления данными, опираясь на модель DFG. Дифференцированная поддержка и обучение: разрыв между «ядром» и «периферией» категорий удобно положить в основу обучающих программ – базовый уровень (лицензия, идентификатор, архив, документация), затем продвинутый (тесты, зависимости, метаданные), затем экспертный (контейнеры, CI/CD, управление сообществом). Баркер и коллеги, обобщив институциональные траектории поддержки кода, предложили встраивать ПО в политики организаций на нескольких уровнях – и роль библиотеки в этой многоуровневой схеме вполне определима.

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

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

• Разрыв «политика – практика» – расхождение между предписанным в документе и реально происходящим.
• Сила и исполнимость политики – обязательность формулировки и наличие механизма проверки.
• Шкала R/E/N – кодирование покрытия категории: требование, рекомендация, не упоминается.
• Рекомендательный потолок – ситуация, когда практики признаются важными, но не закрепляются как обязательные.
• План управления ПО (SMP) – документ, описывающий обращение с кодом по аналогии с планом управления данными.
• RSE as a service – сервис централизованной поддержки разработки исследовательского ПО.

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

1. Выберите журнал, важный для исследователей вашей организации, и закодируйте его авторские правила по тринадцати категориям (R/E/N). Сравните профиль с таблицей «Обобщенный профиль покрытия категорий по стратам».
2. Проведите мини-аудит политики вашей организации в отношении кода (если ее нет – зафиксируйте это как результат). Какие категории не покрыты?
3. На основе кейса DFG набросайте проект пункта о плане управления ПО, который библиотека могла бы предложить включить во внутренние требования к проектам.