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

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

В качестве иллюстрации Крис Грамм приводит пример с выдуманным проектом под названием SwizzleStax.

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

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

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

Но что будет дальше?

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

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

Разумеется, этот «зоопарк имён» идёт только во вред проекту. А опосредованно и всем связанным с ним модулям, хотя их авторы ожидали совершенно иного эффекта.

Почему так произошло? Крис Грамм называет две основных причины.

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

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

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

Посмотрим на автомобильную промышленность. Большинство производителей уже перешли от применения уникальных имён (Pontiac Fiero, Grand Am, Firebird и т. д.) к поддержке одного бренда (BMW 3, 5, 7). Это позволяет им не только экономить деньги, но и сократить время, необходимое для вывода продукта на рынок, фокусируя энергию основного бренда на каждой модели.

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

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

Если вернуться к нашему примеру, то модуль следовало бы назвать либо Swizzlestax WidgetMaker, либо просто WidgetMaker, если и так очевидно, к какому именно проекту относится этот модуль.

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

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

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

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

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

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