Не стучать, открыто

Недавняя публикация на osnews.com под названием «The Common Creative(s)» вновь обострила интерес к сути открытых софтверных проектов.

Недавняя публикация на osnews.com  под названием «The Common Creative(s)» вновь обострила интерес к сути открытых софтверных проектов. Вкратце ее идея такова: путем простановки одной из стандартизованных пиктограмм сообщить посетителю домашней страницы любого открытого проекта о том, насколько автор готов к участию новых разработчиков и общению с пользователями. Человеку, не очень хорошо знакомому со свободными проектами, это может показаться бредом — ведь проекты открытые, так что участвовать в них, казалось бы, может кто угодно. Но не все так просто.

В последнее время об open source не пишет только ленивый, и, увы, во многих случаях этот «неленивый» оказывается человеком неосведомленным. В результате расползаются байки о том, что якобы все опенсорсные программисты ненавидят жирных капиталистов и завидуют Биллу Гейтсу, что они против распространения их софта за деньги или, призывая к переходу на свободное ПО, сами боятся пиратов и т. д.

По сути, рассуждения о природе open source сводятся к попытке проанализировать довольно тонкую материю — отношение творца к своему произведению, как в этическом, так и в юридическом аспектах. К сожалению, единственные люди, действительно способные пролить свет на этот вопрос, то есть сами разработчики открытого софта, обычно слишком заняты, чтобы разъяснять публике свою позицию. Ну а сентенции харизматиков вроде Столлмана и Торвальдса даже внутри сообщества разработчиков вызывают неоднозначные отзывы.

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

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

Когда человек учится программированию, ему, конечно же, хочется понять, где он не прав — иначе продвижение вперед попросту невозможно. Для этого как минимум нужно показать код другим, более опытным людям. Чем больше людей посмотрят его программу, пусть даже не читая сам код, а просто сообщая о результатах использования, тем лучше он будет понимать, куда надо двигаться. Этот пример очень хорошо иллюстрируется кучей открытых проектов, заброшенных авторами на начальной стадии разработки. На образчики «раннего творчества» порой натыкаешься совершенно случайно, например введя в поисковике фамилию известного программиста. Сюда же относятся программы с открытым исходным кодом, созданные в рамках дипломных проектов.

Один такой, к сожалению, запущенный проект — Kognition, программа для оптического распознавания символов. В ней реализованы интересные алгоритмы, предусмотрено простое модульное добавление распознаваемых языков, движок для обучения. Есть даже неплохой графический интерфейс с эффектной отрисовкой процесса распознавания. Я уж не говорю о том, что движок для распознавания шрифтонезависим, а это само по себе очень серьезно для такой, казалось бы, «студенческой поделки». Да вот беда: авторы-немцы писали дипломный проект и документацию к программе на родном языке, а распространенным международным языком немецкий не является. Поэтому подхватить падающее знамя оказалось некому.

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

Мотив второй — паблисити. Многие свободные программы написаны как пример возможностей их автора, в качестве демонстрации потенциальным работодателям. Ведь умение не только писать грамотный и понятный код, но быстро и без финансовых инвестиций в отдел HR собирать вокруг себя команду из классных специалистов ценится не меньше «погонов» MSCS. Бывает, конечно, и наоборот, когда известный программист вдруг уходит с прибыльного и престижного места в open source. Так было с основным разработчиком Ardour Полом Дэвисом, который, отработав несколько лет вторым по важности программистом на Amazon.com, решил уйти и воплотить в жизнь мечту — написать программную цифровую станцию для записи и сведения многоканального звука. Впрочем, к Ardour мы еще вернемся.

Мотив третий и самый распространенный — потребность в инструменте для решения собственных задач. Если вам нужен программный продукт, которого в готовом виде нет (либо существующий продукт вам или вашей фирме не по карману или не соответствует требованиям), вы всегда можете написать его сами. Загвоздка тут в том, что чаще всего вы не программист, а, скажем, врач, инженер, преподаватель, филолог, музыкант — да кто угодно, только не профессиональный программист. Создать полноценный инструмент при таком раскладе непросто, поэтому сделать проект открытым и попытаться привлечь к нему внимание более опытных программистов, заинтересованных в таком же инструменте, — вполне логичное решение. Одна из моих любимых иллюстраций этого варианта — LilyPond, свободная система набора нотных партитур полиграфического качества. Ее главными разработчиками являются два голландских профессиональных музыканта, играющих в оркестре. Они не просто написали программу, позволяющую создавать действительно красивые сложные партитуры для последующей печати, но и создали превосходные нотные шрифты, которые используются сейчас почти во всех свободных нотных редакторах.

Работать с такими энтузиастами, пожалуй, интереснее всего. Во-первых, эти люди пишут программу для удовлетворения своих ежедневных потребностей, а потому случаи, когда они внезапно исчезают с горизонта на долгое время или насовсем, довольно редки. Во-вторых, они всем сердцем жаждут сделать программу максимально удобной. В-третьих, они приветствуют вливание в проект новых разработчиков. С программистами, которые по такому принципу пишут софт для своего хобби, случаются очень интересные вещи. Иногда процесс программирования увлекает их настолько, что они перестают решать прикладные задачи и все свободное время начинают отдавать непосредственно написанию и отладке кода. Это, например, произошло с четверкой разработчиков MIDI-секвенсера Rosegarden, изначально писавшегося под IRIX: они настолько увлеклись программированием, что вскоре стали больше программистами, чем музыкантами. Так что каждый раз, когда они изредка сообщают, что, мол, «попробовали тут сочинить вещь-другую», в списке рассылки раздается понимающее хихикание пользователей со стажем. Однако не будем забывать, что ровно то же самое в свое время случилось и с обожаемым музыкантами насквозь закрытом Logic Audio.

Мотив четвертый весьма амбициозен — желание создать инструмент, способный заменить собой некий раскрученный массовый продукт. Таких программ не очень много, и вряд ли вы этому удивитесь. Их разработчики не всегда заинтересованы в самопиаре, как правило, хотят использовать программу в повседневной работе, но неизменно пытаются дать «наш ответ» то «Фотошопу», то «Иллюстратору», то «Автокаду», ну и так далее. При этом, несмотря на предполагаемую ориентацию на массы, управление проектами такого рода часто носит явные черты авторитарности, а то и тоталитарности, и попасть в команду основных разработчиков непросто. Более того, влияние пользователей на ход разработки тоже ослаблено. И это — при мощной инфраструктуре из доброго десятка списков рассылки, различных wiki (Wiki — средство общения и совместной работы: это сайт, на котором страницы могут быть изменены и добавлены прямо из браузера во время просмотра. Страницы автоматически создаются и связываются друг с другом. Концепция Wiki включает мысль, что любой документ, созданный в Wiki, подлежит редакции любым пользователем. — Прим. ред), уроков использования и гигантском сообществе пользователей! Парадокс? Давайте разбираться.

Для начала приведу два ярких примера: The GIMP и Inkscape. Первый вряд ли нуждается в представлении: усилиями отечественных бумажных и сетевых журналов с Windows-версией этой программы перезнакомилась добрая половина технически грамотной части страны (и в большинстве случае тут же удалила, ибо невозможно без слез пользоваться софтом, написанным на Windows-версии библиотеки Gtk). Ядро разработчиков The GIMP сформировалось давно, и попасть в него и правда трудно. Тем, кто хочет поучаствовать, предлагают начать с исправления известных ошибок, что должно помочь лучше понять устройство The GIMP и позволить избежать архитектурных недочетов кода в будущем. Одному богу известно, каково соотношение талантливых и бездарных программистов, отсеивающихся таким образом. Но подумайте: ведь это то самое решето, отделяющее зерна от плевел, то бишь более способных программистов от менее способных, на отсутствие которого во многих открытых проектах справедливо и с некоторым опасением указывают аналитики.

А вот второй пример, Inkscape — очень удачный и перспективный форк векторного редактора Sodipodi для Windows и Linux (тоже на основе Gtk). Форки вообще имеют к теме статьи самое непосредственное отношение. Форк — это создание нового приложения из кода приложения, уже существующего, вызванное желанием сделать «более правильный» или имеющий схожую функциональность продукт. В большинстве известных мне случаев форки являются результатом перепалки основных разработчиков относительно пути развития программы или разногласий относительно подхода к принципу написания кода. Очень часто форки не выживают, утаскивая в небытие и исходную программу, ведь от ее разработки происходит внезапный отток творческих сил и целый кусок кода по обе стороны баррикад остается без поддержки и лишается шансов на дальнейшее развитие.

Упомянутый форк от Sodipodi, родившийся более года назад, был поступком в высшей степени мотивированным. Дело в том, что основной разработчик Sodipodi Лаурис Каплински, весьма талантливый художник, несмотря на личную заинтересованность в хорошей программе на контакт с пользователями шел неохотно, новые версии выпускал «от балды» и точных планов на будущее программы не имел. В результате после отпочковывания кода в свет вышла одна-единственная новая версия Sodipodi, из принципиальных улучшений которой можно назвать разве что логические функции работы с контурами.

Что дает новый проект — Inkscape? Внимательных к пользователям разработчиков, частые (раз в два-три месяца) релизы новых версий, официально опубликованный и соблюдаемый план развития программы и, как следствие, четкую цель — мощный векторный редактор на основе стандарта SVG.

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

К слову, несколько раз форкать пытались и The GIMP. Скажите, вы много знаете о результатах? Вот именно, что нет, — справиться с таким объемом кода, лишь в этом году прошедшего серьезный рефакторинг, ой как непросто. Поэтому пользователи терпят гонор разработчиков и ждут завершения интеграции с подпроектом GEGL, обещающей 16 и более бит на канал, все мыслимые цветовые пространства, поддержку ICC-профилей и другие деликатесы. Благо ждать осталось недолго, а часть GEGL (та же раскладка на Lab) окажется уже в версии 2.2, которая вот-вот появится.

Последний обещанный пример — Ardour. Его основной разработчик Пол Дэвис — квалифицированный специалист в области цифровой обработки сигнала (DSP). В проекте участвуют и другие профессионалы, имеющие многолетний опыт программирования приложений для работы со звуком и создания программных прошивок для различных звуковых устройств. Сам Пол, например, является автором драйверов под Linux для линейки известных полупрофессиональных звуковых карт RME Hammerfall, а Джек О’Квин — вообще ветеран DSP-программирования с тридцатилетним стажем. В свое время мистер Дэвис успел пожалеть о том, что выбрал для Ardour лицензию GPL, тем более что толковую бизнес-модель на основе свободного софта ему придумать не удалось. Сейчас он кормится на деньги тех, кто либо уже пользуется этой программой (чья финальная версия, правда, запаздывает на год), либо тех, кто планирует поставлять Ardour со своими звуковыми железками. По этой причине автор попросил сообщество воздержаться от подробного документирования Ardour, поскольку надеется продавать финальную коробочную версию программы с уже написанной им толстенной книжкой. Не раз убеждавшись в том, что маркетологи из программистов неважные, позволю себе усомниться в реальности этой затеи. Тем не менее пожелаем Полу, тратящему много сил на эту стратегически важную разработку, всяческих успехов. Не так уж много среди свободного звукового софта программ, знамя которых хочется поднять над головой и гордо нести вперед.

Сейчас можно говорить о новом поколении опенсорсных программистов, лучше понимающих степень ответственности за то, что выходит наружу, и более открытых к контакту с пользователями. Не случайно доводка графического интерфейса под стандарты, заданные GNOME Human Interfaces Guidelines, стала обычным делом даже несложных и, казалось бы, «наколенных» разработок, вовсе не претендующих на свой уголок в новелловском корпоративном десктопе.

Но все-таки будьте готовы к тому, что, внимательно выслушав ваши предложения и идеи, разработчик скажет: «Извините, это идет вразрез с моими планами» и закроет дверь. Он свободен в своем выборе, как и вы. И если вы умны, то не будете на него обижаться.