Как НЕ надо создавать софт в эпоху блокчейнов

Долго откладывал этот пост, надеясь дождаться того момента, когда наступит время показать продукт “лицом”. Однако чем дольше длится мое ожидание, тем больше опыта и знаний накапливается у нашей небольшой, но очень храброй команды, и тем сильнее ощущается потребность поделиться и рассказать сообществу не о продукте как таковом, а о том КАК создается наш продукт. Почему именно сейчас?

Окей, рассказываю.

Примерно с весны текущего, 2017, года я довольно плотно подсел на Graphene, и особенно на то, как он используется автономной корпорацией Bitshares. Многие считают Bitshares децентрализованной биржей, но это представление ошибочно, поскольку в первую и главную очередь Bitshares является компанией, бизнесом на блокчейне, а встроенная в движок графена децентрализованная торговая площадка - это лишь одна из функций платформы, которая, в сочетании с такими инструментами, как MPA (привязанные к рынку активы), дает этому бизнесу возможность существовать полностью автономно и не зависеть вообще ни от каких внешних провайдеров услуг, кроме инфраструктурных (сеть, электричество, etc.).

Исследование архитектуры DAC Bitshares в буквальном смысле открыло мне глаза. Даже не знаю, в какой именно момент это произошло, но довольно быстро в моем сознании оформилась отчетливая картина, схема действий, к реализации которой мне посчастливилось принять самое непосредственное участие. Все ссылки я укажу в конце этого поста, а сейчас мне хотелось бы лишь акцентировать внимание на главном - о проблемах, которые я вижу, и о подходах к их решению, представляющихся мне эффективными. И речь не идет о рекомендациях мастодонтам вроде Amazon, Google, Oracle, etc. - я говорю о местных, деревенских проектах - p2p обменники, очередные шлюзы и другие новые (часто довольно здравые) идеи, возникающие в сообществе время от времени. Яркие недавние примеры - ecurrex, бот-информатор, escrow.ruble [надо бы ссылки прицепить].

Что мне не нравится в этих "проектах разработки ПО", так это их абсолютно параноидальная Закрытость и практически полное отсутствие какой бы то ни было организации процесса. Тут и там проскакивают сообщения о том, что кто-то что-то пилит, тестирует в закрытом режиме, а потом - начинается жуткий флейм в чатах несчастного рудекса по поводу того, как эти новые проекты кого-то разочаровали или, напротив, осчастливили. Попытки сделать супер-проект силами двух-трех разработчиков, желательно в свободное от основной работы время и без малейших намеков на достойное финансирование несчастных как правило объясняется элементарной жадностью. В некоторых случаях имеет место ложная скромность авторов идеи. В особых, клинических, случаях - картину дополняет заказчик, желающий запилить для какого-нибудь существующего бизнеса свой блокчейн с перламутровыми пуговицами - но это не сильно отличается от обыкновенного скама, а потому отдельно от него даже не рассматривается.
Ребята. Это блокчейн. Матрица нас _уже_ имеет. И будет продолжать делать это, пока мы не адаптируемся под новые реалии и не поймем главного - старые бизнес-модели тут слабо применимы.

"Не надо так!” (с)

Надо - так:

объявите цели проекта;
откройте процесс проектирования (дорожная карта, архитектура и потребность в ресурсах);
откройте управление конфигурацией продукта (план, задачи, код, документация);

Почему это важно:

прозрачность - вам покажут, кто это делал до вас и чем там все закончилось;
прозрачность - вы поймете, что вам не нужен php и почему;
прозрачность - вам дадут денег на реализацию;

Как это спасет вас от копирования:

никак;
копия всегда останется копией, и вы сможете это доказать (конфигурация продукта и бэклог открыты);
копия не захочет появляться, потому что деньги будут в вашем проекте, а не в чужом;
у копии не будет сообщества и репутации оригинала. Noway;

Как оставить деньги в проекте и дать ему шанс развиваться и процветать:

не берите денег “на проект”, не давая ничего взамен - продавайте инвесторам доли в проекте - токен в Bitshares практически ничего не стОит;
инвестор приходит не только (и не столько) в те проекты, которые будут приносить им процент от прибыли - в подавляющем большинстве случаев инвестор - это заказчик конечного функционала, и он останется с вами до тех пор, пока ваши интересы совпадают. Дополнительная монетизация доли в проекте - это лишь бонус, но не сама цель;
блокчейн помнит все - если вы получили копейку - вы должны показать - как вы ее потратили. Новым инвесторам всегда интересно - что было с проектом до них;

Как показать прогресс разработки (и получить очередь из инвесторов):

привяжите задачи в Github к выплатам, которые получают исполнители;
реализуйте эффективную схему мотивации исполнителей на качественное выполнение задач;
сделайте систему выплат исполнителям прозрачной и гарантирующей справедливую оценку результата;
привлекайте исполнителей не только к формулировке понятной им задачи, но и к оценке трудоемкости и сроков выполнения взятых ими на себя обязательств;
фиксируйте обещания исполнителей в блокчейне и сделайте эту фиксацию частью мотивационной программы исполнителей (квалификационные и репутационные токены);

Если вы решили связаться с блокчейнами и остаться в этой сфере надолго - вам прийдется поменять взгляд на многие привычные вещи. Разработка ПО под сценарии использования в юрисдикции публичных реестров - это новый вид деятельности для многих из нас (разработчиков ПО), и пытаться действовать по старым шаблонам - стрелять себе в ногу. IMHO.

А теперь обещанные ссылки: