К вопросу об обзоре Елашкина

[vitus_wagner]

Некто Елашкин (artimind) опубликовал на www.elashkin.com обзор Open Source Software как бизнес-модели.

ramendik покритиковал его в своём журнале. В связи с чем завязалась довольно горячая дискуссия с участием таких признанных лидеров российского OSS community как aen_.


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

Елашкин утверждает, что "законы о собственности не менялись со времен царя Хаммурапи". Это, к сожалению, совсем не так. Хороший обзор истории англосаксонских законов об автороском праве, которые сейчас навязываются всему миру через всякие ВТО и Бернские конвенции, есть в книге Лессинга Free Culture. Там ясно текстом написано, что современно понятие копирайта сложилось во второй половине XX века. Ни статут королевы Анны, ни американское законодательство 1790 года не резервировали за автором такого количества прав, которые резервирует современное законодательство - и американское, и российское. К сожалению, аналогичной обзорной работы по эволюции российских законов со времен Пушкина (первого российского автора, который ухитрялся жить на гонорары) до наших дней я не знаю.

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

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

Если уж копаться во внутренней противоречивости воззрений Столлмана, то тогда уж надо цепляться к GNU FDL, которая признана несоответствующей
DFSG из-за понятия "неизменяемых секций".

Ну уж о том, что автор регулярно путает проект GNU, весь корпус GPL-еd программ (я, например, никаких прав на catdoc FSF не передавал) и OSS в целом, можно и не говорить.

Далее, Елашкин делит потенциальный ресурс разработчиков OSS на категории, выделяя категорию "сисадминов", т.е. людей должностные обязанности которых в принципе не заключаются в разработке софта, а заключаются в том, чтобы "всё работало". И утверждает, что по мере увеличения участия этих людей в разработке, они будут сталкиваться со всё большим сопротивлением руководства, которое-де крайне не заинтересовано, в том чтобы сотрудники тратили рабочее время на работу не в интересах фирмы.

При этом не учитывается тот момент, что вообще-то эта самая категория разработчиков действует преимущественно в интересах своих фирм. Они дописывают в используемые их фирмами программные продукты фунциональность, востребованную в бизнес-процессах этих фирм. Т.е. начальство в большинстве случаев прекрасно понимает за что оно платит деньги лично мне, когда я исправляю ошибки в Tcl/Tk или openssl. Эти продукты будут использованы в наших собственных разработках, и будут приносить нашей фирме доход. То что эти исправления появятся в CVS на sf.net или openssl.org - это нам же и добавляет удобства - скачав следующую версию данного продукта, нам не придется возиться с приложением наших исправлений в виде патчей. Выгода от включения наших патчей в общий процесс разработки, проявляющаяся в упрощении нашей жизни, гораздо больше чем гипотетический вред от того, что какие-то гипотетические конкуренты смогут воспользоваться результатами нашей работы.

То есть начальник задает мне вопросы не вида "А какого хрена ты на это время тратишь?", а "А почему ты до сих пор не убедил core team включить этот патч в очередной релиз?".

Это - столь любимые Епишкиным факты. Могу URL-ки на баги в соответствующих BTS предъявить.

Но самое интересное в этом обзоре - это то, для кого он вообще предназначен.

На рынке IT есть две категории игроков - производители коммерческого ПО и его потребители, и отношения к ним близки к антагонистическим.
То что выгодно Adobe, Microsoft и Oracle, скорее не выгодно простому пользователю, и наоборот.

Тем не менее из трех выводов, которые делает Елашкин:


1. Качество ПО не зависит от типа лицензии
2. ТСО FOSS продуктов не меньше, чем для коммерческого ПО
3. Бизнес модель FOSS плохо масштабируется


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

Впрочем, с полезностью для потребителя первых двух выводов тоже можно поспорить.

1. Потребителя интересует не качество абстрактного программного продукта вообще, а возможность выбрать для своего IT-решения продукт с максимальным качеством. Еще есть такой добрый консалтинговы термин "управление качеством", который намекает на то, что лучше иметь не самое высокое, но управляемое, подконтрольное качество. Т.е. важна возможность точно оценить это качество. В области коммерческих продуктов тут мы имеем только честное слово фирмы-производителя. О ненадежности и неполноте анализов качества коммерческих продуктов Елашкин пишет достаточно подробно. С открытыми исходниками всё гораздо проще. Мы можем провести настолько глубокий анализ качества, насколько нам не жалко денег.

2. Качество программного продукта важно не само по себе. Важна эффективность применения этого продукта в бизнес-процессе потребителя. Даже очень качественный микроскоп вряд ли сильно увеличит производительность труда плотника, забивающего гвозди. Поэтому возможность адаптации под конкретные нужды потребителя может оказаться важнее, скажем, производительности. Пусть коммерческий продукт выполняет операцию за 2 секунды, а опенсурсный - за 20. Но если в коммерческом продукте мне потребуется 10 нажатий мышкой для того, чтобы до этой операции добраться, и это занимает 30 секунд, то потратив два часа на доработку опенсурсного продукта, чтобы эта операция выполнялась одной кнопкой на самом видном месте, я получу выигрыш в 10 секунд. И уже на 721-м выполнении мои трудозатраты окупятся.

Собственно по этой же самой причине все оценки TCO, VCO и т.д. проходят по категории "статистика", которая идет после лжи и наглой лжи.
Мы искусственно вырываем из бизнес-процесса некоторый компонент, и оцениваем затраты на него. Хотя эти затраты далеко не главное в бизнес-процессе. Практически в любой не-IT фирме затраты на работу IT-отдела составляют отнюдь не главную статью расхода. Поэтому смотреть надо в первую очередь на то, как выбор того или иного решения сказывается на работе всей фирмы. Если повышение TCO в два раза позволяет сократить простои на 10% то может быть на это повышение стоит пойти?

ramendik справедливо поднимает вопрос о том, что эффективность использования программного обеспечения определяется квалификацией IT-специалистов и пользователей. Цена лицензий в любом случае пренебрежимо мала по сравнению с затратами на обучение и оплатой квалифицированных сотрудников. Вопрос в том, какая модель позволяет с меньшими затратами добиться необходимой квалификации - дорогостоящие курсы коммерческих фирм из которых выходят специалисты, аббревиатуру которых расшифровывают как Must Call Someone Experienced, или огромное количество опубликованных и доступных бесплатно книг, активные community в которых участвуют в том числе и авторы и текущие мейнтейнеры проектов. Исследования на эту тему по-моему никто пока не проводил. Хотя судя по обилию community посвященных коммерческому программному обеспечению, можно сделать вывод что фирменные курсы профессиональное общение не заменяют.

И тут мы возвращаемся к столлмановской идеи Free Software as Free Speech.

Что же касается масштабируемости бизнес-модели, то о чьей бизнес-модели идет речь? О бизнес-модели пользователя? Ну вот например, livejournal, вот например, Google, вот например Slashdot, одна публикация URL-ки на коммерческий сайт на котором как правило приводит к падению этого сайта из-за чрезмерной нагрузки. У всех этих сайтов ключевые компоненты инфраструктуры - OpenSource.

Или о бизнес-модели производителя? А заинтересован ли потребитель в масштабировании бизнес-модели производителя? Чем больше фирма-производитель, тем проще ей игнорировать каждого конкретного пользователя с его конкретными проблемами. Зачем тратить на него драгоценное время своих инженеров - есть еще 100 миллионов других пользователей. Лучше новую анимированную рюшечку добавить. Может это еще пару миллионов чайников привлечет.

Мне приходилось иметь дело с поддержкой коммерческих фирм разного размера. На вертикальном рынке - хорошо. Там пользователя любят и ценят, любой нетривиальный support request попавдает к разработчику соответствующего куска. И пользователь, эксплуатирующий программу в нетривиальных условиях, особенно если он умеет грамотно формулировать свои проблемы быстро становится равноправным собеседником. Он имеет шанс получить доступ к внутрифирменным отладочным инструментам разработчика, а то и к исходному коду. Эту картинку я с обоих сторон наблюдал. А возьмем какой-нибудь Oracle или Microsoft - там ты не пробъешься через девочек в call-центре. И единственный способ достучаться до разработчиков, это пробираться через какое-нибудь community, где они участвуют. Но фирменная политика скорее всего не позволит им поделиться инструментами, которые смогут действительно решить твою проблему.

Comments

[aen-.livejournal.com]

Виктор, а Вам будет приятно, если каждое упоминание Вашего имени я буду сопровождать "Выдающийся деятель российского и международного движения за FOSS..."? :-)

[vitus_wagner]

АлексеЙ, ну я же не каждое!

[alexkuklin.livejournal.com]

в мемориз! (ц) :)

[aen-.livejournal.com]

На мой взгляд, единственная серьезная тема, затронутая г-ном Елашкиным, -- проблема масштабируемости софтверного бизнеса, построенного на FOSS.
Если говорить о России, то у нас весьма сильное community разработчиков, местами структурированное. Грамотность этого community не только в специфических вопросах IT, но теперь уже и в правовых вопросах сейчас весьма высока. Но вот фирм, строящих бизнес на FOSS, -- почти нет, а если брать суммарный оборот имеющихся, то картинка будет еще грустнее.
Это и понятно. Бизнес -- очень серьезный риск, личный риск, я даже отдаленно не представлял себе всю тяжесть этого проклятого занятия, когда начинал. Могу сказать и другое. Если бы бизнес ALT не вели программисты, убежденные в важности дела, то он или загнулся бы, или не был бы именно FOSS-бизнесом. А кто из community готов лезть в это дело? А именно сейчас во многом решается его успех на следующие 2-3 года.

[aen-.livejournal.com]

Я это вот к чему, собственно. Если сейчас у российского community не откроется "второго дыхания", ориентированного на FOSS-бизнес, причем в кооперации, без обычных раздраев и поливаний соседа, то мы упустим очень серьезный шанс увеличить свои (условно) 2% до 10%. А вот после 10% начинается сосвемс другая игра, в которой уже гораздо легче масштабироваться.

[ramendik]

А у многих ли программистов и прочих активных участников FOSS community (это всё же не эквиваленты - я вот не программист, но всяко участник) есть _ресурсы_, даже минимальные, на то, чтобы "ориентироваться на FOSS-бизнес"?

Даже если не говорить об overhead на организацонные вопросы (для мелкого бизнеса это очень значимо, но, скажем, можно действовать "под крылом" одной из существующих компаний) - нужны (1) вложения в проекты и (2) чем-то семью кормить.

[aen-.livejournal.com]

(1) -- Проблема серьезная, но решаемая. Уже сделано немало, остальное развивиается постепенно, на проценты с доходов. Объединение имеющихся сервисов у разных групп уже даст очень много.
(2) -- Так вот я как раз об этом. Это очень большой риск. Я рисковал и рискую.

[cybem.livejournal.com]

Боюсь, для второго дыхания еще не пришло время. Мне кажется, что на это нужно еще лет 5.

[aen-.livejournal.com]

Вы рассчитываете, что через 5 лет оно появится у Вас? Или просто дети вырастут?

[kouzdra.livejournal.com]

Вопрос - а что Вы считаете FOSS-бизнесом. Я с Linux и проч имею дело примерно с 1996 года, причем вполне коммерческим образом - ну типа рабочая среда для выполнения контрактов. В общем и целом, фирмы, где я работал старались быть лояльными к духу и все, что можно было выложить, выкладывали (не говоря уж о том, что было нужно выложить).

КПД у этого есс-но паровозный, но это вроде бы не бага, а фича.

[aen-.livejournal.com]

У меня довольно жесткие требования. Если это софтверная фирма, то я назову ее бизнес FOSS-бизнесом, если :
0. Позиционирует себя как FOSS-фирма.
1. Все свои инициативные разработки (в том числе документацию) она выпускает под свободными лицензиями (двойное лицензирование допустимо, но без уловок в виде задержки свободных версий).
2. Публично продвигает полностью свободные решения, использует в своих решения проприетарный софт только по явному требованию заказчика или при отсутствии свободных аналогов (ну, с java пока ничего не попишешь, например). То есть не пытается получить прибыль с "комбинированных" решений.
3. При рассмотрении заказов на разработку софта старается убедить заказчика в выгоде разработки FOSS, отдает предпочтение заказам на разработку FOSS.

[vitus_wagner]

Ну моя точка зрения, упомянутая в данном посте, состоит в том, что надо брать числом, а не масштабом. Правда, малому бизнесу у нас в стране гораздо хуже, чем бизнесу крупному. Кто готов? Ну вот мое начальство похоже почти готово. Если судить по тому, как распределяются программистские силы между закрытыми и открытыми проектами.

[aen-.livejournal.com]

Насчет того, кому хуже -- не уверен.
Конечно, нужно горизонтальное масштабирование, я о том же. Но нужен горизонтальный сервис, желательно с единой торговой маркой. Людские ресурсы для него есть, спрос тоже есть.

[dinozavrik.livejournal.com]

Я, может быть, сунусь со своим суконным рылом в калашный ряд, но...

Есть одна близкая мне тема - создание (авторинг) DVD. Лично я занимаюсь этим непрофессионально, но есть знакомые, которые этим зарабатывают себе на жизнь.

Так вот, в том же DVD используются сплошь... ну если и не проприетарные (хотя не уверен насчёт DTS), так точно патентованные технологии. С каждого продукта, работающего с ними, платятся отчисления создателям стандарта - DVD-консорциуму, Dolby labs и так далее.

Хорошо, я готов даже допустить, что есть такие страшные альтруисты, которые создадут программу для сведения DVD, заплатят все необходимые отчисления и всё-таки будут поставлять исходники. Ну и что помешает другим собрать эти исходники в своих продуктах и никаких отчислений Dolby не платить? Самой Dolby это явно не по нутру придётся.

Поэтому открытых исходников такого профессионального софта не будет никогда (любительские поделки не в счёт). А следовательно, как минимум в этом случае бизнес-модель OS терпит неудачу.

Аналогичные рассуждения можно привести не только для DVD, но и для других типов медианосителей. Да и вообще для программ, работающих с патентованными технологиями.

[vitus_wagner]

Что помешает - угроза судебного процесса со стороны той же Dolby. А вообще, вы правы - патенты сейчас - один из самых серьезных камней преткновения. Вообще-то насчет "никогда" Вы не правы. Срок действия патента - ограничен. Вон LZW алгоритм, используемый в gif-формате уже свободен от patent encumbering. Вопрос в том, что к тому времени когда истечет срок действия патентов на DVD-технологии, эти технологии уже вряд ли кому будут нужны, кроме энтузиастов ретрокомпьютинга.

[dinozavrik.livejournal.com]

Вот именно, а к тому времени будет актуален HD, в котором опять будут свои патенты.

[ramendik]

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

[dinozavrik.livejournal.com]

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

Если вам повезёт, то для полноценного диска вам потребуется программа ценой 200$ (DVD-Lab pro).
Если не повещёт (запросы больше), то ценой 26000$ (ScenaristNT).
И вопрос отнюдь не в защитах, а в самой сборке DVD.

Аналогия для программистов: это как если бы компилятор бейсика был доступен бесплатно, а вот даже за компилятор C брали бы деньги (а за C++ - астрономические деньги).

[kouzdra.livejournal.com]

Знаете - я не вижу больших причин для несуществования таких программ. Open Source обладает одной замечательной осбенностью - на патенты там часто можно плюнуть. Это, разумеется, незаконно, и ограничивает масштаб проектов, но при минимальной аккуратности просто нет адекватного объекта для репрессий.

Скажем Open Source софтверные DVD-плееры есть (а там, imho, тот же набор проблем), и в смысле совместимости они лучше коммерческих. У меня не было случая, чтобы mplayer не смог чего-то воспроизвести, а вот с виндовым плеером проблемы бывали неоднократно.

PS: Я поискал и кое-что нашел - http://www.linuxjournal.com/article/6953
Оценивать не берусь, ибо очень от темы далек.

[mashckoff.livejournal.com]

Во-вторых, GPL предназначена для защиты прав авторов и пользователей (которым автор данной лицензией делегирует права) _от_ _недобросовстных_ _посредников_ в существующем правовом поле.

ИМХО, это важное уточнение.

[ramendik]

Вот в вопросе "квалификации пользователей" - с классическими юниксоидами рубился и рубиться буду. По мне так для большинства "рядовых" пользователей - важнее не повышать их квалификацию, а приспосабливать ИТ-систему (не только ПО, а весь комплекс) к низкоквалифицированной работе. Другой вопрос, что сейчас (а не пять лет назад) FOSS-решения это уже _лучше_ позволяют сделать - за счёт чёткого выделения задач и исключения неправильных путей действия (последствия которых - от потери рабочего времени до разрушения ПО на рабочей станции).

[vitus_wagner]

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

[aen-.livejournal.com]

"Open source kills jobs" :-)

[ramendik]

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

Адаптация микроскопа под нужды плотника

[gdy.livejournal.com]

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