Концепция "свободного" программного обеспечения
Чашка кофе стоит гораздо дороже, чем стакан воды.
Именно так обстоят дела, хотя жить без воды мы не можем, а жить без кофе можем вполне.
Добавлю к этому, что создание инфраструктуры для очистки и транспортировки чистой воды стоит миллиарды долларов.
Основная же причина разницы в стоимости – предельные издержки.
Доставить один стакан воды по городу (если система доставки уже создана) практически ничего не стоит.
А для одной чашки кофе, как Вы понимаете, требуется больше зёрен, больше обжарки, больше электричества, больше картонных стаканчиков, больше овса, больше коров, больше персонала… сложите это всё, добавьте ещё дюжину факторов и Вы поймёте почему за кофе заламывают такую цену.
Вот почему первое, что нужно понять в концепции "свободного" программного обеспечения, это что предельная стоимость одного электронного письма, одной загрузки, одного бита и тому подобных услуг и продуктов близка к нулю.
Если бы это был единственный фактор прибыли, большая часть программного обеспечения в принципе была бы не очень хорошим бизнесом. Формула простая: разработка обходится дорого, но цена постоянно снижается по причине воздействия рыночных сил.
Следующий важный аспект – это создание замкнутого пользовательского цикла. В отличие от кофе, программное обеспечение вознаграждает своих потребителей. Со временем используемое вами программное обеспечение становится более привычным, оно открывает файлы, которые вы создали вчера, и перейти на что-то новое становится всё труднее и труднее. Согласитесь, примерно по такому же признаку действуют вещества, вызывающие зависимость.
Но настоящим чудом современного программного обеспечения является именно сетевой эффект. Проще говоря: программы работают лучше для каждого пользователя, когда их используют и другие люди. Сетевой эффект существенно вознаграждает старт. Вы ведь хотите общаться с Вашими друзьями в одной социальной сети, не так ли?
Иногда программное обеспечение создаётся глобальной командой, что часто называют открытым исходным кодом. Такие сообщества существуют для обслуживания пользователя и решения его проблем. В других случаях разработка ПО происходит по бизнес-схеме, максимально похожей на традиционную.
Проект с открытым исходным кодом, создаваемый сообществом, может добиться процветания при бесплатной бизнес-модели. Точно так же ПО бывает полезным если создаёт достаточную ценность, за которую люди готовы платить.
Сложим вместе факторы, которые я перечислил, и мы получим две крайности, с которыми сталкивается большинство компаний-разработчиков:
- Бесплатное ПО рассматривается как лучший способ начать работу. Низкая предельная стоимость новых пользователей означает, что Вы быстро можете добиться успеха. Свежим примером может быть 1,000,000 новых пользователей для Threads за одну неделю. Проблема здесь в том, что некоторые компании предпочитают относиться к новым пользователям не как к клиентам, а как к продукту. Потребители не могут уйти позже по причине замкнутого пользовательского цикла, сетевой эффект поддерживает рост системы и компания может вводить новые способы монетизации. В частности, почему бы не обслуживать кого-то ещё кроме "бесплатных" пользователей. По мере роста, Вы делаете проект немного хуже и облегчаете жизнь прежде всего спонсорам. (Важное исключение: этот случай не касается массовой добровольной оплаты. Но, если Ваши потребители и так платят Вам большие деньги, представьте, какого качества должен быть продукт и массовая поддержка).
- Дорогое (или скажем проще "не бесплатное") программное обеспечение редко даёт волшебные масштабы мирового масштаба. Для этого необходима особая гармония со своими пользователями. Вместо того чтобы запирать людей в замкнутом цикле, Вы можете сосредоточиться на вознаграждении из за то, что они остаются с Вами. Кстати, именно так работают все бизнесы в мире (кроме временных искусственных монополистов, разумеется).
Итак, есть несколько путей для процветания Вашей компании, но все они должны быть первично основаны на продуктивном взаимодействии с пользователем.
Сложно сказать какой вариант лучше, но лучше не смешивать обе эти схемы.