Здравствуй Хабр!
Размышляя о способе заработка на своём маленьком проекте, придумал, как мне казалось, оригинальную модель финансирования. Внутренний копираст тут же начал ехидно ухмыляться и потирать ручки, предвкушая миллионы прибыли и всемирную славу изобретателя велосипедов. Он чуть было не задушил мои намерения поделиться идеей с общественностью, но, как известно, ничто в нашем мире не ново — погуглив, обнаружил как минимум три ресурса с описанием или упоминанием данной модели. Далее буду описывать её в том виде, который сформировался лично у меня.
Признаюсь честно: перед публикацией на хабре искал похожие темы очень поверхностно, но, учитывая то, что слежу довольно активно за новыми статьями и вряд ли пропустил бы столь интересную тему, буду считать, что публикация уместна.
Итак, какие же мысли легли в основу:
Решением этих проблем является несколько изменённая модель crowd funding, встречайте…
Изначально придумал для этой модели название donation driven development, но потом переписал на нынешнее (как она называется здесь), чтобы не возникало путаницы с существующими терминами. Можно ещё хитрее (и более точно): community-donations-shaped development. Если сформулировать кратко, то: сообществом пользователей продукта оплачивается только его ра��витие, а не каждая отдельная копия, при этом развитие происходит в том направлении, которое выбирается сообществом и подкрепляется пожертвованиями.
Далее более развёрнуто.
Основные положения модели:
*под оценкой понимается определение сложности задачи и необходимых для её выполнения ресурсов (финансирование, время, специалисты)
Фичей может быть практически что угодно, начиная от добавления определённого языка интерфейса и заканчивая рефакторингом кода для улучшения производительности.
Эту модель можно применять как для standalone приложений так и для веб-сервисов, для маленьких или довольно больших проектов (по размеру команды разработчиков или по богатству функционала). Возможно, с некоторыми доработками она применима и к opensource проектам.
Среди плюсов стоит перечислить следующее:
Естественно имеются и свои минусы:
Все фичи находятся в общем пуле. Добавить фичу в пул может любой желающий, при этом она будет иметь статус подлежащей обсуждению.
В обсуждении участвует всё сообщество. Каждый может комментировать, голосовать за фичу и вносить свои предложения. Если разработчики сочли запрос адекватным и реализуемым, они начинают оценку и оформление техзадания. В техзадании должен быть представлен список всех необходимых ресурсов и выполнена разбивка фичи на подзадачи (в дальнейшем это упростит оценку готовности работ и позволит обосновать запрашиваемую сумму). Так же разработчики могут разделять фичу на независимые составляющие, если это уместно. В дальнейшем ведётся обсуждение техзадания. Когда техзадание финализировано, фича получает статус ожидающей финансирования.
Теперь любой желающий может пожертвовать некоторую сумму на работу над да��ной фичей. Если пожертвование не анонимное, то пользователь заносится в группу заинтересованных, которым могут быть предоставлены эксклюзивные возможности (например тестирование бета-версии фичи или более высокий приоритет в обсуждениях). Все могут контролировать процесс сбора средств и следить за состоянием выполнения, так как разработка может идти параллельно с финансированием. Собранных пожертвований может не хватать до необходимой суммы, в этом случае имплементация остаётся на совести разработчиков. Если же пожертвований собрано больше чем необходимо, то излишки могут быть потрачены на общее развитие проекта либо на наём стороннего разработчика и ускорение имплементации.
Следует отметить, что при разработке необходимо чётко следовать техзаданию, так как оно фактически является контрактом с сообществом пользователей. Так же следует обновлять статус готовности фичи по мере выполнения работ и информировать сообщество в случае возникновения каких-либо неожиданностей. Если разработка становится невозможной, то фича либо отбрасывается на стадию обсуждения, либо закрывается со статусом невозможности имплементации и непотраченные средства возвращаются донаторам для перераспределения по другим фичам. Если же разработка прошла успешно и протестирована внутри команды разработчиков, то можно переходить к публичному тестированию.
Публичное тестирование может быть невозможно в силу сложности или характера фичи, однако, если оно принципиально возможно, то обязательно должно быть проведено на сообществе пользователей. Детали проведения тестирования могут отличаться в зависимости от конкретной фичи, политики разработчиков и всего проекта в целом. В случае обнаружения недоработок фича может быть отброшена на стадию разработки или обсуждения. В случае успешного завершения тестирования фича помещается в стабильную версию и получает статус завершённой.
После интеграции новые возможности становятся доступны всем пользователям, независимо от их пожертвований. Несмотря на долгий путь фичи до данного состояния и возможность повлиять на ход событий каждого пользователя в сообществе, может получиться так, что будут иметься пользователи недовольные нововведением.
Рассмотрение всего спектра проблем и отыскание их решений тянет на целую серию статей, так что я ограничусь наиболее важными на мой взгляд.
Проблема: Пользователи не жертвуют на развитие проекта.
Решение: Тут может быть несколько причин. Самая невероятная — имеющаяся версия продукта идеальна и не требует доработки. В этом случае остаётся надеяться на благодарность пользователей разработчикам такого великолепного софта. Более реальная причина — слишком высокие запросы разработчиков. Согласитесь, никто не будет платить 1000$ за изменение фона какой-нибудь кнопки, даже если это повысит юзабилити на 146%. Ставьте реальные цели и запрашивайте адекватные суммы (например, можно рассчитывать размер пожертвования основываясь на количестве необходимого времени и стоимости часа Вашей работы). Кроме того возможен вариант, когда целевая аудитория продукта просто неплатёжеспособна. Тогда надо либо перестраиваться на другую аудиторию, либо начинать заниматься благотворительностью.
Проблема: Всем пользователям не угодишь. Что нравится одним – совершенно не устраивает других.
Решение: В случае standalone приложений можно иметь несколько веток стабильной версии. Так же можно разрешать/запрещать фичи в конфигурации, если это позволяет архитектура приложения. И вообще подобные вопросы лучше разрешать ещё на этапе обсуждения фичи.
Проблема: Слишком большое количество фич и слишком высокая скорость их генерации сообществом.
Решение: Тут не обойтись без модерации, нужно с самого начала грамотоно организовать весь процесс работы с фичами. Разумные правила функционирования сообщества помогут держать процесс под контролем. Так же разработчики должны трезво оценивать свои возможности – не гнаться за всеми фичами (и соответствующими денежными средствами) но и не запускать разработку.
Проблема: Организация разработки и управление кодом (особенно когда параллельно ведётся работа над многими фичами).
Решение: По этой проблеме, к сожалению, мало чего могу сказать, так как не имею много опыта. Пожалуй разделение проекта на слабосвязанные модули может упростить работу, так как большинство фич будут разрабатываться в пределах одного модуля и мерджинг веток разработки не будет большой проблемой.
Хочется верить что данная модель будет работать в реальном мире. По крайней мере в случае с zbedic видно, что необходимые суммы были собраны для некоторых фич. Если вам известны другие примеры – делитесь ссылками.
Быть может кого-то данная статься подтолкнёт к размышлениям или даже вдохновит на создание целой платформы для DDD. Что касается использования в моём проекте, то до реализации руки дойдут ещё не скоро, но я обязательно вернусь к этой идее.
P.S.: Прошу сильно не пинать за оформление и возможные ошибки, так как это моя первая статься на хабре и вообще первая публикуемая где-либо статья. Конструктивная критика приветствуется.
Спасибо за внимание.
Размышляя о способе заработка на своём маленьком проекте, придумал, как мне казалось, оригинальную модель финансирования. Внутренний копираст тут же начал ехидно ухмыляться и потирать ручки, предвкушая миллионы прибыли и всемирную славу изобретателя велосипедов. Он чуть было не задушил мои намерения поделиться идеей с общественностью, но, как известно, ничто в нашем мире не ново — погуглив, обнаружил как минимум три ресурса с описанием или упоминанием данной модели. Далее буду описывать её в том виде, который сформировался лично у меня.
Признаюсь честно: перед публикацией на хабре искал похожие темы очень поверхностно, но, учитывая то, что слежу довольно активно за новыми статьями и вряд ли пропустил бы столь интересную тему, буду считать, что публикация уместна.
Итак, какие же мысли легли в основу:
- Делать качественное и востребованное ПО – это здорово!
- Ещё лучше, когда оно бесплатно для пользователя.
- Но разработчику нужны деньги чтобы выжить.
- Продавать за фиксированную цену готовый продукт – не хорошо (см. пункт 2)
- Надеяться на добровольные пожертвования – сомнительная перспектива.
Решением этих проблем является несколько изменённая модель crowd funding, встречайте…
Feature-donation driven development
Изначально придумал для этой модели название donation driven development, но потом переписал на нынешнее (как она называется здесь), чтобы не возникало путаницы с существующими терминами. Можно ещё хитрее (и более точно): community-donations-shaped development. Если сформулировать кратко, то: сообществом пользователей продукта оплачивается только его ра��витие, а не каждая отдельная копия, при этом развитие происходит в том направлении, которое выбирается сообществом и подкрепляется пожертвованиями.
Далее более развёрнуто.
Основные положения модели:
- Последняя стабильная версия продукта доступна всем, всегда и бесплатно.
- Баги стабильной версии фиксятся в срочном порядке и так же бесплатно.
- Разработка ведётся методом имплементации фич.
- Фичи могут добавляться как командой разработчиков, так и сообществом пользователей.
- Перед началом имплементации фича должна быть оценена* разработчиками.
- Оплата принимается от сообщества пользователей в пользу конкретной, уже оцененной фичи.
- Разработчики обязуются имплементить профинансированные фичи.
*под оценкой понимается определение сложности задачи и необходимых для её выполнения ресурсов (финансирование, время, специалисты)
Фичей может быть практически что угодно, начиная от добавления определённого языка интерфейса и заканчивая рефакторингом кода для улучшения производительности.
Эту модель можно применять как для standalone приложений так и для веб-сервисов, для маленьких или довольно больших проектов (по размеру команды разработчиков или по богатству функционала). Возможно, с некоторыми доработками она применима и к opensource проектам.
Среди плюсов стоит перечислить следующее:
- Разработчики тратят силы на функциональность, действительно необходимую пользователям (так как последние голосуют своими деньгами).
- Пользователи знают точно, на что тратятся их пожертвования.
- Всегда доступна бесплатная стабильная версия продукта.
Естественно имеются и свои минусы:
- Сомнительно, что получится заработать огромные деньги таким образом.
- Есть вероятность вообще ничего не заработать при исключительно жадных пользователях.
- Необходимость тратить силы на поддержание сообщества в здоровом состоянии.
- Отрицательное отношение пожертвовавших пользователей ко всем остальным, получающим продукт на халяву.
Детали жизненного цикла фичи
Все фичи находятся в общем пуле. Добавить фичу в пул может любой желающий, при этом она будет иметь статус подлежащей обсуждению.
Обсуждение
В обсуждении участвует всё сообщество. Каждый может комментировать, голосовать за фичу и вносить свои предложения. Если разработчики сочли запрос адекватным и реализуемым, они начинают оценку и оформление техзадания. В техзадании должен быть представлен список всех необходимых ресурсов и выполнена разбивка фичи на подзадачи (в дальнейшем это упростит оценку готовности работ и позволит обосновать запрашиваемую сумму). Так же разработчики могут разделять фичу на независимые составляющие, если это уместно. В дальнейшем ведётся обсуждение техзадания. Когда техзадание финализировано, фича получает статус ожидающей финансирования.
Финансирование
Теперь любой желающий может пожертвовать некоторую сумму на работу над да��ной фичей. Если пожертвование не анонимное, то пользователь заносится в группу заинтересованных, которым могут быть предоставлены эксклюзивные возможности (например тестирование бета-версии фичи или более высокий приоритет в обсуждениях). Все могут контролировать процесс сбора средств и следить за состоянием выполнения, так как разработка может идти параллельно с финансированием. Собранных пожертвований может не хватать до необходимой суммы, в этом случае имплементация остаётся на совести разработчиков. Если же пожертвований собрано больше чем необходимо, то излишки могут быть потрачены на общее развитие проекта либо на наём стороннего разработчика и ускорение имплементации.
Разработка
Следует отметить, что при разработке необходимо чётко следовать техзаданию, так как оно фактически является контрактом с сообществом пользователей. Так же следует обновлять статус готовности фичи по мере выполнения работ и информировать сообщество в случае возникновения каких-либо неожиданностей. Если разработка становится невозможной, то фича либо отбрасывается на стадию обсуждения, либо закрывается со статусом невозможности имплементации и непотраченные средства возвращаются донаторам для перераспределения по другим фичам. Если же разработка прошла успешно и протестирована внутри команды разработчиков, то можно переходить к публичному тестированию.
Публичное тестирование
Публичное тестирование может быть невозможно в силу сложности или характера фичи, однако, если оно принципиально возможно, то обязательно должно быть проведено на сообществе пользователей. Детали проведения тестирования могут отличаться в зависимости от конкретной фичи, политики разработчиков и всего проекта в целом. В случае обнаружения недоработок фича может быть отброшена на стадию разработки или обсуждения. В случае успешного завершения тестирования фича помещается в стабильную версию и получает статус завершённой.
Интеграция в стабильную версию
После интеграции новые возможности становятся доступны всем пользователям, независимо от их пожертвований. Несмотря на долгий путь фичи до данного состояния и возможность повлиять на ход событий каждого пользователя в сообществе, может получиться так, что будут иметься пользователи недовольные нововведением.
Проблемы и возможные решен��я
Рассмотрение всего спектра проблем и отыскание их решений тянет на целую серию статей, так что я ограничусь наиболее важными на мой взгляд.
Проблема: Пользователи не жертвуют на развитие проекта.
Решение: Тут может быть несколько причин. Самая невероятная — имеющаяся версия продукта идеальна и не требует доработки. В этом случае остаётся надеяться на благодарность пользователей разработчикам такого великолепного софта. Более реальная причина — слишком высокие запросы разработчиков. Согласитесь, никто не будет платить 1000$ за изменение фона какой-нибудь кнопки, даже если это повысит юзабилити на 146%. Ставьте реальные цели и запрашивайте адекватные суммы (например, можно рассчитывать размер пожертвования основываясь на количестве необходимого времени и стоимости часа Вашей работы). Кроме того возможен вариант, когда целевая аудитория продукта просто неплатёжеспособна. Тогда надо либо перестраиваться на другую аудиторию, либо начинать заниматься благотворительностью.
Проблема: Всем пользователям не угодишь. Что нравится одним – совершенно не устраивает других.
Решение: В случае standalone приложений можно иметь несколько веток стабильной версии. Так же можно разрешать/запрещать фичи в конфигурации, если это позволяет архитектура приложения. И вообще подобные вопросы лучше разрешать ещё на этапе обсуждения фичи.
Проблема: Слишком большое количество фич и слишком высокая скорость их генерации сообществом.
Решение: Тут не обойтись без модерации, нужно с самого начала грамотоно организовать весь процесс работы с фичами. Разумные правила функционирования сообщества помогут держать процесс под контролем. Так же разработчики должны трезво оценивать свои возможности – не гнаться за всеми фичами (и соответствующими денежными средствами) но и не запускать разработку.
Проблема: Организация разработки и управление кодом (особенно когда параллельно ведётся работа над многими фичами).
Решение: По этой проблеме, к сожалению, мало чего могу сказать, так как не имею много опыта. Пожалуй разделение проекта на слабосвязанные модули может упростить работу, так как большинство фич будут разрабатываться в пределах одного модуля и мерджинг веток разработки не будет большой проблемой.
Заключение
Хочется верить что данная модель будет работать в реальном мире. По крайней мере в случае с zbedic видно, что необходимые суммы были собраны для некоторых фич. Если вам известны другие примеры – делитесь ссылками.
Быть может кого-то данная статься подтолкнёт к размышлениям или даже вдохновит на создание целой платформы для DDD. Что касается использования в моём проекте, то до реализации руки дойдут ещё не скоро, но я обязательно вернусь к этой идее.
P.S.: Прошу сильно не пинать за оформление и возможные ошибки, так как это моя первая статься на хабре и вообще первая публикуемая где-либо статья. Конструктивная критика приветствуется.
Спасибо за внимание.