Пол Рубенс

Вообразите себе такую ситуацию: ваша компания внедряет, причем с немалыми усилиями, надежное и хорошо спроектированное программное обеспечение, чтобы поддерживать некоторые важные бизнес-процессы. И тут вдруг выясняется, что в сообществе разработчиков этого проекта далеко не все гладко. У программного обеспечения неожиданно появилось ответвление, и будущее проекта висит на волоске.

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

Исследователи Грегорио Роблес и Хесус Гонсалес-Барахона из испанского Университета короля Хуана Карлоса определяют «ответвление» (forking) следующим образом: «Ответвление возникает, когда часть сообщества разработчиков (или независимая сторона, вовлеченная в проект) начинает проводить полностью независимую дальнейшую модернизацию имеющегося исходного кода. Для того чтобы считаться ответвлением, проект должен иметь: новое название; иное направление развития; параллельную инфраструктуру (веб-сайт, систему управления версиями, список подписчиков и т. д.); новое сообщество разработчиков (не связанное с оригинальным проектом).

Следует помнить, что ответвление не является повсеместным явлением. Несмотря на то что в последние годы оно встречается чаще, доля таких проектов в общей массе проектов свободного ПО не увеличивается.

Оценка ответвления с обеих сторон

Возможно, столкнуться с «ответвлением» лично вам и не придется, но неопределенность дальнейшей судьбы проекта, на который сделала ставку ваша компания, в любом случае заставляет нервничать. Как же ИТ-директору следует относиться к этому?

«С одной стороны, возможность ответвления — одно из основополагающих прав разработчиков свободного программного обеспечения, — заметил президент Open Source Initiative Эллисон Рандал. — И мы понимаем, что свобода ответвления очень важна. Это отличный способ оживить умирающий проект».

В качестве примера Рандал привел пакет LibreOffice. До появления этой ветви проект OpenOffice.org страдал от «человеческого фактора», который не позволял развивать код дальше. Ветвь LibreOffice оказалась весьма успешной и сегодня уже затмила собой OpenOffice.org.

Но, к сожалению, ответвление не всегда дает такой положительный результат. «Я сталкивался с ситуациями, когда ветвление проекта разделяло сообщество, приводило к напряженности, сокращению ресурсов и в конечном итоге убивало проект, — указал Рандал. — Если проект разделяется, с каждой стороны остается только половина работающих над ним. Обе стороны начинают бороться за одних и тех же пользователей и в конечном итоге не получают критической массы. В такой ситуации пользователи оказываются в беде».

Но можно предпринять меры, которые помогут вам остаться на правильной стороне.

«Если об ответвлении уже объявлено, его следует рассматривать как стандартный сценарий для оценки рисков, — советует Рандал. — Необходимо проанализировать обе ветви и выяснить, имеется ли у какой-то из них критическая масса разработчиков. Ветвь с критической массой победит, даже если за ней нет никакой компании. Если ветвь пользуется успехом, поддерживающие ее компании непременно появятся».

Опасности реальной жизни

Иногда не вполне ясно, какой из ветвей будет сопутствовать успех, и ни одна из сторон не располагает критической массой разработчиков и пользователей. «В этом случае имеет смысл занять выжидательную позицию и наблюдать, что происходит, или выбрать другой проект, — указал Рандал. — По крайней мере, надо заняться поиском альтернативы».

Когда в начале нынешнего года от проекта ownCloud отделилась ветвь Nextcloud, за ней стоял основатель ownCloud Фрэнк Карличек. Он хотя и является инициатором Nextcloud, но в целом выступает против ответвления, объясняя свою позицию так: «Ответвления — это крайняя мера. У такого развития событий есть множество недостатков. Ответвления вредят сообществу и разрушают его, и в самом худшем случае разделяют его на две равные части».

Создавая Nextcloud, он прекрасно понимал, что для ИТ-директора, чья компания будет использовать проект и платить за подписку или техническую поддержку, ответвление создаст дополнительные трудности, которые по возможности нужно будет минимизировать. «Если у компании (например, у ownCloud) есть клиенты, вы несете перед ними ответственность, — пояснил Карличек. — Естественно, вам нужно, чтобы и в случае ответвления они оставались довольны. Нужно убедиться в том, что пользователи смогут осуществить безболезненный переход без финансовых потерь, а это непросто».

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

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

Нужно ли ИТ-директору бояться ответвления? Лучший способ получить ответ на этот вопрос — изучить историю появления новых ветвей.

В своем исследовании Роблес и Гонсалес-Барахона проанализировали «все сколько-нибудь значимые ответвления». В августе 2011 года ими было выявлено 220 подобных проектов. Прекращение реализации как первоначального проекта, так и всех его ветвей наблюдалось в 9% случаев. При появлении ветвей, обусловленных прекращением реализации оригинального проекта (возможным или фактическим), доля действительно прекращенных оригинальных проектов составила 10%. Дальнейшее развитие ответвлений обрывалось чуть чаще — в 14% случаев.

Это означает, что в девяти случаях из десяти оригинальный проект или его ветвь продолжат свое существование и вы получите необходимое вам программное обеспечение. Вот почему при появлении ответвлений Карличек рекомендует прежде всего сохранять спокойствие: «Мой совет ИТ-директору — расслабиться и наблюдать за тем, как развиваются два проекта, чтобы понять, какой из них в конечном итоге будет обладать лучшим функционалом. По прошествии нескольких месяцев можно будет спокойно принять решение о том, на какой из них имеет смысл сделать ставку. Делать это немедленно от вас никто не требует».

– Paul Rubens What CIOs need to know about open source forking. CIO. October 4, 2016

Поговорите с любым проповедником идей Open Source, и он наверняка скажет вам, что никакого другого пути просто не существует. Достоинств у программного обеспечения с открытым кодом много, они весьма разнообразны и на сегодняшний день хорошо известны. Использовать такие программные продукты можно бесплатно. Есть возможность самостоятельно адаптировать их к своим нуждам. Поскольку за исходным кодом следит множество людей, прорехи в системе безопасности ликвидируются очень быстро. Устранить ошибку может любой желающий, и в этом смысле от поставщика пользователи не зависят. Закрытые стандарты не ограничивают вашу свободу. И наконец, вы не останетесь без поддержки, если производитель свернет свой бизнес или просто решит, что продукт не приносит ему больше желаемой прибыли.

Однако апологеты программных средств с открытым кодом, скорее всего, не скажут вам, что, несмотря на несомненные и реальные их преимущества, есть ситуации, когда проприетарное программное обеспечение с закрытым кодом окажется для бизнеса более эффективным вариантом.

В каких же случаях имеет смысл отдать предпочтение проприетарным средствам?

Когда неискушенным пользователям справиться с ними легче

Операционная система Linux оказала огромное влияние на рынок серверов, а вот про настольные ПК этого сказать нельзя. И на то есть свои причины. Несмотря на заметный прогресс, достигнутый за последние несколько лет, взаимодействовать с Linux непосвященным по-прежнему сложно, а пользовательский интерфейс различных дистрибутивов в сравнении с интерфейсом Windows или Mac OS X явно проигрывает.

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

Когда они становятся стандартом де-факто

Большинство специалистов, работающих с компьютерами, хорошо знакомы с приложениями Microsoft Word и Excel и активно используют их в своей деятельности. Да, у этих программ есть прекрасные альтернативы (например, LibreOffice и Open Office), но альтернативные варианты отличаются от продуктов Microsoft с точки зрения функционала, пользовательского интерфейса, производительности, плагинов и API, что затрудняет их интеграцию с приложениями независимых разработчиков. В 90% случаев все выглядит абсолютно одинаково, но есть риск того, что существующие различия приведут к каким-либо нестыковкам, особенно при обмене документами с поставщиками или клиентами.

Проприетарные программные средства имеет смысл использовать также при подготовке специалистов. Их поставщики давно пришли в вузы, и теперь студенты обучаются на примере их программного обеспечения. «Их продукты не обязательно являются лучшими, но они были выбраны учебными заведениями еще до того, как вокруг программного обеспечения с открытым кодом сформировалось достаточно большое сообщество, – пояснил участник Apache Software Foundation и старший научный сотрудник Лаборатории реактивного движения НАСА Крис Мэттмен. – В процессе обучения студенты лучше узнают программное обеспечение, предлагаемое такими поставщиками, что позволяет им эффективнее работать с ним. И когда они попадают в бизнес-среду, то вполне естественно стремятся продолжать использовать программные средства, к которым уже привыкли».

Когда проприетарное программное обеспечение лучше поддерживается

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

«Некоторые клиенты предпочитают обращаться за поддержкой к внешнему поставщику услуг и готовы платить за оперативное удовлетворение своих запросов, – указал профессор Университета Карнеги – Меллона Тони Вассерман. – Зачастую представители сообщества очень быстро отвечают на вопросы, опубликованные на форумах, посвященных популярным проектам с открытым кодом, но не надо путать это с гарантированной поддержкой поставщика по телефонному звонку на бесплатную линию».

Когда программное обеспечение предоставляется как сервис

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

Когда проприетарный продукт лучше работает на вашем оборудовании

Многие виды проприетарного оборудования требуют специальных драйверов, которые чаще всего поставляются с закрытым кодом и работают только на аппаратных средствах производителя. Даже если драйвер с открытым кодом существует, он может оказаться не лучшим вариантом. «Разработчики программного обеспечения с открытым кодом могут не знать всех нюансов оборудования, поэтому проприетарный драйвер зачастую работает лучше», – пояснил Мэттмен.

Когда важны гарантии и ответственность поставщика

Некоторые компании, выпускающие программные продукты с открытым кодом (например, Red Hat), работают так же, как и поставщики проприетарного программного обеспечения. Они предлагают на свои продукты ту же ограниченную гарантию, что и производители проприетарных программных средств. «Эти компании действуют точно так же, как и поставщики проприетарных средств, ну разве что реже приглашают вас поиграть в гольф», – заметил Вассерман.

Между тем в мире существует гораздо больше проектов с открытым кодом, которые не поддерживаются коммерческими организациями. Стало быть, вы не получаете и гарантий. И если это не соответствует политике закупок программного обеспечения, которой придерживается ваша организация, вам придется поискать проприетарного поставщика.

Когда нужен надежный поставщик, который в обозримой перспективе вас наверняка не бросит

Да, производитель коммерческого программного обеспечения вряд ли будет продолжать развивать и поддерживать свой продукт, если спрос упадет и продукт перестанет быть прибыльным. Компания может даже полностью свернуть бизнес. Но небольшой проект с открытым кодом тем более подвержен опасности того, что стоящие за ним люди утратят к нему интерес. И если такое произойдет, то найти другого разработчика программного обеспечения с открытым кодом, который возьмет на себя эту миссию, будет непросто. (Это скорее аргумент против небольших проектов с открытым кодом, чем в защиту проприетарного программного обеспечения, но вы по крайней мере можете следить за финансовыми показателями крупных производителей программных средств и, анализируя их, принимать обоснованные решения.)

- Paul Rubens. 7 Reasons Not to Use Open Source Software. CIO Magazine.

Интернет вещей стремительно распространяется. Датчики, сетевые чипы и другие технологии, требуемые для объединения самых разных интернет-устройств, начиная от светильников и умных часов и заканчивая промышленным оборудованием, стоят сегодня совсем недорого.

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

Большинство аналитиков согласны с тем, что масштабы Интернета вещей в перспективе станут огромными. По оценкам группы Acquity Group (входящей в состав компании Accenture), к 2019 году оснастить свои дома подключенными технологиями планируют две трети потребителей; почти половина намерена приобретать носимые устройства. Как прогнозируют в Gartner, к 2020 году общее число подключенных потребительских, деловых и промышленных «вещей» достигнет 26 миллиардов. Это в 30 раз больше, чем в 2009 году, когда их насчитывалось около 900 миллионов. (По мнению Gartner, реклама Интернета вещей сегодня достигла своего пика.)

«Для практического применения “вещи”, выполняющие сбор и передачу данных, должны быть подключены к системам автоматизации, — указал аналитик Forrester Джеффри Хэммонд. — Эти программные системы осуществляют интеллектуальное управление “вещами” и сетями, которые те используют, и отвечают за упорядочение и хранение больших объемов собранных данных, а также за их обработку перед выдачей окончательного представления, помогающего решать какие-то полезные задачи».

Проектирование приложений для Интернета вещей

Для разработчиков порядок проектирования очень важен. Каков наилучший способ создания приложений, способных выполнять самые разные функции, от дистанционного управления домашними устройствами и сбора с датчиков метеоданных для формирования прогноза погоды до информирования производителя авиационных двигателей о том, что один из его продуктов нуждается в техническом обслуживании? Какими навыками нужно для этого обладать? С чего следует начать?

Отправной точкой для приложений Интернета вещей являются сами «вещи». У этих устройств обычно нет экрана (хотя бывают и исключения), они оснащены маломощным процессором, работают под управлением встроенной операционной системы и поддерживают связь (как правило, беспроводную) с другим оборудованием посредством одного или нескольких телекоммуникационных протоколов. «Вещи» можно подключать непосредственно к Интернету, к соседним «вещам» или к устройству, выполняющему роль интернет-шлюза, — внешне оно обычно выглядит, как пластиковая коробочка с мигающими лампочками.

На следующем уровне — уровне приема данных — находятся ПО и инфраструктура, развернутые в корпоративном ЦОД или в облаке. Они принимают потоки данных, поступающие от «вещей», и упорядочивают их. ПО, работающее на уровне приема данных, обычно отвечает также за управление «вещами» и обновление при необходимости их прошивки.

Далее располагается уровень аналитики, на котором обрабатываются упорядоченные данные. И в самом конце находится уровень конечных пользователей — программа, с которой эти пользователи взаимодействуют. Это может быть корпоративное ПО, веб-приложение или мобильное приложение.

«При создании приложений Интернета вещей разработчики чаще всего имеют дело с двумя последними уровнями, — отметил главный аналитик компании Forrester Фрэнк Джиллетт. — Маловероятно, что разработчику прикладных программ понадобятся инструменты для управления оконечными устройствами или шлюзами, а также средства, которые будут функционировать на уровне приема данных».

Поэтому имеет смысл заниматься созданием приложений на базе уже готовых платформ Интернета вещей. Эти платформы обычно уже включают в себя уровень приема, на котором осуществляется последовательное архивирование входящих данных, а также уровень аналитики, средства тонкой настройки, функции активации и управления, шину передачи сообщений в реальном времени и API для взаимодействия платформы с построенными на ее базе приложениями.

Сегодня стартапы, например Xively, Mnubo, Bug Labs и ThingWorx, предлагают уже много таких платформ, оснащенных средствами взаимодействия с широким спектром «вещей», выпускаемых большим количеством производителей.

Платформы для Интернета вещей выпускают и крупные производители. Компания Microsoft предлагает решение Intelligent Systems Service, а SAP — Internet of Things Solutions.

В перспективе какие-то поставщики платформ, очевидно, будут приобретены крупными игроками — компанией Oracle и другими известными разработчиками корпоративного программного обеспечения, считают аналитики. При этом многие специализированные платформы будут использоваться в конкретных отраслевых сценариях.

Стоит ли создавать платформу с нуля?

Компания OnFarm использует облачную платформу ThingWorx для разработки собственного веб-приложения. Использование ThingWorx помогло OnFarm существенно сократить объемы программирования и в короткие сроки создать веб-панели, подключаемые к источникам данных через API ThingWorx.

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

В настоящее время OnFarm считывает данные с более чем пяти тысяч устройств, предоставляя своим клиентам более семи миллионов порций данных в месяц. И этот объем ежегодно увеличивается на 30%. Другим преимуществом выбранной платформы стала ее масштабируемость.

Поначалу генеральный директор OnFarm Ланс Донни подумывал о создании платформы для Интернета вещей с нуля, но такая идея была быстро отвергнута из-за большой конкуренции на рынке. Тогда компания наняла программиста, он написал на JavaScript интерфейс, позволяющий новым датчикам поддерживать взаимодействие с платформой ThingWorx способом, предусмотренным их производителями. Код этот находится непосредственно в ThingWorx. «К нам начали обращаться клиенты, желающие использовать в нашем решении какой-то конкретный датчик, — отметил Донни. — Выполняя их просьбу, мы связались с поставщиком, получили у него API и разработали интерфейс для связи ThingWorx с новыми датчиками».

Компания привлекла также четырех разработчиков, которые занимались созданием пользовательского интерфейса веб-приложения средствами Bootstrap, AngularJS и JavaScript. Интерфейс этот взаимодействует с ThingWorx через API RESTful. «Весь процесс был организован очень рационально, благодаря чему нам удалось сосредоточить основные усилия на вопросах производительности и гибкости при обращении к данным, их использовании и отображении на экране», — подчеркнул Донни.

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

- Paul Rubens. How to Develop Applications for the Internet of Things. CIO.  Nov 5, 2014