Путевка в жизнь для Open Source-проекта

Содержание:
1. Введение (Вы читаете данный раздел);
2. Распространение;
3. Перевод.

---

В разработке свободного ПО программист обычно выступает и в роли бескорыстной службы поддержки. Ему необходимо отвечать на каждое письмо - ведь адресат хочет пользоваться вашей программой и ему нужна помощь, иначе он бы не писал. На прием писем удобно назначить адрес на Gmail, фильтры которого хорошо справляются со спамом. Заводить ли отдельный адрес или пользоваться существующим, рабочим, - дело вкуса. Будьте готовы к шутникам, коими так славится Русь. Некогда я нарочно для своего редактора TEA создал адрес tea@list.ru. И что же? Некий человек, вероятно, считая себя большим затейником, придумал на сайте знакомств для геев объявление и оставил этот e-mail. Мне начали приходить полные надежды послания - мол, давай знакомиться. Но я скучно отвечал, что этот адрес предназначен для общения с пользователями редактора TEA, и давал ссылку. Может, таким образом у TEA прибавилось этих самых пользователей, кто ведает?..

Вообще удобно общаться с пользователями по e-mail через добротный почтовый клиент вроде Claws или KMail, а не веб-интерфейс. Так получается оффлайн-база с письмами, а заодно и архив патчей. Пользователям лучше отвечать сразу: и человеку приятно, и на вас не «висит». Хорошо бы выучить английский - половина писем будет приходить к вам именно на этом языке. Кроме того, стоит помнить, что даже подробная документация не лишит вас удовольствия отвечать на простейшие вопросы, возникающие у пользователей, которые не пожелали эту документацию прочесть.

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



Трудно недооценить сообщения об ошибках. Чем их приходит больше, тем лучше для программы. Однако радикальный звездопад ошибок свидетельствует о том, что нужно более ответственно писать код. В групповой разработке обычно создают базу ошибок - bug-tracker (по-русски получается что-то вроде «жуколов»), куда вносится описание ошибки и назначается человек, который желает её исправить - «закрыть». Порочная практика - когда к bug-trackery доступ дан только зарегистрированным пользователям. Человек может быть не зарегистрирован, и прилагать лишние усилия ему не захочется. Для внутренних нужд проекта такой bug-tracker, может, и удобен, но пользователям от него толку мало. Не буду давать отрицательные примеры - их достаточно.

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