фея внутреннего бояна

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

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

…

Это не значит, что вы не имеете права защищать определённое решение. Но вы должны терпеливо выслушать анализ, который вы уже выполнили внутри и который повторяется в списках рассылки для разработчиков. Не пишите: «Да, мы уже всё это проходили у нас, но так не получится по причинам А, Б и В. Когда вы вдумаетесь, то увидите, что единственное решение — это…» Это вредно не столько потому, что звучит высокомерно, сколько потому, что говорит, что вы уже посвятили этой теме неизвестное (но большое, подумают люди) количество аналитических ресурсов за закрытыми дверьми. Это создаёт впечатление, что идёт какая-то работа, принимаются решения, которые неизвестны открытому сообществу; это прекрасный способ вызвать возмущение.

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

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

Русский перевод книги «Producing Open Source Software».