Мой номер

Реклама


Rambler's Top100
Главная arrow Статьи arrow Создание ПО arrow Open source убьёт мир
Open source убьёт мир
Написал gdever   
16.11.2008
Открытое программное обеспечение в последние несколько лет захватило умы очень многих людей и создало вокруг себя шумиху совершенно несоизмеримую своей значимости. Почему не стоит впадать в транс услышав мантру "open source", написано далее.

Фанатики (именно фанатики) открытых исходников постулируют следующие идеи:

1. Любой может залезть в исходники и исправить ошибку.
2. Открытые программы более надежны в силу пункта 1.
3. Любой может доработать программу и поработать таким образом на все open source сообщество.
4. В программах с открытыми исходниками не может быть «закладок» и «черных ходов».

Разберемся последовательно со всеми пунктами.

1. Любой может залезть в исходники и исправить ошибку.
Да. Теоретически это так. Проблема в том что в реальности это практически никогда не происходит. Дело в том что всех пользователей можно разделить на 2 группы — те, которые о программировании слыхом ничего не слыхивали, и те, которые о программировании имеют то или иное представление. Пользователи из первой группы по очевидным причинам в исходники никогда не полезут. Пользователей же из второй группы можно разделить ещё на две части — люди профессионально занимающиеся программированием и восторженные новички, прочитавшие что-нибудь из серии «... для чайников». Первые в чужие исходники в трезвом уме никогда не полезут так как очень хорошо знают что такое чужие сорцы. Так же они очень хорошо осведомлены, что даже в своем коде через несколько месяцев разобраться очень проблематично, не то что в чужом. Поэтому в кишки программе лезут именно восторженные новички и с упоением, с полным ощущением собственной непогрешимости улучшают код. Точнее это они думают что улучшают код. На самом деле они лепят горбатого, понятно как влияющего на программу.

2. Открытые программы более надежны в силу пункта 1.
Бородато-пузатые дядьки-программисты ратующие за свободные исходники не знают, или не хотят знать, или скрывают, что знают о существовании дисциплины под названием «Управление IT-проектами». Эта дисциплина вводит такую характеристику качества программного кода как количество ошибок на 1000 строчек кода. Данная характеристика вводится почти во всех учебниках по IT-менеджменту. Но ни в одном таком учебнике не делается разделение на величину этой характеристики для программ с открытыми исходниками и с закрытыми. Да ребята, примите этот факт. Количество ошибок одинаково.

3. Любой может доработать программу и поработать таким образом на все open source сообщество.
Есть такая хорошая фраза - «Кто как хочет так и дрОчит». Именно потому что «кто как хочет» рождаются абсолютно нелогичные и уродливые интерфейсы, которые абсолютно не согласованы друг с другом. Например в рамках одной программы для обозначения одного и того же действия могут использоваться разные термины. Отдельно стоит упомянуть локализацию и ошибки локализации. Помню в восьмой Убунте во время установки выбрал язык системы — русский. Открываю Файрфокс — английский. «Так я и думал. Именно так я и предполагал.» © Именно из-за этих проблем создатели всех более-менее успешных программных проектов с открытыми исходниками рано или поздно сбиваются во всякие Foundation'ы и Group'пы. И по своей организации очень сильно начинают напоминать любую другую компанию по созданию софта. Хотя это и не афишируется особо.

4. В программах с открытыми исходниками не может быть «закладок».
Брехня. Может. Помню получил как-то заказ на доработку одного движка интернет-магазина. Редкостное говно кстати. Так вот, на официальном сайте этого говно-движка прям на главной странице пишется, что за такой-то месяц в наших магазинах куплено товаров на X рублей. Моя задача состояла в том чтобы убрать код, который отправляет автору этого скрипта информацию о совершаемых покупках. Прелесть правда? Кто там подумал про privacy?

Как видно из приведенных доводов open source это в большинстве случаев мистификация, фикция, пустой звук, пиар в конце концов. Эта утопия создана программистами для программистов. Проблема в том что создание ПО это не только программирование. Это ещё и анализ требований, это проектирование, это тестирование, это написание документации, это техническая поддержка после релиза. Все это очень важные вехи в развитии программного продукта. Для одного только тестирования я могу назвать более семи различных этапов. Open source касается только программирования, а что делать с другими этапами создания софта идеология open source ответа не дает. И не сможет никогда дать.
Сформировать ссылку на статью для вашего сайта | Просмотров: 5222

0

Коментарии (4)
RSS комментарии
 1 ку то есть re:
Написал(а) bioboy, в 02-07-2010 04:47
Истина в абсолюте!! :grin
 2 Свободное ПО
Написал(а) Вадим Жмудь website, в 23-12-2010 13:53
На сайте: http://www.gnu.org/philosophy/free-sw.ru.html 
прочитал определение СПО в виде «четыре основных свобод»:  
• Свобода выполнять программу в любых целях (свобода 0).  
• Свобода изучать работу программы и модифицировать программу под свои нужды (свобода 1). Это предполагает доступ к исходному тексту.  
• Свобода передавать копии, чтобы помочь своему ближнему (свобода 2).  
• Свобода передавать копии своих измененных версий другим (свобода 3). Этим вы можете дать всему сообществу возможность получать выгоду от ваших изменений. Это предполагает доступ к исходному тексту.  
ВОПРОС: «Свобода вносить изменения» не означает ли в том числе и свободу закрывать доступ к части исходных кодов?  
В перечисленных четырех свободах я усматриваю свободу анархического разрастания версий различных программ.  
Действительно, я внесу изменение, пусть даже весьма грамотное, которое облегчает жизнь мне персонально, но я свободен от того, чтобы гарантировать, что это измененное СПО не ухудшит исполнение других функций, которые мне заведомо не нужны. Если это измененное СПО кто-то начнет использовать, может сработать эффект «отравленной конфеты». Пользователь полагает, что это СПО гарантирует выполнение каких-то функций, которые предшествующая версия гарантировала. Но эта измененная версия может уже и не гарантировать, я же ее «свободно» испакостил под свои персональные задачи.  
К примеру, мне не нравятся батальные сцены в книге Льва Толстого «Война и мир», и я их изыму. Получится другая книга, которая мне лично будет больше нравиться. Какой-нибудь любитель батальных сцен наоборот подправит батальные сцены и добавит к ним детальное описание оружия, и соображения тактики и стратегии. Кто-то захочет исправить диалоги главных героев, кто-то исправит описание природы, кто-то густо добавит описания природы из Пришвина и Паустовского… Получится триста тридцать три версии «Войны и мира», а может быть кто-то и название исправит. Разве не бред? Потом вы захотите получить эту книгу и прочесть – вам надо будет найти первоисточник среди множества версий. Но первоисточник может и не сохраниться, ведь каждый читатель будет у себя хранить ту версию, которая ему милей всего. У кого-то Болконский женится на Элен Безуховой, а Наташа Ростова с Денисом Давыдовым удерет в партизаны, у кого-то – Пьер и Андрей создадут однополую семью…  
Скажите, что одно дело – литература, а другое – программы? А вот и нет.  
Простой пример: Программа OrCAD для разводки печатных плат. Каждый дополняет библиотеку элементов своим «творчеством». Эти дополнения, естественно, не совпадают, хотя могут быть одни и те же имена элементов или напротив с разными именами одни и те же элементы. Если я потом с чужой библиотекой элементов открою свои файлы, они откроются с ошибками, каких-то элементов в схеме не будет, или они будут заменены другими элементами, разводка будет невозможна, то есть вся работа будет насмарку. Чтобы этого избежать, мы ВЫНУЖДЕНЫ ВВОДИТЬ СТАНДАРТИЗАЦИЮ на библиотеку, то есть в рамках структуры, подчиненной мне, ТРЕБОВАТЬ единообразия, ЗАПРЕТИТЬ кому попало вносить новые элементы, и поручить это дело единственному специалисту на предприятии. Тем самым мы достигаем унификации изменений хотя бы в рамках предприятия. Но передавая файл другой организации, мы сталкиваемся с той же проблемой. То есть нам надо договариваться о стандартизации и унификации уже в рамках нескольких предприятий, действующих в одной сфере с одним и тем же программным продуктом. А ведь речь идет не о самом ПО, а о библиотеке элементов, которая по определению свободна к пополнению и редактированию любым пользователем.  
Подумайте над этим. Если у кого-то есть ответ, буду рад его прочесть.
 3 Написал(а) gdever, в 23-12-2010 14:25
2Вадим Жмудь 
 
Вы всё логично расписали. Ирония в том что мифология СПО не способна дать более-менее внятный ответ на Ваш вопрос, ибо все постулаты СПО не тянут даже на тезисы какой-либо методологии разработки ПО. И, по сути, являются не более чем лозунгами, которые смачно и со звоном разбиваются о суровую IT реальность. 
 
Ну а что касается права закрыть свои доработки, то вот интересная статья на эту тему http://gdzone.ru/content/view/276/41/
 4 СПО
Написал(а) Вадим Жмудь website, в 24-12-2010 09:59
Спасибо за ответ. 
В итоге могу кратко резюмировать мое ИМХО на эту тему:  
 
 
1. Я СТОЮ за то СПО, за которое мне не грозит СЕСТЬ. 
 
2. Свобода пользователей ПО измеряется длиной цепи его разработчиков, и наоборот. 
 
3. Не кажется ли вам, что термины \"свободное\" и \"открытое\" по отношению к программному обеспечению (и не только!) являются ВЗАИМНОИСКЛЮЧАЮЩИМИ? 
 
 
(с) http://proza.ru/2010/12/24/449

Только зарегистрированные пользователи могут оставлять коментарии.
Пожалуйста зарегистрируйтесь или войдите в ваш аккаунт.

Последнее обновление ( 03.10.2010 )
 
< Пред.   След. >
Design by ah-68 - Copyright © 2007 by www.gdzone.ru