Почувствуй исходник | автор: Luca | 14 июня 2009
Категория: Open Source
Похоже большая часть фоссовцев считает, что распространение исходного кода величайшее благо. Ну, я тут, чтобы рассказать, что это не только персики со сливками. OSS конвенция (примечание - разновидность международного договора) - это в первую очередь распространение исходного кода пакетов у которого много минусов о которых никто не хочет говорить.
1) OSS модель вынуждает даунстримные проекты принимать решения, которые должны быть сделаны апстримными разработчиками.
2) Распространение исходного кода ослабляет апстримные усилия по тестированию.
3) Одновременный эффект: распространение исходного кода приводит к дублированию усилий даунстримом.
Похоже большая часть фоссовцев считает, что распространение исходного кода величайшее благо. Ну, я тут, чтобы рассказать, что это не только персики со сливками. OSS конвенция (примечание - разновидность международного договора) - это в первую очередь распространение исходного кода пакетов у которого много минусов о которых никто не хочет говорить.
Во-первых, OSS модель вынуждает даунстримные проекты принимать решения, которые должны быть сделаны апстримными разработчиками. Какие это решения? Например, какой компилятор должен быть использован? Какие флаги компиляции следует использовать? Какие версии должны быть у библиотек? Когда программа компилируется для распространения существует много таких вторичных решений, которые должны быть приняты. Смысла от таких решений больше, если они принимаются теми, кто пишет код, то есть апстримными разработчиками. Но в инновационном linux мире, большая часть решений принимается даунстримом, на уровне дистрибутива, людьми не слишком понимающими код, но знающими, как сделать rpm. Даже, если они немного знакомы с кодом, несомненно то, что подлинные авторы кода знают больше. Тем не менее, важнейшие решения, способные повлиять на производительность и стабильность конечного продукта, принимают сопровождающие пакетов. Это не свобода выбора. Это свобода потр.. с этим.
Во-вторых. Распространение исходного кода ослабляет апстримные усилия по тестированию. Любой тестер программного обеспечения до проведения тестирования и обеспечения качества узнает, что к разным бинарникам эффективно применять разные тестовые сценарии. Каждый раз, когда даунстримный проект патчит программый код или компилирует его по-другому, то по существу создается форк кода. Это тотчас же подрывает все тестирование проведенное апстримным проектом. Даже фоссклоуны могут увидеть к каким проблемам это приводит. В самых очевидных случаях, это закончится чем-то подобным фиаско Debian с OpenSSL. В более трудноуловимых случаях, пользовели, сообщающие о проблемах, потому что дистрибутив использует флаг компиляции, который апстримные разработчики не тестировали или потому что использовалась другая версия библиотеки, которая была у разработчика, когда он делал svn коммит. Они говорили, что FOSS будет лучше, потому что будет глобальное распределенное тестирование общедоступного кода. В действительности все тестируют слегка отличающиеся двоичные трансляции общедоступного кода, поэтому вся эффективность распыляется на эти многочисленные вариации.
Одновременный эффект: распространение исходного кода приводит к дублированию усилий даунстримом. Мы уже видели как каждый дистр идет своим путем, несомненно, решая все теже проблемы, что и другие дистры. Какой компилятор должен быть использован? Какие версии должны быть у библиотек? Какие версии лучше работают вместе? Сотни дистров без общего тестирования и интеграции фактически дублируют усилия по многу раз. Многое не возможно использовать повторно, потому что отличаются конфигурации. Огромная растрата. Угадайте почему рост числа числа linux пользователей и тестеров не пропорционален росту качеста дистров? Каждый новый дистр только увеличивает растрату, работая также как все остальные. Хей, они все работают бесплатно, верно?
Кроме того, с точки зрения разработчика не все в розовом цвете. Но как так может быть? Разработчики любят исходный код, не так ли? Рад, что ты спросил.
Общее у OSS библиотек то, что на них нет хорошей документации. Все в порядке, говорит разработчик, просто читайте исходный код. Для того кто не пишет код это может звучать хорошо. Кому нужна документация, когда по коду видно что он делает, верно?
К сожалению, неверно.
Отложим проблему чтения исходного кода и выясним что же в полной мере делает отстоем. Необходимо документирование API, исходный код слишком конкретен. Если разработчик может видеть реализацию какого-либо конкретного интерфейса, то он может очень легко невольно начать зависеть от особенностей реализации (часто даже не предусмотренных реализотором). Исходный код "чрезмерно определяет" API. Хуже, если разработчики начинают зависеть от ошибок.*
Конечно же, правильнее документировать библиотеки, интерфейсы и скрывать реализацию. Сделайте предположения четче, йада, йада. Существует куча инженеров, понимающих это. Проблема заключается в том, что для OSS, наличие исходного кода служит оправданием не создавать документацию. "Взгляните на код", говорят они, как будто это одно и тоже. Вот как потребители и реализаторы библиотеки попадают в беду.
Более земная проблема. Как разработчики окупят свои затраты на разработку, раскрывая все свои "секретные ингредиенты"? Эту проблему обсуждали до смерти на других форумах, но ее тем не менее стоит упомянуть и здесь. Да, я устал от всех ваших сообщений о том, что Google сколотил капитал на open source. Но знаете что? Они не продают программное обеспечение. Если ваша цель состоит чисто в производстве программных продуктов для конечных потребителей, то какая будет бизнес модель? Уверен, что кто-то собирается упомянуть Redhat, а вы хотите, чтобы еще раз пробежался по доходам Redhat vs MS vs Adobe? В конце концов, несмотря на коммерческие open source успехи, немногие из них, если таковые вообще имеются, связаны с непосредственной продажей программного обеспечения компанией. (Они не рассчитывают быть купленными Sun). Определенно не могу сдержать дыхание.
Последний пункт. Распространение open source проектов по большей части в исходных кодах фактически откладывает решение описанных выше проблем. Если бы все OSS проекты действительно бы пытались распространять бинарники, то поняли бы насколько хер..ва ситуация (и возможно даже попытались бы исправить это). Если OSS разработчики смогут показать, что действительно могут координировать распространение программ в двоичной форме, то и коммерческие компании обучатся и присоединятся, принося пользу всем.
Заметьте, что я не говорю, что распространению исходного кода нет места. Это полезно для исправления ошибок и координирования улучшений в апстрим коде. Но слишком многие фричудилы отделываются от двоичного распространения, не признавая присущих ему преимуществ. Это от невежественности.
* Обратите внимание на то, что отсутствие исходного кода не предотвращает этого полностью. Существует много известных примеров Win32 программ, зависящих от ошибок исполняющей среды. Отношение к подобными ошибкам строже и исправить их значительно проще, если исходный код открыт.
Источник
Прочитано 9425 раз и оставлено 696 комментариев.
Похоже большая часть фоссовцев считает, что распространение исходного кода величайшее благо. Ну, я тут, чтобы рассказать, что это не только персики со сливками. OSS конвенция (примечание - разновидность международного договора) - это в первую очередь распространение исходного кода пакетов у которого много минусов о которых никто не хочет говорить.
1) OSS модель вынуждает даунстримные проекты принимать решения, которые должны быть сделаны апстримными разработчиками.
2) Распространение исходного кода ослабляет апстримные усилия по тестированию.
3) Одновременный эффект: распространение исходного кода приводит к дублированию усилий даунстримом.
Похоже большая часть фоссовцев считает, что распространение исходного кода величайшее благо. Ну, я тут, чтобы рассказать, что это не только персики со сливками. OSS конвенция (примечание - разновидность международного договора) - это в первую очередь распространение исходного кода пакетов у которого много минусов о которых никто не хочет говорить.
Во-первых, OSS модель вынуждает даунстримные проекты принимать решения, которые должны быть сделаны апстримными разработчиками. Какие это решения? Например, какой компилятор должен быть использован? Какие флаги компиляции следует использовать? Какие версии должны быть у библиотек? Когда программа компилируется для распространения существует много таких вторичных решений, которые должны быть приняты. Смысла от таких решений больше, если они принимаются теми, кто пишет код, то есть апстримными разработчиками. Но в инновационном linux мире, большая часть решений принимается даунстримом, на уровне дистрибутива, людьми не слишком понимающими код, но знающими, как сделать rpm. Даже, если они немного знакомы с кодом, несомненно то, что подлинные авторы кода знают больше. Тем не менее, важнейшие решения, способные повлиять на производительность и стабильность конечного продукта, принимают сопровождающие пакетов. Это не свобода выбора. Это свобода потр.. с этим.
Во-вторых. Распространение исходного кода ослабляет апстримные усилия по тестированию. Любой тестер программного обеспечения до проведения тестирования и обеспечения качества узнает, что к разным бинарникам эффективно применять разные тестовые сценарии. Каждый раз, когда даунстримный проект патчит программый код или компилирует его по-другому, то по существу создается форк кода. Это тотчас же подрывает все тестирование проведенное апстримным проектом. Даже фоссклоуны могут увидеть к каким проблемам это приводит. В самых очевидных случаях, это закончится чем-то подобным фиаско Debian с OpenSSL. В более трудноуловимых случаях, пользовели, сообщающие о проблемах, потому что дистрибутив использует флаг компиляции, который апстримные разработчики не тестировали или потому что использовалась другая версия библиотеки, которая была у разработчика, когда он делал svn коммит. Они говорили, что FOSS будет лучше, потому что будет глобальное распределенное тестирование общедоступного кода. В действительности все тестируют слегка отличающиеся двоичные трансляции общедоступного кода, поэтому вся эффективность распыляется на эти многочисленные вариации.
Одновременный эффект: распространение исходного кода приводит к дублированию усилий даунстримом. Мы уже видели как каждый дистр идет своим путем, несомненно, решая все теже проблемы, что и другие дистры. Какой компилятор должен быть использован? Какие версии должны быть у библиотек? Какие версии лучше работают вместе? Сотни дистров без общего тестирования и интеграции фактически дублируют усилия по многу раз. Многое не возможно использовать повторно, потому что отличаются конфигурации. Огромная растрата. Угадайте почему рост числа числа linux пользователей и тестеров не пропорционален росту качеста дистров? Каждый новый дистр только увеличивает растрату, работая также как все остальные. Хей, они все работают бесплатно, верно?
Кроме того, с точки зрения разработчика не все в розовом цвете. Но как так может быть? Разработчики любят исходный код, не так ли? Рад, что ты спросил.
Общее у OSS библиотек то, что на них нет хорошей документации. Все в порядке, говорит разработчик, просто читайте исходный код. Для того кто не пишет код это может звучать хорошо. Кому нужна документация, когда по коду видно что он делает, верно?
К сожалению, неверно.
Отложим проблему чтения исходного кода и выясним что же в полной мере делает отстоем. Необходимо документирование API, исходный код слишком конкретен. Если разработчик может видеть реализацию какого-либо конкретного интерфейса, то он может очень легко невольно начать зависеть от особенностей реализации (часто даже не предусмотренных реализотором). Исходный код "чрезмерно определяет" API. Хуже, если разработчики начинают зависеть от ошибок.*
Конечно же, правильнее документировать библиотеки, интерфейсы и скрывать реализацию. Сделайте предположения четче, йада, йада. Существует куча инженеров, понимающих это. Проблема заключается в том, что для OSS, наличие исходного кода служит оправданием не создавать документацию. "Взгляните на код", говорят они, как будто это одно и тоже. Вот как потребители и реализаторы библиотеки попадают в беду.
Более земная проблема. Как разработчики окупят свои затраты на разработку, раскрывая все свои "секретные ингредиенты"? Эту проблему обсуждали до смерти на других форумах, но ее тем не менее стоит упомянуть и здесь. Да, я устал от всех ваших сообщений о том, что Google сколотил капитал на open source. Но знаете что? Они не продают программное обеспечение. Если ваша цель состоит чисто в производстве программных продуктов для конечных потребителей, то какая будет бизнес модель? Уверен, что кто-то собирается упомянуть Redhat, а вы хотите, чтобы еще раз пробежался по доходам Redhat vs MS vs Adobe? В конце концов, несмотря на коммерческие open source успехи, немногие из них, если таковые вообще имеются, связаны с непосредственной продажей программного обеспечения компанией. (Они не рассчитывают быть купленными Sun). Определенно не могу сдержать дыхание.
Последний пункт. Распространение open source проектов по большей части в исходных кодах фактически откладывает решение описанных выше проблем. Если бы все OSS проекты действительно бы пытались распространять бинарники, то поняли бы насколько хер..ва ситуация (и возможно даже попытались бы исправить это). Если OSS разработчики смогут показать, что действительно могут координировать распространение программ в двоичной форме, то и коммерческие компании обучатся и присоединятся, принося пользу всем.
Заметьте, что я не говорю, что распространению исходного кода нет места. Это полезно для исправления ошибок и координирования улучшений в апстрим коде. Но слишком многие фричудилы отделываются от двоичного распространения, не признавая присущих ему преимуществ. Это от невежественности.
* Обратите внимание на то, что отсутствие исходного кода не предотвращает этого полностью. Существует много известных примеров Win32 программ, зависящих от ошибок исполняющей среды. Отношение к подобными ошибкам строже и исправить их значительно проще, если исходный код открыт.
Источник
ВНИМАНИЕ !
Возможно что-то уже неактуально. Обращайте внимание на даты !
Эта статья опубликована 14 июня 2009-го года !
Прочитано 9425 раз и оставлено 696 комментариев.
. Гы-гы, мигом бы вернулись на родную винду.
Аналогичные трансформации окон в Vista/семерке сделаны на порядок аккуратнее и четче.
Одинаково связаны документы в OO и MSO?
#1.