Open Source → Локализованная скорость реакции
Я бы хотел продолжить, а вернее, дополнить недавний пост Сергея Голубева . Идея написать дополнение появилась у меня после проведения и обсуждения его итогов.
Дело в том, что не всегда разработчики исправляют ошибки так быстро, как хотелось бы. Особенно, если они описаны не в багзиле проекта, а на каком-либо форуме или в блоге. Хотя в большинстве случаев, конечно же, разработчики оперативно реагируют на все сообщённые недочёты, но есть и исключения. Собственно, чтобы таких исключений было меньше и пишу этот пост.
Небольшое отступление. На самом деле, реагировать на багрепортты, только если они описаны в багзиле — хорошее правило, это приучает пользователей к порядку и исключает возникновение бардака и неразберихи. Так вот…
Несколько раз я лично сталкивался со случаями, когда даже при грамотном описании ошибки в багзиле (вплоть до приложения патча), разработчики не спешили исправлять проблему. Чаще всего, на это были те или иные основания. Один из самых ярких примеров — ошибки с кодировкой. Именно поэтому ситуация, описанная Сергеем, показательна.
Если основные разработчики англоязычные, то им очень трудно понять проблемы людей, которые используют кодировку, отличную от латиницы. Не потому что они «вредные такие», а просто потому что они не сталкиваются с этой проблемой. Конечно, можно попытаться воспроизвести ошибку, но для них это, зачастую, не просто. В то же время, в багзиле и ToDo почти всегда есть намного более интересные задачи, с точки зрения программистов, и решение проблем с кодировками откладывается все дальше и дальше.
При этом требовать чего-либо и обвинять в бездействии разработчиков не справедливо, ведь большинство проектов пишут энтузиасты, «just for fun». Но проблемы-то такие есть и их как-то нужно решать. Вопрос — как?
Ответ можно найти в том же посте. Нужно, чтобы разработчики «говорили на одном языке» со своими пользователями. В прямом и переносном смысле. А лучше всего понимают друг друга люди, которые живут в схожих социально-культурных условиях. Из этого следует, что только при наличии русскоязычных разработчиков в различных международных проектах мы сможем использовать весь потенциал СПО.
Дело в том, что не всегда разработчики исправляют ошибки так быстро, как хотелось бы. Особенно, если они описаны не в багзиле проекта, а на каком-либо форуме или в блоге. Хотя в большинстве случаев, конечно же, разработчики оперативно реагируют на все сообщённые недочёты, но есть и исключения. Собственно, чтобы таких исключений было меньше и пишу этот пост.
Небольшое отступление. На самом деле, реагировать на багрепортты, только если они описаны в багзиле — хорошее правило, это приучает пользователей к порядку и исключает возникновение бардака и неразберихи. Так вот…
Несколько раз я лично сталкивался со случаями, когда даже при грамотном описании ошибки в багзиле (вплоть до приложения патча), разработчики не спешили исправлять проблему. Чаще всего, на это были те или иные основания. Один из самых ярких примеров — ошибки с кодировкой. Именно поэтому ситуация, описанная Сергеем, показательна.
Если основные разработчики англоязычные, то им очень трудно понять проблемы людей, которые используют кодировку, отличную от латиницы. Не потому что они «вредные такие», а просто потому что они не сталкиваются с этой проблемой. Конечно, можно попытаться воспроизвести ошибку, но для них это, зачастую, не просто. В то же время, в багзиле и ToDo почти всегда есть намного более интересные задачи, с точки зрения программистов, и решение проблем с кодировками откладывается все дальше и дальше.
При этом требовать чего-либо и обвинять в бездействии разработчиков не справедливо, ведь большинство проектов пишут энтузиасты, «just for fun». Но проблемы-то такие есть и их как-то нужно решать. Вопрос — как?
Ответ можно найти в том же посте. Нужно, чтобы разработчики «говорили на одном языке» со своими пользователями. В прямом и переносном смысле. А лучше всего понимают друг друга люди, которые живут в схожих социально-культурных условиях. Из этого следует, что только при наличии русскоязычных разработчиков в различных международных проектах мы сможем использовать весь потенциал СПО.
- +7
- fog
- 14 февраля 2011, 11:07
Проблема СПО в модели «just for fun», её проблема в том, что каждый делает не то, что должен, а то что хочет. А ведь иногда нудные и скучные вещи делают продукт более дружественным к пользователю, более стабильным и массовым. Всем известно, что программировать новое намного интереснее, чем оптимизировать и тестировать старое. Вот и получается что за нудные и неинтересные вещи никто не делает. Именно проработанность нудных, но важных вещей являются тем, что отличает СПО от коммерческого софта. Когда человек не получает деньги за труд он вправе делать то хочет, а не то что должен. Но если никто этого не сделает то кто? Кто-то должен пожертвовать свои силы на ради всего проекта, а не ради удовлетворения ЧСВ реализовав «крутую фичу». В СПО это целиком и полностью лежит на личной совести и чувстве ответственности разработчиков. И как показывает жизнь ответственность просыпается у очень не многих людей. И в основном только у тех кто работает в линуксом в корпорациях, таких как редхат, новел и оркл. В открытом сообществе таких людей единицы на миллион.
К сожалению среди многих разработчиков СПО вырабатывается чувство, что если они кодят бесплатно то им все должны. Но это не верно. Суть творческого труда в том, что никто ни кому не должен. Если творение плохое, то и пользоваться им никто не будет, а следовательно и пользы от такого труда ноль. Программа обретает ценность тогда когда её пользуются. Если вы написали суперский код, но им никто не пользуется потому, что непродуманна система управления, то цена такому труду ноль, вне зависимости от мастерства и квалификации.
Мы можем долго ругать микрософт за их говнокод, но он реально приносит пользу людям. А какой толк от классного линукса когда процента пользователей менее 1%. Разработчики создавая линукс думали прежде всего о себе, а не о тех кто их трудом будет пользоваться. Избитая фраза — «не нравится, так напиши лучше» это проявление неуважения к пользователям, за что линукс и поплатился.
Но не подумайте, что я антилинуксойд, много лет я пытался прекратить компилировать и начать жить на линуке. И благодаря убунте я таки это сделал это и уже пол года на ней работаю. И мне не нравится когда приверженцы других дистрибутивов обвиняют убунту во всех смертных грехах СПО. Мне нравится что когда после установки системы она сразу работает. Дополнительная кастомизация полностью на моей совести, но то что из коробки я имею полный и стабильный функционал это я воспринимаю как уважение ко мне.
Качественный и отлаженный код это проявление уважения разработчиков к пользователю. И пользователь заплатит за это своей любовью… и деньгами :) Долго неисправляемые баги пользовательского интерфейса это проявление полного неуважения.
В СПО единственное, что пользователи и разработчики обязаны делать — это уважать друг друга, и ценить друг друга. И больше никто никому ничего не должен. Я сам программист и отчетливо понимают, что я нуждаюсь в пользователях, так же как они нуждаются в нас. Если разработчики не будут ценить пользователей, то и они не будет ценить нас. И не нужно требовать от всех уважения. Даже если из десяти хотя бы один проявит свою любовь это уже окупит наши труды (и в финансовом плане тоже). Нужно просто расширять пользовательскую базу, и больше думать о тех кто вашим трудом пользуется.
З.Ы Простите что коммент вышел больше статьи, но просто накипело.
У проприетарной и свободной модели разработки есть свои плюсы и минусы. Но вот как объединить плюсы обоих моделей и избавится от недостатков, кажется не знает никто. Есть несколько моделей с которыми экспериментируют корпорации. Например редхат практикует классическую модель меритократии, когда решения принимает наиболее достойные из сообщества. Но критериев «достойности» нет и такие решения могут быть не оптимальны. Оракл практикует или пытается практиковать более радикальную схему — «благоразумный диктатор». В этом случае последнее слово всегда остается за корпорацией, но свобода людей не ограничивается. Это достигается добровольным соглашением между руководством и тех кто добровольно соглашается подчиняться.
Но эта модель абсолютно неприемлема среди подавляющего большинства разработчиков. Большинство молоды и в них бурно кипят анархические настроения. Любой намек на ограничение свобод вызывает у них ярость. А добровольное осознание необходимости подчиняться единым правилам приходит только с большим опытом. А таким опытом обладают разработчики, которые вошли в индустрию программирования в 80-90х годах. А тогда это была редкая специальность. И поэтому наделенных не только знаниями, но и жизненной мудрость разработчиков очень мало. В основном это те кому за 30-40 лет. Таким разработчикам более свойственна дисциплинированность и собранность. Так что они будут приносить огромную пользу при любой модели управления.
Очень показательно было, как разработчики относятся к багрепортам. Совместно с одним товарищем обнаружили, что в alsa чудовищным образом была поломана обработка 24-битных потоков (вместо звука были одни хрипы). Честно говоря, там вообще все через одно место сделано, но именно эта часть была вообще нерабочей.
Написали багрепорты непосредственно на багтрекер альсы и в багтрекер убунты, в которой мы, собственно, и обнаружили проблему (ибо наши карточки поддерживают вывод звука только в формате 24 бита). Ноль эмоций.
Ладно… фиг с ними. Собрат по несчастью меня немного опередил и написал патч, который исправлял проблему, плюс сделал кое-какие другие доработки, касающиеся конкретной звуковушки. Все патчи закинули на багтрекер. Опять никакой реакции.
В итоге несколько последующих релизов людям (а таких нашлось немало) приходилось патчить и пересобирать исходники alsa руками, чтобы все нормально работало.
Как я уже писал выше, проблема не только в том, что большинство не могут чётко сформулировать проблему на английском языке — совсем другое дело, когда есть не только запись в багзиле, но и живой человек, которому необходимо решение этой проблемы.