На недавно прошедшей конференции Application Developer Days 2012 мне довелось прочитать коротенький доклад о том, как создаются Open Source проекты на примере OpenVZ Web Panel. К сожалению, у меня было 10 минут, вместо положенных 30-40 и в результате 80% подготовленного материала оказалось “за бортом”. Организаторы, почему-то в последний момент передумали и убрали даже 5-минутную секцию с вопросами, так что остался без фидбэка. Но не буду сильно наезжать на организаторов — они старались как могли и конференция явно удалась, за что им огромное спасибо. Также очень порадовало и качество большинства докладов.
Теперь к сути топика — хочу выложить полную версию рассказа о том, как создаются Open Source проекты на примере собственного начинания, поделится мыслями и взглядами на разработку подобных проектов, рассказать о внутренней кухне, попробовать предостеречь от типичных ошибок.
Большая часть всего, что написано ниже — абсолютно субъективно. Некоторые вещи можно считать крамольными, однако многое было буквально выстрадано на собственном опыте.
Текста довольно много. Для особо нетерпеливых — можно просто полистать слайды.
Немного о подопытном кролике проекте
OpenVZ Web Panel — это довольно популярная бесплатная веб-панель управления виртуальными серверами на технологии OpenVZ. В подтверждение этого можно сказать, что версия 2.0 была установлена на более чем 17 000 серверов. Для серверного продукта вполне солидная цифра.
Что представляет собой OpenVZ? Это одна из технологий контейнерной виртуализации серверов. Кому-то нравится и подходит для решения задач, кому-то не очень, но сейчас не об этом. OpenVZ по сути является плацдармом для коммерческого продукта Parallels Virtuozzo Containers. Изначально для OpenVZ не было хорошей бесплатной веб-панели управления. Сам я активно пользуюсь OpenVZ. Существовавшие бесплатные панели меня не устраивали по тем или иным причинам. В результате родился проект OpenVZ Web Panel.
Разработка была исключительно в целях удовлетворить свои потребности, поэтому на определенном этапе было решено сделать проект Open Source. Поделится своими наработками с другими людьми, которые, возможно, тоже были в поиске подобной панели.
Идея вашего проекта
Рекламный блок вы прочитали, теперь возвращаемся к сути топика. Итак вы собрались создать свой Open Source проект. Первое, что должно у вас быть — это классная идея. В отличие от коммерческих проектов у вас не будет отдела маркетинга, массированной рекламы в специализированных изданиях и на биллбордах. Рекламу по телевизору бесплатного браузера Google Chrome может позволить себе только компания Google.
Если вы не уверены в идее проекта, можете попробовать поделиться ей и обсудить на специализированных форумах. В коммерческой разработке в большинстве случаев вы едва ли поступите аналогично. Здесь же страха и рисков, что идею кто-то украдет, на порядок меньше. Обязательно спросите себя несколько раз, чем ваша идея и проект будет лучше аналогичных разработок. Может быть достаточно присоединиться и улучшить уже существующий проект?
Кроме того, идею, желательно, как можно быстрее проверить на практике. Желательно выпустить альфа-версию и посмотреть на реакцию аудитории. Если будут восторженные отклики и множество пожеланий — вы идете в верном направлении. Если все молчат, то это хороший повод задуматься.
Мотиваторы-демотиваторы
Любой создаваемый вами проект должен иметь какую-то внятную мотивацию. Проекты из разряда “это прикольная штука и такой проект повысит мою карму” на практике очень быстро угасают. Примеры более весомой мотивации: вы собираетесь сами использовать свой проект или у вас есть конкретный заказчик. В случае OpenVZ Web Panel работал первый вариант, то есть необходимо было удовлетворить собственные нужды. Без сильной мотивации довести проект даже до первого релиза будет очень сложно.
Иногда люди говорят: создам Open Source проект, а потом на нем заработаю. Это пример неправильной мотивации. На самом деле, если вы действительно хотите заработать, то думать об Open Source нужно в самую последнюю очередь. Иначе наиболее вероятен следующий план развития событий: проект сделан, как зарабатывать — не понятно. В итоге мотивация полностью утрачена и продолжать развитие проекта вы уже не захотите.
Эффективная разработка
Старайтесь оставаться сфокусированным на нескольких самых важных для вашего проекта вещах. Сообщество будет толкать вас в сторону самых разнообразных изменений, уводить от основного курса. Например, для OpenVZ Web Panel если бы я соглашался и реализовывал все запросы пользователей, то давно бы уже делал очередной Webmin, а не систему управления контейнерами.
Разработка должны быть максимально эффективна в плане времени. Это единственный и самый дорогой ваш ресурс. Зачастую, принятые решения могут идти в ущерб качеству или каким-то требованиям, но если они эффективны по времени, то скорее всего вы идете в правильном направлении.
Кроме того желательно, чтобы вы умели выполнять практически любую задачу, которая встретится в вашем проекте. Если вы планируете какие-то работы делегировать другим людям, а работать они будут на общественных началах, то, поверьте, работа пойдет самым неэффективным образом. Плюс велика вероятность, что они вас просто продинамят.
Довольно трудным вопросом в плане эффективности является вопрос автоматизации процессов. С одной стороны вы же программист и предпочитаете действовать по принципу “за час написать и за 5 минут долететь”. Это принцип работает очень часто в ущерб вашему времени. Автоматизировать надо только то, что действительно повторяется из раза в раз.
В Open Source проектах обычно нет профессиональных тестеров, которые внимательно проверят все тест-кейсы и заведут вам баги, поэтому тестировать свой продукт, в первую очередь, будете вы сами. Это значит, что нужно заставлять себя писать функциональные и юнит-тесты, иначе вынуждены будете либо тратить время на ручное тестирование, либо пропускать в релиз серьезные проблемы. Тут, конечно, можно сказать: «спасибо, Кэп». Однако, в угоду экономии времени очень часто в проектах страдает именно этот пункт.
И последний момент. Если хотите вести разработку более-менее серьезно — занимайтесь учетом времени. Поставьте Redmine, заводите не только баги, но и задачи, пишите сколько потратили на них времени. Только тогда вы начнете понимать сколько в действительности стоит та или иная фича. В следующий раз вы уже вряд ли потратите два дня на автоматизацию одноразовой процедуры, которая делается вручную за полчаса. Кроме того, если вдруг появится спонсор, то будет гораздо легче объяснять стоимость той или иной фичи.
В рамках работы над OpenVZ Web Panel ко мне не раз обращались с просьбой собрать продукт в виде пакета под «любимую ОС». Причем под любимой ОС порой фигурировал и ArchLinux и Gentoo. Я ничего не имею против этих дистрибутивов, но сообщество их пользователей настолько мало по сравнению с тем же CentOS или Debian, что я потрачу кучу времени на очень сомнительную в плане пользы задачу. У панели есть замечательный Shell-инсталлятор. Я знаю, что он менее предпочтителен по сравнению с пакетами. Однако я также очень хорошо знаю, что поддержка пакетов на должном уровне для, скажем, пяти дистрибутивов Linux — это очень затратная задача в плане времени. Пока Shell-инсталлятор экономит мне уйму времени на разработку. Самое забавное, что если любителя Debian (который уже пятый по счету обещает прислать пакет, но ни один так нормальный пакет и не прислал), я еще попрошу попробовать собрать пакет под CentOS, то… ну вы меня поняли.
Качество продукта
Довольно часто пользователи Open Source продуктов недовольны их качеством. Если вы хотите сломать этот стереотип, не забываете о качестве продукта.
Под качеством нужно понимать не только тестирование продукта. Качество должно быть во всем — в дизайне, в юзабилити, во вспомогательных инструментах, сайте продукта, документации, технической поддержке.
Ниже скриншот фронт-энда для менеджера закачек wget. Подход программиста к дизайну интерфейса в чистом виде: «есть опция — должна быть на экране».
А вот скриншот WordPress. Можно любить или не любить этот продукт, но признать то, что люди явно работают над качеством продукта — стоит.
Нередко в Open Source проектах можно увидеть графический интерфейс, где в изобилии хаотично разбросаны элементы управления, а логика работы понятна только автору. Не забывайте о пользователях, пробуйте проводить ревью того, что вы делаете представляя себя в роли типичного пользователя. Если что-то работает не очевидным образом, будьте уверены — большая часть пользователей обязательно запутается и совершит ошибку. Характерный признак такой проблемы — в issue tracker’е уже 20-ый тикет на одну и ту же тему — где находится элемент управления. В этой ситуации люди часто ограничиваются просто добавлением информации в FAQ или Knowledge Base. На самом деле FAQ и Knowledge Base надо регулярно просматривать на предмет решения проблем в продукте и уменьшения списка часто задаваемых вопросов.
Не нужно забывать и о таком моменте, что качество кода на самом деле ваших пользователей интересует в последнюю очередь. А вот удобство использования, отсутствие как run-time так и логических ошибок очень сильно влияет на впечатление о продукте. Зачастую авторы стремятся к гармонии в плане кода и забывают об удобстве продукта. Понятно, что качество кода коррелирует с качеством продукта, но акцент желательно все-таки делать именно на втором моменте. В конце концов, многие успешные Open Source проекты имеют довольно унылый по качеству код. Хороший повод призадуматься (но не подумайте, что я агитирую вас писать говнокод).
Технологии
Open Source проекты предоставляют отличную возможность для обкатки новых технологий и проведения экспериментов. Обязательно пользуйтесь этим моментом. В корпоративных приложениях можно годами ждать перехода на использование какой-то модной и крайне удобной технологии. Здесь же вы сами себе CEO и CTO и все технические, архитектурные и стратегические решения можете принимать единолично.
Однако не стоит забывать и о конечных пользователях. Если у вас веб-приложение будте уверены, что большинство из них едва ли понимает, чем HTML3 отличается от HTML5. Однако если вы полностью откажетесь от поддержки IE, то они это обязательно заметят и просто не поймут. Пользователю в первую очередь важен контент, а не ваши технологические навороты.
В Open Source разработке вы менее ограничены в применении сторонних библиотек и фреймворков. Например, в OpenVZ Web Panel для UI используется известная библиотека ExtJS. Если вы захотите использовать эти библиотеку в своем коммерческом продукте, то нужно будет раскошелиться на весьма недешевую лицензию. С другой стороны работая с библиотекой ExtJS в рамках Open Source проекта вы можете получить ценный опыт ее практического использования и далее этот опыт применить в коммерческом проекте.
Отсутствие бюджета на разработку также толкает на поиск альтернатив дорогим платным компонентам. Нередко оказывается, что такие компоненты на порядок проще интегрировать и поддерживать, чем коммерческие аналоги. В конце концов, вы даже можете посодействовать развитию другого Open Source проекта, исправляя какие-то проблемы.
Инструменты
Существует довольно много удобных инструментов, помогающих в разработке Open Source проекта. Многие из них вы знаете и, наверняка, пользовались. Однако по настоящему их начинаешь ценить, когда работаешь над коммерческим проектом, где по тем или иным причинам эти инструменты не доступны. Вспоминаешь корпоративный Exchange и SharePoint и начинаешь грустить по Gmail и MediaWiki.
Не стоит также забывать о том, что ряд компаний стимулируют разработку Open Source проектов, раздавая таким проектам бесплатные лицензии на собственные коммерческие проекты. Например Atlassian может дать вам бесплатную лицензию на Jira или Confluence. Для разработки OpenVZ Web Panel некоторое время я использовал IDE RubyMine, бесплатную лицензию на который любезно предоставляли товарищи из JetBrains (пользуясь случаем передаю им привет и требую продления лицензии :)). В рамках интеграции с биллингом WHMCS, также понадобилась лицензия на продукт. Официально они не предоставляют бесплатных лицензий, но интерес был взаимный, поэтому лицензия была оперативно предоставлена. Поэтому, если вас интересует какой-то коммерческий продукт, который бы помогал в разработке проекта, обращайтесь к производителям этого продукта. Скорее всего вы сможете получить бесплатную лицензию, внятно объяснив зачем вам нужен именно их продукт.
Сообщество
Часто люди думают, что сообщество позволяет решать любые проблемы проекта. Это абсолютно неверно. Во-первых, если только вы не пишите инструмент для разработчиков, то среди пользователей оказывается, что нет программистов. Да и разбираться в дебрях вашего говнокода они почему-то не спешат. Если же вдруг вам прислали патч, то на проверку окажется, что в лучшем случае это костылик, который и работать-то не будет для большинства пользователей.
Очень сложно уговорить людей тестировать сырой продукт. Даже фичи, которые запрашивал сам пользователь он предпочитает проверить только после релиза.
С другой стороны, багрепорты о насущных проблемах и голосование за фичи — работает вполне неплохо. Главное, не терять собственный контроль над ситуацией и быть готовым принять сложное и, может быть, не всем угодное, но правильное с точки зрения продукта, решение. Иначе моментально начинается известное произведение, где «лебедь раком щуку». Причем вы выступаете в роли отнюдь не лебедя.
Если же вам нужно перевести интерфейс на другой язык, попробовать причесать документацию, предложить что-то на обсуждение — сообщество всегда к вашим услугам. Устраивать холивары и бесконечные обсуждения — это тоже конек некоторых людей практически в любом сообществе.
И как обычно, в любом сообществе есть тот, кто чем-то недоволен и считает, что вы должны бросить все дела и заниматься только его проблемами. В конце концов он же пожертвовал вам 10 долларов.
Деньги?!
Я уже говорил о том, что если собрались заработать на проекте, то скорее всего этот проект не стоит начинать как Open Source. Отказаться от такой схемы в будущем будет очень сложно. С другой стороны как-то мотивировать разработку в финансовом плане все равно нужно. Даже на элементарную поддержку проекта вы можете нести расходы, например на , железо и прочее.
Ряд моих знакомых, почему-то продолжают свято верить, в что подобные проекты вполне могут жить на пожертвования. Не могут. На вскидку сейчас не могу вспомнить ни одного проекта, где видел более-менее внятную собранную сумму рядом с кнопкой Donate (тут важно не путать спонсорство и пожертвования). Если вы не создатель Википедии и на сайте проекта не висит личной фотографии с грусными глазами, то пожертвований вам едва ли хватит даже на сайта проекта. Не буду говорить о собственном проекте, т.к. для него статистика не публична. Но недавно заглядывал на сайт проекта Gitlab. Довольно интересное начинание, много заинтересованных. Внизу «градусник» с прогресом сбора суммы в 1000 долларов. Заглядывал туда 3 недели назад и сегодня. Собранная сумма изменилась меньше чем на 150 долларов. Причем это даже очень неплохо по сравнению со другими.
Более реальные способы заработка — это продажа альтернативных лицензии (подходит для встраиваемых в другие системы продуктов) и коммерческая поддержка (подходит для сложных в освоении продуктов). Для меня же лично, наиболее симпатичным выглядит вариант наличия спонсора-клиента или спонсоров, заинтересованного в развитии вашего проекта.
Правда с появлением спонсора очень желательно не допустить пару типичных ошибок. Первое это потеря всех прав продукт и передача их заказчику. Второе это бесконечная работа над кастом-версиями продукта без возможности работы над главной линией. И то и другое в конечном итоге приведет к тому, что вы будете вынуждены закрыть проект именно как Open Source.
Выводы, куда ж без них
Старайтесь чтобы в проект был в первую очередь интересен вам самим и решал какую-то вашу проблему. Большинство успешных Open Source проектов, которые приходят сейчас в голову, шли именно по такому пути. Это и Rails и Nginx и многие другие.
Если вы решили крупно заработать с помощью создания Open Source проекта, то заранее тщательно продумайте бизнес-модель. Скорее всего, лучше делать проект закрытым.
Помните о самом дорогом вашем ресурсе — времени. В конце концов, у вас наверняка есть основная работа и хоть какая-нибудь личная жизнь.
И последнее, создавайте законченный продукт, которым можно будет гордиться. Не останавливайтесь на «супер технологичной», но альфа-версии. Самое трудное и в коммерческой и в Open Source разработке — это довести продукт до релиза. Потом сможете ездить по конференциям и рассказывать всем о вашем успешном начинании (как, например, это делает автор Sphinx’а :)).
P.S. Все вышенаписанное — исключительно личное мнение. Я, как и многие другие, склонен ошибаться, учиться на своих ошибках и делать многие вещи неправильно, но при этом пытаться учить других :)
Автор: SibProgrammer
