Open Source это ...

Считается, что Open Source — это не сколько открытый код, сколько бесплатный. Это практически верно, потому что, если есть открытый код, то с ним можно сделать что угодно.

Изначально такой проект представляется просто как хобби, с результатами которого хочется поделиться. И пока у разработчика есть интерес к разработке, это будет являться его основным мотивом.

Я разделяю Open Source-проекты на крупные и мелкие. Крупные проекты — это те, которые поддерживаются некой командой более 2-3-человек и у которых много реальных пользователей. Мелкие проекты — это те, которые поддерживаются 1-2 разработчиками и у которых не так много пользователей.

Крупные проекты крупные не потому что они такие хорошие и качественные. Нет. В основе их популярности лежат деньги. Всегда. Когда вы встречаете такой проект, то оказывается, что за ним лежит какой-то бизнес. Есть проекты, которые годами спонсируются бизнесом, например фирма вашего друга будет платить вам зарплату. Для них это мизерные расходы, но зато фирма может гордится тем, что поддерживает движение Open Source.

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

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

Из-за этого забрасывается огромное количество прекрасных проектов.

Можно сколько угодно кидаться лозунгами об Open Source, человеческую природу не изменишь — выполняя свою работу, нужно получать за неё вознаграждение. И лучше материальное. Крупные проекты оказываются под крылом бизнеса, а значит их разработчики намного сытнее и довольнее. Код проекта может быть полным говном, но пиар и маркетинг сделают своё дело.

Из всего сказанного вытекает один простой вывод: если вы решили сделать открытый проект, то подумайте об этом 100 раз, потому что с вероятностью 99% вы не получите с него денег, если не подумаете об этом заранее.

•••

Как зарабатывать на Open Source-проекте?

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

То есть нужно сразу представить, что у вас уже есть идеальный продукт и вы его продаёте. Будут ли его покупать в принципе?

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

Поэтому для продажи проекта (будем считать его продуктом) нужно, чтобы проект имел какие-то «фишки», которые будут либо уникальными, либо лучше работающими, чем у конкурентов.

Если этого всего нет, то можно даже не мечтать, что с такого проекта получится что-то заработать.

Но если проект стоящий, то желательно сразу подумать как именно на нём зарабатывать.

Наверное самый распространённый вариант — это сопутствующие услуги. Вы предлагаете свой проект бесплатно, но часть услуг оказываете за деньги. Именно такой вариант я выбрал для своей MaxSite CMS. Система полностью открыта и бесплатна, но создание шаблонов и плагинов для неё будет уже за деньги.

Такой вариант хорош ещё и тем, что втянуться в этот бизнес может любой желающий. В больших проектах очень высокая конкуренция среди вебмастеров, а для менее популярных проектов можно стать чуть ли не единственным высококлассным специалистом. Я знаю несколько разработчиков MaxSite CMS, которые буквально «окучили» рынок крупных городов (например Харьков). Но здесь нужно продавать не систему, а готовый сайт (клиенту как правило вообще похер на чём он работает).

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

Следующий вариант заработка — это донат или спонсорство. Я его пробовал много раз, но по факту — это совсем мизер. В принципе это понятно — зачем платить за то, что доступно бесплатно?

Другой формой доната можно считать что-то вроде «оплатите разработку», где можно финансово поучаствовать в развитии проекта. По факту результат близок к нулю.

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

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

Сейчас такой вариант наверное уже сложнее реализовать, но я бы его не скидывал со счётов.

В какой-то мере зарабатывать можно и на бартере. Когда-то за небольшой баннер Coopertino предоставлял мне бесплатный хостинг. Были несколько хостингов, которые проплачивали небольшую рекламу, а также были те, кто предлагал участие в партнёрке. Это совсем одиночные деньги, поэтому я бы на них не ориентировался.

•••

Язык программирования оказывает существенное влияние на возможность продавать свой продукт. Но здесь мы уже говорим не об Open Source, а скорее об Close Source — закрытом исходном коде.

В лучшем положении — это написание программ на больших языках на заказ. Если это не коммерческая фирма, то можно не беспокоиться о защите программы, поскольку заказчик сам заинтересован, чтобы она не «утекла», либо она настолько специфичная, что другим не нужна и даром.

Если же речь о заказчике-фирме, то нужно сразу защитить свою программу от распространения. У меня было много подобных программ и я их защищал с помощью reg-ключа, но так, что была привязка в аппаратному обеспечению компьютера. Вначале клиент запускал маленькую программу, которая собирала нужные данные и отправляла этот ключ мне. Я уже генерировал лицензию. При смене компа, ключ переставал работать навсегда и нужна была новая лицензия. Также было ограничение времени лицензии. Жёстко, но это позволило мне много лет получать деньги за свой труд.

Что касается открытых языков, то всё намного сложнее. В PHP код закрыть невозможно, поэтому волей-неволей, а разработчик вынужден продавать именно Open Source.

За всё время у меня была только одна такая разработка — это MaxCache для WordPress. Этот проект я сразу делал для продажи, потому что знал что есть много бесплатных альтернатив. Поэтому свой кэш сделал так, чтобы он оставлял далеко позади конкурентов (проверено суровыми скептиками).

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

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

Спасло то, что это была первая версия кэша, но у меня была в разработке новая с новыми «фишками». Но урок — не доверяй! — усвоил.

Поэтому очень важно понимать как именно вы будете защищать свой код.

Достаточно долго я шифровал код через Zend, потому что дешифратор был почти на каждом хостинге. Мне казалось, что это достаточно хорошая защита, но однажды мне написал покупатель, который показал как можно взломать код. Прислал мне все файлы и показал как нашёл инструкцию. Тогда я понял, что нужно делать своё шифрование.

Главная сложность в том, что любой php-код можно расшифровать. Я, ради интереса, проверял защиту других разработчиков (многим потом писал), но почти всё сводится к циклам и eval(). Для раскодировки даже не нужны особые знания, достаточно посмотреть в коде и заменить на echo(). То есть PHP элементарно не предназначен для шифрования исходного кода.

Многие разработчики используют для шифровки код, который уже есть в Сети. С 99% вероятности это значит, что есть и обратный код расшифровки. Есть даже сайты, где можно шифровать/дешифровать код с разными алгоритмами. И будет большой ошибкой думать, что злоумышленник не сможет их найти.

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

Но «хакеры» скорее всего не будут делать это бесплатно, поэтому всё упрётся в финансы: возможно стоимость лицензии ниже, чем стоимость взлома. Именно так я и поступил с MaxCache — его стоимость была невысокая, взламывать код просто не имеет смысла.

И хотя «социальная инженерия» достаточно эффективна, нужно подойти к этому вопросу технически. Неважно как именно, но нужно всегда держать в голове тот факт, что можно получить исходный PHP-код. Поэтому код нужно обфусцировать.

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

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

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

function OOООOОOО($OOОOОО,$OОOООО,$OООOОOO) {
    $OООООООOO=$OОOООО.$OООOОOO;
    return str_replace($OOОOОО,$OОOООО,$OООOОOO);
}

Понять назначение этой функции будет крайне сложно, а значит для взлома нужно написать свой деобфускатор. То есть технически это всё реализуется, но требуется время и высокая квалификация.

Таким образом обфускатор позволяет достаточно серьёзно защитить код, но часто стоит задача его не взламывать, а только поправить некоторые части — «обнулить».

Например вы привязываете код к какому-то домену. Выдаёте клиенту шифрованный ключ, который проверяется в ядре системы. Скорее всего вы сделаете проверку лицензии на простом if-условии, а значит для взлома достаточно просто поменять либо $_SERVER['HTTP_HOST'], либо знак условия.

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

Чтобы обойти такие вещи, используют API и удаленный сервер лицензий. То есть сайт клиента делает запрос на удалённый сервер, где хранятся все лицензии, и тот в ответ выдаёт ключ.

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

Ошибка разработчика в том, что он думает, что достаточно только зашифровав код. Но, поскольку всегда есть вероятность его расшифровки, то всегда есть вероятность и его «обнуления».

Поэтому нужно шифровать не код, а данные. Код делится на две части. Первая часть — можно открыто, можно обфусцировать, но именно её и получают все клиенты. Вторая часть — это по настоящему шифрованный код (через openssl как положено) уникальный для каждого клиента. Лицензия состоит из двух «хитрых» файлов, которые используются в дешифраторе.

Получается, что даже имея доступ исходному коду, дешифровать вторую часть будет невозможно. Чем сложнее алгоритм формирования ключей, тем сложнее будет понять откуда система получает настоящий ключ. Взлом такой системы невозможен путём замены $_SERVER['HTTP_HOST'] или ворованного ключа с другого домена. Каждая новая версия обновления будет иметь свой ключ, а значит обновленную лицензию. То есть даже если будет взлом, то старая лицензия не будет работать с новым кодом.

Здесь важно понимать, что речь идёт не о создании «идеальной защиты», а только о том, чтобы максимально усложнить её вскрытие. Обычному честному клиенту, где и так всё работает, защита по барабану. Но для разработчика защита нужна не только от свободного распространения, но и от взломов клиента.

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

Это я к тому, что при продаже продукта важно обеспечить его защиту на каждом уровне.

•••

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

Слава Украине! Смерть рашистам!