Открывашка

Архив

Когда я работал в маленьком вычислительном центре (администратором, системным и прикладным программистом) с системами на базе клонов мини-компьютеров PDP-11 ...

ДЕМОС (да простит меня одноименная отечественная команда) работала на этих машинках не сказать чтобы очень хорошо (по крайней мере, в моих руках), и мой опыт общения с ней был невелик, но он имел (и имеет) определенную отдачу: все навыки (затраты на приобретение которых и составляют основную часть пресловутой "общей стоимости владения") применимы и сегодня, работаю ли я с Linux, FreeBSD или Solaris.

ОСРВМ и особенно РАФОС, напротив, были исключительно вылизанными и беспроблемными продуктами с минимумом глюков и неплохой по тем временам документацией и поддержкой. Я научился инсталлировать за полдня ОСРВМ на нетиповое железо, хакать драйверы для доступа к нестандартным функциям железа и писать, как мне говорили, неплохие программки. И даже некоторое количество денег я таким образом заработал, причем сильно больше, чем зарабатывали мои друзья, тратившие время на уяснение различий System V и BSD и изучение POSIX.

Однако мода на PDP прошла, и все свои затраты на освоение специфичных для нее ОС мне пришлось списать в чистый убыток. А счастье было так возможно...

...Если бы я тогда был таким умным и информированным, как сегодня, я бы сообразил, что ситуация вполне схожа с той, что случилась почти десятью годами раньше с культурой программирования, администрирования и пользования PDP-10 (разработки той же Digital) с ее ITS. Операционная система ITS, между прочим, была сильно покруче TOPS (фирменная система для PDP-10 от Digital), RSX, RT-11 и современных ей версий Unix вместе взятых. И приложения для нее писали на LISP, который тоже сильно покруче вульгарного C.

Перепиши хакеры из MIT, Стэнфорда и Карнеги-Меллонского университета ITS на LISP, вся история пошла бы в другую сторону, и открытыми системами мы называли бы, скорее всего, не потомков Unix, а потомков ITS.

Не так давно я узнал, что легендарная аббревиатура ITS расшифровывалась как Incompatible Timesharing System, то есть несовместимая система с разделением времени. Решающим для перспективности среды, инструментария и культуры оказалась не "крутизна", а совместимость, то есть переносимость и открытость.

За пятнадцать с лишним лет, прошедших с момента окончательного торжества открытости над "крутизной", мы научились различать много аспектов открытости.

Я не буду говорить об открытости в смысле внешних технических интерфейсов просто потому, что против нее никто сегодня не возражает [1].

Я не буду также говорить об открытости в смысле свободы использования, модификации и распространения, поскольку это слишком глубокая тема для одной полосы текста.

Меня интересует открытость в смысле свободы доступа к исходным текстам. Доступа "на чтение", так сказать. Я думаю, на сегодня это самый важный аспект открытости, который отличает перспективное от неперспективного в мире программного обеспечения [2].

Из свойственного мне духа противоречия я много раз пытался играть роль advocatus diaboli и найти хотя бы один аргумент в пользу закрытости кода.

Аргумент от защиты "интеллектуальной собственности" не "прокатывает" вне зависимости от отношения к содержанию этого оксюморона: даже благоволящее к нему модернистское законодательство закладывает механизм защиты "ИС" через открытость - через патенты и приоритеты. Вот прятать "чужую ИС" в закрытом коде, напротив, можно очень успешно.

Аргумент от "сохранения чистоты и совместимости" не подтверждается практикой: проблемы с совместимостью имеют тенденцию возникать как раз в домене "закрытого" софта, а открытость, похоже, является мощнейшим стимулом против "форкинга" [3].

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

Универсальных же аргументов я не нашел, однако одна проблема остается. Понятно, как запустить новый проект методом открытого кода. Понятно, как перевести на открытый код индивидуально (или малой группой разработчиков, да хоть бы и большой) написанную программу, находящуюся, так сказать, в пререлизном состоянии, в версии 0.xx.

Непонятно одно: как "открыть" разработку, выполнявшуюся "закрытым" методом в течение долгого времени и имеющую серьезную пользовательскую базу.

Весной гулять значительно приятнее, чем зимой, но есть период между тем, как сойдет снег, и тем, как вс§ @#$, вмерзшее в него за зиму, уберут. По завершении цикла "открытия" продукт будет более надежным и безопасным, чем в начале пути (в том числе и для "тупых" пользователей, которым исходники ну напрочь не нужны и которые умеют только ставить чужие заплатки), но неизбежен период между тем, как все дыры в разработке вылезут наружу, и тем, как они будут залатаны.

Неясно, что делать в это время конечным пользователям. Если бы я имел несчастье администрировать и сегодня какую-нибудь систему, основанную на закрытом софте (как я работал когда-то с RSX или RT), решение разработчика "вот так сразу" опубликовать ее исходники сильно бы меня расстроило. Смертельно - если бы на ней работали критически важные приложения.

Я не вижу никакого - опять-таки универсального - механизма купировать эту проблему. Опыт, который в этом направлении накоплен, пока небогат: код серьезных проектов открыла Netscape (Mozilla), открывает Sun Microsystems (Solaris) и еще несколько производителей, - и я думаю, он заслуживает тщательного изучения.

В любом случае, этот переход недешево обошелся Netscape, недешево обойдется Sun и, я опасаюсь, другим (им самим и их клиентам) обойдется значительно дороже, поскольку Sun и Netscape все же довольно нетипичны для производителей "закрытого" софта.

---

1 (обратно к тексту) - Вряд ли кто-то будет декларировать, например, ОС общего назначения, не соответствующую сетевой модели OSI или спецификациям POSIX.

2 (обратно к тексту) - Я не отрицаю той роли, которые играют различные юридические гарантии, прописываемые в разных типах лицензий на открытый (в терминах Open Source Initiative) или свободный (в терминах GNU) софт, просто я думаю, что не менее половины своей силы открытый софт черпает из открытого "доступа на чтение".

3 (обратно к тексту) - Forking - "разветвление" развития программы на несовместимые варианты.