Меня зовут Алексей, я скорее инженер, чем разработчик. Занимался производствами, конструировал приборы и в какой-то момент решил попробовать сделать универсальный конструктор для учёта всего, что мне было нужно на производстве — материалов, заказов, процессов, планирования сроков и т.п.

Предполагалось, что мы вместе с разработчиком запилим такую платформу за полгода, будем продавать лицензии и станем миллионерами. Но так к��к задача оказалась сложной, а через полгода разработки стало понятно, что потребуется чуть больше времени, чем ожидалось, было решено выложить её в open source.

Решение было принято под влиянием моды того времени на открытые системы: стартапы получали по 10 млн баксов под таблички без функционала, но зато с MIT-лицензиями, проводились конференции, изо всех утюгов неслось, как здорово на сопровождении все зарабатывают миллионы...

В общем, начитавшись всей этой чуши, поставили MIT, залили на GitHub, написали статью на Хабр — и... получили поток комментариев: «Ваш код — УГ» и «Всё надо переделать на Laravel».

В итоге, потратив охулиард нервных клеток и набрав 900 звездочек на GitHub, я бросил это опенсорсное занятие и поставил самые обыкновенные платные лицензии.

Очень высокий уровень требований от тех, кто никогда не будет использовать ваше ПО*

* и никогда сам не выложит ни строчки своего кода в паблик

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

Да, действительно: если вы не Яндекс, который шарит свой внутренний проект, снабжённый полноценной командой и бюджетами, — то ранние версии будут, мягко говоря, кривоваты.

Выкладываться при этом все равно нужно как можно раньше. То есть тут прямое противоречие: чтобы выжить, надо положить болт на все 100500 методичек, по которым живут корпоратив��ые разработчики, и кратчайшим путём делать функционал — потом выкладывать его или пытаться продавать, и только после этого улучшать.

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

Здесь поясню: когда ты внутри корпоративной системы, всегда кажется, что всего не хватает. На самом же деле ресурсов — дофига, просто тратятся они на другое. Весьма распространена ситуация, когда программист, освободившись от корпоративных оков, запускает свой маленький пет-проект и радостно начинает генерить в нём микросервисы, лямбды, статистику, аналитику, кубернетесы, оптимизирует функции до предела — а потом погибает от того, что это никому не нужно, хотя железо уже жрёт по 500 баксов в месяц просто ради чтения комментариев в Telegram.

Если вы запускаетесь, когда ваш код сияет, — ваш проект уже одной ногой в могиле.

Если бы я запускался сейчас, то я бы всё замуровал в бинарник — и всё.

Звёздочки на GitHub ничего не стоят

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

Действительно, иногда есть бесплатные части проектов, ориентированных на корпоративного потребителя, где сейлзы за много денег продают продвинутые версии ЛПРам. Но это если продукт ориентирован на корпоративного потребителя, �� что если нет... Тогда вы можете иметь хоть 40К звёзд — они вам не помогут ни на рубль продать что-то пользователям, которые целенаправленно искали бесплатный продукт, а платящие на звёздочки смотрят по диагонали.

Более того, если вы бесплатной версией цепляете корпоративного потребителя, который может заплатить, он не побежит к вам с просьбами выставить счёт или сделать под него платную версию. Он придёт просить выделить ему бесплатную — даже если у вас уже есть платная. Даже если лицензия стоит 1000 рублей в месяц всего, провести её через корпоративные согласования равносильно 10 миллионам. Одно дело — менеджер увидел бесплатную возможность (то есть без согласований бюджета) реализовал её: если всё выгорело, он молодец. Но если есть хоть рубль стоимости, его надо обосновывать — и ��друг что-то пошло не так, а он сам подписался как цель, на которую будут переведены стрелки в случае фейла. Профит теряется, возникает трение, которое должны ликвидировать сейлзы, пилоты и вся эта обкладка из бумажек и ритуалов. И звёздочки на GitHub их не заменяют.

Если вы раздаёте код бесплатно, то и разрабатываете бесплатно

Заработать на доработках — экстра сложно. Вы же уже выложили 300 тысяч строк кода бесплатно, — почему дописать ещё тысячу должно стоить 100 000 рублей?

И приходят, конечно, не с простыми пожеланиями (зачем они нужны). Бесплатный пользователь приходит с пожеланиями, себестоимость которых — не меньше миллиона рублей, при этом считая, что это стоит максимум 10 000 и будет сделано завтра. Ну а иначе зачем тратить время и писать вам эти пожелания?

Если это корпоративный бесплатный пользователь, то его пожелание будет минимум на 10 млн рублей себестоимости — со всем корпоративным фаршем: согласованиями, документооборотом и так далее. Корпоративный пользователь по-другому просто не может — он в принципе не способен упростить взаимодействие.

Сколько он готов за это заплатить? Для него интересно предложение, которое раз в 10 дешевле, чем поручить такой объём работы кому-то внутри. Даже если у вас экстра-класс по эффективности разработки, взаимодействие с таким заказчиком всё равно будет происходить с эффективностью его стороны — то есть с очень низкой. Эту часть никак не оптимизировать.

И понятно, что как-то компенсировать разработку основного кода — вообще без шансов: если он стоит ноль, то он стоит ноль.

Магия заключается в установке цены за лицензию — как только я поставил цену за лицензию, я тут же перестал тратить дни на бесполезные переговоры о диком функционале. Магическим образом те, кто платит за лицензию, не генерят адские, трудновыполнимые пожелания за стоимость пачки сухариков.

Если сам код бесплатен, то ценностью обладает пользователь

Бесплатная версия: «А почемy вы не сделали блокиратор в случае XYZ? У нас тут 5 человек вашей системой пользуется, и нам приходится контролировать — нажимаем мы на „Сохранить“ снизу или „Закрыть“ сверху (пользуемся бесплатной версией). Считаем, что вы это должны исправить в кратчайшие сроки. Сообщите мне о результатах».

Платная версия: «Столкнулись с такой проблемой: в случае XYZ полосу прокрутки иногда не видно чётко — приходится подвигать её, чтобы понять положение. Мы, конечно, и так справляемся, но, возможно, это можно улучшить. Спасибо».

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

Это прямо однозначно так считывается: ваш код бесплатен — значит, вы нуждаетесь в пользователях. Пользователь не платит — значит, он и есть ценность. Какая? Существенно бо́льшая, чем ваш код, который вы раздаёте. Как минимум — на бесплатную поддержку! Как максимум — на кастомные доработки.

Поэтому когда пишут, что для open-source проектов можно заработать на поддержке — это чушь. Да, у нас иногда покупали поддержку, но не с целью получения поддержки, а чтобы получить разработку по цене поддержки — и потом генерировали какие-то дикие ситуации, когда мы через инструкции в Telegram дистанционно что-то «разрабатывали» в проекте у пользователя. Это было похоже на проведение операции на сердце через ноздрю.

В этом месте все приводят в пример Red Hat, но там, вообще-то, продаются корпоративные версии с обязательной поддержкой — то есть она на самом деле включена в лицензию. Именно так в итоге поступили и мы.

Также очень помогло замедление обмена сообщениями.

Ответ по email на следующий рабочий день вместо ответа в Telegram в течение часа в десять раз повышает качество запроса!

Когда использовался Telegram, в семи из десяти случаев запрос на поддержку приходил в виде «у нас там огонёк...». Что у них за огонёк? При взаимодействии через Telegram предполагается, что вы сами будете это выяснять — это ваша задача. Email с ответом на следующий день при этом действует как вытрезв��тель.

Лицензии и email оказались очень действенными инструментами для разгрузки времени от потока сообщений от людей, которые никогда вам не заплатят — даже если уверяют обратное.

Привлечение аудитории на бесплатный проект очень платно

Сейчас такой поток информации, что ваш бесплатный проект просто останется незамеченным в этом потоке. Одно дело — вы Google и со всеми своими ресурсами «шерите банану» (нормальная pro версия между прочим платная), другое — вы, небольшая команда, и пытаетесь в рамках своих возможностей привлечь внимание к бесплатному проекту. И очень быстро обнаруживаете, что:

• бесплатных площадок, на которых можно опубликоваться, не так много;

• эффект от них не очень большой;

• приходится давать самую обычную рекламу;

• реклама — капец дорогая, и конкурируете вы в ней с теми, кто может себе позволить платить за рекламу; если вы изначально бесплатны, ваши ресурсы быстро заканчиваются;

• как только вы вставите хоть какую-то монетизацию — например, сделаете очень сильную открытую версию и первоначальную продвинутую платную — вас начнут гнать с большинства каналов: с Reddit, с Хабра (я тут получал страйк) — и неважно, что вашу платную версию пока никто не покупает. Разбираться с этим никто не будет — смотрят наискосок.

И наконец, самое важное: бесплатная аудитория потом очень плохо конвертируется в платную. Реальный пользователь платит сразу. Если он не платит сразу — он не заплатит никогда.

Ели у вас нет 10 миллионов баксов кэшем — стоит рассчитывать так. Если они у вас есть, то вам тоже стоит так рассчитывать, наши конкурентные проекты имели по 10 мультов, но они у них быстро закончились.

Да у вас просто проект плохой — хорошие проекты на донатах миллионы собирают

Сначала проект действительно был плохой. Со временем, благодаря работе над функционалом и качеством, аудитория начала расти. Мейнтейнер в таком случае сначала радуется — а потом вынужден работать на износ, потому что рост аудитории влечёт за собой рост баг-репортов, объёма техподдержки и запросов на бессмысленный функционал и неизбежное выгорание.

Вместе с этим ростом иногда приходили донаты. Самый большой разовый донат был 300 000 рублей, суммарно набралось под миллион. При этом были люди, которые отправляли донат на 5 тысяч рублей, а потом требовали, чтобы мы выделили им 5 часов на техподдержку — «потому что они себе так видят этот вопрос». Приходилось возвращать такие донаты и ставить товарищей в бан.

• Окупают ли донаты разработку? Однозначно — нет.

• Лицензии продавать эффективнее? Однозначно — да.

• Дичи с продажей лицензий больше или меньше, чем с донатами? Однозначно — меньше.

Заключение

Open source — это когда капитальные затраты отбивать не требуется или когда понятно, что продажа нецелесообразна. Тогда OSS может привлечь что-то интересное и непредсказуемое со стороны.

В моём случае правда, ко мне регулярно прилетают различные мутные предложения «партнёрства» непонятного толка, в которых обычно предлагают разработать что-то объёмом в пару тысяч часов бесплатно. Возможно, другим везёт лучше.

Или, например, навайбкодить можно и выложить в OSS — зачем, я не очень понимаю. Продукт это не только код, но и документация, примеры, которых у таких проектов нет.

Библиотеки востребованы, но лишь немногие из них продолжают поддерживаться — рано или поздно энтузиазм мейнтейнеров иссякает и лишь изредка образуются сообщества, которыми тоже нужно постоянно заниматься.

То есть если вы — не корпорация-монстр, а небольшой проект, — делайте сразу лицензии. Хотите, чтобы пользователь мог попробовать бесплатно — сделайте это. Установите, например, лимит на пару пользователей, такой, при котором бизнес, способный заплатить, не сможет удобно использовать ваш продукт в реальных условиях.

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

Тотум — универсальный конструктор для создания кастомных ERP, MES, PIM и AI-приложений под задачи бизнеса без участия разработчиков.

Готовый интерфейс, логика, программируемая текстовыми инструкциями, многопользовательский режим и любые интеграции — исходящие и входящие API, SSH, подключение к БД — позволяют вам самостоятельно и максимально быстро запустить нужный функционал.

Ссылка: https://ru.totum.online
Описание на Хабр: https://habr.com/ru/companies/totum_online/articles/967298/