информационная безопасность
без паники и всерьез
 подробно о проекте
Rambler's Top100За кого нас держат?Страшный баг в Windows
BugTraq.Ru
Русский BugTraq
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Модель надежности отказоустойчивой... 
 Google по-тихому включила изоляцию... 
 25 лет FreeBSD 
 Microsoft покупает GitHub 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / закон / статьи
ЗАКОН
главная
обозрение
статьи
форум
рассылка
free soft
предложить материал




The Bat!

Культ добра и программное обеспечение


   Данная статья была опубликована в еженедельнике "Компьютерра", №19 за 2003 год (494)

   Культ добра

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

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

   Точнее, третьего. А особенно, вождю. Аборигены под его мудрым руководством построили точную (в меру своего разумения) копию аэродрома и стали ждать приносящих добро железных птиц, но тщетно. Ритуал возжения огней на ВПП, однако, сохранился и после вождя и был позднее описан антропологами как "культ добра": костры привлекают птиц, птицы несут добро.

   Можно пофантазировать на тему, были ли туземцы мирными или воинственными, и чем бы закончилась попытка получить добро добром от железной птицы, если бы она, сбившись с пути или испытывая технические неполадки, все же села на "аэродром", приняв его за настоящий.

   Мораль пересказанной истории (очень любимой теоретиками и практиками системного проектирования) однако не в этом, а в том, что в ней выражена суть "провинциализма". "Провинциал" вовсе не обязательно туп, ленив и нелюбопытен. Напротив, очень часто он сообразителен, трудолюбив и глаза его широко и искренне открыты в направлении нового. Он даже не обязательно беден.

   Но цивилизация, в провинции которой он очутился, является ему в виде абстрактных, фрагментарных организованностей ("вещей") систем, целостность, конкретная полнота которых ему неведома.

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

   Мне кажется, это дает ключ к теме "провинциализма" бытования ИТ в госорганах, поднятой Павлом Протасовым в его статье. Рубеж "провинции" проходит не по кольцевой дороге и не по государственной границе, а по пониманию того, как устроена ИТ-цивилизация.

   Программное обеспечение

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

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

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

   Качество исполняемого кода - вещь вполне измеримая, если не научными, то эмпирическими методами. Однако качество ПО не сводится к качеству программ в их текущесм состоянии; например, программа с пятью ошибками, не поддающимися исправлению, вполне может оказаться хуже, чем программа с десятью, но которые могут быть исправленны. Переносимая (не зависящая от особенности конкретной ОС или конкретной аппаратной архитектуры) программа, даже с меньшей функциональностью или слабой эргономикой, может быть лучше, чем более функциональная и эргономичная, но тянущая за собой устаревающее окружение с соответствующими издержками. И т.п.

   Свобода ПО дает ключ к измерению качества ПО как такового, не всегда предлагая "здесь и теперь" более качественные (безошибочные, функциональные, эргономичные) программы. Релизы популярных дистрибутивов предлагают единовременный "срез" процесса, который, конечно, к своему моментальному состоянию не сводится. Свобода ПО - это не просто свобода изучения, модификации и применения отдельных программ, но и свобода понимания того, как та или иная база кода реально развивается (кто принимает участие в разработке, с какой степенью вовлеченности, как осуществляется управление процессом, быстро ли исправляются найденные ошибки, во что обходятся функциональные или эргономические новшества и т.п.). Соответственно, и относиться к дистрибутиву нужно соответствующим образом: как к окну в программное обеспечение, а не как к "программному обеспечению".

   К сожалению, Протасов, видимо, в процессе написания статьи так идентифицировался со своим лирическим героем-"чайником", что получить какие-либо конкретные пояснения к его претензиям к свободному софту я так и не смог. Например, узнать, вид и качество кернинга каких именно свободных шрифтов его не устраивает. Или понять, в чем смысл сравнения двух весьма разных классов программ - текстовых редакторов и словарных процессоров, и какое отношение это имеет к модели лицензирования и разработки(Вроде бы, понятно, что текстовый редактор написать проще, поэтому их и больше на порядок, чем словарных процессоров, как свободных, так и несвободных, так и тех и других вместе взятых.). Или, если уж анализ опускается до столь малоаппетитных подробностей, как унаследованные приложения "Клиппер" - почему нельзя пользоваться для их поддержки тем же свободным "Клипом" (http://www.itk.ru/clip/clipchangelog.shtml).

   АРМы и "ПК"

   Поднятый вопрос о соотношении идеологий автоматизированных рабочих мест(АРМ, по-английски workstation, кстати.) и идеологии персональных компьютеров решается, как мне кажется просто. За очень редкими исключениями, если нужно, чтобы на том или ином месте действительно выполнялись работы, его нужно автоматизировать, а не ставить на стол ПК. Цена вопроса - это цена содержания технолога-программиста. Технолог-программист не обязан вести масштабные проекты на "хардкорных" языках и даже владеть всеми тонкостями техники по Кнуту. Он может быть квалифицированным администратором, умеющим сценировать (скриптовать) рутинно выполняемые бизнес-процедуры на языке запросов к БД и языке оболочки ОС. Но он обязан понимать специфику предметной прикладной области (допустим, если автоматизируется работа секретарей и бухгалтеров, он должен понимать, что такое документооборот) и, более того, специфику конкретной организации.

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

   Отчасти так и получалось, пока компьютеры были изолированными "островками" в океане бумажного документооборота и устного общения. После того, как на компьютеры посадили функцию коммуникации, оказалось, что ПК пожираемы вирусами, ведут к неразберихе в архивах, что "софт из коробки" зачастую снижает, а не повышает производительность в сравнении с ручным ? на пишмашинке и калькуляторе, и, что хуже всего, в итоге, оказывается, за ними тоже нужен пригляд. Конечно, нанимаемый или приглашаемый компанией "писишник-эникейщих" обходится дешевле технолога, но работа его, увы, чаще сводится к устранению последствий неприятностей и к объяснению того, какие именно ограничения программ "из коробки" не дают решить определенную задачу в приемлемые сроки с приемлемым качеством (В общем и целом, даже заядлые "писишники" из "Эппл компьютерз" и "Майкрософт" с очевидностью стремятся хотя бы частично вернуть "АРМ-каркас" (прежде всего, управляемость) в свои решения (в форме перетаскивания своих оболочек с самодельных на стандартную ОС у первой или попытки предложить радикальную альтернативу в форме NT-систем у второй.)

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

   Цена свободы

   Существует упорно продвигаемое заблуждение о некоммерческом характере разработки свободных программ. Наблюдениями оно не подтверждается. Ни в коем случае не стоит преуменьшать роль бескорыстных усилий исследователей и разработчиков (и несомненно, то, что результаты таких усилий безболезненно интегрируются в пул свободных программ, является одной из сильных сторон свободного ПО), но и преувеличивать ее не стоит. Существуют исследования, показывающие чуть ли не половину свободного кода, разработанного в инициативном порядке и бескорыстно, однако, из их поля зрения выпадают крупнейшие проекты (такие, как ГНУ, Apache, Xfree86, OpenOffice.org и т.п.), поставляющие бОльшую часть активно применяемого кода. Существуют кейс-исследования, посвященные, например, первым годам разработки "Линукс", но их предмет нетипичен(Системное программирование и системные программисты вообще нетипичны, а к ядрам и авторам их модулей это относится вдвойне.). Программирование и программисты, пишущие "с нуля" нетипичны. Типичен прикладной "софт". Мэйнстрим рынка - это "багфиксы"(Bug fix - исправление ошибки.) и исполнение "фичареквестов"(Feature request - запрос дополнительной функциональности.)

   Волонтеры и активисты, в основном, работают на "фронтире", в то время как "мэйнстрим" обеспечивается гораздо более объемными (и зачастую менее привлекательными) работами, производимыми, как правило, в коммерческих рамках (неважно, оплачивается ли сама разработка или исполнение работ, в которых она выполняет инструментальную роль). Не вполне понятен призыв Протасова бесплатно выполнять какие-то работы, на которые существует достаточно артикулированный рыночный спрос. Та же разработка свободной платформы для документооборота - понятная и в современных условиях (в контексте существования таких проектов, как, например, OpenOffice.org) не слишком затратная задача. Не стоит пытаться подменять субботниками регулярные работы по озеленению города (тем более, что муниципалитет собирает деньги на их выполнение). Но если город озеленяется регулярно, вероятность того, что житель по своей инициативе посадит дерево или куст, повышается. По крайней мере, его, возможно, не затопчут.

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

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

   Стандартизация интерфейсов, форматов, протоколов в госсекторе и для взаимодействия его с частным сектором, или, по крайней мере, организация этого процесса - прямая функция государства, и она на сегодня в России злостно государством не исполняется (даже на таком уровне, на котором в США разабатываются их "ФИПСы"(FIPS - "федеральный стандарт обработки информации".))(А в тех случаях, когда исполняется, результат не оказывает никакого влияния на рутину госзаказа. Например, типовой профиль стандартов для высшей школы разработан, и неплохой, а университеты продолжают оставаться бесплатной (а то и оплачиваемой из госбюджета) рекламной площадкой для продвижения нестандартных решений. Хороший пример приводит и Протасов, ссылаясь на инструкцию, в которой какие-то умники из Росархива рекомендуют нестандартные закрытые форматы - интересно было бы спросить в Росархиве, готов ли этот орган покрывать неизбежные убытки от следования рекомендациям, сочиненным его чиновниками?). Поэтому госпоставки в значительной части представляют собою клубок некомпетентности, "подкруток" ТЗ под конкретных исполнителей, "откатов" и т.п., и с трудом могут быть сегодня названы сегментом рынка.

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

   Если государство начнет выполнять эту, свою собственную, задачу, ресурсы на реализацию найдутся, и часто эта реализация будет свободной (закладывать основу разработок и стимулировать их дальнейшую свободу можно, включая в ТЗ требования демонстрации реализуемости путем предоставления справочной реализации - под свободной лицензией). Не из каких-либо высоких соображений, а исходя из того, что свободная разработка дешевле, а перспективы приворовать на несвободной реализации стандарта весьма туманны. На сегодня нет никаких проблем в свободном программном обеспечении типового документооборота, и даже "конструкторы" для этого появляются(Например, OpenOffice.org.). Рассчитывать, что кто-то из разработчиков будет в это вкладываться в условиях явного "контрпротекционизма" большинства министерств, ведомств и местных органов власти - неразумно.

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




Rambler's Top100
Рейтинг@Mail.ru



назад «     » вперед

  Copyright © 2001-2018 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach