Страница:
9.6. Открой программу, продавай марку
Это – выдуманная деловая модель. Вы открываете исходник технологии, лежащей в основе программы, сохранив за собой тестовые инструменты или право определять критерии совместимости, а затем продаете пользователям торговую марку, удостоверяя, что выполненные ими реализации технологии являются совместимыми со всеми, носящими данную марку.
(Именно так «Sun Microsystems» должны были бы поступить с Java и Jini).
(Именно так «Sun Microsystems» должны были бы поступить с Java и Jini).
9.7. Открой программу, продавай наполнение
Это – еще одна выдуманная деловая модель. Вообразите нечто наподобие сервиса по обслуживанию программы, показывающей биржевые котировки. Ценны здесь ни программа-клиент, и ни сервер, а обеспечение объективно надежной информации. Поэтому вы открываете исходники всего программного обеспечение и продаете подписку на информацию. По мере того, как хакеры переносят клиент на новые платформы и улучшают его различными способами, ваш рынок автоматически расширяется.
(Это – причина, по которой AOL должна открыть исходный код своей программы-клиента.)
(Это – причина, по которой AOL должна открыть исходный код своей программы-клиента.)
10. Когда открыть, а когда закрыть
Рассмотрев деловые модели, которые поддерживают разработку программного обеспечения с открытыми текстами, мы можем теперь приблизиться к общему вопросу о том, когда исходному коду, с точки зрения экономики, имеет смысл быть «открытым», а когда – быть «закрытым». Но сначала, нам должно стать ясно, чем выгодна каждая из стратегий.
10.1. В чем выгода?
«Закрытые» исходные тексты позволяет Вам собирать арендную плату за ваши секретные биты; с другой стороны, исключена возможность действительно независимого аудита кода. Подход, связанный с открытым кодом, обеспечивает условия для независимой экспертизы кода, но вы не получите арендной платы за секретные биты.
Вознаграждение за секретность битов хорошо понятно; традиционно модель бизнеса по продаже программного обеспечения была построена на этой основе. До недавнего времени выгода, получаемая за счет независимого аудита кода со стороны сообщества не была понята в достаточной степени. Операционная система Linux, однако, внедрила в сознание урок, который мы должны были усвоить годы назад на опыте развития основных программ, обеспечивающих работу Интернет и других отраслей разработки: что независимая экспертиза открытых исходных текстов – единственный масштабный метод для достижения высокой надежности и качества программы.
Поэтому на конкурентном рынке клиенты, ищущие высокую надежность и качество, вознаградят производителей программного обеспечения, которые идут путем открытия исходного кода, а заодно откроют способы поддержки потока дохода от обслуживания, способы создания добавленной стоимости, и также вспомогательных рынков, связанных с программным обеспечением. Этот процесс лежит в основе удивительного успеха Linux, доля которого росла от нулевой отметки в 1996 году до более чем в 17 % на рынке серверов к концу 1998 года, и кажется, собирается доминировать на этом рынке в течение двух лет (в начале 1999 года IDC прогнозировала, что рост Linux до 2003 года будет происходить быстрее чем всех других операционных систем, вместе взятых).
Почти настолько же важное преимущество открытых исходников – полезность их использования в качестве способа распространения открытых стандартов и построения рынков вокруг них. Лавинообразным ростом Интернет во многом обязан тому факту, что TCP/IP никому не принадлежит; ни у кого нет права распоряжаться основными протоколами Интернет как своей собственностью.
Стоящие за успехом TCP/IP и Linux эффекты, обусловленные совместной работой над ними, должным образом прояснены, и, в конце концов, приводят нас к мысли о следствиях доверия и симметрии: потенциальные участники разделенной инфраструктуры могут обоснованно доверять ей в большей степени, если смогут полностью проследить, как она работает, и предпочтут инфраструктуру, в которой все стороны имеют равные права, нежели ту, в которой одна сторона находится в привилегированном положении, которое использует для того, чтобы получать арендную плату или осуществлять контроль.
Однако, на самом деле, не столь уж необходимо использовать эффект от совместной работы, которые обеспечивают симметрию прав, чтобы поднять свой вес в глазах пользователей программы. Никакой потребитель программного обеспечения не будет сознательно стремиться запереть себя в контролируемую поставщиком монополию, становясь зависимым от закрытых исходных текстов, если существует любая альтернатива приемлемого качества, код которой открыт. Роль этого аргумента растет по мере того, как программное обеспечение становится более критичным для бизнеса потребителей программного обеспечения – чем более от него зависит существование бизнеса, тем менее потребитель может допустить контроль извне.
Наконец, важное преимущество для потребителей открытого программного обеспечения, связанное с доверием – то, что оно является защищенным от будущих проблем. Если исходные тексты открыты, клиент может надеяться на помощь даже в том случае, если продавец пошел ко дну. Это может быть особенно важно для «покрывания фенечками», так как циклы эксплуатации аппаратных средств ЭВМ имеют тенденцию к сокращению; однако, этот эффект является более общим и влечет за собой увеличение ценности открытого программного обеспечения.
Вознаграждение за секретность битов хорошо понятно; традиционно модель бизнеса по продаже программного обеспечения была построена на этой основе. До недавнего времени выгода, получаемая за счет независимого аудита кода со стороны сообщества не была понята в достаточной степени. Операционная система Linux, однако, внедрила в сознание урок, который мы должны были усвоить годы назад на опыте развития основных программ, обеспечивающих работу Интернет и других отраслей разработки: что независимая экспертиза открытых исходных текстов – единственный масштабный метод для достижения высокой надежности и качества программы.
Поэтому на конкурентном рынке клиенты, ищущие высокую надежность и качество, вознаградят производителей программного обеспечения, которые идут путем открытия исходного кода, а заодно откроют способы поддержки потока дохода от обслуживания, способы создания добавленной стоимости, и также вспомогательных рынков, связанных с программным обеспечением. Этот процесс лежит в основе удивительного успеха Linux, доля которого росла от нулевой отметки в 1996 году до более чем в 17 % на рынке серверов к концу 1998 года, и кажется, собирается доминировать на этом рынке в течение двух лет (в начале 1999 года IDC прогнозировала, что рост Linux до 2003 года будет происходить быстрее чем всех других операционных систем, вместе взятых).
Почти настолько же важное преимущество открытых исходников – полезность их использования в качестве способа распространения открытых стандартов и построения рынков вокруг них. Лавинообразным ростом Интернет во многом обязан тому факту, что TCP/IP никому не принадлежит; ни у кого нет права распоряжаться основными протоколами Интернет как своей собственностью.
Стоящие за успехом TCP/IP и Linux эффекты, обусловленные совместной работой над ними, должным образом прояснены, и, в конце концов, приводят нас к мысли о следствиях доверия и симметрии: потенциальные участники разделенной инфраструктуры могут обоснованно доверять ей в большей степени, если смогут полностью проследить, как она работает, и предпочтут инфраструктуру, в которой все стороны имеют равные права, нежели ту, в которой одна сторона находится в привилегированном положении, которое использует для того, чтобы получать арендную плату или осуществлять контроль.
Однако, на самом деле, не столь уж необходимо использовать эффект от совместной работы, которые обеспечивают симметрию прав, чтобы поднять свой вес в глазах пользователей программы. Никакой потребитель программного обеспечения не будет сознательно стремиться запереть себя в контролируемую поставщиком монополию, становясь зависимым от закрытых исходных текстов, если существует любая альтернатива приемлемого качества, код которой открыт. Роль этого аргумента растет по мере того, как программное обеспечение становится более критичным для бизнеса потребителей программного обеспечения – чем более от него зависит существование бизнеса, тем менее потребитель может допустить контроль извне.
Наконец, важное преимущество для потребителей открытого программного обеспечения, связанное с доверием – то, что оно является защищенным от будущих проблем. Если исходные тексты открыты, клиент может надеяться на помощь даже в том случае, если продавец пошел ко дну. Это может быть особенно важно для «покрывания фенечками», так как циклы эксплуатации аппаратных средств ЭВМ имеют тенденцию к сокращению; однако, этот эффект является более общим и влечет за собой увеличение ценности открытого программного обеспечения.
10.2. Как они взаимодействуют?
Когда арендная плата за секретные биты выше, чем отдача от открытости исходного кода, становится экономически целесообразной закрытость исходных текстов. В тех же случаях, когда выгоды от открытости кода больше чем арендная плата за секретность, имеет смысл открыть исходный код.
Само по себе, это – тривиальное наблюдение. Становится интересно, когда мы замечаем, что отдачу от открытости кода тяжелее измерить и предсказать чем арендную плату за секретность битов, а это говорит о том, что намного чаще ожидаемый доход недооценивается, нежели оценивается слишком высоко. Действительно, пока основная часть делового мира не начала заново продумывать предпосылки перехода к открытым исходным текстам после открытия Mozilla в начале 1998 года, их предполагаемая доходность повсеместно оценивалось, как близкая к нулю, что впоследствии оказалось неверным.
Так, как мы можем оценить преимущества открытости кода? Вообще это – трудный вопрос, но мы можем приблизиться к решению этой проблемы, так же, как и к любой другой проблемы в будущем. Мы можем начать с наблюдения за прецедентами, в которых основанный на открытости подход преуспел, либо не оправдал себя. Мы можем пробовать обобщить наблюдения до модели, из контекста которой, по крайней мере, будет чувствоваться то, что открытый код приносит чистую прибыль для инвестора или бизнеса, стремящегося увеличить отдачу. Затем мы можем возвратиться к данным и пробовать усовершенствовать модель.
После анализа, представленного в [1], мы можем ожидать, что открытый исходный текст дает высокую отдачу там, где (a) надежность/ стабильность/ масштабируемость – критическое требование, и (b) правильность проектирования и реализации проекта можно без труда проверить другими средствами, кроме независимой экспертизы кода. (Второй критерий встречается на практике в случае с большинством хоть сколько-нибудь сложных программ.)
Рациональное желание потребителя избегать того, чтобы оказаться запертым в рамках монополии одного поставщика, увеличит его интерес к открытым текстам (и, следовательно, конкурентоспособность поставщиков открытых программ), поскольку программное обеспечение становится более критичным для него. Таким образом, появляется еще один критерий (c): тенденция движения к открытости кода появляется тогда, когда программное обеспечение становится критическим для бизнеса местом размещения капитала (как, например, во многих корпоративных информационно-управляющих системах).
Что касается прикладной области, то, как мы заметили выше, инфраструктура, основанная на открытости, создает доверие и эффект соразмерности, которые имеют тенденцию со временем привлекать больше клиентов в соревновании с закрытой инфраструктурой; часто лучше захватить меньшую часть быстро расширяющего рынка, нежели большую часть закрытого и застойного. Соответственно, для программного обеспечения, являющегося основой инфраструктуры, стратегия, основанная на открытости кода, направленная на большее распространение, весьма вероятно, будет иметь более высокую отдачу в течение долгого периода, нежели стратегия, основанная на закрытости и арендной плате за интеллектуальную собственность.
Фактически, способность потенциальных клиентов рассуждать о будущих последствиях стратегии продавца и их нежелание принимать монополию одного поставщика подразумевает более сильное ограничение; уже не обладая подавляющей властью над рынком, Вы можете выбрать либо стратегию, направленную на увеличение распространения открытого продукта или стратегию «доходов напрямую из закрытых исходных текстов» – но не обоих. (Аналоги этого принципа видимы и в других сферах, например на рынках электроники, где клиенты часто отказываются покупать устройства, имеющие только одного производителя). Ситуация может быть сформулирована без противопоставления: там, где эффект от совместной работы (положительные его аспекты) преобладают, открыть исходные тексты, вероятно, будет правильным.
Мы можем подвести итог этим рассуждениям, заметив, что открытые тексты, вероятно, производят большую отдачу, чем закрытые, в случае с программным обеспечением, которое (d) формирует или обеспечивает инфраструктуру коммуникаций либо компьютерных систем.
Наконец, мы можем обратить внимание на то, что поставщики уникальных или сильно отличающихся от других услуг имеют больше основания бояться копирования их методов конкурентами, нежели поставщики услуг, для которых критические алгоритмы и методы хорошо известны. Соответственно, открытые исходные тексты, более вероятно, доминируют, когда (e) ключевые методы (или их эквиваленты) – часть общеизвестных технических знаний.
Программы, обеспечивающие работу Интернет, Apache, и реализация отвечающего стандартам ANSI Unix API под названием Linux – главные образцы программ, удовлетворяющих всем пяти критериям. Дорожка к открытости в развитии таких рынков хорошо-иллюстрирована переходом сетей передачи данных на TCP/IP в середине 1990-ых после пятнадцати лет неудавшихся попыток построить империю на закрытых протоколах типа DECNET, XNS, IPX, и им подобных.
С другой стороны, открытые тексты, кажется, наименее пригодны для компании, которая является единственным обладателем приносящей доход программной технологии (строго выполняющей критерий (e)), которая, вместе с тем, являются (a) относительно нечувствительной к ошибкам, (b) может без труда быть проверенной другими средствами помимо независимой экспертизы кода; которая (c) некритична для бизнеса, и которая не увеличивают существенно свою ценность (d) из-за совместной работы над ней или повсеместного распространения.
Приведу пример такого чрезвычайного случая: в начале 1999 года меня спрашивала, «мы должны открыть исходный текст?» компания, которая пишет программы для вычисления способов распила древесины на лесопилках, обеспечивающих максимальный выход теса из необработанного лесоматериала. Мое заключение было «нет». Единственный критерий, который выполнялся в данном случае – (c), но при необходимости опытный оператор мог бы произвести необходимые вычисления и вручную.
Важное условие – то, что, специфичность изделия или технологии, заключенных в этих критериях, может изменяться со временем, что мы увидим в следующем ниже социологическом исследовании.
В заключение сформулируем следующие критерии дифференциации, стимулирующие движение к открытости кода:
(a)
надежность/ стабильность/ масштабируемость является критической характеристикой;
(b)
правильность проектирования и реализации не может с легкостью быть проверена другими средствами, кроме независимой экспертизы;
(c)
программное обеспечение является критичным для пользователя в управлении его бизнесом;
(d)
программное обеспечение формирует или поддерживает общую инфраструктуру компьютерных систем и коммуникаций;
(e)
ключевые методы (или функциональные их эквиваленты) – общеизвестны из текущего уровня техники.
Само по себе, это – тривиальное наблюдение. Становится интересно, когда мы замечаем, что отдачу от открытости кода тяжелее измерить и предсказать чем арендную плату за секретность битов, а это говорит о том, что намного чаще ожидаемый доход недооценивается, нежели оценивается слишком высоко. Действительно, пока основная часть делового мира не начала заново продумывать предпосылки перехода к открытым исходным текстам после открытия Mozilla в начале 1998 года, их предполагаемая доходность повсеместно оценивалось, как близкая к нулю, что впоследствии оказалось неверным.
Так, как мы можем оценить преимущества открытости кода? Вообще это – трудный вопрос, но мы можем приблизиться к решению этой проблемы, так же, как и к любой другой проблемы в будущем. Мы можем начать с наблюдения за прецедентами, в которых основанный на открытости подход преуспел, либо не оправдал себя. Мы можем пробовать обобщить наблюдения до модели, из контекста которой, по крайней мере, будет чувствоваться то, что открытый код приносит чистую прибыль для инвестора или бизнеса, стремящегося увеличить отдачу. Затем мы можем возвратиться к данным и пробовать усовершенствовать модель.
После анализа, представленного в [1], мы можем ожидать, что открытый исходный текст дает высокую отдачу там, где (a) надежность/ стабильность/ масштабируемость – критическое требование, и (b) правильность проектирования и реализации проекта можно без труда проверить другими средствами, кроме независимой экспертизы кода. (Второй критерий встречается на практике в случае с большинством хоть сколько-нибудь сложных программ.)
Рациональное желание потребителя избегать того, чтобы оказаться запертым в рамках монополии одного поставщика, увеличит его интерес к открытым текстам (и, следовательно, конкурентоспособность поставщиков открытых программ), поскольку программное обеспечение становится более критичным для него. Таким образом, появляется еще один критерий (c): тенденция движения к открытости кода появляется тогда, когда программное обеспечение становится критическим для бизнеса местом размещения капитала (как, например, во многих корпоративных информационно-управляющих системах).
Что касается прикладной области, то, как мы заметили выше, инфраструктура, основанная на открытости, создает доверие и эффект соразмерности, которые имеют тенденцию со временем привлекать больше клиентов в соревновании с закрытой инфраструктурой; часто лучше захватить меньшую часть быстро расширяющего рынка, нежели большую часть закрытого и застойного. Соответственно, для программного обеспечения, являющегося основой инфраструктуры, стратегия, основанная на открытости кода, направленная на большее распространение, весьма вероятно, будет иметь более высокую отдачу в течение долгого периода, нежели стратегия, основанная на закрытости и арендной плате за интеллектуальную собственность.
Фактически, способность потенциальных клиентов рассуждать о будущих последствиях стратегии продавца и их нежелание принимать монополию одного поставщика подразумевает более сильное ограничение; уже не обладая подавляющей властью над рынком, Вы можете выбрать либо стратегию, направленную на увеличение распространения открытого продукта или стратегию «доходов напрямую из закрытых исходных текстов» – но не обоих. (Аналоги этого принципа видимы и в других сферах, например на рынках электроники, где клиенты часто отказываются покупать устройства, имеющие только одного производителя). Ситуация может быть сформулирована без противопоставления: там, где эффект от совместной работы (положительные его аспекты) преобладают, открыть исходные тексты, вероятно, будет правильным.
Мы можем подвести итог этим рассуждениям, заметив, что открытые тексты, вероятно, производят большую отдачу, чем закрытые, в случае с программным обеспечением, которое (d) формирует или обеспечивает инфраструктуру коммуникаций либо компьютерных систем.
Наконец, мы можем обратить внимание на то, что поставщики уникальных или сильно отличающихся от других услуг имеют больше основания бояться копирования их методов конкурентами, нежели поставщики услуг, для которых критические алгоритмы и методы хорошо известны. Соответственно, открытые исходные тексты, более вероятно, доминируют, когда (e) ключевые методы (или их эквиваленты) – часть общеизвестных технических знаний.
Программы, обеспечивающие работу Интернет, Apache, и реализация отвечающего стандартам ANSI Unix API под названием Linux – главные образцы программ, удовлетворяющих всем пяти критериям. Дорожка к открытости в развитии таких рынков хорошо-иллюстрирована переходом сетей передачи данных на TCP/IP в середине 1990-ых после пятнадцати лет неудавшихся попыток построить империю на закрытых протоколах типа DECNET, XNS, IPX, и им подобных.
С другой стороны, открытые тексты, кажется, наименее пригодны для компании, которая является единственным обладателем приносящей доход программной технологии (строго выполняющей критерий (e)), которая, вместе с тем, являются (a) относительно нечувствительной к ошибкам, (b) может без труда быть проверенной другими средствами помимо независимой экспертизы кода; которая (c) некритична для бизнеса, и которая не увеличивают существенно свою ценность (d) из-за совместной работы над ней или повсеместного распространения.
Приведу пример такого чрезвычайного случая: в начале 1999 года меня спрашивала, «мы должны открыть исходный текст?» компания, которая пишет программы для вычисления способов распила древесины на лесопилках, обеспечивающих максимальный выход теса из необработанного лесоматериала. Мое заключение было «нет». Единственный критерий, который выполнялся в данном случае – (c), но при необходимости опытный оператор мог бы произвести необходимые вычисления и вручную.
Важное условие – то, что, специфичность изделия или технологии, заключенных в этих критериях, может изменяться со временем, что мы увидим в следующем ниже социологическом исследовании.
В заключение сформулируем следующие критерии дифференциации, стимулирующие движение к открытости кода:
(a)
надежность/ стабильность/ масштабируемость является критической характеристикой;
(b)
правильность проектирования и реализации не может с легкостью быть проверена другими средствами, кроме независимой экспертизы;
(c)
программное обеспечение является критичным для пользователя в управлении его бизнесом;
(d)
программное обеспечение формирует или поддерживает общую инфраструктуру компьютерных систем и коммуникаций;
(e)
ключевые методы (или функциональные их эквиваленты) – общеизвестны из текущего уровня техники.
10.3. Doom: социологическое исследование
История пользующейся спросом игры Doom фирмы Id software иллюстрирует способы, которыми давление со стороны рынка и эволюция продукта могут серьезно изменить соотношение сил в споре между закрытостью и открытостью исходных текстов.
Когда игра Doom была сначала выпущена в конце 1993 года, мультипликация в реальном времени и от первого лица сделали ее совершенно уникальной (в противоположность критерию (e)). Это произошло не только из-за ошеломляющей техники визуального воздействия, но и потому, что в течение многих месяцев никто не мог выяснить, как это было достигнуто на маломощных микропроцессорах того времени. Эти секретные биты стоили некоторой очень серьезной арендной платы. Кроме того, потенциальная отдача от открытости кода была низкой. Как одиночная игра, программа была (a) терпимой к ошибкам в работе, (b) не сильно трудной для проверки правильности работы, (c) не критичной для пользователя, (d) не использовала преимущества от совместной разработки. Для Doom экономически рационально было оставаться закрытой.
Однако, рынок вокруг Doom не останавливался. Потенциальные конкуренты изобрели функциональные эквиваленты ее методов мультипликации, начали появляться другие игры-стрелялки от первого лица, наподобие Duke Nukem. Поскольку эти игры отъедали долю в рынке Doom, стоимость арендной платы за секретность битов понизилась.
С другой стороны, усилия по расширению доли на рынке ставили перед разработчиками новые задачи – лучшая надежность, больше функций игры, больше пользователей, многоплатформенность. С появлением режима мультиплеера («deathmatch») и сервисов для игроков в Doom, рынок начал демонстрировать существенные преимущества совместной разработки. Все это требовало часов программирования, которые id предпочла бы потратить на следующую игру.
Все эти тенденции подняли преимущества от открытости исходных текстов. В некоторый момент кривые вознаграждения пересеклись, и открытие исходного кода Doom стало экономически рациональным для id, что позволило ей перейти к зарабатыванию денег на вторичных рынках типа производства сборников, основанных на сценарии игры. В некоторый момент времени после прохождения точки пересечения это, и в самом деле случилось. Полные исходные тексты Doom были опубликованы в конце 1997 года.
Когда игра Doom была сначала выпущена в конце 1993 года, мультипликация в реальном времени и от первого лица сделали ее совершенно уникальной (в противоположность критерию (e)). Это произошло не только из-за ошеломляющей техники визуального воздействия, но и потому, что в течение многих месяцев никто не мог выяснить, как это было достигнуто на маломощных микропроцессорах того времени. Эти секретные биты стоили некоторой очень серьезной арендной платы. Кроме того, потенциальная отдача от открытости кода была низкой. Как одиночная игра, программа была (a) терпимой к ошибкам в работе, (b) не сильно трудной для проверки правильности работы, (c) не критичной для пользователя, (d) не использовала преимущества от совместной разработки. Для Doom экономически рационально было оставаться закрытой.
Однако, рынок вокруг Doom не останавливался. Потенциальные конкуренты изобрели функциональные эквиваленты ее методов мультипликации, начали появляться другие игры-стрелялки от первого лица, наподобие Duke Nukem. Поскольку эти игры отъедали долю в рынке Doom, стоимость арендной платы за секретность битов понизилась.
С другой стороны, усилия по расширению доли на рынке ставили перед разработчиками новые задачи – лучшая надежность, больше функций игры, больше пользователей, многоплатформенность. С появлением режима мультиплеера («deathmatch») и сервисов для игроков в Doom, рынок начал демонстрировать существенные преимущества совместной разработки. Все это требовало часов программирования, которые id предпочла бы потратить на следующую игру.
Все эти тенденции подняли преимущества от открытости исходных текстов. В некоторый момент кривые вознаграждения пересеклись, и открытие исходного кода Doom стало экономически рациональным для id, что позволило ей перейти к зарабатыванию денег на вторичных рынках типа производства сборников, основанных на сценарии игры. В некоторый момент времени после прохождения точки пересечения это, и в самом деле случилось. Полные исходные тексты Doom были опубликованы в конце 1997 года.
10.4. Знать, когда отпустить
Doom представляет собой интересный предмет для исследования, потому что это ни операционная система, ни программное обеспечение, обеспечивающее коммуникации либо являющееся основой сети; он к настоящему времени далеко отстоит от обычных и очевидных примеров успеха, связанного с открытостью кода. Действительно, цикл жизни Doom, вместе с «точкой пересечения», может служить характерным примером, символизирующим экологическую нишу приложений среди остального программного кода – того, в котором коммуникации и распределенные вычисления создают серьезные проблемы с устойчивостью к ошибкам/ надежностью/ масштабируемостью, определяемые только при аудите со стороны членов сообщества разработчиков, и часто пересекающие границы между техническими окружениями и конкурирующими участниками рынка (со учетом всего подразумеваемого доверия и проблемами симметрии прав).
Doom развился от одиночной игры до «deathmatch». Все в большей и большей степени эффектом от совместной разработки становится вычисление. Подобные тенденции видимы даже в самых критических деловых приложениях, типа ERP ([enterprise resource planning] планировании ресурсов предприятий), в той степени, в какой сетевые виды коммерческой деятельности все более интенсивно имеют дело с поставщиками и клиентами – и, конечно, они присущи всей архитектуре World Wide Web. Из этого следует, что почти всюду, выгоды от открытых исходников устойчиво повышаются.
Если существующие тенденции продолжаются, центральной проблемой, стоящей перед разработчиками программного обеспечения, управляющими развитием продукта, в следующем столетии будет знание того, когда его «отпустить» – когда позволить закрытому коду перетечь в открытую инфраструктуру, чтобы эксплуатировать эффект экспертной оценки и получить более высокую отдачу от обслуживания и других вторичных рынков.
При получения прибыли существуют очевидные стимулы для того, чтобы не отойти от точки пересечения слишком далеко в любом направлении. Кроме того, есть серьезный риск упустить возможность ожидая слишком долго: Вас могут похоронить конкуренты, перешедшие на открытые исходные тексты в той же самой рыночной нише.
Причина этого является серьезной проблемой – то, что и масса пользователей, и объединение талантливых разработчиков, доступные для вовлечения в сотрудничество при разработке открытых программ, для любой конкретной категории изделий ограничено, вербовка их имеет тенденцию к прекращению. Если два производителя первым и вторым перейдут к открытым кодам, и их программы исполняют одинаковые функции, первый, вероятно, привлечет большинство пользователей и более заинтересованных разработчиков; второй должен будет подбирать остатки. Вербовка имеет тенденцию останавливаться и по мере того, как пользователи освоятся с продуктом и упадут инвестиции вложений времени разработчиков непосредственно в код.
Doom развился от одиночной игры до «deathmatch». Все в большей и большей степени эффектом от совместной разработки становится вычисление. Подобные тенденции видимы даже в самых критических деловых приложениях, типа ERP ([enterprise resource planning] планировании ресурсов предприятий), в той степени, в какой сетевые виды коммерческой деятельности все более интенсивно имеют дело с поставщиками и клиентами – и, конечно, они присущи всей архитектуре World Wide Web. Из этого следует, что почти всюду, выгоды от открытых исходников устойчиво повышаются.
Если существующие тенденции продолжаются, центральной проблемой, стоящей перед разработчиками программного обеспечения, управляющими развитием продукта, в следующем столетии будет знание того, когда его «отпустить» – когда позволить закрытому коду перетечь в открытую инфраструктуру, чтобы эксплуатировать эффект экспертной оценки и получить более высокую отдачу от обслуживания и других вторичных рынков.
При получения прибыли существуют очевидные стимулы для того, чтобы не отойти от точки пересечения слишком далеко в любом направлении. Кроме того, есть серьезный риск упустить возможность ожидая слишком долго: Вас могут похоронить конкуренты, перешедшие на открытые исходные тексты в той же самой рыночной нише.
Причина этого является серьезной проблемой – то, что и масса пользователей, и объединение талантливых разработчиков, доступные для вовлечения в сотрудничество при разработке открытых программ, для любой конкретной категории изделий ограничено, вербовка их имеет тенденцию к прекращению. Если два производителя первым и вторым перейдут к открытым кодам, и их программы исполняют одинаковые функции, первый, вероятно, привлечет большинство пользователей и более заинтересованных разработчиков; второй должен будет подбирать остатки. Вербовка имеет тенденцию останавливаться и по мере того, как пользователи освоятся с продуктом и упадут инвестиции вложений времени разработчиков непосредственно в код.
11. Деловая экология открытых исходных текстов
Сообщество разработчиков открытых программ организовало себя таким способом, который имеет тенденцию усиливать производительность при разработке. В мире Linux, в частности – экономически существенным является тот факт, что существуют многочисленные конкурирующие дистрибуторы Linux, которые формируют «модельный ряд» отдельно от разработчиков.
Разработчики пишут код, и делают его доступным через Интернет. Каждый дистрибутор выбирает некоторый поднабор доступного кода, объединяет в пакеты и продает это клиентам под своей маркой. Пользователи выбирают среди дистрибутивов и могут дополнить дистрибутив, загружая код непосредственно с сайтов разработчиков.
Эффект этого расслоения – в создании очень изменчивого внутреннего рынка для патчей. Разработчики конкурируют друг с другом, под наблюдением дистрибуторов и пользователей, соревнуясь в качестве своего программного обеспечения. Дистрибуторы конкурируют за пользовательские доллары, соревнуясь в уместности своей политики выбора, а также прибавочной стоимости, которую они добавляют к программному обеспечению.
Эффект первого порядка от этой внутренней структуры рынка – то, что никакой узел в сети не является незаменимым. Разработчики дистрибутивов могут выбыть с рынка; даже если их часть кода не продолжает собираться непосредственно другим разработчиком, соревнование за внимание пользователей будет иметь своей тенденцией быстрое появление функциональных альтернатив. Дистрибуторы могут терпеть неудачу, не повреждая и не ставя под угрозу общую открытую кодовую основу. Экология в целом дает более быстрый ответ на рыночные требования, и более способна к ответным ударам и самовосстановлению, нежели любой монолитный продавец закрытых программ, который может произвести операционную систему.
Другой важный эффект – подъем планки и увеличение эффективности посредством специализации. Разработчики не испытывают давления, которые обычно ставят под угрозу обычные закрытые проекты и превращают их в смоляные ямы – никаких контрольных списков бессмысленных и отвлекающих возможностей программы от маркетоидов, никакие поручений от управляющих использовать неподходящие и устаревшие языки либо среды программирования, никаких требований, переизобртения колеса новым и несовместимым способом во имя дифференцирования изделия или защиты интеллектуальной собственности, и (что наиболее важно) никаких крайних сроков. Никакого стремительного выпуска в свет версии 1.0 прежде, чем она доделана – которое (как в случае с DeMarco и Lister, судя по наблюдению обсуждения их разработки в стиле «разбудите меня, когда ее доделаете» в [3]), вообще способствует не только более высокому качеству, но и фактически, самому быстрому написанию действительно рабочей программы.
Дистрибуторы, с другой стороны, занимаются тем, что они делают наиболее эффективно. Будучи освобожденными от потребности финансировать масштабную и непрерывно продолжающуюся разработку программного обеспечения только для того, чтобы остаться конкурентоспособными, они могут концентрироваться на системной интеграции, упаковке, проверке качества, и обслуживании.
И дистрибуторы и разработчики сохраняют объективность с помощью постоянной обратной связи и контроля со стороны пользователей, которые являются неотъемлемой частью метода открытой разработки.
Разработчики пишут код, и делают его доступным через Интернет. Каждый дистрибутор выбирает некоторый поднабор доступного кода, объединяет в пакеты и продает это клиентам под своей маркой. Пользователи выбирают среди дистрибутивов и могут дополнить дистрибутив, загружая код непосредственно с сайтов разработчиков.
Эффект этого расслоения – в создании очень изменчивого внутреннего рынка для патчей. Разработчики конкурируют друг с другом, под наблюдением дистрибуторов и пользователей, соревнуясь в качестве своего программного обеспечения. Дистрибуторы конкурируют за пользовательские доллары, соревнуясь в уместности своей политики выбора, а также прибавочной стоимости, которую они добавляют к программному обеспечению.
Эффект первого порядка от этой внутренней структуры рынка – то, что никакой узел в сети не является незаменимым. Разработчики дистрибутивов могут выбыть с рынка; даже если их часть кода не продолжает собираться непосредственно другим разработчиком, соревнование за внимание пользователей будет иметь своей тенденцией быстрое появление функциональных альтернатив. Дистрибуторы могут терпеть неудачу, не повреждая и не ставя под угрозу общую открытую кодовую основу. Экология в целом дает более быстрый ответ на рыночные требования, и более способна к ответным ударам и самовосстановлению, нежели любой монолитный продавец закрытых программ, который может произвести операционную систему.
Другой важный эффект – подъем планки и увеличение эффективности посредством специализации. Разработчики не испытывают давления, которые обычно ставят под угрозу обычные закрытые проекты и превращают их в смоляные ямы – никаких контрольных списков бессмысленных и отвлекающих возможностей программы от маркетоидов, никакие поручений от управляющих использовать неподходящие и устаревшие языки либо среды программирования, никаких требований, переизобртения колеса новым и несовместимым способом во имя дифференцирования изделия или защиты интеллектуальной собственности, и (что наиболее важно) никаких крайних сроков. Никакого стремительного выпуска в свет версии 1.0 прежде, чем она доделана – которое (как в случае с DeMarco и Lister, судя по наблюдению обсуждения их разработки в стиле «разбудите меня, когда ее доделаете» в [3]), вообще способствует не только более высокому качеству, но и фактически, самому быстрому написанию действительно рабочей программы.
Дистрибуторы, с другой стороны, занимаются тем, что они делают наиболее эффективно. Будучи освобожденными от потребности финансировать масштабную и непрерывно продолжающуюся разработку программного обеспечения только для того, чтобы остаться конкурентоспособными, они могут концентрироваться на системной интеграции, упаковке, проверке качества, и обслуживании.
И дистрибуторы и разработчики сохраняют объективность с помощью постоянной обратной связи и контроля со стороны пользователей, которые являются неотъемлемой частью метода открытой разработки.
12. Вкус победы
«Трагедия общин» не может быть применима к развитию программ с открытыми кодами в том виде, как она понимается сегодня, но это не подразумевает, что отсутствуют причины задаться вопросом о том, жизнеспособна ли существующая сила, движущая сообщество. Будут ли ключевые игроки рынка уклоняться от сотрудничества, по мере того, как ставки становятся выше?
Есть несколько уровней, на которых можно задать этот вопрос. Наша альтернативная «Комедия общин» базируется на том аргументе, что ценность индивидуальных вкладов в открытые тексты трудно превратить в деньги. Но этот аргумент имеет намного меньше силы для фирм (подобно, скажем, дистрибуторам Linux), которые уже связали поток дохода с открытым кодом. Их вклад уже превращается в деньги каждый день. Действительно, устойчива ли их совместная роль сейчас?
Исследование этого вопроса приведет нас к пониманию некоторого количества интересных вещей, связанных с нынешней экономикой открытого программного обеспечения в реальном мире – и о том, что будет значить для промышленности программного обеспечения в будущем собственно идея сферы услуг.
На практическом уровне, применимом к сообществу разработчиков открытых программ в том виде, в котором оно существует сейчас, этот вопрос обычно излагается одним из двух различных способов. Первый: распадется ли Linux на фрагменты? Второй: наоборот, разовьется ли Linux до состояния доминирующего, квазимонополистического игрока?
Историческая аналогия, к которой обращаются люди при предположении, что Linux распадется на фрагменты – поведение продавцов, продававших свои собственные версии Unix в 1980-ых. Несмотря на бесконечный разговор об открытых стандартах, несмотря на многочисленные союзы и консорциумы и соглашения, собственнический Unix разваливался. Желание продавцов дифференцировать свои изделия, добавляя и изменяя функции ОС, оказалось более сильным, нежели интерес в росте размера рынка Unix в целом с помощью поддержания совместимости (и, следовательно, понижения барьера входа для независимых разработчиков программного обеспечения и общей стоимости владения для потребителей).
Это, с большой вероятностью, вряд ли случится с Linux, по той простой причине, что все дистрибуторы вынуждены использовать общую основу открытого кода. Действительно, для любого из них невозможно поддержать дифференцирование, потому что лицензии, из-за которых код Linux эффективно развивается, требуют, чтобы они делились исходными текстами со всеми. С того момента, когда любой дистрибутор реализует новую возможность, все его конкуренты могут свободно копировать ее.
Так как все участники рынка понимают это, никто даже не думает о выполнении маневров, подобных тем, которые фрагментировали собственнический Unix. Вместо этого, дистрибуторы Linux вынуждены конкурировать способами, которые фактически приносят пользу потребителям и всему рынку. То есть они должны конкурировать в обслуживании, поддержке, и делать ставку при проектировании на то, какие средства на самом деле способствуют облегчению установки и использования.
Общая основа исходных текстов также исключает возможность монополизации. Когда пользователи Linux волнуются об этом, название, которое они обычно бормочут – «Red Hat», компания, которая является крупнейшим и наиболее успешным из дистрибуторов (занимая около 90 % рынка в США). Но известно, что в течение нескольких дней после выхода в мае 1999 года долгожданного релиза 6.0 дистрибутива Red Hat, перед тем, как CD-ROM ов Red Hat было выпущено в достаточном количестве, «слепки» выпущенных CD-ROM, скачанные с FTP-сервера Red Hat рекламировались одним книжным издателем и несколькими другими дистрибуторами компакт-дисков, по более низким ценам чем заявляла сама Red Hat.
Red Hat не могла при этом ничего сделать, поскольку ее основатели очень хорошо понимают, что они не производят и не могут владеть ни одним битом в своем изделии; социальные нормы сообщества Linux запрещают это. По аналогии с современным известным наблюдением Джона Гилмора (John Gilmore) о том, что Интернет интерпретирует цензуру как угрозу и прокладывает маршруты в ее обход, можно сказать, что сообщество хакеров, ответственное за Linux интерпретирует попытки контроля как угрозу и прокладывает маршруты вокруг них. Для Red Hat соблазн возразить против клонирования предварительно выпущенного ею новейшего продукта поставил бы под серьезную угрозу ее возможность привлечь в будущем к сотрудничеству членов сообщества разработчиков.
Есть несколько уровней, на которых можно задать этот вопрос. Наша альтернативная «Комедия общин» базируется на том аргументе, что ценность индивидуальных вкладов в открытые тексты трудно превратить в деньги. Но этот аргумент имеет намного меньше силы для фирм (подобно, скажем, дистрибуторам Linux), которые уже связали поток дохода с открытым кодом. Их вклад уже превращается в деньги каждый день. Действительно, устойчива ли их совместная роль сейчас?
Исследование этого вопроса приведет нас к пониманию некоторого количества интересных вещей, связанных с нынешней экономикой открытого программного обеспечения в реальном мире – и о том, что будет значить для промышленности программного обеспечения в будущем собственно идея сферы услуг.
На практическом уровне, применимом к сообществу разработчиков открытых программ в том виде, в котором оно существует сейчас, этот вопрос обычно излагается одним из двух различных способов. Первый: распадется ли Linux на фрагменты? Второй: наоборот, разовьется ли Linux до состояния доминирующего, квазимонополистического игрока?
Историческая аналогия, к которой обращаются люди при предположении, что Linux распадется на фрагменты – поведение продавцов, продававших свои собственные версии Unix в 1980-ых. Несмотря на бесконечный разговор об открытых стандартах, несмотря на многочисленные союзы и консорциумы и соглашения, собственнический Unix разваливался. Желание продавцов дифференцировать свои изделия, добавляя и изменяя функции ОС, оказалось более сильным, нежели интерес в росте размера рынка Unix в целом с помощью поддержания совместимости (и, следовательно, понижения барьера входа для независимых разработчиков программного обеспечения и общей стоимости владения для потребителей).
Это, с большой вероятностью, вряд ли случится с Linux, по той простой причине, что все дистрибуторы вынуждены использовать общую основу открытого кода. Действительно, для любого из них невозможно поддержать дифференцирование, потому что лицензии, из-за которых код Linux эффективно развивается, требуют, чтобы они делились исходными текстами со всеми. С того момента, когда любой дистрибутор реализует новую возможность, все его конкуренты могут свободно копировать ее.
Так как все участники рынка понимают это, никто даже не думает о выполнении маневров, подобных тем, которые фрагментировали собственнический Unix. Вместо этого, дистрибуторы Linux вынуждены конкурировать способами, которые фактически приносят пользу потребителям и всему рынку. То есть они должны конкурировать в обслуживании, поддержке, и делать ставку при проектировании на то, какие средства на самом деле способствуют облегчению установки и использования.
Общая основа исходных текстов также исключает возможность монополизации. Когда пользователи Linux волнуются об этом, название, которое они обычно бормочут – «Red Hat», компания, которая является крупнейшим и наиболее успешным из дистрибуторов (занимая около 90 % рынка в США). Но известно, что в течение нескольких дней после выхода в мае 1999 года долгожданного релиза 6.0 дистрибутива Red Hat, перед тем, как CD-ROM ов Red Hat было выпущено в достаточном количестве, «слепки» выпущенных CD-ROM, скачанные с FTP-сервера Red Hat рекламировались одним книжным издателем и несколькими другими дистрибуторами компакт-дисков, по более низким ценам чем заявляла сама Red Hat.
Red Hat не могла при этом ничего сделать, поскольку ее основатели очень хорошо понимают, что они не производят и не могут владеть ни одним битом в своем изделии; социальные нормы сообщества Linux запрещают это. По аналогии с современным известным наблюдением Джона Гилмора (John Gilmore) о том, что Интернет интерпретирует цензуру как угрозу и прокладывает маршруты в ее обход, можно сказать, что сообщество хакеров, ответственное за Linux интерпретирует попытки контроля как угрозу и прокладывает маршруты вокруг них. Для Red Hat соблазн возразить против клонирования предварительно выпущенного ею новейшего продукта поставил бы под серьезную угрозу ее возможность привлечь в будущем к сотрудничеству членов сообщества разработчиков.