“Ох уж мне эти
сказки... Ох уж мне эти сказочники”
(“Падал прошлогодний снег”)
“Рыбный день №16” оказался на поверку очень скоромным. Пережаренным несло за версту (для обладающих носом достаточной чувствительности).
Одним из наиболее странных “упущений” в рассматриваемой статье является тот факт, что автор умудрился рассматривать Open Source Software (OSS) и Freeware, не объяснив различий между OSS и свободным ПО (Free Software, FS) – используя термин “свободное ПО” как синоним OSS. Это дает возможность предположить либо незнакомство автора с концепцией FS, либо сознательное замалчивание этой концепции(по неизвестной читателям причине). Тщательный анализ текста показывает, что в злом умысле автора, скорее всего, обвинить нельзя. Он, вероятно, честно и бесхитростно не знает,что такое FS. Например, он обвиняет в Open Source в излишней идеологической нагрузке – тогда как идея OSS значительно менее идеологизирована, чем идея FS. Автор ссылается на г-на Столлмена и FSF – но они-то как раз поддерживают FS, а не OSS (идея OSS для RMS недостаточно радикальна). Таким образом, при чтении статьи возникает (и остается висящим в сознании) вопрос: “А на того ли нападает автор (со всеми его ножами), на кого хотел?” Или даже зарождается желание применить операцию Find/Replace и заменить в тексте все вхождения “Open Source” на “Free Software”. Но потом выясняется – нет, не все так просто. Потому как многие признаки, свойственные OSS в целом (а не только FS) достаточно честно описаны автором. Таким образом, автор смешал в “одном флаконе” две концепции (безусловно, в чем то общие) и назвал эту странноватую смесь именем одного из компонентов. Кстати, когда автор пишет “Freeware vs. Open Source” - у непосвященного читателя (который одним ухом где-то слышало про FS) может появиться резонный вопрос о том, с какой стороны от этого жесткого “vs.” находится FS – и не дай Бог, чтобы такой читатель решил, что Free Software ближе к Freeware – слова-то такие похожие... Эта путаница в понятиях является наиболее веским доказательством недостаточной компетентности автора в обсуждаемых вопросах.
Единственное объяснение неправильного использования терминов, которое не кидает тень на уровень информированности автора, может заключаться в сознательном нежелании автора “не затуманивать” мозги читателей многочисленными терминами (и особенно объяснениями различий между ними) – несмотря на то, что в контексте данной статьи эти термины должны были быть четко разграничены. Подход понятный, но вряд ли вызывающий уважение. Обычно, доведение до людей полуправды – признак не очень чистых умыслов (и/или предвзятости в суждениях). Поэтому я рискну отвергнуть подобную версию.
Теперь перейдем к сказочкам.
Автор проявил незаурядную фантазию, умудрившись объединить в одной сказке архитектуру плагинов и возможность модифицировать и расширять существующий код. Это мне напомнило недоумение одного из моих преподавателей по поводу борьбы “макросы против процедур”. Он (преподаватель) тогда резонно заметил – борьба эта является следствием низкого профессионализма. Нельзя сравнивать вещи из разных уровней, разных областей. Безусловно, расширяемая закрытая архитектура обладает преимуществами перед нерасширяемой. Но и продукт OSS, как любой другой, может обладать разной степенью расширяемости. Я не знаю, где и в какой форме автор вычитал оригинал этой сказки – но либо рассказчик был плохой, либо слушатель – сказку изрядно переврали. Можно написать монолитный и нечитаемый код, можно выложить его исходники на www.sourceforge.net – это не сделает результирующий продукт реально пригодным к расширению. В качестве примера плохо расширяемого продукта OSS можно привести sendmail – насколько я знаю, внутренняя архитектура его достаточно запутана, чтобы у кого-либо возникало серьезное желание его “порасширять”. Вместе с тем, существует множество OSS и FS, которое действительно является расширяемыми. Расширяемость реализована либо в виде милых автору разделяемых библиотек/плагинов (apache, gaim, gkrellm), либо за счет использования компонентных архитектур типа Bonobo/KParts.
По-видимому, произошло некоторое двойное толкование термина “расширяемость”.
Расширяемость как добавление внешних относительно продукта функций (в пределах, ограниченных базовой системой) – это про плагины. И действительно, тут, вроде, коммерческое ПО не может сильно проиграть открытому и свободному (при условии, что все API очень хорошо документированы). Хотя, должен сказать, как бы ни была хороша документация, всегда есть шанс, что некоторые особенности закрытого API окажутся недокументированными. В свое время, работая над некоторой программой для платформы Win32 я не мог понять некоторых мелочей в работе одного из т.н. Common Controls. Просмотрев MSDN, я не нашел ответа на свой вопрос. И только посмотрев исходный текст Wine (очевидно, не Microsoft Windows – кто бы мне дал этот текст), я получил ответ. И, хотя Wine – даже не эмулятор (как следует из его названия) – ответ оказался точным.
Второе значение слова “расширяемость”, которое действительно имеет значение к OSS/FS – возможность расширять базовый функции. И тут закрытое ПО действительно проигрывает принципиально. Если OSS (при соблюдении некоторых условий, типа качества проектирования, качества кода и пр.) предоставляет сторонним относительно проекта разработчикам возможность что-то поменять – то в закрытом ПО только фирма-производитель обладает такой привилегией. Не захотела бы компания Microsoft предоставлять возможность создания драйверов “нестандартных” файловых систем – никто не мог бы разрабатывать такие драйвера (насколько мне известно, спецификации существуют, но они таковы, что задача и по сей день остается нетривиальной).
Экспертиза кода – дело важное и нужное. И я полностью разделяю убежденность автора в этом. Что меня не убеждает – это предполагаемая автором (ничем не доказанная) возможность договориться с любым автором Freeware. Например, представьте себе, что автор некоей полезной (и очень хорошей!) программы – пацифист. А исходники затребовало МО России (согласитесь, для него требования по защищенности – не пустые слова). Я думаю, шансы военных получить отрицательный ответ весьма велики. Обвиняя сторонников OSS/FS в черно-белом видении вопроса о защищенности – автор позволяет себе рецидив подобного дефекта зрения в отношении авторов Freeware – либо с автором можно договориться, либо не очень-то и нужно было договариваться.
При этом автор игнорирует чисто статистический эффект количества экспертов для обоих рассматриваемых им случаев. В случае исходников “по требованию” оно (количество) наверняка будет меньше, чем в случае исходников “для всех”. Разумеется, как всякий статистический эффект – он может проявляться, может и нет – но в не-двухцветном мире, наверное, вероятности (вероятность нахождения ошибки) тоже важны, не правда ли? И – самое главное – если нашли проблему в закрытом ПО (даже при получении исходников) – совершенно не ясно, что с ней делать. То ли автору слать запрос на изменения (но он их сделает только в следующей версии, а вам программа нужна сегодня). То ли пытаться чинить самостоятельно (можно оказаться перед лицом проблем лицензирования – Freeware не обязательно подразумевает разрешение на модификацию исходного кода). А если Вы поставляете что-то, использующее такую программу? Можете ли вы поставлять ее в модифицированном виде – это один вопрос, который вам предстоит решить (и, вполне возможно, ответ будет отрицательным).
Для автора эти вопросы не интересны. Он так уверен в способности пользователя договориться с автором, что считает все остальные проблемы решаемыми “как следствие” этой договоренности. Если первое достаточно сомнительно, то второе сомнительно еще более. Равным образом он игнорирует вопрос о стоимости полной независимой экспертизы относительно крупного программного проекта.
Главное, чего не понял автор в этой сказке – ее мораль. “Добру молодцу урок” не пошел, наверное, впрок. Об этом свидетельствует выкрик в небо: “Но кто-то мне может внятно объяснить, с какой стати я должен это делать сейчас?! “ Очевидно, создание группы людей знакомых со внутренним устройством его программы достаточной причиной не является. Очевидно, получение полезных советов (и просто патчей) от этих людей при жизни автора – тоже никакой ценности программному продукту не несет (а если и несет, то проблемы при открытии кода явно и заведомо превышают такую ценность). Если уж говорить по гамбургскому счету, то на сегодня ОС Linux (как технически, так и организационно) застрахована от любых неприятностей в жизни ее основателя – потому как количество людей, знающих про то, как устроено ядро – явно выше некоей минимальной критической массы, которая нужна для поддержания проекта на плаву. Та же ситуация, насколько мне известно, с FreeBDS, Apache, и др. “флагманскими” продуктами OSS/FS – количество людей, которых нужно “отстрелить” для мгновенного закрытия подобных проектов, достаточно велико.
Автор предлагает свое решение: он завещает свой код другу. Но что же делать, если у человека не нашлось такого друга, которому можно быть бы передать проект? И захочет ли друг заниматься кодом автора? И что делать с проектами, которые размером существенно превышают способности “друга” их поддерживать и развивать (если он по очень крепкой дружбе не станет работать на них 24x7)? При всем уважении к авторам FAR Manager я думаю, что масштаб этого проекта не сравним с крупными OSS/FS разработками. Но даже проект FAR, думается, может встретить серьезные проблемы при попытке передать его “другу по наследству” - если только сам друг не был заранее уведомлен о таком наследии и морально подготовлен.
При рассмотрении этой сказки автор забыл, что сани нужно готовить летом. В тот момент, когда разработчик перестал заниматься проектом – искать замену может оказаться просто поздно. Такой проект имеет очень хорошие шансы умереть вместе с последней строкой, написанной его первым автором. Тогда как проект, обладающий широким кругом разработчиков (не ограниченных кругом личных знакомств) обладает гораздо большей живучестью.
Возможно, автор считает, что круг его личных знакомств позволит ему найти помощников по работе над любым проектом (и наследников для передачи прав на разработку, ежели возникнет необходимость) – так, что открывать исходники для всего мира ему не придется. Что же, можно позавидовать его уверенности. Однако есть серьезные основания полагать, что для большинства проектов и разработчиков этот путь будет крайне проблематичным.
Выводы, сделанные г-ном Рыбниковым, выглядят достаточно сумбурно. С одной стороны, он пытается делать выводы для пользователей: “Разработчикам показалось удобным — НЕ НАМ. Это их «заморочки»”. С другой – для разработчиков: “мало того, что ты делаешь какую-то работу — создаешь программное обеспечение...”. Именно выводам “для пользователя” посвящена большая часть заключения. При этом автор удивительным образом решает проблемы пользователя старым девизом “не любо – не кушай”. Подход известный и старый. И спорить с ним практически невозможно. Только еда должна быть все-таки съедобной. Сказки же, изрядно перевранные автором – в своих оригинальных версиях дают объяснение всех тех практических (не философских, не этических) ценностей, которые конечный пользователь может получить при использовании OSS/FS – не напрямую, от факта наличия исходников (исходники сами по себе для пользователя действительно никакой ценности не имеют), а опосредованно – за счет вторичных, производных достоинств.
Автор выделяет “особую судьбу” для крупных проектов: “Уж слишком большое сообщество, как правило, работает над такими проектами, и, к слову, ввиду последней особенности они так или иначе все равно «самопроизвольно» становятся открытыми”. Иначе как инфантилизмом веру в “самопроизвольное открытие исходников” объяснить трудно.
При этом автор самым трогательным образом проявляет жалость к разработчикам, которых кто-то “обязывает” открывать исходные тексты. Имеет место непонимание мотивов, движущих разработчиками в момент публикации. Только внутренняя убежденность разработчика в необходимости открытия текстов может подвигнуть его на такой шаг (разумеется, я не рассматриваю случаи, когда работа над открытым проектом ведется в коммерческой компании).
И в эпилоге, в последних его
строках, автор снова говорит не о пользователе, а о разработчике. Беспокоясь о его здоровом
сне (как профессор Преображенский – об аппетите доктора Борменталя),
настоятельно советует не
петь на ночь “мантры
от FSF”. Как разработчик могу только поблагодарить автора за заботу. Но
позволю себе заметить, что полупрофессиональные статьи, содержащие
полуправду (к тому же еще и тенденциозно преподнесенную) гораздо сильнее
портят нервную систему и крепкий сон.