Интересная статья-комментарий опубликована в
http://www.humans.ru/humans/90498/h_print_view_t:
У нас на форуме периодически поднимается тема о коммерческой поддержке Форта с одной стороны и открытых библиотеках для него - с другой.
В приведенной ниже части статьи как раз обсуждается вся сложность работы с опенсорсом, и его развитие. Вкратце - нет
реальной отдачи. Гордость за бесплатный продукт со временем сменяет удовлетворение от сделанного, а затем усталостью уже от всего того потока информации, с которым приходится иметь дело (саппорт/багтрекинг/фичи/...). Ты просто привыкаешь. Нет смены состояния "эйфория/программинг", того вечного двигателя, который зовется программерским творчеством, состоянием "в потоке" (термин Джоэла Спольски)
. И изредка начинает проявляться то самое Желание. Желание Забить.
Имхо,
в первую очередь именно
коммерческая поддержка Форту необходима, как воздух. Без неё не будет развития.
Цитата:
Опасность перегрузки и "сгорания"
Разработка добровольцами программ с открытыми исходниками является рискованным мероприятием и по другим причинам. Для создания серьезной программы недостаточно посидеть за компьютером пару часиков в субботу и воскресенье. Это скорее длительная работа на (возможно еще одну) полную ставку. Если кто-то в дополнение к своему "хобби" по разработке программ с открытыми исходниками должен еще и зарабатывать себе на жизнь и/или учиться в вузе, то возникает опасность перегрузки. Кстати, значительная часть отличного кода в открытых исходниках была написана теми, кто в дополнение к этой разработке еще и работал/работает на полную ставку в университете или какой-нибудь фирме.
Как это ни парадоксально звучит, но при наличии основной работы успех по созданию программы в открытых исходниках может обернуться реальной угрозой благополучию разработчика-добровольца. Если ваша программа успешна, и пользователи полны энтузиазма, вы можете превратиться в бесплатный отдел техпомощи по телефону, затрачивая на звонки пользователей, разбор писем и ответы по электронной почте все больше и больше времени. Как профессиональный преподаватель программирования, я вижу определенную опасность в романтизации разработки методом открытых исходников, особенно в среде студентов. "Сгорание" определяется как синдром психической и эмоциональной опустошенности, влекущий развитие негативной самооценки, отрицательного отношения к работе, а также потерю внимательности и чуткости к пользователям. Давайте проанализируем соответствующую часть хроники Linux за 1998 год:
"Март
Анонсирован Линус 3.0. Рождение второй дочери Линуса было большой радостью и привело к значительным перерывам в разработке ядра, поскольку вся работа встала, и многие присланные заплаты были потеряны. Ропот возник, поскольку стало ясно, насколько сильно весь процесс разработки зависит от постоянного присутствия Линуса.
Октябрь
Напряженность в списке рассылки linux-kernel сменилась взрывом негодования после того, как Линус потерял слишком много присланных исправлений. Линус тоже вышел из себя и взял отпуск на некоторое время. Постепенно все пришло в норму, но разговоры не прекратились. Еще раз стало очевидным, что ядро Linux становится слишком большим, для того чтобы один человек мог быть на высоком уровне во всех вопросах. Обсуждались некоторые пути снижения загрузки Линуса, но ничего реального предпринято не было."
Сгорание представляет собой основную проблему тех, кто по роду занятий должен помогать другим. Оно возникает, когда люди, помогая другим, отдают настолько много сил и времени, что совершенно перестают заботиться о себе. Сгоранию подвержены не только программисты, но и профессиональные педагоги, журналисты, медики, социальные работники, а также служащие правоохранительных структур. Оно начинается, когда разработчик затрудняется в выборе приоритетов и, несмотря на давление пользователей и непрерывный поток требования по исправлению ошибок и совершенствованию программы, начинает отдавать себе отчет, что, в конце концов, его добровольное участие в этой разработке должно иметь более низкий приоритет, чем основная работа и интересы семьи. Приведем некоторые из факторов, которые способствуют возникновению этого состояния:
Продолжительное состояние стресса вследствие чрезмерности взятой на себя нагрузки (работа в режиме 12*7 или "стольник в неделю" как такой режим называют программисты --- прим. автора);
Конфликт между красивой мечтой и реальностью;
Слишком интенсивный поток сообщений по электронной почте;
Неумение планировать и распределять свое время (к примеру, круглосуточные отладочные авралы);
Вовлечение в крысиные гонки с коммерческими разработками;
Ролевые конфликты, в когда человек раздирается на части конфликтующими требованиями основной работы, семьи и его добровольных обязанностей (по разработке/поддержанию продукта с открытыми исходниками);
Архитектурные проблемы, обнаруженные слишком поздно в процессе разработки, в сочетании с выбором неоптимальных инструментов и методов программирования (например, если продукт, который можно и нужно написать на Perl или Python, пишется на чистом С --- прим. автора);
Чрезмерное стремление к совершенству (перфекционизм), т.е. трудности с адаптацией к росту объема обратной связи от пользователей и неспособность отвергать просьбы по расширению возможностей программы и исправлению имеющихся ошибок;
Нереалистичные сроки наряду с неспособностью выдерживать график работы в других проектах (при одновременной работе сразу над несколькими проектами --- прим. автора);
Недостаточный уровень поддержки со стороны других разработчиков проекта с открытыми исходниками или их полное отсутствие (разработка в одиночку --- прим. автора).
В публикациях результатов исследований, посвященных изучению феномена "сгорания", сообщались различные негативные последствия для здоровья жертв: от возникновения апатии до сердечных приступов. Пока неясно, сколько лидеров проектов с открытыми исходниками хоть раз страдали от депрессии, вызываемой сгоранием. Большинство программистов находит, в конце концов, способы приспособиться к работе в условиях стресса. Но адекватно адаптироваться к этой стрессовой нагрузке могут все же не все. Зачастую те, кто сгорает, были самыми многообещающими разработчиками в начале своей карьеры. Они перфекционисты, идеалисты и трудоголики. Она включаются в работу по разработке программного обеспечения методом открытых исходников с большим энтузиазмом, с высоким уровнем преданности идеям открытых исходников и нацелены на выполнение работы на самом лучшем уровне, на какой только они способны. Они энергичны, полны энтузиазма и обладают высоким уровнем притязаний. И как результат, они зачастую пытаются откусить больше, чем могут прожевать.
Руководство крупным проектом может существенно увеличить опасность сгорания ведущего разработчика. Он обычно "принимает на грудь" весь объем управленческой работы, который валится на него, и тратит на это больше времени, чем другие разработчики. С ростом пользовательской базы и числа разработчиков, даже количество писем по электронной почте может превысить способности по переработке информации любого нормального человека. Для успешных проектов это значит, что необходимость отвечать на письма пользователей конфликтует с процессом программирования и отладки, а все они вместе мешают семейной жизни и основной работе. Проблема техностресса вследствие перегрузки информацией (сочетание "стартового возбуждения", вызываемого постоянно приходящими новостями, перегрузки информацией и ролевых конфликтов) в коллективах разработчиков методом открытых исходников, а также сгорание лидеров даже не упоминается в СиБ. Крэйг Брод (Craig Brod) определяет техностресс так:
"... современная болезнь приспособления, вызванная невозможностью справляться с новыми компьютерными технологиями в здравой манере. Он проявляется двумя различными, но связанными путями: непрерывной борьбой по освоению новых компьютерных технологий, а также в более специфичной форме излишней идентификации с той или иной компьютерной технологией."
Я хотел бы снова отметить, что лидеры успешных проектов с открытыми исходниками получают так много писем по электронной почте, что даже простое их чтение представляет собой заметную нагрузку. В интервью 1995 года Линус Торвальдс заметил:
"Вопрос: Что представляет собой Ваш нормальный день (т.е. на что обычно тратится Ваше время: учеба, Linux, свободное время)?
Ответ: Linux забирает мое "рабочее время" --- даже простое чтение электронной почты требует как минимум два часа в день, а ответы на эти письма и собственно разработка заполняют весь остаток дня. Тем не менее, мне удается вырвать время на другие свои увлечения, поскольку я могу, по сути, заниматься Linux на своей работе в университете (там знают, что я занимаюсь разработкой Linux, и разрешают мне это делать)."
Здесь существует и другой аспект, который любая жизнеспособная модель разработки программ с открытыми исходниками должна уметь предсказывать. Это "смерть на служебной лестнице" как крайний случай гонки за статусом. Подобно спорту, где каждый хочет быть чемпионом, по крайней мере, на начальной стадии проекта с открытыми исходниками его лидер должен доказывать, что он превосходит своих конкурентов. Проблема в том, что иногда это превращается в непосильные крысиные гонки против более сильного или коммерческого продукта: с каждой новой версией альтернативных продуктов от разработчика свободной программы ожидают, по меньшей мере, быстрого достижения паритета с конкурентами, и никого не волнует, чего это ему будет стоит. Лояльные пользователи требуют и ожидают реализации новых возможностей, появившихся в конкурирующих продуктах, не понимая, что разработка "их" продукта ведется на добровольных началах, и поэтому может иметь иные приоритеты и другую скорость разработки. К примеру, в прошлом многие пользователи выражали неудовлетворение медленными темпами выпуска новых версий дистрибутива Debian по сравнению версиями Red Hat.
Как уже указывалось, благодаря своей центральной позиции, ведущий разработчик вынужден "принимать на грудь" большинство управленческих функций, и работа по обработке большей части замечаний и предложений пользователей ложится на него. Это значит, что в отсутствие иерархических ограничений на поток информации (как в ее получении, так и в ее распространении) по сравнению со своими заместителями лидер проекта с открытыми исходниками поставлен в худшие условия в связи с перегрузкой избыточной информацией. В конце концов, выполняя управленческие функции, он может деквалифицироваться настолько, что это вызовет недовольство остальных разработчиков.
Подведем некоторые итоги. Начать проект с открытыми исходниками легко и интересно, но закончить его непросто, и успех может оказаться весьма дорогим удовольствием. Длительная напряженная разработка крупного продукта с открытыми исходниками представляет собой реальную угрозу для разработчиков-добровольцев и может постепенно превратить изначально интересный проект в изматывающее сопровождение сложной программы. Очевидно, что разработчик программы с открытыми исходниками будет чувствовать себя несколько более комфортно, если он относится к разработке как научной деятельности и воспринимает себя как научного исследователя какой-то проблемы. Это значит, что после создания базовых элементов программы и доводки ее до некоторого уровня зрелости, он имеет моральное право остановить разработку в любой подходящий момент или передать ее кому-то, или, наконец, решить самому превратиться в коммерческого разработчика и посмотреть, примет ли коммерческий мир его детище. Конечно, существуют явные идеологические проблемы и трудности связанные с больным самолюбием, возникающие в процессе принятия такого решения (в особенности с передачей продукта другим разработчикам --- прим. автора). В таких случаях разделение продукта на коммерческую и некоммерческую ветви (подобно TCL и Sendmail), или же создание коммерческой компании, получающей выгоду от усилий добровольцев, могут быть рациональными решениями, и их стоит рассматривать всерьез. Для любого сложного и успешного проекта с открытыми исходниками чисто добровольческая стадия может, вероятно, быть лишь переходной.