Материал из Linuxformat.

Содержание 1 Взлет и падение открытого проекта 1.1 Идея 1.2 Быстрый рост 1.3 Первая сборка 1.4 Падение

Взлет и падение открытого проекта

Грэхем Моррисон (Graham Morrison) расскажет о радостях и разочарованиях создания собственного Linux-приложения.

Многие из нас мечтают написать собственную программу с открытым кодом. Грэхем Моррисон в 2001 году попытался сделать нечто подобное, взявшись за создание программы-каталогизатора фотографий для Linux, с применением своих новых знаний C++.

Результат – Kalbum – был встречен благожелательно, программа стала так популярна, что её стали включать в состав многих дистрибутивов. Но 4 года спустя проект стал увядать, и сейчас Грэхем ищет новых разработчиков, чтобы развивать программу.

Ниже он приводит несколько факторов, которые привели проект к застою, и дает некоторые советы тем, кто начинает работу над своей программой с открытым кодом.

Идея

Kalbum – небольшой проект. Я не совершал никаких действий над ним в течение трех лет. Он справляется со своей работой и делает все то, что мне от него требуется. Это не так важно, но траектория его взлета и падения типична для многих проектов с открытым кодом.

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

KDE или Gnome?

Я принял решение начать проект, который позволит мне продвинуться в программировании на C++.

До этого я использовал C и привык думать о решениях, как о наборе функций. Разбиение задачи на малюсенькие кусочки казалось вполне естественным, но объектная модель, используемая в C++, притягивала к себе как шаг к идеалу, ведь объекты и наследование позволяют гораздо эффективнее управлять задачей.

Gnomе считался API «только для C», тогда как Qt/KDE отстаивали C++. Вместе с наличием исчерпывающей документации по Qt, это определило мой выбор.

Плохое проектирование

Я изучал новый язык и инструментарий одновременно, мне было сложно сориентироваться, за что следует браться в первую очередь в таких проектах, как этот. Ответ, как правило, состоит в том, чтобы заставить вещи двигаться так быстро, насколько это возможно. В данном случае имеется в виду появление чего-либо «осязаемого» на экране. Если бы при проектировании я четко представлял дальнейшее развитие программы, можно было бы избежать многих часов тяжелой работы. И, что важнее, это могло сделать Kalbum более понятной программой для потенциальных помощников. Qt имеет мощные служебные программы для манипуляций над изображениями, но когда сначала делаешь, а потом думаешь, хорошую программу не сделать. Процесс разработки, когда вы проводите пару часов, работая над чем-нибудь, компилируете и видите изменения на экране, ободряет. Это «пришпоривает» вас – и Kalbum в этот период развивался быстрее всего, но потом процесс затормозился по самым примитивным причинам. Как поменять сортировку изображений в альбоме? Это должно было быть совсем просто, но вышла крутая схватка характеров – разработчика против API.

Быстрый рост

Изначально я планировал, что любой кто использует Kalbum, сможет просто перетаскивать миниатюру изображения с одного на другое место. Разумеется, я рассуждал, что раз миниатюры так хорошо подходят для наглядного отображения файлов, то должен существовать механизм их перемещения. Однако, в KDE на тот момент это не выглядело реальным. Вы можете пересортировать изображения в списке, но когда вам потребуется упорядоченный показ изображений в таблице, это будет просто невыполнимо.

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

Не ракетостроение

Это типичный программистский кошмар, потому что решение должно быть простым и легким для понимания. Проблема в том, что я понимал свой код только те несколько секунд, пока его вводил. Все работало, но когда я снова взглянул на функцию, закончив ее писать, я не смог понять, как же она на самом деле работала. Полную неразбериху можно обнаружить в функции KalbumView::editMoveWindow – я до сих пор не понимаю, как она работает. Вероятность случайной ошибки в таких запутанных подпрограммах, как эта, весьма высока, и тут не может быть никаких оправданий плохой работе.

Однажды я вставил простое окно для добавления даты и комментария в каждое изображение, единственное, что было упущено в ядре приложения – это экспорт в HTML для создания пользовательских web-страничек. Я совсем запутался со своим web-дизайном и концепцией папок, выглядевшей наиболее подходящей для фотоальбома. Закладки по правую сторону страницы позволили бы быстро перескакивать на главную страницу, миниатюры изображений или большую картинку выбранного изображения.

Код HTML я взял с неиспользуемого коммерческого проекта, над которым когда-то работал.

Затем была проведена несложная работа по разметке HTML-кода и комментариев, которые я мог менять, используя превосходные манипуляции над строками Qt. Совсем не было времени изучать, как можно было использовать возможности XML и XSLT. Также подразумевалось, что HTML мог быть редактируемым, и комментарии оставляли возможность того, что папка может быть использована как шаблон для другого дизайна. Выглядело все это грубо, но зато работало.

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

Подготовка к запуску

Наверное, одна из наибольших проблем в разработке открытых приложений встречается на этом этапе. Вы даете всем понять, что проект недоделан, что он представляет собой временное решение, однако пользователи штудируют ваш исходный код, рассказывают вам о всех ошибках и строят планы дальнейшей разработки. К тому времени, как проект разрастается до определенного размера, он напоминает смесь ошибок новичка (только взгляните на размер главного класса приложение Kalbum – 67 Кб исходного текста!), рано или поздно он уподобляется Пизанской башне и нуждается в пересмотре своих основ. Постоянно растущее количество времени и сил тратится просто на то, чтобы заставить приложение работать, при этом речь пока не идет о добавлении действительно серьезной функциональности.

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

Никакого публичного выпуска бы не получилось, если бы не существовало множества форумов, на которых я мог опубликовать приложение. На момент выпуска Kalbum, превосходным местом для всех приложений KDE был сайт http://apps.kde.com. Там содержался большой и регулярно обновляемый список новых и улучшенных приложений, зачастую этот портал был первым на пути энтузиастов KDE, ищущих поутру новые программы. Также у пользователей существовала возможность оставлять комментарии и ставить программе оценки.

Первая сборка

Я создал RPM-пакет для Mandrake 8.2 и загрузил его вместе с исходными текстами на ныне умерший http://apps.kde.com. Через некоторое время разные люди скачали программу, и уже в течение первых 30 минут стали поступать отчеты о многочисленных ошибках. Оказалось, что существовала непонятная зависимость: только что созданный RPM-пакет требовал библиотеки NVIDIA. Это являлось результа том сборки моего RPM-пакета на системе с картой NVIDIA, и единственный путь исправления состоял в сборке на системе без нее. После загрузки исправленных пакетов, я решил, что на сегодня хватит, и отправился спать.

На следующее утро пара сотен человек скачали Kalbum, а мой ящик был полон писем от разных людей, у которых возникли сложности. Особенность Open Source-проектов состоит, в частности, в том, что ваша программа тестируется на огромном количестве комбинаций оборудования и ПО, поэтому у кого-то, где-то обязательно возникнут проблемы. Для меня это стало совершенной неожиданностью и большую часть свободного времени я тратил на то, чтобы помочь людям заставить работать посредственное приложения для управления фото на их системах.

Также приходили отчеты об ошибках от разработчиков, включивших Kalbum в тот или иной дистрибутив. Они жаловались, что я не использовал стандартный диалог представления структуры каталогов и что я использовал неправильное имя для HTML-файлов. После месяцев изолированной разработки было странным обсуждать, как и что должно было быть. Было бы гораздо лучше, если бы эта обратная связь и взаимодействие являлись частью разработки с самого начала, но так проекты, к сожалению, не начинаются.

Также казалось странным, что в проект оказались вовлечены люди, которые никогда до этого с ним не контактировали. В один момент пошел поток итальянцев, имеющих такие же специфичные проблемы. Через пару недель один из них обмолвился, что программа Kalbum была представлена в итальянском журнале, что и стало причиной такой активности.

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

Зависть к Album

Самым сюрреалистичным моментом было появление другой программы, носящей имя KalbumPhoto. Это был прототип приложения, почти с теми же самыми возможностями, что и у Kalbum. Казалось, что разработчик зачастую предпочитает запускать свой собственный проект, чем присоединиться к одному из уже существующих. Совершенно понятно желание осуществлять контроль или быть свободным для экспериментов, но поразительно, как плодотворно могут работать двое людей, когда они работают вместе. После короткой переписки с автором KalbumPhoto, мы уладили разногласия и оба пошли собственным путем. Здесь также присутствовало давление со стороны сообщества разработчиков KDE, пытающихся создать стандартную систему подключаемых модулей для работы с изображениями, которая могла бы упростить работу похожих приложений. В принципе, идея была великолепна: комментарии и даты, присвоенные фотографиям в digiKam, могли бы читаться Kalbum, Konqueror или любым иным приложением, которое использует ту же библиотеку. Проблема состояла в том, что мы все имели слегка отличающиеся взгляды и не могли договориться, поэтому создание общего стандарта было сложным.

Будучи изначально моей маленькой поделкой, Kalbum быстро разрабатывалась на протяжении нескольких следующих месяцев. Мне разонравились модальные окна первоначальной версии, которые теперь были использованы для диалогов альбомной информации и экспорта, так же как и комментарии к каждому фото. Пока это было оставлено как есть, но пользовательский интерфейс был изменен для использования «липких» (dockable) элементов управления. Это делало работу удобнее: приложение можно было использовать так же, как и раньше, но теперь имелась возможность прикрепить окно к главному приложению или оставлять его в любой части экрана.

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

Мои слабости

Одна из главных проблем Open Source – плохая документация, и мой проект не стал исключением. Несмотря на две недели, потраченные на добавление возможности множественного редактирования, я не заставил себя потратить и десяти минут на то, чтобы поведать миру о существовании этой возможности, или даже о том, как ее использовать, если пользователь случайно на нее наткнется. Для них это, вероятно, должно было выглядеть как ошибка. Отсутствие документации – это то, что останавливает так много Open Source-приложений. Это правдиво как для KDE, так и для Kalbum.

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

Поддержка технологии «Drag and Drop» обернулась кошмаром, возможность включения этой удобной возможности в Kalbum стала результатом тренировок и исследований, которые велись со множеством приложений. Информация подбиралась по кусочкам из таких программ, как PixiePlus, Kooka, Gwenview и самого Konqueror, пока ее не стало достаточно для выполнения работы. Решение состояло в создании собственного MIME-типа для миниатюр, потока двоичных данных и перехватчика событий. Это означало, что миниатюры, наконец, могли перетаскиваться из одного места в другое, появилась возможность перетаскивать их между несколькими копиями Kalbum для обмена фотографиями.

К сожалению, это было сложно воплотить, потому что снова возникала вечная беда Open Source – отсутствие достаточной документации.

Падение

На протяжении основного периода разработки, различные люди прикладывали руку к исправлению разных мелочей тут и там. Обычно это были части, беспокоящие их как пользователей, или ошибки, которые могли быть легко исправлены. И однажды я решил, что будет лучше перевести проект на SourceForge, нежели исправлять все своими силами. Случайно или нет, в этот момент у меня почти не было свободного времени для работы над проектом, и чем дальше, тем труднее мне становилось возвращаться к разработке Kalbum.

Каждое добавление требовало все больше и больше времени для внедрения, и разработка стала вязнуть. Теперешнее состояние проекта разительно отличается от былого энтузиазма в самом начале. Теперь на моем жестком диске есть версия с несколькими возможностями, о которых просили пользователи, но я ее пока не выпустил. Здесь и использование EXIF для автоматического вращения изображений, и новое окно предпросмотра, но самое главное, эта версия использует кэш изображений KDE для заметного ускорения загрузки миниатюр.

Столкновение с пустотой

Это конец кривой, финальная стадия в жизненном цикле маленького, разрабатываемого одним человеком открытого проекта. Очевидно, что для того, чтобы продвигаться вперед, необходимо проделать над Kalbum серьезную работу. Мне нужно провести перестройку классов, вычленить HTML-генератор в отдельное приложение и создать больше шаблонов. Это будут основные дела – ничего другого добавлять мне не хочется.

Девяноста четыре человека скачали Kalbum с сайта в июле, спустя три года после выхода последней версии. Это, не включая огромного количества других сайтов, с которых доступна загрузка. Ввод "generated by Kalbum" в поисковой машине выдает сотни результатов и я все еще получаю письма с недовольством по поводу приставки "K". Kalbum не мертв. Он в морозильнике.

Существуют реальные планы выпустить следующую версию, но до сих пор мне не удалось найти достаточно времени, чтобы воплотить их. Я хочу использовать в Kalbum систему ярлыков, похожую на Gmail, хочу чтобы он работал более как интерактивный фотожурнал, нежели как экспортер изображений, также ему очень нужны несколько дополнительных шаблонов. Идеи, подобные этим, превосходны, их вполне достаточно, чтобы заставить меня запустить KDevelop.

Если бы я начинал проект, подобный Kalbum, сейчас, то очень многое я сделал бы по-другому. Во-первых, я бы поискал похожий проект и попытался помочь ему. Если в работу с самого начала вовлечено несколько человек, то проблем становится меньше. Нехватка людей и недостаток ответственности за проект – вот главные причины того, что текущим статусом Kalbum является пауза, «подвешенность». Изменения, вероятно, будет легче вносить тогда, когда я переделаю Kalbum для запус- ка в KDE 4.

Это потребует некоторой серьезной работы над базовой частью кода, но я надеюсь, что после этого разработка станет доступнее и проще.

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

Поддержка и тестирование также важны, следовательно, нужна документация. Какой смысл добавлять возможности, о существовании которых никто, кроме программиста, не знает? Также важно не допустить появление апатии и разочарования в собственной работе. Текущая версия Kalbum, помещенная на SourceForge, ни разу не была собрана в двоичную форму (держите пальцы скрещенными, это должно произойти во время прочтения вами данной статьи) и Kalbum никогда не фигурировал на превосходном http://kde-apps.org. Всему виной плохое проектирование и управление разработкой, так что очень важно осознавать свою ответственность. Еще более важно то, что программистам надо использовать свое приложение. Нельзя сделать интерфейс лучше, если программист не знает, как это на самом деле будет использоваться.

Подведем итоги

Не считая множества трудностей, с которыми столкнулся процесс разработки Kalbum, то, что он являлся открытым проектом, было для меня чрезвычайно ценным опытом. Он предоставил мне возможность работать и общаться с людьми со всего мира. Я отполировал свои программистские навыки и пережил некоторые радости и разочарования оттого, что иду в ногу с миром Open Source. Мне не терпится впутаться во что-то, подобное Kalbum, снова. Но самое лучшее состоит в том, что практически любой пользователь может делать похожие вещи, используя дистрибутив Linux на своем компьютере.