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

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

Эксперт Крис Грамм, который десять лет занимался вопросами брендирования в компании Red Hat, считает, что это большая ошибка. К названию проекта следует относиться примерно так же, как к имени ребёнка.

Поскольку не делать ошибок значительно проще, чем потом их исправлять, он решил поделиться своим опытом. Вот какие советы Грамм даёт на страницах сайта OpenSource.com

Найдите бренд, которым вы сможете владеть

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

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

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

Поиск в базе данных товарных знаков

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

Как минимум, целесообразно провести проверку по базам товарных знаков США (и, конечно, России — C. Г.). Причём необходимо обращать внимание не только на точные совпадения, но и на похожие варианты написания, которые можно перепутать с выбранным брендом.

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

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

Расширенный поиск по Сети

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

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

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

Поддержка сообщества важнее юридической правоты. На это правило всегда следует ориентироваться. И не только при выборе названия.

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

Проверка доменного имени

Любому проекту нужен собственный сайт. Причём крайне желательно, чтобы имя сайта ассоциировалось с названием проекта.

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

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

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

Выбор сценария архитектуры бренда

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

· одно имя для проекта, продукта и компании;

· одно имя для продукта и компании, другое для проекта;

· одно имя для проекта и продукта, другое для компании.

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

Пример первого сценария: компания NGINX, продукт NGINX Plus, проект NGINX.

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

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

Но у подобного сценария есть и минусы. Если на основе свободного решения планируется сделать некий платный продукт, то одинаковые названия могут привести к путанице. Будет очень непросто объяснить пользователю, почему ему предлагается заплатить за то же самое, что распространяется бесплатно, причём под тем же именем.

К тому же подобный подход усложняет изменение стратегии компании, если это изменение потребуется в будущем. Грамм вспоминает трудности, с которыми столкнулась компания Red Hat, разделяя бренд Red Hat Linux на продукт Red Hat Enterprise Linux и проект Fedora.

Пример второго сценария: компания Datastax, продукт Datastax Enterprise, проект Cassandra.

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

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

Пример третьего сценария: компания Canonical, продукт Ubuntu Advantage, проект Ubuntu.

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

Третий сценарий отдаляет саму компанию от создаваемых ею проектов и продуктов. Это позволяет в перспективе неограниченно расширять направления деятельности. К тому же в крайнем случае компания сможет разорвать отношения с проектом с минимальным для себя репутационным ущербом.

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

Отделение проекта и продукта от компании опасно тем, что название компании не становится известным. Много ли пользователей популярной системы Ubuntu знает о том, что её разрабатывает компания Canonical? Ответ на этот вопрос, вероятнее всего, будет отрицательным.

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