Открытые стандарты: Открытый исходный код, Открытый контур

Дэвид Уорд

Дєвид Уорд

В Интернете по большей части доминирует программное обеспечение; и в последние несколько лет в рамках методологии гибкой разработки (agile development) резко возросли темпы иннова­ций − инноваций, которые требуют стандартизации. Код не является нормативом, хотя именно он является определяющим фактором в открытом программном обеспечении (ОПО). ОРС и согласо­ванные стандарты необходимы. При этом ОРС должны учитывать, что цикл открытого ПО способен создать условия для достижения консенсуса между участниками рынка в отношении заполнения пробела в стандартах, и понимание этого может играть ключевую роль в нашем общем будущем.

Перед членами сообщества (сообщества IETF, прим. ред.) и сторонними наблюдателями стоит насущный вопрос: Нужны ли в мире растущего числа проектов в сфере открытого про­граммного обеспечения (ОПО) организации по разработке стандар­тов (ОРС), такие как Инженерный совет Интернета (IETF).
Для тех, кто только что присоединился к этой дискуссии, поясним, что суть вопроса не в том, должны ли существовать ОРС. Они – ре­альность, связанная с торговой политикой и международными от­ношениями. Их основная задача состоит в том, чтобы не допустить появления коммуникационной «вавилонской башни» и установить контроль над использованием глобальной коммерческой и инфор­мационной инфраструктуры. Вопрос в том, играют ли эти организа­ции роль в создании условий для инновации.
В Интернете по большей ча­сти доминирует программное обеспечение; и в последние несколько лет в рамках ме­тодологии гибкой разработ­ки (agile development) резко возросли темпы инноваций − инноваций, которые требуют стандартизации.
Проблемы ОРС
Чтобы идти в ногу с техноло­гическим прогрессом гаранти­ровать, что собственные про­цессы разработки остаются актуальными, ОРС, такие как IETF, должны изменить свои процессы.
В Интернете по большей части доминирует про­граммное обеспечение; и в последние несколько лет в рамках методологии гибкой разработки (agile development) резко возросли темпы инноваций − инноваций, которые требуют стандартизации. Код не является нормативом, хотя именно он является определяющим фактором в открытом программном обеспечении (ОПО).
ОРС и согласованные стандарты необходимы. При этом ОРС долж­ны учитывать, что цикл открытого ПО способен создать условия для достижения консенсуса между участниками рынка в отношении заполнения пробела в стандартах, и понимание этого может играть ключевую роль в нашем общем будущем.
Для стороннего наблюдателя (и даже для некоторых инсайде­ров), недавняя реорганизация рабочих групп (рабочих групп IETF, прим. ред.) напоминает простую перестановку стульев, то есть в принципе ничего не меняет.

Темпы реализации проектов ОРС и ОПО соотносятся как минимум 2:1 (два года на бумажный стандарт против одного года на продукт, который создает фактический стандарт).
Создается впечатление, что многие ОРС в разных странах мира не могут определить сферу своей деятельности и держаться в этих гра­ницах. Напротив, на их «территориях» бурно произрастают новые группы по изучению новых технологий. Каждая организация потен­циально (и рискованно) считает себя вечной. Незначительное число ОРС имеют план собственного жизненного цикла, предусматриваю­щий ограничение полномочий и сферы деятельности применитель­но к новым технологиям.
Реальной согласованности действий между ОРС практически не существует. Это ослабляет усилия и ресурсы участвующих компаний и физических лиц, создает путаницу для потребителей этих техно­логий.
Внутри IETF мы сталкиваемся с многочисленными проблемами, связанными с собственным жизненным циклом. Сколько времени тратится на дальнейшую стандартизацию уже зарекомендовавшей себя технологии за счет более актуальных рабочих групп? Как мы справляемся с проблемами, технологиями и новой архитектурой, которые проходят сквозь всю нашу существующую структуру (на­пример, недавний бум модели YANG во многих рабочих группах)? В сравнении с популярными сетевыми проектами ОПО, в чем про­игрывает IETF?
А главное, как мы можем убедить компании-стартапы, но­вых разработчиков, новых потребителей в том, что мы го­товы прислушаться к их мнению? И при этом не демон­стрировать превосходство, а проявлять демократизм, где ценятся реальный качества и засулуги?
Для стороннего наблюдателя (и даже для некоторых инсайдеров), недавняя реоргани­зация рабочих групп напоминает простую пе­рестановку стульев, то есть в принципе ничего не меняет. Здесь действует Закон Конвея.
Без фундаментальных структурных изменений ничего другого ожидать не следует. Мир не должен ждать два года, чтобы получить стандарт Цепи Функции Обслуживания (Service Function Chaining), и еще дольше, чтобы получить стандарт для Оверлеев Сетевой Виртуализации (Network Virtualization Overlay) (или виртуализации сетевых функций в целом, что больше является проблемой Европейского института телекоммуникационных стан­дартов).

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

• Эффективное и беспристрастное управление третьими лицами помогает избежать пересекающихся, однобоких и создающих пу­таницу проектов.

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

• Эффективное управление позволяет сформировать сообщество, которое учитывает связность проекта по восходящей и нисходя­щей.

Эффективное и беспристрастное управление тре­тьими лицами помогает избежать пересекающихся, однобоких и создающих путаницу проектов.
Дефекты защиты возникают в результате не­достаточного внимания проекта к вопросам безопасности, недостаточного количе­ства рецензентов и специалистов по обслуживанию. Так случилось недав­но с OpenSSL (HeartBleed), и сейчас эту проблему решает Инициатива Корневой Инфраструктуры (Core Infrastructure Initiative) консорциу­ма Linux Foundation (для OpenSSL, OpenSSH и NTPd).

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

Кроме того, надлежащее управление может обеспечить необ­ходимые юридические, управленческие, стратегические и биз­нес-процессы для адекватного осуществления прав собственности и лицензирования разработок, управления релизами, вовлечения от­крытого сообщества. Есть отличные примеры этому в консорциумах Linux Foundation, Apache Foundation и OpenStack Foundation.
Альтернативная модель ОРС
ОРС выдвинули несколько предложений включить в свою дея­тельность и стандартизировать сетевые архитектуры, которые были разработаны в открытом ПО путем определения программного ин­терфейса на уровне конечной точки, интерфейса или приложения (Application Program Interface, API). Консорциум Open Networking Foundation (ONF) – отличный пример ранних попыток создать дру­гую гибридную модель: пытаясь связать оба мира, он использовал слово «стандарт», чтобы описать протокол обмена данными, и слово «открытый» для описания архитектуры.
Протокол разрабатывался на основе множества зачастую несовме­стимых с предыдущими версиями стандартов. Организация очень быстро перешла к активной поддержке и развитию рынка для про­токола, архитектуры и контроллера OpenFlow (последний вид дея­тельности обычно не ассоциируется с традиционной ОРС).
Несмотря на доступность контроллеров и сетевых коммутаторов с открытым кодом, большинство разработок были осуществлены за пределами ONF отдельными заинтересованными группами. ONF не предоставил собственной эталонной реализации..
Наиболее важный урок, который ОРС и ОПО могут извлечь из опы­та ONF, состоит в следующем: действительно успешные экосистемы и сообщества создаются на основе открытости решений и сотрудни­чества, а не через посредство осуществления права собственности, и только таким образом удастся избежать фрагментации и путаницы. В отличие от ОРС, в проектах ОПО есть место маркетингу, однако главное внимание должно уделяться формированию сообщества и привлечению к работе заинтересованных лиц.
Почему важны открытые API и концептуальные стандарты
Многие из новых проектов ОПО предлагают широкомасштабные и связанные между собой архитектуры решений. Важно рассмотреть роль таких ОРС, как IETF, в создании нормативной соединительной ткани этих новых архитектур, чтобы обеспечить в этой среде не­обходимую функциональную совместимость (См. https://tools.ietf. org/html/draft-opsawgoperators-ietf-00, опубликованную членами Internet Society).
Будущие стандарты в программно-конфигурируемых сетях будут появляться в форме API и рамочных концепций приложений и сер­висов. Те же причины, по которым стандартизируются ба­зовые Интернет-протоколы, применимы и к этим концепциям более высокого уровня: совме­стимость, выбор и дизайн системы.
Стандартизация необходима для развенчания мифа о том, что будущее, объединяю­щее огромное количество ОПО, это будущее, в кото­ром все ПО и все решения являются бесплатными, и единственно возможная экономическая модель для производителя – исключи­тельно поддерживать ОПО.
Напротив, правильно спроектиро­ванные, открытые и стандартизирован­ные кнцепции, протоколы, конечные авто­маты и иже с ними позволяют разработчикам предоставлять интеллектуальную собственность в виде модулей, которые, при необходимости, можно легко заменить. Безусловно в рамках разрабатываемых решений останет­ся место компонентам ОПО, поддерживаемым сообществом, одна­ко посредством стандартизации стимулы к инновациям у ведущих разработчиков и стартапов будут сохранены.
Стандартизация необходима для развенчания мифа о том, что бу­дущее, объединяющее огромное количество ОПО, это будущее, в ко­тором все ПО и все решения являются бесплатными, и единственно возможная экономическая модель для производителя – исключи­тельно поддерживать ОПО.
Таким образом, поддержка производителем ОПО становится ра­циональной и понятной, как и ее использование в сообществе опе­раторов.

Открытый контур
Несмотря на политические или экономические права на суще­ствование, право любой ОРС пользоваться авторитетом нужно за­служить. IETF является, пожалуй, наиболее подходящей ОРС для решения задачи по стандартизации программно-конфигурируемых сетей. Сфера деятельности IETF одновременно не слишком широкая (например, IETF не занимается вопросами здравоохранения и без­опасности или защиты окружающей среды и изменения климата), но и не слишком узкая (например, не какая-то определенная услуга или сетевая область сервисный). Опыт IETF в определении архитек­туры, разработке протокола, моделировании информации и данных (YANG) может быть полезен для реализации сетевых проектов ОПО.
Как добиться значимости IETF в данной среде
Чтобы утвердить IETF в качестве авторитета в области новых раз­работок, необходимых профессионалам и операторам в сфере IT, я предлагаю IETF сделать следующее:

• Подумать о реформировании и реструктурировании для под­держки более гибкого процесса. Отбросить всё мертвое и освобо­дить место для новой работы. В частности, нужно быстро осознать неудачу, чтобы быстрее преуспеть с меньшим набором актуаль­ных идей, но лучшего качества, чтобы двигаться со скоростью развития рынка. Больше встреч в формате BoF (Birds of Feather), больше успешных и нужных рабочих групп с более коротким сроком работы, мень­ше бумажной волокиты, больше ощутимых результатов. Позвольте новым рабочим группам выполнять техническую работу параллельно с разработкой концепции, архитектуры, требований и сценариев использования, в которых мы увязли. Сократите продолжительность цикла для всего (чтобы прийти к какому-то консенсусу, два года вполне достаточ­ный срок).

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

• Уделить больше внимания разработке ПО в структуре IETF. Необ­ходимо поощрять эксплуатационную совместимости и демонстра­цию функций на протяжении всего цикла разработки. Работаю­щий код когда-то был одним из принципов IETF, но запоздалый работающий код ведет к потере гибкости. Подумайте о «хакато­нах» применительно к процессу разработки стандартов. По моему опыту, наиболее удачные стандарты были созданы параллельно с написанием кода.
• Расширить проведение исследовательских работ (это уже хорошо получается), тем самым вовлекая больше участников.
• Исправить, изменить и перестроить процесс взаимодействия с другими организациями, потому что это крайне важно для со­трудничества с проектами ОПО. На самом деле, даже не исполь­зуйте существующий процесс как модель.
• Принять во внимание проекты открытого ПО. Прежде всего, это потребует организации открытого взаимодействия между исполнительным комитетом IETF (Internet Engineering Steering Group, IESG) и авторитетными консорциумами ОПО в работе над совместными проектами. Хороший пример такого совме­стимого и надлежащим образом управляемого проекта – проект OpenDaylight (Linux Foundation), который продвигает использова­ние моделей YANG в IETF, а также другие проекты открытого ПО.

Активное исследование и мониторинг проектов ОПО позволяет ак­тивно вкладывать наши ресурсы в новые технологии вместо того, чтобы ждать, когда они сами придут к нам.
Обратная связь между сторонами поможет определить области новых и существующих проектов, которые необходимо стандарти­зировать, которые должны подчиняться существующим стандартам, либо не соответствуют стандартам. Исходя из опыта, написание кода до стандартизации обеспечивает наиболее полное и простое опреде­ление протоколов.
Часть этого процесса потребует, чтобы IETF постаралась не копи­ровать всё в рабочие группы IETF. Специалисты ОРС и специалисты по ОПО – это не одно и то же. Парадоксально, но для наших целей, код не является нормативом. Однако также сложно определить и стандартизировать API, без написания кода. Принудительная ин­теграция навыков и целей может изменить сообщество в худшую сторону. Сотрудничество, взаимодействие и обмен идеями подходят нам гораздо больше. (Обратите внимание, что сотрудничество не удастся, если цикл ОРС будет замедлять работу партнера по ОПО. Справедливо и обратное: пассивное сообщество открытого ПО не сможет взаимодействовать ни с одной ОРС).
И наконец, мы должны (1) адаптировать и принять новые законы, и (2) постараться избежать Закона Конвея.
Если мы признаем существование этих законов, мы должны также понимать, что роли ОПО и ОРС должны измениться. Мы должны проложить новую траекторию, двигаться быстрее и сконцентриро­ваться на задаче создания более масштабного и более совершенного Интернета.
Источник: Open Standards, Open Source, Open Loop. David Ward. IETF Journal, Volume 10, Issue 3