В наше время само понятие open source используют все кому не лень и каждый в своих интересах. Тут к услугам уважаемой публики и «священные войны» на форумах, и аргументы при общении с чиновниками в битвах за госзаказы. Кто-то представляет открытый код панацеей от всех бед, кто-то рисует его адептов исчадиями ада. Но есть люди, которые с его помощью зарабатывают конкретные и подчас весьма существенные, деньги. На их кочку зрения мы и попробуем встать.
Мы намеренно оставим в стороне домашнего пользователя и юношей дерзких со взором горящим. Хотя нет, к юношам мы обратимся — если вам не всё равно, что происходит в индустрии, то статья предназначена в том числе и для вас.
Но вообще мы будем говорить об использовании открытого кода в большом бизнесе. Возможно в том бизнесе, в котором и вам придётся работать. Плохо, но будет лучше.Тренды — штука крайне упрямая. Мы можем говорить о том, что open source всё ещё не захватил власть над миром, однако факт — открытого кода всё больше, он проникает всё глубже, используется всё интенсивнее и число его пользователей постоянно растёт.
Если читатель пользуется Mozilla Firefox — он уже прикоснулся к святому Граалю индустрии. Так и с open source в большом бизнесе — мы можем каждый год задавать себе вопрос «он уже пришёл?», прислушиваться к голосам аналитиков и, качая головой, сами себе отвечать — «нет, ещё нет». И это будет справедливо, причём по целому ряду причин, о которых мы поговорим ниже. И это будет объективно — есть множество отчётов, мнений и результатов дискуссий.
Однако тренд очевиден — большой бизнес всё чаще поворачивается лицом к открытому коду. Сегодня практически все вендоры, ещё вчера исповедовавшие религию закрытого кода в том или ином виде, работают и с открытым — Oracle, Novell, и даже такой монстр, как Microsoft.
Это важно потому, что как бы мы ни льстили себе, факт остаётся фактом — львиную долю оборота и доходов генерирует вовсе не обычный пользователь. В основном IT-индустрия зарабатывает на бизнес-клиентах, а крупные корпорации для всех являются приоритетом номер один. Причём, как ни странно, справедливо это и для такого сектора, как потребительская электроника. Акции Dell взлетели в цене, после того как компания подтвердила факт разработки эксклюзивного смартфона для крупнейшего в мире мобильного оператора — China Mobile.
Потому что это означает для неё автоматический выход на целых 350 млн потенциальных пользователей. Кстати, говоря о потребительской электронике — Linux, который на сегодняшний день является самым большим open source проектом, уже давно проник в мир электроники и уверенно себя чувствует на рынке встроенных систем, а также в автомобильной индустрии.
В свете этого растущее внимание поставщиков к open source — важный тренд. Это значит, что внимание растёт и у их любимых и самых доходных клиентов — крупных корпораций. Однако между вендором и клиентом почти всегда стоит интегратор, то есть другая, зачастую не уступающая вендору по размерам и влиянию, компания. Что именно выберет заказчик, часто зависит именно от неё. Потому позиция таких компаний и их взгляд на open-source крайне важны.
Впрочем, позиция системного интегратора, как и следовало ожидать — самая спокойная и взвешенная. Поговорите с людьми Microsoft — и вы услышите арию во славу закрытых решений. Дайте слово представителям Латвийской ассоциации открытых технологий, и они пропоют осанну открытому коду. И только те ребята, которые реально доводят системы напильником до тех пор, пока клиент не останется довольным, знают про подводные камни и того и другого подхода.
Открытый или бесплатный?
Для многих «открытый код» и «бесплатные программы» — это синонимы. А между тем это заблуждение, ведь не всё, что открыто, обязательно бесплатно. И наоборот. А подмена понятий действительно имеет место быть и часто совершается совершенно сознательно. Например, когда Государственное агентство социального страхования от безвыходности (нет бюджета) переходит на OpenOffice.org, это подаётся как «латвийские государственные структуры выбирают открытый код!». А в действительности эти структуры просто выбирают то, что
бесплатно. Какой там на самом деле код — их может интересовать, а может и не интересовать.
Открытость кода важна только тогда, когда мы хотим построить свою систему на базе чего-то и осознанно выбираем полуготовое решение, которое можно довести до ума. Однако никто не говорит, что это решение будет бесплатным! Да, за лицензии на какой-нибудь открытый CRM мы заплатим ноль целых и ноль десятых лата, однако «доведение до ума» — это вполне конкретные затраты, в первую очередь человеко-часы (но не только).
Это работа, которую кто-то должен сделать и которая стоит реальных и подчас существенных денег. Причём часто эта работа может стоить дороже, чем инсталляция в организации коммерческого аналога, например Microsoft Navision — потому что потребует больше времени, потому что по открытому коду меньше специалистов и, наконец, потому, что в процессе работы мы натолкнулись на неожиданные подводные камни.
Однако у открытого кода есть одно важное и несомненное преимущество, которое понимают и в Microsoft — его практически всегда можно довести до ума, если очень хочется. Да, это будет стоить денег, но когда у тебя есть исходный код, ты можешь сам добавить нужную тебе функциональность. Тут бы самое время сказать «а в случае с Microsoft, если функции нет, то всё, приплыли». Но не выйдет — вот уже несколько лет крупные заказчики могут получить в своё распоряжение большую часть исходников Navision.
Для того самого «доведения до ума». Впрочем, Navision — это частный случай. Обычно закрытый код, это всё же закрытый код. Нет функции? Заказывайте и ждите. И платите. Вообще, когда кто-то спорит о выгодности или невыгодности закрытого или открытого кода, то в ход идут результаты многочисленных исследований — при желании в Сети их можно найти с добрый десяток и с «подходящими» результатами на любой вкус и цвет. Однако люди, которые участвуют в проектах для крупных компаний, крайне скептически смотрят на эти отчёты.
По их мнению, на стоимость проекта может влиять даже то, какие техники и методики использует конкретный менеджер проекта, насколько дальновидным и профессиональным
Почему крупный бизнес поддерживает ядро Linux?
Большие компании вроде HP, Freescale, Fujitsu, IBM, Intel, SGI участвуют в процессе работы над ядром для того, чтобы удостовериться в том, что операционная система хорошо работает на их железе. Это, в свою очередь, привлекает сообщество open source к их продукции.
Дистрибьюторы, такие как MontaVista, Novell или Red Hat, кровно заинтересованы в том, чтобы Linux был настолько мощным и «дееспособным», насколько это возможно. Поэтому они активно работают над улучшением ядра Linux.
Компании вроде Nokia, Samsung и Sony используют Linux для управления видео-камерами, телевизорами и прочими устройствами. Принимая участие в работе над ядром Linux, они гарантируют, что платформа и далее будет удовлетворять их нуждам.
В работе над Linux помогают и компании, прямо не связанные с информационными технологиями. В ядре 2.6.25 благодаря Volkswagen появилась поддержка сетевого протокола PF_CAN. А в версии 2.6.30 появился патч, созданный специалистами Quantum Controls BV (производитель навигационного оборудования для яхт). Они принимают участие в этой работе по той же причине, что и остальные — чтобы быть уверенными: Linux продолжит удовлетворять их нужды.
Энтузиастам-одиночкам это может просто нравиться или они повышают свою квалификацию. Кроме того, участие в подобных проектах является большим плюсом для очень многих работодателей в сфере open source.
Неожиданные и, что важнее, совсем непредвиденные задержки могут подчас значительно увеличить стоимость любого проекта, вне зависимости от типа выбранного решения, будь то open source или самая закрытая в мире платформа.
Ещё один важный фактор — это что делается: решение или продукт. Если надо решить конкретную проблему в уже, например, работающей системе, то все ходы хороши — мы можем взять что-то бесплатное и «прикрутить» его как workaround, не особо задумываясь о влиянии на всю систему. Естественно, мы протестируем его, задокументируем, но всё равно подход будет: «Работает? Ну и ладно. Потом доделаем по уму».
В случае масштабных проектов подобные фокусы уже значительно более рискованны и могут даже привести к удорожанию всего проекта. Потому что если в какой-то момент ты понимаешь, что всё, что до сих пор было проделано с этим open source компонентом, никуда не годится, то надо или искать что-то другое (и вся проделанная работа псу под хвост),
или тратить значительные усилия на доводку напильником.
Для большого бизнеса имеет значение и имя вендора. Решения в больших компаниях принимают наёмные менеджеры, которые отчитываются перед акционерами, часто далёкими от информационных технологий, однако, как и все люди, реагирующими на бренды. Вариант, когда компания меняет биллинговую систему и при сумме контракта в 300 млн USD выбирает решение «Васи Пупкина», может быть понят не так или вовсе не понят.Безусловно, менеджеры подстрахуются, положив на стол результаты тендеров, которые проведут именитые консалтинговые компании, и вообще системный интегратор будет солидным и, что называется, на слуху.
Но всё равно — большой бизнес любит проверенные временем, хорошо известные имена. Это даёт гарантии и уверенность в том, что компания не исчезнет в никуда. Впрочем, справедливости ради — экономический кризис оказал благотворное влияние на уровень снобизма акционеров. Многих внезапно заинтересовали не большие имена, а как можно более быстрое и значительное сокращение издержек.
До недавнего времени у open source была конкретная проблема — за ним в принципе не стояли большие имена. Некоторые аналитики полагают, что это одна из самых серьёзных проблем открытого кода как такового. Уже сегодня ситуация кардинально изменилась и процесс не остановить — Accenture, Google, IBM, Intel, Novell, Oracle, Sun и даже Microsoft, которой должна претить сама философия. Список, мягко говоря, неполный, но представление о составе «команды поддержки» даёт.
Человеческий фактор
Выше мы уже сказали, что одна из существеннейших расходных статей любого проекта — человеко-часы, то есть работа людей. Управление человеческими ресурсами является одной из самых болезненных проблем, с которыми сталкиваются вендоры, которые работают с исходным кодом. Open source традиционно связан с бесплатной работой увлечённых людей. Кому-то интересно заниматься имплементацией вот этой технологии на этой платформе — он с ней и ковыряется. Сидит в Сингапуре — и ковыряется (называется он при этом гордым словом maintainer).
А потом на него выходят люди из, например, известного производителя рутеров и говорят: «А давай ты, мил человек, будешь развивать свой проект во-о-от в этом направлении, а?
Нам как раз нужна такая штука для нашей новой программы по управлению большими магистральными рутерами стоимостью 1 млн USD. А мы тебе денег дадим, а?». Он, польщённый вниманием, соглашается — может быть даже переезжает в Стокгольм, в офис компании. И продолжает ковыряться, пока в один прекрасный день не решает бросить это дело и не отправиться на Гаити бабочек ловить. И на вопрос «а как же так?» беспечно отвечает, что ему неинтересно и что код вот до этой стадии готовности он доведёт, а дальше сами уж как-нибудь. Это не бред, а одна из реальных историй. И таких историй люди из компаний, занимающихся open source, могут рассказать десятки. Особенно всё плохо обстоит в том случае, если человек не соглашается работать по контракту, но любезно соглашается довести что-то, с чем он ковырялся, до состояния, когда это можно использовать в проекте. Его, не связанного формальным контрактом, от того, чтобы отправиться на охоту за бабочками может остановить только серьёзный удар по репутации в сообществе open source (и с этим всё строго). Однако что если репутация для него более не важна? Например, он решил сменить вид деятельности? При этом, что самое парадоксальное на взгляд постороннего — компании ведь применяют такую модель вполне осознанно и код, поддерживаемый на голом энтузиазме, тоже используются вполне осознанно. То есть у подобного подхода привлечения разработчиков есть конкретное коммерческое обоснование и строгий расчёт. Заключается он в основном в том, что сделать то же самое своими силами и с нуля может стоить значительно дороже, чем даже риск того, что какой-то конкретный maintainer внезапно потеряет интерес к своему кусочку проекта.
Кроме того, создать open source комьюнити вокруг себя может быть выгодно — это неплохой способ поискать свежую кровь и таланты, с тем чтобы потом нанять их. Да и сарафанное радио и шум вокруг компании и её проектов тоже никто не отменял (взять хотя бы Google). Но всё равно есть проблема управления человеческими ресурсами, с которой индустрия только начинает сталкиваться и только задумывается о противоядии. Она реально существует и является ещё одной из причин, почему открытый код не слишком активно и охотно используется
в проектах для большого бизнеса.
Думаем, не надо расписывать, что в случае с коммерческим софтом подобные ситуации не то чтобы невозможны, но значительно менее вероятны. Конечно, в каждой компании есть люди, которые придумали что-то и потому являются экспертами вот по этому модулю или вон той технологии. Но закрытый софт как минимум лучше задокументирован, а код пишется по единым стандартам, принятым в организации, и перенять его не такая уж большая проблема.
Без Linux никак
Когда мы говорим про open source, мы не можем обойти вниманием Linux. Это крупнейший в мире open source проект. Это основная платформа для открытых решений. Конечно, бывает и так, что открытый код используют на закрытой платформе. Однако чаще всего говорим — «open source», подразумеваем— Linux.
Применительно к большому бизнесу это означает, что для того, чтобы имплементировать в компании какую-то открытую систему, там надо перейти на Linux. А это значит, что в компании должны быть люди, знакомые с платформой.
Факт: согласно последнему ежеквартальному исследованию Foote Partners специалисты по Linux любой квалификации являются вторыми по востребованности на IT рынке труда США. Нужнее их только люди, знакомые с Java EE, SE и ME. Что это значит? Это значит, что этим людям сейчас платят больше, потому что их меньше, чем нужно рынку. Аналитики связывают этот факт с кризисом и миграцией больших компаний с устаревших мейнфреймов и систем на базе Unix на Linux. Причём выбор Linux идёт не только потому, что он дешевле, а потому, что часть старых систем для Unix может быть адаптирована и для Linux. Но при том, что linux-люди в цене, на рынке их мало. Их мало в США, их мало и у нас. Руководители проектов крупных европейских компаний жалуются на трудности с их поиском. Причём ведь требования к ним отличаются от того, к чему многие привыкли. Например, выше мы уже говорили, что с open source часто работают «оторванные студенты». Это не обязательно плохо — многие компании ищут себе в штат именно таких увлечённых специалистов.
«Первое, что я делаю, когда мне присылают CV людей, претендующих на место в моём open-source проекте, это использую Google, — говорит топменеджер одной европейской телекоммуникационной компании. — Я просто вбиваю его имя и смотрю, есть ли у него несколько самостоятельных open source проектов». Всем также известно, что многие крупные компании, например Google, поощряют трату определённого количества рабочего времени на собственные проекты. В то же время наш собеседник в рижском офисе одного из крупнейших в мире системных интеграторов компании Accenture сетует на то, что у латвийских разработчиков «неправильный» в этом смысле менталитет: «бесплатно никто даже не почешется».
Робкая попытка автора указать на различие в уровне жизни вызывает у него искренний смех: «Вы где-то видели современного программиста, который подрабатывает вечерами и вагоны разгружает? Сегодня не 90-е, у нас в этой индустрии зарабатывают может быть и меньше, чем там, но тоже весьма и весьма неплохо. Однако вместо того, чтобы придти домой и после работы написать что-то, что ему нравится, он пойдёт пить пиво с друзьями или играть в игры».
Интеллект не продаётся, но вполне воруется
При этом к компаниям, которые хотят работать с open source вообще и Linux в частности, в больших проектах для корпораций предъявляются подчас взаимоисключающие требования —
их сотрудники должны быть увлечёнными «линуксоидами» со своими персональными проектами и в то же время в компании должна царить достаточно жёсткая рабочая дисциплина. Это пока всё ещё редко встречающаяся комбинация, требующая особого подхода с точки зрения организации команды и её управления. А всё потому, что в мире открытого кода вопрос с правами на интеллектуальную собственность стоит, что называется, ребром. Например, разработчикам обычно просто запрещают делать copy/paste кода.То есть в теории можно, конечно, но только под присмотром системного архитектора и с чётким указанием на источник и тип лицензии.
Определение Open Source
1. Свободное распространение
Лицензия не должна ограничивать ни одну из сторон от продажи или безвозмездной передачи программы, её компонента или дистрибутива, содержащего программы из разных источников. Лицензия не должна быть платной ни в каком виде и ни при каких условиях.
2. Источник кода
Программа должна включать исходный код и должна позволять распространение исходного кода наряду с программой, либо должно быть явное указание на то, где этот код можно получить. Исходный код должен быть представлен в таком виде, чтобы его мог понять программист.
3. Производные работы
Лицензия должна позволять модификации и производные работы и должна позволять их распространение на абсолютно тех же условиях, что и оригинальное программное обеспечение.
4. Неприкосновенность исходного кода автора
Лицензия может ограничивать распространение исходного кода в модифицированной форме только в том случае, если лицензия допускает распространение patch files (заплаток) с исходным кодом в целях модификации исходного кода программы во время компиляции и создания программного продукта. Лицензия должна разрешать распространение программ, созданных из модифицированного исходного кода, но при этом может требовать, чтобы производные программы отличались по названию или номеру версии от оригинала.
5. Отсутствие дискриминации
Лицензия не может дискриминировать людей или группы людей.
6. Отсутствие дискриминации области применения
Лицензия не может ограничивать никого от создания программы для специальной области применения. Например, нельзя ограничивать сферу использования программы бизнесом или запрещать её использование для генетических исследований.
7. Распространение лицензии
Права, идущие «в комплекте» с программой, автоматически распространяются на всех, кто использует программу без необходимости создания отдельных и специальных лицензий.
8. Лицензия не должна быть ограничена продуктом
Права, связанные с программой, не должны зависеть от того, является ли программа частью дистрибутива. Если программа извлекается из дистрибутива и распространяется или используется отдельно от него, все, кто получают или используют программу, должны иметь такие же права, которые даёт оригинальный дистрибутив.
9. Лицензия не должна ограничивать другие программы
Лицензия не должна накладывать ограничения на программы, которые распространяются вместе с данной программой. Например, в лицензии не должно быть указано, что все программы на данном DVD обязательно должны быть с открытым исходным кодом.
10. Лицензия должна быть технологически нейтральной
В лицензии не должно быть указаний на то, что она диктует использование определённых технологий или типов и видов интерфейсов.
И раз уж мы упомянули лицензии — на сегодня это также очень больной вопрос для большого бизнеса. Не секрет, что в open source существует множество лицензий (мы насчитали 65 штук только действующих, не считая ещё 10 заброшенных) разного типа, и их ничуть не меньше, а, пожалуй, и побольше, чем у Microsoft, SAP или Oracle. Потому в большом проекте, в котором задействованы элементы чужих наработок, надо очень пристально следить за тем, какие у всего этого хозяйства виды лицензий. На самом деле специалисты, которые во всём этом разбираются и могут провести «аудит» системы на предмет использующихся лицензий и тех последствий, которые следуют из факта их использования, только появляются.
И соответствующей информации им в помощь пока ещё очень мало. Тут же надо сказать и о том, что многие типы лицензий open source являются решающим фактором и для большого бизнеса — ни один вменяемый оператор связи или банк не станет строить свой бизнес на open source-проекте, который требует возвращать модифицированный код.
Потому что это ставит под угрозу безопасность всей системы — вряд ли сегодня кто-то может быть уверен в том, что у него совсем нет дыр. Что уж там говорить про «обычные» компании, если вот даже один из крупнейших центров трансакций кредитных карт в США компания Heartland Payment Systems в результате взлома потеряла 130 миллионов уникальных номеров кредитных и дебетных карт…
Последний гвоздь
Ну а закончим мы на простом и очень коротким примере, который должен быть понятен всем. Как известно, на мобильном рынке существует несколько операционных систем. Apple iPhone OS и ОС BlackBerry мы не берём, так как они используются только двумя компаниями строго для своих трубок. А посмотрим мы на Symbian, Windows Mobile и Google Android. Первая и последняя — открытые, а вторая — закрытая. И да, есть ещё Linux, но его почти не применяют, и сейчас читателю должно наконец-то стать понятно — почему.
Поставим себя на место создателя мобильного телефона, благо сегодня свою трубку из «деталей» может собрать любая компания, были бы деньги и желание. Набор железа у нас есть, однако без операционной системы он не оживёт. В случае с Windows Mobile мы платим за использование лицензии на каждой конкретной трубке, однако получаем от компании поддержку, хорошо документированные наборы для разработчиков, все API и прочие плюшки, свежесть и размер которых зависит от нашего имени, намерений и истории отношений с Microsoft. Последнее, впрочем, вполне может быть решающим.
Если мы решили поставить формально бесплатный Symbian и у нас при этом нет штатных специалистов по этой ОС, нам так или иначе придётся обратиться в Symbian Professional Services, которая ещё два месяца назад принадлежала Nokia, а теперь — Accenture. В Symbian Professional Services работают 160 человек, большая часть которых помогает таким как мы подогнать ОС к железу. Не бесплатно, разумеется — но плата будет фактически одноразовой, фиксированной и часто известной заранее, ещё до начала работы. Если же мы обратимся к Google Android (и нет, несмотря на то что ОС построена на ядре Linux, это не Linux «в чистом виде»), то и здесь, при том что формально он бесплатный, нам придётся заплатить Google за помощь во внедрении этой ОС. Однако её размер при этом будет варьироваться в зависимости от того, насколько близка наша трубка будет к «референсной» платформе — будут ли там стоять сер-
Топ-15 самых востребованных IT-специалистов в США, июль 2009
1. Java EE, SE, ME
2. Linux
3. Virtualization (все платформы)
4. Microsoft .NET
5. NetWeaver (SAP)
6. Flex
7. Business process management/
modeling/improvement
8. SAP SM (Service Management)
9. Security (почти все сферы)
10. SAN (storage area networking)
11. Project management
12. SAP PS (Project Systems)
13. SAP HCM (SAP HR)
14. SAP FI (Financial Accounting)
15. SAP CO (Controlling)
Источник: исследовательская компания Foote Partners
Ну а напоследок — Linux. Эту ОС можно поставить на мобильное устройство, и digital times периодически упоминает про эту экзотику в новостях. Однако это именно что экзотика — просто потому, что желающим экспериментировать с этой ОС приходится делать это самостоятельно. Судя по тому, что коммерчески успешных Linux-смартфонов нет, без профессиональной помощи получается это у всех одинаково плохо.
«Новая модель персональных компьютеров построена вокруг сервисов: онлайн-музыка, видео, приложения, построенные и запускающиеся в интернете. Старый мир высокодоходных операционных систем и „настольных“ приложений уже просто плохо соотносится с новым миром» (Джим Землин, исполнительный директор The Linux Foundation).
Мы намеренно оставим в стороне домашнего пользователя и юношей дерзких со взором горящим. Хотя нет, к юношам мы обратимся — если вам не всё равно, что происходит в индустрии, то статья предназначена в том числе и для вас.
Но вообще мы будем говорить об использовании открытого кода в большом бизнесе. Возможно в том бизнесе, в котором и вам придётся работать. Плохо, но будет лучше.Тренды — штука крайне упрямая. Мы можем говорить о том, что open source всё ещё не захватил власть над миром, однако факт — открытого кода всё больше, он проникает всё глубже, используется всё интенсивнее и число его пользователей постоянно растёт.
Если читатель пользуется Mozilla Firefox — он уже прикоснулся к святому Граалю индустрии. Так и с open source в большом бизнесе — мы можем каждый год задавать себе вопрос «он уже пришёл?», прислушиваться к голосам аналитиков и, качая головой, сами себе отвечать — «нет, ещё нет». И это будет справедливо, причём по целому ряду причин, о которых мы поговорим ниже. И это будет объективно — есть множество отчётов, мнений и результатов дискуссий.
Однако тренд очевиден — большой бизнес всё чаще поворачивается лицом к открытому коду. Сегодня практически все вендоры, ещё вчера исповедовавшие религию закрытого кода в том или ином виде, работают и с открытым — Oracle, Novell, и даже такой монстр, как Microsoft.
Это важно потому, что как бы мы ни льстили себе, факт остаётся фактом — львиную долю оборота и доходов генерирует вовсе не обычный пользователь. В основном IT-индустрия зарабатывает на бизнес-клиентах, а крупные корпорации для всех являются приоритетом номер один. Причём, как ни странно, справедливо это и для такого сектора, как потребительская электроника. Акции Dell взлетели в цене, после того как компания подтвердила факт разработки эксклюзивного смартфона для крупнейшего в мире мобильного оператора — China Mobile.
Потому что это означает для неё автоматический выход на целых 350 млн потенциальных пользователей. Кстати, говоря о потребительской электронике — Linux, который на сегодняшний день является самым большим open source проектом, уже давно проник в мир электроники и уверенно себя чувствует на рынке встроенных систем, а также в автомобильной индустрии.
В свете этого растущее внимание поставщиков к open source — важный тренд. Это значит, что внимание растёт и у их любимых и самых доходных клиентов — крупных корпораций. Однако между вендором и клиентом почти всегда стоит интегратор, то есть другая, зачастую не уступающая вендору по размерам и влиянию, компания. Что именно выберет заказчик, часто зависит именно от неё. Потому позиция таких компаний и их взгляд на open-source крайне важны.
Впрочем, позиция системного интегратора, как и следовало ожидать — самая спокойная и взвешенная. Поговорите с людьми Microsoft — и вы услышите арию во славу закрытых решений. Дайте слово представителям Латвийской ассоциации открытых технологий, и они пропоют осанну открытому коду. И только те ребята, которые реально доводят системы напильником до тех пор, пока клиент не останется довольным, знают про подводные камни и того и другого подхода.
Открытый или бесплатный?
Для многих «открытый код» и «бесплатные программы» — это синонимы. А между тем это заблуждение, ведь не всё, что открыто, обязательно бесплатно. И наоборот. А подмена понятий действительно имеет место быть и часто совершается совершенно сознательно. Например, когда Государственное агентство социального страхования от безвыходности (нет бюджета) переходит на OpenOffice.org, это подаётся как «латвийские государственные структуры выбирают открытый код!». А в действительности эти структуры просто выбирают то, что
бесплатно. Какой там на самом деле код — их может интересовать, а может и не интересовать.
Открытость кода важна только тогда, когда мы хотим построить свою систему на базе чего-то и осознанно выбираем полуготовое решение, которое можно довести до ума. Однако никто не говорит, что это решение будет бесплатным! Да, за лицензии на какой-нибудь открытый CRM мы заплатим ноль целых и ноль десятых лата, однако «доведение до ума» — это вполне конкретные затраты, в первую очередь человеко-часы (но не только).
Это работа, которую кто-то должен сделать и которая стоит реальных и подчас существенных денег. Причём часто эта работа может стоить дороже, чем инсталляция в организации коммерческого аналога, например Microsoft Navision — потому что потребует больше времени, потому что по открытому коду меньше специалистов и, наконец, потому, что в процессе работы мы натолкнулись на неожиданные подводные камни.
Однако у открытого кода есть одно важное и несомненное преимущество, которое понимают и в Microsoft — его практически всегда можно довести до ума, если очень хочется. Да, это будет стоить денег, но когда у тебя есть исходный код, ты можешь сам добавить нужную тебе функциональность. Тут бы самое время сказать «а в случае с Microsoft, если функции нет, то всё, приплыли». Но не выйдет — вот уже несколько лет крупные заказчики могут получить в своё распоряжение большую часть исходников Navision.
Для того самого «доведения до ума». Впрочем, Navision — это частный случай. Обычно закрытый код, это всё же закрытый код. Нет функции? Заказывайте и ждите. И платите. Вообще, когда кто-то спорит о выгодности или невыгодности закрытого или открытого кода, то в ход идут результаты многочисленных исследований — при желании в Сети их можно найти с добрый десяток и с «подходящими» результатами на любой вкус и цвет. Однако люди, которые участвуют в проектах для крупных компаний, крайне скептически смотрят на эти отчёты.
По их мнению, на стоимость проекта может влиять даже то, какие техники и методики использует конкретный менеджер проекта, насколько дальновидным и профессиональным
Почему крупный бизнес поддерживает ядро Linux?
Большие компании вроде HP, Freescale, Fujitsu, IBM, Intel, SGI участвуют в процессе работы над ядром для того, чтобы удостовериться в том, что операционная система хорошо работает на их железе. Это, в свою очередь, привлекает сообщество open source к их продукции.
Дистрибьюторы, такие как MontaVista, Novell или Red Hat, кровно заинтересованы в том, чтобы Linux был настолько мощным и «дееспособным», насколько это возможно. Поэтому они активно работают над улучшением ядра Linux.
Компании вроде Nokia, Samsung и Sony используют Linux для управления видео-камерами, телевизорами и прочими устройствами. Принимая участие в работе над ядром Linux, они гарантируют, что платформа и далее будет удовлетворять их нуждам.
В работе над Linux помогают и компании, прямо не связанные с информационными технологиями. В ядре 2.6.25 благодаря Volkswagen появилась поддержка сетевого протокола PF_CAN. А в версии 2.6.30 появился патч, созданный специалистами Quantum Controls BV (производитель навигационного оборудования для яхт). Они принимают участие в этой работе по той же причине, что и остальные — чтобы быть уверенными: Linux продолжит удовлетворять их нужды.
Энтузиастам-одиночкам это может просто нравиться или они повышают свою квалификацию. Кроме того, участие в подобных проектах является большим плюсом для очень многих работодателей в сфере open source.
Неожиданные и, что важнее, совсем непредвиденные задержки могут подчас значительно увеличить стоимость любого проекта, вне зависимости от типа выбранного решения, будь то open source или самая закрытая в мире платформа.
Ещё один важный фактор — это что делается: решение или продукт. Если надо решить конкретную проблему в уже, например, работающей системе, то все ходы хороши — мы можем взять что-то бесплатное и «прикрутить» его как workaround, не особо задумываясь о влиянии на всю систему. Естественно, мы протестируем его, задокументируем, но всё равно подход будет: «Работает? Ну и ладно. Потом доделаем по уму».
В случае масштабных проектов подобные фокусы уже значительно более рискованны и могут даже привести к удорожанию всего проекта. Потому что если в какой-то момент ты понимаешь, что всё, что до сих пор было проделано с этим open source компонентом, никуда не годится, то надо или искать что-то другое (и вся проделанная работа псу под хвост),
или тратить значительные усилия на доводку напильником.
Для большого бизнеса имеет значение и имя вендора. Решения в больших компаниях принимают наёмные менеджеры, которые отчитываются перед акционерами, часто далёкими от информационных технологий, однако, как и все люди, реагирующими на бренды. Вариант, когда компания меняет биллинговую систему и при сумме контракта в 300 млн USD выбирает решение «Васи Пупкина», может быть понят не так или вовсе не понят.Безусловно, менеджеры подстрахуются, положив на стол результаты тендеров, которые проведут именитые консалтинговые компании, и вообще системный интегратор будет солидным и, что называется, на слуху.
Но всё равно — большой бизнес любит проверенные временем, хорошо известные имена. Это даёт гарантии и уверенность в том, что компания не исчезнет в никуда. Впрочем, справедливости ради — экономический кризис оказал благотворное влияние на уровень снобизма акционеров. Многих внезапно заинтересовали не большие имена, а как можно более быстрое и значительное сокращение издержек.
До недавнего времени у open source была конкретная проблема — за ним в принципе не стояли большие имена. Некоторые аналитики полагают, что это одна из самых серьёзных проблем открытого кода как такового. Уже сегодня ситуация кардинально изменилась и процесс не остановить — Accenture, Google, IBM, Intel, Novell, Oracle, Sun и даже Microsoft, которой должна претить сама философия. Список, мягко говоря, неполный, но представление о составе «команды поддержки» даёт.
Человеческий фактор
Выше мы уже сказали, что одна из существеннейших расходных статей любого проекта — человеко-часы, то есть работа людей. Управление человеческими ресурсами является одной из самых болезненных проблем, с которыми сталкиваются вендоры, которые работают с исходным кодом. Open source традиционно связан с бесплатной работой увлечённых людей. Кому-то интересно заниматься имплементацией вот этой технологии на этой платформе — он с ней и ковыряется. Сидит в Сингапуре — и ковыряется (называется он при этом гордым словом maintainer).
А потом на него выходят люди из, например, известного производителя рутеров и говорят: «А давай ты, мил человек, будешь развивать свой проект во-о-от в этом направлении, а?
Нам как раз нужна такая штука для нашей новой программы по управлению большими магистральными рутерами стоимостью 1 млн USD. А мы тебе денег дадим, а?». Он, польщённый вниманием, соглашается — может быть даже переезжает в Стокгольм, в офис компании. И продолжает ковыряться, пока в один прекрасный день не решает бросить это дело и не отправиться на Гаити бабочек ловить. И на вопрос «а как же так?» беспечно отвечает, что ему неинтересно и что код вот до этой стадии готовности он доведёт, а дальше сами уж как-нибудь. Это не бред, а одна из реальных историй. И таких историй люди из компаний, занимающихся open source, могут рассказать десятки. Особенно всё плохо обстоит в том случае, если человек не соглашается работать по контракту, но любезно соглашается довести что-то, с чем он ковырялся, до состояния, когда это можно использовать в проекте. Его, не связанного формальным контрактом, от того, чтобы отправиться на охоту за бабочками может остановить только серьёзный удар по репутации в сообществе open source (и с этим всё строго). Однако что если репутация для него более не важна? Например, он решил сменить вид деятельности? При этом, что самое парадоксальное на взгляд постороннего — компании ведь применяют такую модель вполне осознанно и код, поддерживаемый на голом энтузиазме, тоже используются вполне осознанно. То есть у подобного подхода привлечения разработчиков есть конкретное коммерческое обоснование и строгий расчёт. Заключается он в основном в том, что сделать то же самое своими силами и с нуля может стоить значительно дороже, чем даже риск того, что какой-то конкретный maintainer внезапно потеряет интерес к своему кусочку проекта.
Кроме того, создать open source комьюнити вокруг себя может быть выгодно — это неплохой способ поискать свежую кровь и таланты, с тем чтобы потом нанять их. Да и сарафанное радио и шум вокруг компании и её проектов тоже никто не отменял (взять хотя бы Google). Но всё равно есть проблема управления человеческими ресурсами, с которой индустрия только начинает сталкиваться и только задумывается о противоядии. Она реально существует и является ещё одной из причин, почему открытый код не слишком активно и охотно используется
в проектах для большого бизнеса.
Думаем, не надо расписывать, что в случае с коммерческим софтом подобные ситуации не то чтобы невозможны, но значительно менее вероятны. Конечно, в каждой компании есть люди, которые придумали что-то и потому являются экспертами вот по этому модулю или вон той технологии. Но закрытый софт как минимум лучше задокументирован, а код пишется по единым стандартам, принятым в организации, и перенять его не такая уж большая проблема.
Без Linux никак
Когда мы говорим про open source, мы не можем обойти вниманием Linux. Это крупнейший в мире open source проект. Это основная платформа для открытых решений. Конечно, бывает и так, что открытый код используют на закрытой платформе. Однако чаще всего говорим — «open source», подразумеваем— Linux.
Применительно к большому бизнесу это означает, что для того, чтобы имплементировать в компании какую-то открытую систему, там надо перейти на Linux. А это значит, что в компании должны быть люди, знакомые с платформой.
Факт: согласно последнему ежеквартальному исследованию Foote Partners специалисты по Linux любой квалификации являются вторыми по востребованности на IT рынке труда США. Нужнее их только люди, знакомые с Java EE, SE и ME. Что это значит? Это значит, что этим людям сейчас платят больше, потому что их меньше, чем нужно рынку. Аналитики связывают этот факт с кризисом и миграцией больших компаний с устаревших мейнфреймов и систем на базе Unix на Linux. Причём выбор Linux идёт не только потому, что он дешевле, а потому, что часть старых систем для Unix может быть адаптирована и для Linux. Но при том, что linux-люди в цене, на рынке их мало. Их мало в США, их мало и у нас. Руководители проектов крупных европейских компаний жалуются на трудности с их поиском. Причём ведь требования к ним отличаются от того, к чему многие привыкли. Например, выше мы уже говорили, что с open source часто работают «оторванные студенты». Это не обязательно плохо — многие компании ищут себе в штат именно таких увлечённых специалистов.
«Первое, что я делаю, когда мне присылают CV людей, претендующих на место в моём open-source проекте, это использую Google, — говорит топменеджер одной европейской телекоммуникационной компании. — Я просто вбиваю его имя и смотрю, есть ли у него несколько самостоятельных open source проектов». Всем также известно, что многие крупные компании, например Google, поощряют трату определённого количества рабочего времени на собственные проекты. В то же время наш собеседник в рижском офисе одного из крупнейших в мире системных интеграторов компании Accenture сетует на то, что у латвийских разработчиков «неправильный» в этом смысле менталитет: «бесплатно никто даже не почешется».
Робкая попытка автора указать на различие в уровне жизни вызывает у него искренний смех: «Вы где-то видели современного программиста, который подрабатывает вечерами и вагоны разгружает? Сегодня не 90-е, у нас в этой индустрии зарабатывают может быть и меньше, чем там, но тоже весьма и весьма неплохо. Однако вместо того, чтобы придти домой и после работы написать что-то, что ему нравится, он пойдёт пить пиво с друзьями или играть в игры».
Интеллект не продаётся, но вполне воруется
При этом к компаниям, которые хотят работать с open source вообще и Linux в частности, в больших проектах для корпораций предъявляются подчас взаимоисключающие требования —
их сотрудники должны быть увлечёнными «линуксоидами» со своими персональными проектами и в то же время в компании должна царить достаточно жёсткая рабочая дисциплина. Это пока всё ещё редко встречающаяся комбинация, требующая особого подхода с точки зрения организации команды и её управления. А всё потому, что в мире открытого кода вопрос с правами на интеллектуальную собственность стоит, что называется, ребром. Например, разработчикам обычно просто запрещают делать copy/paste кода.То есть в теории можно, конечно, но только под присмотром системного архитектора и с чётким указанием на источник и тип лицензии.
Определение Open Source
1. Свободное распространение
Лицензия не должна ограничивать ни одну из сторон от продажи или безвозмездной передачи программы, её компонента или дистрибутива, содержащего программы из разных источников. Лицензия не должна быть платной ни в каком виде и ни при каких условиях.
2. Источник кода
Программа должна включать исходный код и должна позволять распространение исходного кода наряду с программой, либо должно быть явное указание на то, где этот код можно получить. Исходный код должен быть представлен в таком виде, чтобы его мог понять программист.
3. Производные работы
Лицензия должна позволять модификации и производные работы и должна позволять их распространение на абсолютно тех же условиях, что и оригинальное программное обеспечение.
4. Неприкосновенность исходного кода автора
Лицензия может ограничивать распространение исходного кода в модифицированной форме только в том случае, если лицензия допускает распространение patch files (заплаток) с исходным кодом в целях модификации исходного кода программы во время компиляции и создания программного продукта. Лицензия должна разрешать распространение программ, созданных из модифицированного исходного кода, но при этом может требовать, чтобы производные программы отличались по названию или номеру версии от оригинала.
5. Отсутствие дискриминации
Лицензия не может дискриминировать людей или группы людей.
6. Отсутствие дискриминации области применения
Лицензия не может ограничивать никого от создания программы для специальной области применения. Например, нельзя ограничивать сферу использования программы бизнесом или запрещать её использование для генетических исследований.
7. Распространение лицензии
Права, идущие «в комплекте» с программой, автоматически распространяются на всех, кто использует программу без необходимости создания отдельных и специальных лицензий.
8. Лицензия не должна быть ограничена продуктом
Права, связанные с программой, не должны зависеть от того, является ли программа частью дистрибутива. Если программа извлекается из дистрибутива и распространяется или используется отдельно от него, все, кто получают или используют программу, должны иметь такие же права, которые даёт оригинальный дистрибутив.
9. Лицензия не должна ограничивать другие программы
Лицензия не должна накладывать ограничения на программы, которые распространяются вместе с данной программой. Например, в лицензии не должно быть указано, что все программы на данном DVD обязательно должны быть с открытым исходным кодом.
10. Лицензия должна быть технологически нейтральной
В лицензии не должно быть указаний на то, что она диктует использование определённых технологий или типов и видов интерфейсов.
И раз уж мы упомянули лицензии — на сегодня это также очень больной вопрос для большого бизнеса. Не секрет, что в open source существует множество лицензий (мы насчитали 65 штук только действующих, не считая ещё 10 заброшенных) разного типа, и их ничуть не меньше, а, пожалуй, и побольше, чем у Microsoft, SAP или Oracle. Потому в большом проекте, в котором задействованы элементы чужих наработок, надо очень пристально следить за тем, какие у всего этого хозяйства виды лицензий. На самом деле специалисты, которые во всём этом разбираются и могут провести «аудит» системы на предмет использующихся лицензий и тех последствий, которые следуют из факта их использования, только появляются.
И соответствующей информации им в помощь пока ещё очень мало. Тут же надо сказать и о том, что многие типы лицензий open source являются решающим фактором и для большого бизнеса — ни один вменяемый оператор связи или банк не станет строить свой бизнес на open source-проекте, который требует возвращать модифицированный код.
Потому что это ставит под угрозу безопасность всей системы — вряд ли сегодня кто-то может быть уверен в том, что у него совсем нет дыр. Что уж там говорить про «обычные» компании, если вот даже один из крупнейших центров трансакций кредитных карт в США компания Heartland Payment Systems в результате взлома потеряла 130 миллионов уникальных номеров кредитных и дебетных карт…
Последний гвоздь
Ну а закончим мы на простом и очень коротким примере, который должен быть понятен всем. Как известно, на мобильном рынке существует несколько операционных систем. Apple iPhone OS и ОС BlackBerry мы не берём, так как они используются только двумя компаниями строго для своих трубок. А посмотрим мы на Symbian, Windows Mobile и Google Android. Первая и последняя — открытые, а вторая — закрытая. И да, есть ещё Linux, но его почти не применяют, и сейчас читателю должно наконец-то стать понятно — почему.
Поставим себя на место создателя мобильного телефона, благо сегодня свою трубку из «деталей» может собрать любая компания, были бы деньги и желание. Набор железа у нас есть, однако без операционной системы он не оживёт. В случае с Windows Mobile мы платим за использование лицензии на каждой конкретной трубке, однако получаем от компании поддержку, хорошо документированные наборы для разработчиков, все API и прочие плюшки, свежесть и размер которых зависит от нашего имени, намерений и истории отношений с Microsoft. Последнее, впрочем, вполне может быть решающим.
Если мы решили поставить формально бесплатный Symbian и у нас при этом нет штатных специалистов по этой ОС, нам так или иначе придётся обратиться в Symbian Professional Services, которая ещё два месяца назад принадлежала Nokia, а теперь — Accenture. В Symbian Professional Services работают 160 человек, большая часть которых помогает таким как мы подогнать ОС к железу. Не бесплатно, разумеется — но плата будет фактически одноразовой, фиксированной и часто известной заранее, ещё до начала работы. Если же мы обратимся к Google Android (и нет, несмотря на то что ОС построена на ядре Linux, это не Linux «в чистом виде»), то и здесь, при том что формально он бесплатный, нам придётся заплатить Google за помощь во внедрении этой ОС. Однако её размер при этом будет варьироваться в зависимости от того, насколько близка наша трубка будет к «референсной» платформе — будут ли там стоять сер-
Топ-15 самых востребованных IT-специалистов в США, июль 2009
1. Java EE, SE, ME
2. Linux
3. Virtualization (все платформы)
4. Microsoft .NET
5. NetWeaver (SAP)
6. Flex
7. Business process management/
modeling/improvement
8. SAP SM (Service Management)
9. Security (почти все сферы)
10. SAN (storage area networking)
11. Project management
12. SAP PS (Project Systems)
13. SAP HCM (SAP HR)
14. SAP FI (Financial Accounting)
15. SAP CO (Controlling)
Источник: исследовательская компания Foote Partners
Ну а напоследок — Linux. Эту ОС можно поставить на мобильное устройство, и digital times периодически упоминает про эту экзотику в новостях. Однако это именно что экзотика — просто потому, что желающим экспериментировать с этой ОС приходится делать это самостоятельно. Судя по тому, что коммерчески успешных Linux-смартфонов нет, без профессиональной помощи получается это у всех одинаково плохо.
«Новая модель персональных компьютеров построена вокруг сервисов: онлайн-музыка, видео, приложения, построенные и запускающиеся в интернете. Старый мир высокодоходных операционных систем и „настольных“ приложений уже просто плохо соотносится с новым миром» (Джим Землин, исполнительный директор The Linux Foundation).
