Обсуждение работа интернета держится на open source — надежна ли такая модель


Оглавление (нажмите, чтобы открыть):

Внедрение Open Source-решений для ИБ влечёт значительные непрямые издержки

Споры о том, какой же софт лучше — проприетарный или открытый — кончатся не скоро. Важнее другое — насколько квалифицированный ИБ-персонал с ним работает

Лет десять назад разработчики Open Source и не помышляли о той популярности, которой теперь могут похвастаться: в разработке ядра Linux участвуют десятки компаний, в т. ч. лидеры ИТ-индустрии, множество открытых решений становятся отраслевыми стандартами, количество Open Source-программ для защиты сетей от уязвимостей, вирусов и хакеров перевалило за несколько тысяч. В исследовании Black Duck Open Source 360° за 2020 г. говорится, что из числа опрошенных исследователями компаний софтом с открытым кодом или свободным ПО пользуется 90% организаций. По сравнению с предыдущим годом число внедрений Open Source выросло на 60%.

В чем же причина популярности Open Source-решений? Ответ на этот вопрос вроде бы очевидный: экономия затрат, поскольку они в большинстве своём бесплатные, отсутствие привязки к проприетарному софту коммерческих компаний и открытый код, который гарантирует бóльшую, как некоторые считают, безопасность ПО. Софт категории Open Source можно свободно загружать, устанавливать и модифицировать. Если иное не предусмотрено ограничительной лицензией, модифицированным софтом можно свободно распоряжаться, выкладывая его код на ресурсы типа GitHub. Список достоинств Open Source продолжает отсутствие каких-либо лицензионных ограничений по количеству установок программ.

Руководитель специальных проектов компании Mosaic451 (она занимается предоставлением управляемых услуг, а также защитой и поддержкой критически важных ИТ-систем) Энди Джордан полагает, что выгода от внедрения открытых решений не столь однозначна, как принято считать, а их защищенность напрямую зависит от того, настолько ответственен применяющий открытое ПО персонал. Своим мнением он поделился с порталом InformationWeek. По словам Джордана, применение Open Source-решений влечет прямые и непрямые издержки и в некоторых случаях эти затраты могут быть не ниже, чем развертывание проприетарного решения (особенно, если это программы для обеспечения защиты компании).

Свои рассуждения он предваряет тем, что в некоторых случаях «бесплатность» ПО с открытым исходным кодом оборачивается закупкой дополнительного оборудования, что может быть неприятным открытием для многих предприятий. Причина: после установки программного решения может выясниться, что оно не соответствует корпоративным политикам компании, или что для того, чтобы полностью раскрыть его функционал, придется перейти на платную версию либо приобрести аддоны или расширения. Например, для надлежащей защиты корпоративных пользователей платформы с открытым исходным кодом Elastic Stack требуется приобрести расширение безопасности

Затраты на внедрение Open Source

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

Выбирающей Open Source компании придется смириться с тем, что разработка и кастомизация интерфейсов требуют огромных затрат времени. В отличие от популярных проприетарных решений, предлагающих решение «из коробки», Open Source — это DIY (сделай это самостоятельно): такой софт нужно правильно установить, настроить, выполнить необходимые изменения и обучить сотрудников, как его использовать. Ситуация усложняется тем, что если что-то пойдет не так, вместо готовой программы на выходе окажется полуфабрикат. Что ещё хуже, при его доработке нельзя рассчитывать на профессиональную техническую поддержку — все должно быть исправлено силами самого внедренца.

Но что, если инженеры компании, рискнувшей перейти на Open Source, не обладают достаточными навыками, чтобы исправить недочеты? В этом случае им на помощь придёт сообщество, но при этом не стоит забывать, что никто из его членов не несет ответственности за советы или рекомендации. Не исключено, что оказавшаяся в трудном положении организация утонет в потоке огромных объёмов информации и поиск ответов на форумах так и не даст ожидаемого ответа. Не стоит также забывать, что сообщества — это не всегда пул профессионалов: многие его участники имеют поверхностные знания. Увы, но внедряющие Open Source компании очень часто сталкиваются с проблемами его обслуживания и поддержки на протяжении всего его жизненного цикла.

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

Отсутствие контроля приводит к проблемам безопасности

В силу многочисленных различий между решениями с открытым исходным кодом (отличия программных пакетов, разные депозитории) они являются сложной мишенью для хакерских атак, однако, также как и проприетарное ПО, Open Source требует постоянного контроля — его нельзя единожды настроить и «забыть», иначе такая забывчивость может обернуться проблемами, которые настигли Equifax — одно из крупнейших бюро кредитных историй. В сентябре этого года стало известно, что неизвестные злоумышленники завладели личной информацией 143 млн. американцев, включая номера социального страхования и водительских удостоверений, полные имена, адреса и т. д. Выяснилось, что хакеры использовали критическую уязвимость в платформе с открытым кодом Apache Struts (CVE-2020-9805), которую Apache Software Foundation устранила в начале марта 2020 г.. Поскольку взлом Equifax произошел в мае, это означает, что Equifax просто не установила критический патч безопасности для веб-инфраструктуры и поэтому стала добычей злоумышленников.

Нет никаких гарантий, что ситуация с Equifax в будущем не повторится. 60% респондентов опроса Black Duck признали, что не обладают необходимыми инструментами управления своим ПО с открытым кодом либо не знают, как им управлять. В связи с этим Джордан рекомендует усилить контроль для защиты Open Source-решений и не полагаться на общепринятое, но ошибочное мнение об их безопасности.

Отсутствие налаженных процессов и базовых критериев работы ПО с открытым кодом — особенно это касается решений и инструментов по безопасности — создаёт проблемы по всему периметру предприятия. Эти проблемы усложняют мониторинг нормальной сетевой активности с последующим выявлением указывающих на кибератаку аномалий и их эффективное устранение. Еще один недостаток безопасности Open Source — «серверы-снежинки», которые для установки исправлений требуют ручной настройки. Практически исключено, что администратор сетевой безопасности отдельно взятой компании обладает навыками администрирования разношерстных Open Source-решений, поэтому компании нужно выделять отдельные бюджеты на обучение персонала.

Таким образом, прежде чем начать внедрение решений в области обеспечения безопасности с открытым исходным кодом, Джордан рекомендует задаться следующими вопросами:

  1. Обладает ли ваше предприятие необходимыми ресурсами для установки и обслуживания продуктов для защиты инфраструктуры с открытым кодом, которую придётся обслуживать, обходясь без профессиональной поддержки со стороны поставщика?
    Это один из основополагающих вопросов: очень часто при переключении с проприетарных решений на Open Source организации недооценивают те сложности, с которыми они могут столкнуться. Это в первую очередь потеря времени при доработке открытых программ и задействование дополнительных человеческих ресурсов. Ситуация усугубляется тем, что по мере роста спроса на опытных специалистов в области ИТ и безопасности предприятиям не хватает внутренних ресурсов для реализации и управления ПО с открытым исходным кодом.
  2. Предусматривает ли ваш бюджет отдельную статью для обучения пользователей?
    На самом деле не все пользователи готовы переучиваться при переходе на открытое ПО. В профильной прессе неоднократно упоминалось о сложностях, с которыми им приходилось сталкиваться при работе с пакетом офисных программ LibreOffice или овладением базовыми Linux-дистрибутивами типа Ubuntu. В итоге компаниям приходилось отказываться от таких решений, хотя в них инвестировались значительные средства. Избежать подобных ситуаций поможет обучение работе с Open Source. Как показывает практика, легче всего адаптируются к работе с таким софтом сотрудники техподдержки, бизнес-операций и удаленные сотрудники.
  3. В равной ли степени поддерживает выбранный вами ИБ-вендор как собственные платформы, так и платформы с открытым исходным кодом, и есть ли у него опыт работы с Open Source?
    Этому вопросу следует уделить особое внимание, поскольку многие поставщики услуг безопасности обладают экспертизой, которая не простирается дальше рамочных решений гартнеровского магического квадранта.

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

Open Source: надежность и безопасность

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

Многие утверждают, что программные продукты, распространяемые вместе с исходными текстами, более качественны, чем коммерческие. При этом проводится параллель между размером кода и его качеством, а коммерческое программное обеспечение часто называют bloatware (т.е. «раздутое»). Но имеет ли смысл сегодня писать компактный код для приложений общего назначения? Интересный анализ стоимости оборудования, необходимого для запуска некоторых программ Microsoft приведен в статье Джоэла Сполски «Письмо о стратегии IV» (russian.joelonsoftware.com/Articles/ StrategyLetterIV.html). Стоимость дискового пространства для установки Microsoft Excel 5.0 в 1993 году составляла 36 долл., а стоимость дискового пространства Excel 2000 на момент его выхода — 1,3 долл. Аналогичная тенденция наблюдается и в области оперативной памяти и процессорной мощности. Думаю, что любой программист согласится, что оптимизировать нужно наиболее часто исполняемый участок кода, и гораздо выгоднее один раз разработать более мощный процессор, чем сотни раз оптимизировать код для менее мощного. В основе роста объема кода лежит не «всемирный заговор» Wintel, а простой экономический расчет. Для мастеров оптимального кодирования всегда найдется работа — например, в области встроенных систем.

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

Опубликованных объективных данных на удивление немного. Компания Reasoning, специализирующаяся на средствах автоматического анализа качества кода и консалтинге, опубликовала недавно данные по анализу кода некоторых популярных продуктов категории Open Source: MySQL (260 056 строк кода), Linux (125 502 строк — только модули, реализующие протокол TCP/IP) и новая версия Apache (76 208 строк). Число ошибок на 1000 строк кода в этих программах составило 0,09; 0,1 и 0,53 соответственно, а среднее число ошибок, найденных специалистами Reasoning в исследованных ими продуктах с коммерческой лицензией составляет 0,55. Еще один анализ качества кода Linux был выполнен компанией Coverity и также показал, что среднее число ошибок в коде открытых продуктов меньше, чем в среднем по некоторому набору неназванного коммерческого программного обеспечения.

На первый взгляд это свидетельствует о преимуществах подхода Open Source. Однако, не следует забывать, что компании Reasoning и Coverity специализируются на предоставлении разработчикам услуг по контролю качества, а потому их данные относительно качества коммерческих продуктов, скорее всего, соответствуют именно «сырому» коду. Косвенным свидетельством тому более высокий уровень ошибок в «сырой» версии Apache, сопоставимый со средним показателем для коммерческого программного обеспечения. Однако большинство крупных производителей программных продуктов имеет мощные системы контроля, не уступающие инструментарию Reasoning и Coverity. Да и анализ кода — не единственный метод: существуют стресс-тесты, прогоняются сотни тысяч тестовых примеров и отлавливаются малейшие отклонения от эталонных результатов и т.п.

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


Если нет данных о прямом сравнении качества кода, то можно попытаться оценить по косвенным признакам. Безопасность в значительной степени является следствием качества кода. Мы очень часто слышим об очередном вирусе, поражающем Windows; казалось бы, это ли не свидетельство ненадежности коммерческого программного обеспечения? Оставим в стороне религиозный спор о Microsoft — популярность продуктов корпорации сослужила ей дурную службу, а низкая квалификация пользователей открывает широкую дорогу злоумышленникам. Вопрос шире: является ли модель разработки кода сообществом более эффективной, чем индустриальная система автоматизированного анализа и бета-тестирования? Упомянем другой коммерческий продукт — OpenVMS. У данной операционной системы по-прежнему нет замены там, где нужна высочайшая степень безопасности и защищенности [2], а вот безопасность и надежность целого ряда приложений с открытым кодом не из первой десятки вызывает сомнения. С достаточно высокой уверенностью можно постулировать, что качество программного обеспечения и его безопасность не зависят от принятой модели разработки.

Вопросы качества кода и безопасности системы достаточно важны, но гораздо более важным для корпоративного заказчика является сервис, сопутствующий поставкам программных продуктов, а здесь у сообщества Open Source начинаются сложности — сервис изначально не был заложен в эту модель. Предполагалось, что доступ к коду самодостаточен, и опытный программист легко найдет причину ошибки и сам ее исправит, в крайнем случае, это сделает кто-то еще в сообществе и сообщит остальным. До определенного этапа этот подход неплохо работал, но выход на корпоративный рынок, с его соглашениями о гарантированном уровне обслуживания и критически важными для бизнеса приложениями, показал, что такая модель не может быть принята серьезными потребителями, а «гибридные модели» пока только в зачаточном состоянии.

Но, может быть, нулевая стоимость лицензий действительно в состоянии похоронить коммерческое программное обеспечение? Увы, стоимость товара — это еще далеко не все затраты. Казалось бы, TCO, достаточно простая метрика для измерения экономического эффекта внедрения новых технологий, позволяет решить споры об экономической эффективности открытого и коммерческого программного обеспечения [3]. Но дьявол, как всегда, таится в деталях, определяющих, насколько близка использованная модель оценки к реальности.

Не удалось найти ни одного исследования, где сравнивались бы экономические параметры открытых и коммерческих продуктов как общей категории, а не отдельных продуктов. Да это, скорее всего, и невозможно в силу «конкретности» самого понятия TCO. Но исследований, посвященных сравнению TCO определенных продуктов, много; чаще всего, речь идет о Linux, Windows или Unix. Рассмотрим одну из наиболее известных работ [4]. Аналитики IDC, рассмотрев два определенных типа задач — Web-приложения и средства групповой работы, — установили, что для задач первого типа у систем RISC/Unix показатель TCO по сравнению с системами Intel/Linux выше в 1,8 раза, а для задач второго типа — в 5,5 раз. С одной стороны, результат неожиданный: трудно понять, почему стоимость обслуживания схожих систем Unix и Linux отличается так сильно. С другой стороны, трудно оспорить факт, что продажи серверов Intel/Linux растут стремительными темпами, на фоне стагнации рынка RISC/Unix. Казалось бы, это исследование однозначно свидетельствует о преимуществах Open Source, однако следует помнить, что в исследовании речь идет о выполнении множества задач, каждая из которых относительно невелика, и вместо одного мощного сервера можно использовать много небольших и более дешевых.

Другое исследование представляет собой пример весьма качественной работы по сравнению экономических эффектов от применения открытых и коммерческих программных продуктов [5]. Расчеты проводились для двух типов компаний среднего и крупного бизнеса, и для нескольких типов стратегий построения информационной инфраструктуры, в зависимости от доли критичных для бизнеса приложений и «стандартных» серверов в общей инфраструктуре. Авторам удалось избежать сложностей и неоднозначностей расчета затрат на персонал, обслуживающий серверы: они просто вынесли эти расходы за скобки. В результате рассчитываемый параметр правильнее назвать VCO (Visible Cost of Ownership), а не TCO. С одной стороны, это ограничивает широту исследования, а с другой — позволяет вычленить бесспорную часть расчетов. Более того, в таком виде это исследование имеет одинаковую ценность для стран с различным уровнем зарплат. Анализ показал, что VCO для Microsoft Windows Server 2003 существенно ниже, чем для Novell/SuSe Linux 8 и Red Hat Enterprise Linux 3.

На какие еще данные по экономике Open Source можно опираться? Безусловно, на опыт удачных внедрений. Такие исследования проводятся методом опроса ИТ-руководителей о планах и результатах внедрения продуктов с открытым кодом. Скажем, согласно исследованию Evans Data [6], 62% менеджеров сказали, что ожидают снижения затрат при использовании Linux, причем 11% считает, что затраты уменьшаться более чем на 50%. Казалось бы, какие аргументы еще нужны? Но не все так просто. Очень показательна аналогичная работа аналитиков Forrester Research [7]; большая часть опрошенных отметила экономию при использовании открытых программных продуктов, однако никто из отметивших экономию точно ее не считал. Наоборот, те кто все-таки удосужился подсчитать результаты внедрения, показали увеличение затрат в среднем на 5-20%.

Да и насколько значим фактор стоимости лицензии для серверных платформ? Чтобы избежать субъективности и учесть все факторы, включая скидки продавца и техническую поддержку, можно использовать результаты тестов TPC. В результате сравнения систем, показавших примерно равную производительность, выяснилось, что отличие в стоимости программного компонента решения на базе Linux от решения на основе Windows составляет менее 1% от общей стоимости. При общей стоимости системы около 2,5 млн. долл. и стоимости СУБД Oracle для этой конфигурации свыше 1 млн. долл., разница в стоимости Linux (6400 долл.) или Windows 2000 (примерно 25 тыс. долл.; все цены даны с учетом трехлетней поддержки) не играет никакой роли.

В случае более дешевой конфигурации на базе 4-процессорного Itanium-сервера стоимость системы на основе Linux составила 426 393 долл., а Windows — 441 022 долл. Разница в стоимости операционной системы (Windows или Linux) составила 5399 долл. Стоимость ОС станет заметной только при дальнейшем снижении общей стоимости системы (аппаратная часть + СУБД + операционная система) в районе 30-40 тыс. долл.

Итак, коммерческое программное обеспечение не уступает по качеству открытым программам, служба поддержки у «коммерсантов» лучше, а общая стоимость владения Open Source, как минимум, не ниже. Неужели нет областей, где Open Source имеет превосходство? Их можно найти, только отказавшись от мифов. Это встроенные системы, куда еще не дотянулась рука «ширпотреба» и где возможность доступа к исходному коду и удаления лишнего кода является критически важной. Это проекты, где с программными продуктами работает квалифицированный разработчик, которому важна возможность настройки инструмента под себя (Eclipse или NetBeans). Это образовательные и исследовательские университеты, где все сильнее проявляют себя вычислительные grid-системы — науке всегда нужно больше при меньших затратах. Думаю, этот список не полон. А вот где у Open Source будут серьезные проблемы? Все на том же корпоративном рынке, где пользователи готовы платить не за возможность полюбоваться кодом, а за проверенные решения и гарантированный сервис.

Мастер Йода рекомендует:  По стопам лучших микросервисная архитектура в разрезе

Колонка CEO. Как мы зарабатываем на open source

Международная компания Percona уже более 10 лет оказывает услуги поддержки, консалтинга и удалённого администрирования СУБД. CEO проекта Пётр Зайцев рассказал dev.by о том, как им удаётся зарабатывать на ПО с открытым кодом и корпоративных решениях для MySQL и MongoDB.

Четыре бизнес-модели

Моделей бизнеса на основе open source несколько. Если посмотреть на основные подходы, то можно выделить четыре типа.

Первая модель — open source-компании с двойной лицензией (MySQL AB в свои ранние годы). Они выпускают продукт как под open source-лицензией, так и под специальной коммерческой. Для игроков этого типа open source служит своего рода рекламой, а деньги приносит коммерческая лицензия.

Вторая модель — это базовое решение open source плюс более продвинутое enterprise-решение, которое уже не является открытым. В качестве примера можно привести MongoDB — у них есть MongoDB Community Edition (открытое решение) и MongoDB Enterprise Edition (коммерческое). Открытое решение используется для маркетинговых целей, а деньги делаются на enterprise-версии.

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

Недавно появилась ещё одна модель, набирающая теперь популярность: создаётся open source-проект, но при этом оказываются дополнительные услуги в облаке — разумеется, платные. Пример использования такой модели — OpenStack. С одной стороны, это open source-проект в чистом виде, с другой — если не хочется устанавливать его самим, а получить настроенным в облаке, то многие компании предлагают такие решения.

Как зарабатываем мы

Мы оказываем разные услуги. Например, некоторые компании не хотят нанимать администратора СУБД, потому что это сложно и дорого. Мы берём такое обслуживание на себя. Эта модель интересна тем, что помогает избежать привязки к одному вендору.

Допустим, вместо дорогой СУБД Oracle компания решает использовать более демократичную MongoDB. Продажники MongoDB, разумеется, пытаются продать клиенту enterprise-версию, которая, по сути, является коммерческим продуктом и ничем не отличается от Oracle. Начав использовать Enterprise, от неё будет уже сложно отказаться. Многие не хотят такого в принципе — им важно использовать программное обеспечение с открытым кодом, а не коммерческий софт, который только базируется на открытом коде.

Наша целевая аудитория очень разная. Мы на рынке более десяти лет, и со многими ныне крупными западными проектами начинали работать, когда они были ещё очень маленькими и почти никому не известными. Если посмотреть на топ-20 сайтов в мире, то, думаю, не ошибусь, если скажу, что как минимум половина из них — наши клиенты.

Крупные технические компании типа Google или Facebook сильно сфокусированы на разработке собственных технологий, у них очень много грамотных инженеров, которые занимаются их проектами. У Facebook, например, есть свой вариант MySQL, они модифицируют ядро Linux, делают свой движок баз данных.

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

Часто традиционные компании приходят к нам, потому что мы можем предложить решения на уровне тех, что используют Google и Facebook, без необходимости создавать собственную технологию. Создавать её долго и дорого, и к тому же не всегда возможно: условия работы в этих компаниях могут оказаться недостаточно привлекательными для потенциальных сотрудников.

Сейчас, правда, наметился интересный тренд: многие нетехнологические бизнесы размещают свои ИT-команды отдельно от остальных подразделений, позволяя развивать свою культуру — лишь бы привлечь высококлассный технический персонал. Например, розничная сеть Walmart создала Walmart Labs, многие банки также создают для ИT-специалистов отдельные компании, чтобы они вывели их инфраструктуру на современный уровень.

Аутсорсинг бывает разный


Open source-аутсорсинг часто критикуют: мол, это дешёвая заказная разработка малокритичных вещей. У нас же всё наоборот: Percona занимается критичными вещами, и стоит это дорого — иногда даже дороже, чем работа штатного сотрудника.

Аутсорсинг часто строится следующим образом: компания предоставляет команду или человека для решения той или иной проблемы. То есть клиент платит за команду или человека. Мы же берём плату за решение как таковое.

Один из наших бизнесов — техническая поддержка. Мы помогаем разработчикам и тем, кто обслуживает наш открытый софт, более эффективно его использовать. Если находятся какие-то ошибки, мы их исправляем.

Этот бизнес интересен тем, что многим большим компаниям (особенно в Америке и в Европе) требуются услуги поддержки. Например, какой-нибудь CEO смотрит на список используемых технологий и хочет, чтобы было понятно, к кому обращаться при возникновении сложных вопросов. По крайней мере, чтобы переложить ответственность: никому не хочется оказаться в ситуации, когда специалист, вроде бы разбирающийся в MySQL, вот уже три дня не может справиться с проблемой — и сайт «лежит», а бизнес стоит. Техподдержка для открытого софта зачастую хорошо работает в некоторых отраслях бизнеса, потому что, в отличие от по умолчанию платной лицензии Oracle, платить за поддержку необязательно. У людей есть выбор в этой ситуации.

Кому это нужно

Компаниям выгодно пользоваться услугами стороннего поставщика, а не нанимать людей в штат, потому что квалифицированный администратор баз данных может обслуживать много серверов — зачастую больше, чем есть в той или иной отдельной компании. Но если компании хочется кого-то нанять, то взять человека на полставки (или на четверть), скажем так, сложно. Придётся нанимать специалиста, который будет загружен реальной работой на 10-20%. Он найдет, чем себя занять в остальное время, но нужно ли это компании?

Сотрудничая с аутсорсинговой компанией, можно оплатить только тот «кусок» работы, который нужен. В переводе на час или на день работы выйдет дороже, но в совокупности получится дешевле, чем содержание полной рабочей ставки, особенно если смотреть на зарплаты в США.

Вторая причина, по которой компаниям это выгодно — человеческий фактор. Если вы принимаете на работу сотрудника, с этим сопряжены определённые риски. Иногда люди спят, болеют, уходят в отпуск или вообще в другие компании. Кроме того, всегда есть риск нанять не очень компетентного администратора, особенно если у вас нет достаточных знаний и опыта в этой сфере. А базы данных — это такой участок работы, где одна ошибка может стоить компании бизнеса.

Мы не раз сталкивались с ситуациями, когда человек думал, что настроил резервное копирование базы, но на деле происходил сбой — данные безвозвратно терялись, и бизнес сталкивался с большими проблемами.

И третья причина заключается в том, что сама технология баз данных достаточно сложна. В Percona, например, есть большая группа экспертов, которые знают разные части этой сложной технологии. Потому у наших клиентов популярностью пользуются такие разовые услуги, как, например, апгрейд до новой версии ПО. Скажем, компания долго использовала MySQL 5.5, но в один прекрасный день они захотели перейти на MySQL 5.6 или 5.7. Даже если у этой компании была команда отличных специалистов с многолетним опытом, они всё равно такого не проходили, а для нас подобный кейс миграции не первый.

Фото: Percona via Glassdoor

*Мнение колумнистов может не совпадать с позицией редакции.

Обсуждение: работа интернета держится на open source — какие аргументы есть у критиков 09.11.2020 22:38

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

Фото — James Sutton — Unsplash

Open source — основа интернета

По данным Linux Foundation, 72% компаний из Fortune 2000 используют open source инструменты для решения своих задач. При этом 55% задействуют открытый код в коммерческих продуктах. Открытое ПО распространено в дата-центрах — например, с ним работают Facebook, Rackspace, NASA и AT&T. Ряд облачных провайдеров и ИТ-компаний даже основал организацию Open Compute Project. Она разрабатывает открытый стандарт архитектуры серверных стоек (Open Rack) и требования к модульному серверу для облачных дата-центров (OpenCloud Server).

Значительная часть популярных open source продуктов — это масштабные проекты вроде Kubernetes, TensorFlow или Ansible. Их разрабатывают и финансируют крупные ИТ-компании. Но есть и небольшие продукты (например, cURL), которые поддерживают энтузиасты. Часто они делают это на добровольной основе и в свободное время. И здесь кроются подводные камни.

Почему такую модель критикуют

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

Значительную часть изменений в open source проект вносит или маленькая команда, или один мейнтейнер. Например, из 25 тыс. коммитов в репозитории cURL, 14 тыс. принадлежат автору — Даниэлю Стенбергу (Daniel Stenberg). Долгое время число разработчиков библиотеки OpenSSL не превышало четырех человек. Большую часть коммитов сделал один из них — Стив Хенсон (Steve Henson). Поэтому в таких условиях легко недоглядеть и «пропустить» баг.

Так, пять лет назад в OpenSSL обнаружили одну из самых крупных уязвимостей в софте — Heartbleed. Она позволяет несанкционированно читать память на сервере или клиенте. Тогда число уязвимых веб-сайтов оценили в полмиллиона. Патч выпустили сразу, но еще в 2020 году работали 200 тыс. сайтов, подверженных Heartbleed.

Фото — James Sutton — Unsplash

Многие open source проекты испытывают проблемы с финансированием. Тот же OpenSSL существует за счет пожертвований комьюнити и доходов с корпоративных контрактов — сумма не превышает миллиона долларов в год. Бывший CEO проекта говорит, что одной из причин появления Heartbleed стал именно недостаток финансирования. Инженерам бывает сложно привлечь средства даже за консультации. По словам Даниэля Стенберга, к нему часто обращаются международные компании с просьбами помочь решить проблему в cURL. Но каждый раз, когда он просит оплатить его работу, беседа почему-то прекращается.

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

Автор проекта, Доминик Тарр (Dominic Tarr), переключился на другие задачи и оставил свое детище без внимания. Некий пользователь предложил взять поддержку модуля на себя.

Тарр согласился и предоставил ему доступ к репозиторию на GitHub и npm. Со временем новый мейнтейнер внедрил в утилиту скрипт, который воровал данные биткоин-кошельков и загружал их на его сервер. Уязвимость затронула большое число пользователей, учитывая, что у event-stream 1,9 млн скачиваний в неделю.


Как исправляют ситуацию

По данным Национального бюро экономических исследований США, главный мотивирующий фактор развития open source — это экономическая выгода. Поэтому разработчики открытого ПО ищут способы его монетизировать. Например, переводят часть модулей на ограничивающие или даже коммерческие лицензии. По этому пути пошли MongoDB, Redis и другие компании.

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

Есть мнение, что подход противоречит концепции открытого ПО. При этом он годится не для всех. В 2020 году HTTP/2 веб-сервер Caddy анонсировал коммерческую лицензию. Но по каким-то причинам месяц назад проект вновь вернули в open source.

Фото — Artem Beliaikin — Unsplash

Мировая интернет-инфраструктура зависит от открытых проектов. Поэтому важно уделять внимание их поддержке. И работа в этом направлении ведется. В Linux Foundation регулярно появляются новые резиденты. Все больше в open source инвестируют крупные компании. Возможно, такие инициативы помогут избежать повторения истории, аналогичной Heartbleed.

Дополнительное чтение в блоге 1cloud.ru:

Спасет ли облако ультра-бюджетные смартфоны
Почему Apple изменила требования к разработчикам приложений
Эволюция архитектуры облака 1cloud

Что нового в Linux kernel 5.3 — графические драйверы, виртуализация и другие обновления
Почему разработчики мейнстрим-браузера снова отказались от отображения поддомена
Почему Apple изменила требования к разработчикам приложений

Юридические проблемы при работе с Open Source кодом

Недавно посетил лекцию по правовым аспектам работы с Open Source кодом. Лекцию читал юрист, да еще на английском языке — это были скучнейшие 3 часа в моей жизни.
Но зато я узнал некоторые нюансы работы с Open Source, которых раньше не знал, а также различия в законодательствах разных стран, которые могут привести к проблемам. Об этом я сейчас и расскажу. Надеюсь это не будет скучнейшее чтиво в вашей жизни 🙂

В общем, все вы наверняка уже знаете, что есть разные типы лицензий для Open Source кода — GPL, LGPL, BSD, MIT, Mozilla public license, Apache software license и другие. У каждой из этих лицензий свои ограничения, плюсы и минусы. Кто не знает или не совсем ориентируется, советую прочитать тексты этих лицензий, хоть это и непросто, или хотя бы обзорные статьи на русском, например, эту или эту.
Я же не буду подробно останавливаться на подробностях этих лицензий, так как про это уже много написано.

Идеализация Open Source:

Сама идея Open Source выглядит очень привлекательно и многие хотят использовать код из Open Source источников, так как он качественный (обычно) и бесплатный (обычно), а заодно экономит кучу времени.
Но безопасно ли это с юридической точки зрения?
Основная идея, которую я почерпнул из этой юридической лекции — это то, что использование Open Source возможно и выгодно, но сложно и опасно. По крайней мере это относится к использованию Open Source кода крупными компаниями, продающими свои продукты World wide. Сейчас объясню почему.

Весь код, из которого собирается продукт, можно разделить на 3 категории:
1. Собственный код, написанный внутри компании.
2. Лицензированные (купленные) сторонние библиотеки. Должен отметить, что даже среди Open Source можно найти код, за который можно заплатить, лицензировать его.
3. Нелицензированный Open source код или любой другой сторонний бесплатный код.

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

1. Если код находится внутри сторонней ОПЛАЧЕННОЙ библиотеки, то вся ответственность и судебный иск ляжет на плечи того, кто делал эту библиотеку, а не на ваши. Вы заплатили и можете спать спокойно.
2. Если же это ваш собственный код или open source код — ответчиком будет ваша компания.

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

В случае же open source кода всё немного запутаннее.

Например, программист Вася нашел в интернете Open Source реализацию классов клиента и сервера на C++ и решил, что их стоит взять, так как это сэкономит ему месяц работы.
Лицензия — MIT или BSD без изменений, то есть можно делать с кодом что хочешь. Вася спросил у менеджера и менеджер сказал «Подходит, берем». Всё скопипастили и всё прекрасно заработало.
А через полгода приходит иск от компании Microsoft о нарушении авторских прав!
Как такое может быть? Легко.
Например, кто-то взял эти исходники в Microsoft и выложил их, как Open Source. Стали ли от этого они Open Source? Нет конечно.
Или если кто-то накопипастил код из других источников с разными лицензиями в одну библиотеку и выложил ее, как Open Source под BSD лицензией. Какая реально лицензия у такого кода и кто автор? Тут даже юрист не разберется.
Или кто-то мог взять Open Source код с лицензией GPL, поменять его немного, и по недосмотру или злонамеренно поменять тип лицензии на MIT. Какая лицензия реально валидна после этого? Правильный ответ GPL. Надо ли говорить о последствиях, если в вашем секретном коде окажется код с GPL лицензией? Или если там окажется пункт про отчисления с продаж.

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

А теперь еще интереснее. В каждой стране свои законы об авторском праве и свои трактовки этих лицензий. Даже внутри Евросоюза нет единого закона. Например, если в лицензии написано, что код находится в Public Domain, то не спешите радоваться. В разных странах этот термин трактуется по-разному. И, например, в Финляндии автор такого кода может через несколько лет прийти и попросить процент с продаж, так как «код в Public Domain, но я все равно хочу процент». И суд скорее всего удовлетворит иск.
Так что, кроме знания лицензий и терминов, при работе с Open Source стоит знать еще и локальные законы, если вы работаете World wide. Кстати, наибольшее число исков по Open Source делам приходят из Америки (понятно почему) и Германии (не ожидал).

Вы можете подумать, что нет ничего страшного в таком судебном иске. На самом же деле, если истец докажет свою правоту, то вам запретят продавать продукт с «украденным» кодом до тех пор, пока спор не будет разрешен!
Представьте себе, что Вася нашел свой код в Windows, подал и выиграл иск и Microsoft обязана перестать продавать свою ОС до тех пор, пока не договорится с Васей. Миллионы долларов убытка каждый день плюс огромный удар по репутации (хе-хе), так что они будут готовы убитьозолотить Васю.

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

Что же в итоге получается?
Стоит ли использовать Open Source или нет?
Ответ, как ни странно — стоит! Слишком много готового отлаженного сложного кода можно взять из Open Source и это может сэкономить месяцы и даже годы работы.
Но нужно быть очень осторожным и дотошным в изучении всех нюансов лицензий и авторства. И помнить, что как только вы включили «свободный» код в свой проект — уже вы несете ответственность за соблюдение авторских прав в каждой строчке этого кода.

Мастер Йода рекомендует:  Оптимизация в GCC — ответы на вопросы викторины

Как заработать миллионы на открытом коде: от Red Hat до Nginx


В 2020 году IТ-компания F5 Networks приобрела российский проект с открытым исходным кодом Nginx за $670 млн. Эта сделка укладывается в новый тренд: сервисы с открытым исходным кодом превратились из альтруистичного способа создавать новые продукты в практичную бизнес-модель, ориентированную на получение прибыли.

До 2020 года компании, работающие по концепции open source (они открывали исходный код своих программ) провели только один крупный экзит (оценка стартапа рынком): в 1998 году провела IPO компания Red Hat. Проекты с открытым кодом — например, операционная система Linux — могли становиться крайне важным элементом множества систем, но практически не приносили прибыли владельцам.

Однако в прошлом году стало заметно, что open source стал способом вырастить миллиардный бизнес: Pivotal Software вышла на IPO, достигнув капитализации в $3,9 млрд в первый день торгов, Salesforce купила MuseSoft за $6,5 млрд. Знаковым событием стала покупка корпорацией IBM разработчика Red Hat за $34 млрд. Как компании изменили свой подход к разработке с открытым кодом, чтобы достичь миллиардной капитализации?

Немного истории

В 80-е годы прошлого века Ричард Столлман основал Free Software Foundation. Изначально идея была в том, чтобы программисты бесплатно делились своими разработками друг с другом. Никто не планировал коммерциализировать «открытый код». Однако все изменилось с созданием Red Hat.

Red Hat вышел на рынок в 1993 году с бесплатной операционной системой Red Hat Linux. Кстати, название Red Hat пришло от любимого головного убора основателя Марка Юинга. Основные деньги тогда зарабатывались на телефонной поддержке клиентов, и компания была довольно мелким игроком. Диски с Red Hat Linux стоили $29,95, а в интернете ПО и вовсе скачивалось бесплатно. Чтобы из маленькой рыбки на рынке превратиться в акулу — поставщика корпоративного ПО уровня Oracle, нужны были действия по увеличению прибыли в десятки раз в короткие сроки.

И вот в 2001 году в компанию пришел Пол Кормье, который предложил продавать расширенный «корпоративный» пакет Red Hat Linux и брать деньги в том числе за установку этого пакета и его техподдержку. Основное ПО в обычной версии по-прежнему оставалось бесплатным.

Это была первая поворотная точка в истории всех open source компаний. Rad Hat подала пример, как зарабатывать на открытом коде, сохраняя сообщество разработчиков-энтузиастов.

От Open Source к Open Core

С развитием современных инструментов разработки делать софт стало гораздо дешевле и быстрее. Многие компании стали чаще выбирать программирование силами собственных сотрудников, а не покупку готового программного обеспечения или аренду облачного сервиса. Это открыло для компаний, работающих в сегменте open source, новые возможности: они по сути поставляют «строительные блоки» для разработчиков, ядро разработки, Open Core. Программисты других компаний с помощью открытого исходного кода решают свои задачи. В результате, однако, распадается «сообщество свободных программистов»: направление проекта жестко задает компания, разработавшая продукт в открытых исходных кодах.

Например, компания Kong создает платформы с открытым исходным кодом и облачные сервисы управления и контроля программирования в корпорациях. Программное обеспечение Kong бесплатное, как и в классическом open source. Бизнес делается на enterprise-версии, которая лучше масштабируется, предоставляет аналитику по проекту и дает прочие функции, необходимые большим компаниям. Годовая лицензия стоит около $100 000.

Как работает бизнес-модель Kong? Сначала разработчики клиента интересуются этим ПО ради бесплатной версии с открытым кодом. Начинают устанавливать софт Kong везде, выстраивают на его базе большую часть разработки. В этот момент к техническому директору компании приходят менеджеры по продажам Kong. Они говорят: «Вы внедрили наш продукт вот здесь и здесь. Вам не хватает определенных функций, которых нет в бесплатной версии, но они есть в расширенной версии Enterprise». Тут технический директор и начинает задумываться о покупке платной версии.

На первый взгляд модель Kong такая же, как у Red Hat, которая еще в 2001 году начала продавать «корпоративную» версию операционной системы. Но главное отличие в том, что пользователи могли выбирать из большого количества альтернативных дистрибутивов Linux. Компания Red Hat не владела ключевой технологией: если ее вариант операционной системы не устраивал клиента, тот теоретически мог перейти на другую версию Linux.

А вот Kong полностью владеет своей технологией и ее разработкой. В мире просто не найдется значительного количества независимых программистов, которые разбираются в Kong настолько, чтобы создать копию ее корпоративного продукта, но при этом не работают в компании.

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

Open source 2.0

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

Чтобы привлечь внимание разработчиков, open source компаниям необходимо стать золотым стандартом. Они подчеркивают свою экспертность на митапах и конференциях для девелоперов. А те, попробовав бесплатную версию, сами не замечая, становятся амбассадорами выбранной технологии в своих компаниях, убеждая руководство купить подписку на «полный пакет».

Так действует все больше компаний. Проект Confluent разработал технологию с открытым кодом Apache Kafka, но ежегодно увеличивает подписку на ее расширенную версию в 3,5 раза. Это позволило ему привлечь $125 млн от Sequoia, Index Ventures и Benchmark.

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

Прагматики против идеалистов

Можно было бы погрустить, что в новом мире open source не осталось места для альтруизма. Однако в этой ситуации можно найти почву для оптимизма. Во-первых, на рынке закрепилась новая модель продажи софта. Во-вторых, она подходит только тем разработчикам, которые смогли сделать свои программы основой инфраструктуры большого числа компаний. А значит, подходит она далеко не всем: например, ее нельзя повторить, если клиент — конечный пользователь.

Даже компании, которые дошли до многомиллионной капитализации, продолжают заботиться о бесплатных пользователях. Например, главным условием российских основателей Nginx для нового владельца F5 стала открытость кода продукта. Стартап, начав как «бескорыстный» open source, пришел к бизнес-модели с платной enterprise-версией. Тем не менее российский продукт до сих пор бесплатно используют миллионы разработчиков и бизнесов по всему миру. При этом зарабатывает проект в основном на крупном платежеспособном бизнесе. Можно сказать, что крупный бизнес оплачивает возможность использования продукта всеми остальными.

Некоторые корпорации открывают внутренние разработки, что практически не встречалось в 90-х. Например, популярный среди разработчиков инструмент React использовался внутри корпорации Facebook. А Google создал открытую программную библиотеку Tensorflow, популярную у разработчиков сервисов с применением искусственного интеллекта. Не монетизируя открытый код напрямую, корпорации привлекают разработчиков, которые стремятся разрабатывать подобные продукты.

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

Что такое открытый исходный код и почему он важен для криптовалюты и открытого блокчейна


В своей статье Питер Ван Валькенбург, глава отдела исследований Coin Center, член совета директоров Zcash Foundation, объясняет, почему развитие программного обеспечения с открытым исходным кодом важно для построения доверительных отношений и обеспечения безопасности в блокчейн-сетях.

Компьютерный код, лежащий в основе всех крупных криптовалют и проектов открытого блокчейна, разрабатывается как ПО с открытым исходным кодом. Регуляторы и директивные органы, пытающиеся понять, что такое криптовалюты, но не знакомые с таким ПО, могут заблуждаться, считая, что эти системы разрабатываются (и должны разрабатываться) одной или несколькими коммерческими компаниями. Хотя многое известное программное обеспечение действительно разрабатывается подобным образом (например, Windows корпорации Microsoft или RDBMS компании Oracle), с проектами с открытым исходным кодом дела обстоят иначе, и это отличие может и должно формировать общественное мнение. ПО с открытым исходным кодом создаётся в сотрудничестве, бесплатно распространяется, публикуется открыто и развивается в качестве продукта сообщества, а не собственности одной компании или лица. В этом случае нет монополии, нет одной компании или индивидуума, которые бы создавали и продавали ПО, владели бы им. Точно так же, как нет единственной компании, владеющей сетью биткоина, не существует одной-единственной компании, производящей ПО, которое, функционируя на связанных в интернете компьютерах, образует эту сеть. Подобная децентрализация несёт некоторые фундаментальные блага, которые может быть тяжело понять людям, не знакомым с разработкой ПО. Чтобы лучше осознать мощь и характер открытого исходного кода, будет полезно получить некоторое представление об одном особенно успешном образце ПО с открытым исходным кодом. Речь идёт об операционной системе Linux.

Открытый исходный код повсюду

Трудно подсчитать, сколько раз за день вы пользуетесь Linux, ведь именно эта операционная система лежит в основе работы большинства серверов в интернете. Всякий раз, когда вы посещаете Facebook, Google, Pinterest, Википедию и тысячи других крупных сайтов, сервисы, которые предоставляют вам эти (такие разные) сайты, вы имеете дело с компьютерами, которые, скорее всего, работают на операционной системе Linux. Linux можно найти и гораздо ближе; скорее всего, он у вас под рукой. Скажем, операционная система Android-смартфонов основана на Linux. Если у вас есть Chromebook, то вы пользуетесь ноутбуком на основе Linux. Эта операционная система всё чаще используется в телевизорах, термостатах, мультимедийных системах в самолётах, автомобилях и т.д.

Почему это интересно? Потому что Linux — это не продукт одного программиста или даже группы программистов; в отличие от MacOS или Windows, его не разрабатывала одна или даже дюжина корпораций. У Linux есть тысячи соавторов. Как сообщила в 2015 году Linux Foundation (некоммерческая организация, способствующая открытому развитию операционной системы), приблизительно 14 000 разработчиков из более чем 1300 различных компаний внесли вклад в виде фрагментов программного кода. В одном лишь 2015 году в усовершенствовании кода впервые поучаствовали 2355 разработчиков. Таким образом, путём экстраполяции можно подсчитать, что к 2020-му свою лепту внесли приблизительно 18 000 человек, и это число будет расти.

В 1996 году автор книги «Собор и Базар» Эрик Рэймонд написал:

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

Преимущества открытого исходного кода

В своей книге Рэймонд рассказывает о том, что открытый исходный код представляет собой революционный метод создания технологий. Linux с тысячами независимых разработчиков, работающих в режиме публичного сотрудничества, служит примером модели открытого исходного кода. Криптовалюты следуют той же модели, но об этом мы поговорим ниже.

Рэймонд выделил несколько преимуществ модели открытого исходного кода. Ключевые в контексте нашей дискуссии — следующие:

  • Каждый достойный образец ПО начинается с удовлетворения личного желания разработчика. Мотивацией большинства разработчиков проектов с открытым исходным кодом служит желание лично использовать создаваемые продукты. Они не связаны контрактом, обязывающим их создать что-то для другого; у них есть личная потребность, которую они удовлетворяют. Таким образом, возникает качественно иная мотивация, порождающая детальное знание проблемы.
  • Хорошие программисты знают, что писать. Великие знают, что переписывать (и использовать повторно). Когда разработка осуществляется открыто, можно избежать избыточности, и проблематичные, усложнённые или излишние коды можно идентифицировать и упростить.
  • Когда вы теряете интерес к программе, то ваш последний долг по отношению к ней состоит в том, чтобы передать её в руки компетентного преемника. Люди приходят в проект с открытым исходным кодом и покидают его в зависимости от своих интересов и компетенции. Никто не застревает в работе над проектами, которые больше не интересны. Появляются свежие головы, предлагающие различные точки зрения на давние проблемы или новые перспективы развития.
  • Восприятие пользователей в качестве коллег-разработчиков — самый лёгкий путь к улучшению кода и эффективной отладке ПО. Многие пользователи открытого исходного кода помогают выявлять проблемы и даже предлагают решения. Грань между потребителем и производителем программ с открытым исходным кодом размыта: работа над ПО прозрачна, она ведётся на глазах у публики, и участие в процессе создания доступно всем.
  • При наличии достаточно большой базы бета-тестеров и разработчиков практически любая проблема будет быстро квалифицироваться, а её решение наверняка окажется для кого-то очевидным. Этот постулат назван Законом Линуса в честь Линуса Торвальдса, создателя ядра Linux, который долгое время оставался главным разработчиком этой операционной системы. Когда процесс разработки кода носит закрытый характер, разработчики рискуют пропустить слабое место или не заметить определённую ошибку. Разработка в среде опытных пользователей с уникальным видением повышает вероятность выявления и устранения багов, что делает ПО с открытым исходным кодом более безопасным и отказоустойчивым.

Результатом такой разработки становится очень надёжный программный код, созданный пользователями для пользователей. Цель состоит не в том, чтобы создать нечто, обогащающее компанию, которая производит и продаёт продукты, а, скорее, в том, чтобы решить проблему, достаточно распространённую, чтобы большое сообщество талантливых программистов с радостью вносило свой вклад. Люди, лишённые навыков программирования, получают от такой модели огромное благо. Бесплатное ПО словно материализуется из воздуха, им может свободно воспользоваться каждый, и оно получает обновления до тех пор, пока пользователи экспертного уровня тоже заинтересованы в его эксплуатации.

Закон и свободное ПО

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

Некоторые лицензии включают требования, что производные программного обеспечения должны выпускаться на таких же условиях. Благодаря подобной схеме база открытого исходного кода растёт и распространяется. Это явление известно как лицензия свободного программного обеспечения, или LGPL-3 — меньшая стандартная общественная лицензия.

Открытый исходный код в криптовалютах и токен-проектах

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

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

Клиент Bitcoin Core — результат работы более чем 450 независимых разработчиков, которые в общей сложности внесли свой вклад в развитие кода более 15 000 раз. ПО доступно для свободного использования и модификации в соответствии с лицензией свободного программного обеспечения MIT, а вся история разработки доступна для обозрения в публичном репозитории на Github — облачном сервисе, позволяющем любому создать аккаунт, загрузить новый код и отслеживать изменения. Если созданный вами репозиторий открыт для всеобщего обозрения, комментариев и предложений об изменениях, то вам даже не нужно платить за аккаунт Github.

Публичный репозиторий также отслеживает так называемые форки оригинального клиента. Форк создаёт клон изначального ПО, который затем можно модифицировать с той или иной целью, не изменяя изначальное хранилище. Разработчики без ограничений совершают форки для репозитория Bitcoin Core на Github, чтобы создать либо специфические приложения, совместимые с биткоином (например, кошелёк для смартфонов), либо новую криптовалюту, которая перестаёт быть совместимой с сетью биткоина и подразумевает создание новой криптовалютной сети (например, так было с лайткоином или Zcash). На сегодняшний день оригинальный клиент Bitcoin Core пережил форк более 10 000 раз, и появляющиеся новые репозитории демонстрируют, что создание производных продуктов продолжается.

На эфириум сейчас приходится как минимум 121 репозиторий, каждый из которых фокусируется на определённом аспекте проекта (например, языках программирования для написания смарт-контрактов, графических браузерах для взаимодействия конечного пользователя с сетью эфириума, совместимых клиентах для участия в работе сети и т.д.). Есть не менее восьми проектов, направленных на разработку совместимых с эфириумом клиентов, а над наиболее популярными клиентами (go-ethereum и Parity) трудятся сотни независимых разработчиков. Код эфириума и его полная история, как и код, а также история биткоина, доступны для публичного обозрения на Github и в других сетевых хранилищах, и все коды выпускаются в соответствии с лицензией LGPL-3, требующей выпускать все будущие производные разработки с такой же лицензией.

Даже недавние проекты, реализованные по инициативе коммерческих стартапов, демонстрируют приверженность кредо открытого исходного кода. Zcash Company разрабатывает протокол Zcash посредством публичного репозитория. Несколько ведущих разработчиков не работают на компанию, а специально созданная некоммерческая организация призвана следить за тем, чтобы постепенно произошёл переход от разработки, осуществляемой компанией, к разработке силами сообщества. База исходного кода Zcash выпускается с лицензией Массачусетского технологического института. Protocol labs, разработчик Filecoin, намерен создать аналогичную открытую модель и уже протестировал её в своём проекте IPFS, работая с кодом в открытых репозиториях и выпуская его с лицензией MIT.

Почему открытый исходный код важен

Криптовалюты и открытые блокчейны способны обеспечить функционал, который был бы регулируемым, если бы его источником была одна-единственная корпорация. Централизованные эмитенты цифровой валюты, такие как Liberty Reserve или E-gold, представляли собой финансовые сервисы и должны были регистрироваться в Управлении Министерства финансов США по борьбе с финансовыми преступлениями, а также получать лицензию, позволяющую переводить деньги, в каждом штате. Если такие токены будут продвигаться на рынке для привлечения инвесторов, они могут быть приравнены к ценным бумагам, и в таком случае потребуется регистрация в Комиссии по ценным бумагам и биржам США. Эти ограничения имеют смысл, поскольку централизованные сервисы связаны с риском того, что сторона, находящаяся в центре всей схемы, не сможет выполнить свои обещания, адекватно протестировав продукт и сделав его безопасным.

Однако технологии вроде биткоина способны предложить аналогичный функционал, будучи открытыми и никому не принадлежащими сетями. Здесь нет никакой корпорации. К этим сетям присоединяются пользователи, а открытое программное обеспечение стимулирует их стремление к сотрудничеству. В конечном счёте все участники приходят к согласию относительно каждого фрагмента данных, необходимых для создания валюты. Децентрализация держится на двух столпах: открытых механизмах консенсуса и программном обеспечении с открытым исходным кодом. Если бы код не был открытым, то как бы участники (не знакомые друг с другом люди в интернете) сумели бы понять систему, к которой они присоединяются, и довериться ей?

На самом деле токен-проекты, основанные на патентованном коде, могут оказаться просто централизованными сервисами, которые прячутся за профессиональным сленгом и «абракадаброй блокчейна». Однако у «истинных» проектов код, создающий децентрализованную сеть, позволяющий участникам доверять друг другу, иметь общую мотивацию и наказывать мошенников, и сам по себе децентрализован. Его разрабатывают у всех на глазах сотни энтузиастов, он доступен всем в мире для использования и модификации и совершенно независим от корпоративных интересов.


Open Source — это круто, 10 доводов

Open Source с каждым днем завоевывает все больше внимания. Многие крупные компании отдают предпочтение Open Source — ПО, и нисколько не жалеют о своем выборе. Сегодня я приведу вам 10 доводов того, почему Open Source — это круто.

Мастер Йода рекомендует:  Лучшие инструменты и советы начинающему C++ программисту

Термин «Open Source» был создан как альтернатива термину «Free software». Для свободного программного обеспечения открытый исходный код является обязательным, что вытекает из самого определении «Free software»

Open Source программное обеспечение завоевывает рынок

Open Source это бесплатно

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

Open Source это безопасность

Открытое программное обеспечение разрабатывается энтузиастами со всего мира. Многие из них сами пользуются этим ПО, и поэтому они не допустят, чтобы какой-нибудь «умник» добавил в программу кусок вредоносного кода. Открытое ПО считается одним из самых безопасных, потому, что какие-либо вирусы детектятся практически сиюсекундно.

Open Source это качество

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

Открытость

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

Большое сообщество

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

Нет пиратству

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

Кроссплатформенность

В силу того, что опенсорсный софт развивается и разрабатывается целым сообществом, велика вероятность, что то или иное программное обеспечение будет портировано на все известные платформы (чего не скажешь о закрытом), и это ли не счастье? Пользоваться любимой программой и под Windows, и под Linux, и даже под Mac.

Конфиденциальность

А вас пугает мысль, что в любой момент доступ к вашей личной информации могут получить сторонние люди? Да? Тогда это еще одна причина, почему вам стоило бы посмотреть в сторону открытого программного обеспечения. Само сообщество, которое разрабатывает такое ПО, очень уважительно относится к чужому личному пространству. Именно по этой причине многие пользователи предпочитают использование дистрибутивов Linux, заместо всемирно известных Windows и Mac.

Децентрализованность

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

Быстрые фиксы ошибок

Если вдруг, по каким-то причинам, в Open Source ПО обнаружится ошибка, будьте уверены, что исправления последуют незамедлительно. Вероятнее всего в тот же день участники огромного сообщества, все же, предложат версию с фиксами, и вам нужно будет просто обновиться.

Обновления

У Open Source-ПО обновления выходят если не по расписанию, то очень часто. Разработчики со всего мира постоянно и непрерывно улучшают определенный продукт, чтобы в дальнейшем пользователи не испытывали проблем с отсутствием тех или иных функций.


Выводы

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

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

Обсуждение: работа интернета держится на open source — надежна ли такая модель

На прошлой неделе в Санта-Кларе (Калифорния) проходила большая конференция по Open Source базам данных — Percona Live. Я набегал туда наездами, поддерживая маркетинговые действия Яндекса, где они представляли ClickHouse (к слову, о ClickHouse в Штатах никто практически не знал; теперь узнали получше).

Но это преамбула. Мне понравилось выступление Пола Дикса из InfluxData по поводу того, как зарабатывать на Open Source. Ниже тезисы в моем вольном изложении, а в конце исходное видео.

Основной мотив в том, что Open Source — это не бизнес-модель, а механизм распространения ПО и способ взаимодействия разработчиков. Open Source разработка всегда субсидируется. Поэтому строить бизнес-модели на Open Source несколько противоестественно.

Существуют и используются следующие способы монетизации:
* Консалтинг и Professional Services
* Платная поддержка
* Встраиваемый компонент в чужих коммерческих продуктов (OEM)
* Коммерческие расширения для использования в продакшене
* Open Core — открытое ядро (вокруг которого закрытые утилиты)
* SaaS

Парадокс состоит в том, что большинство этих способов находятся в противоречии с целями выпуска продукта в Open Source. Пройдемся поподробнее.

Консалтинг. Основная проблема в том, что вместо разработки, инженерам приходится заниматься консалтингом. Но если консальтинговая компания занята собственно консалтингом менее 90% рабочего времени, то это становится экономически нерентабельным или неконкурентным. А кто же будет продолжать развивать Open Source? Поэтому компаниям-разработчикам Open Source невыгодно заниматься консалтингом, и наоборот. Это должны быть разные компании.

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

Встраиваемый компонент (OEM). Бизнес модель состоит в том, что кто-то строит продукт, встраивая в него Open Source компонент с GPL лицензией, и продавая этот продукт, отчисляет какие-то проценты разработчику Open Source компанента. Здесь противоречие в том, что за бесплатное ПО конечный пользователь неявным образом вынужден платить. Для Open Source компании проблема еще в том, что монетизация может быть отложена на неопределенный срок, так как в цикл включается время на построение продукта кем-то другим.

Коммерческие расширения для использования в продакшене. Речь о всяких системах управления, мониторинга, безопасности и т.д., которые предлагаются к продукту Open Source дополнительно за деньги. Наверное, это единственно «чистая» модель в которой нет противоречия. И многие сервисные компании вокруг Open Source продукта более-менее успешно занимаются таким бизнесом.

Open Core. Здесь трудность в том, что тяжело находить баланс между тем, что должно быть бесплатным Open Source, и тем за что надо брать деньги. Чтобы больше заработать, надо как можно больше предлагать за деньги. Но как же тогда идеология Open Source?

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

Решение Пол не предлагает. Но по собственному опыту предполагает, что будут выживать модели, предлагающие разные коммерческие расширения вокруг Open Source. По моему опыту общения с разными компаниями, строящими сервисы вокруг Open Source, это действительно так. Модель чистой поддержки или консалтинга выживает с трудом, только в пакте с дополнительными платными компонентами.

Обсуждение: работа интернета держится на open source — надежна ли такая модель

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

«Для меня это было неожиданностью. Модель open-source интуитивно кажется неправильной», — такие признания можно нередко услышать от CIO предприятий, которые все же решились установить у себя ПО open-source.

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

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

миф первый: «все дело в цене»

Одно из наиболее широко известных достоинств open source – это цена. Загрузил программное обеспечение, установил – и не заплатил ни копейки. Такова теория. Но на практике выясняется, что для многих компаний, использующих open source, цена (равно как и ее отсутствие) — вопрос несущественный. «Дело не в дешевизне, — утверждают CIO таких предприятий. — Дело в эффективности работы — и за нее мы вполне готовы заплатить. Нам нужно надежное программное обеспечение, которое оправдывает наши ожидания и удовлетворяет нашим требованиям».

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

Кроме того, приложения на базе Linux работают значительно быстрее, чем при использовании ОС семейства Windows. На практике это подчас означает, что несмотря на то, что та или иная компания увеличивает штат, количество представительств и объем используемых приложений вдвое, необходимости покупать новые серверы не возникает. Опросы CIO компаний, перешедших на эту ОС, свидетельствуют: Linux увеличивает мощности на 50-75% Несмотря на эти убедительные данные, стоит подчеркнуть, что приверженность некоторых CIO open source – не слепая вера фанатиков. Они не стали бы переходить на open source, если бы эта модель была дороже, чем проприетарное программное обеспечение. «Solaris – мощная коммерческая операционная система. Мы предпочли бы ее open source, если бы она не обходилась так дорого», — признаются некоторые ИТ руководители. С другой стороны, разумеется, хотя стоимость – это важный фактор принятия решения, но серьезные компании не могут рисковать, выбирая худшую модель ради экономии. Они даже не приняли бы к рассмотрению вариант open source, не будь он сравним с коммерческими предложениями — а в некоторых случаях и лучше их.

миф второй: «ложная экономия»


Программное обеспечение open source многие сравнивают с бесплатными бонусами к товарам в «магазине на диване», купленным в ходе промо-акции. И, разумеется, отсутствие платы за приобретение лицензионного программного обеспечения отчасти вынужденно компенсируется затратами на обучение и техническое обслуживание. С другой стороны, поборники open source приводят в качестве аргумента «за» снижение зависимости от вендора, то есть ситуации, когда поставщики заставляют пользователей постоянно переходить на новые версии или платить за дополнительную поддержку. Большинство пользователей open source отмечают «чистые сбережения» — и зачастую весьма ощутимые.

Во многих компаниях сегодня полным ходом идет переключение на open source. К этому шагу их подталкивают аналитические данные, которые позволяют заключить, что такой переход позволит сэкономить десятки миллионов долларов в течение следующих 5 лет.

Достаточно общей схемой миграции на новое ПО в такой ситуации оказывается следующий подход. В тех случаях, когда первостепенной является надежность, используются приложения, которые запускаются на высокотехнологичных отказоустойчивых системах. В то же время большая часть не столь критических приложений вполне может работать на пуле серверов из менее дорогостоящих машин. Каждый компьютер снабжен собственной open source базой данных MySQL, синхронизированной, например, с решением GoldenGate, где есть информация о правилах, ценах и т.д., хранящаяся в отказоустойчивой системе.

Большое достоинство open source заключается в том, что предельные затраты по существу отсутствуют, так как open source, как правило, не требует дополнительных лицензий по мере того, как расширяется внедрение. В результате цена за сделку стремительно падает при добавлении новых систем. В некоторых случаях для компаний сегментов SMB и Enterprise речь может идти о восьмидесяти процентной экономии.

миф третий: «никакой поддержки»

Гари Хейн, аналитик в отделе технологических консультаций Burton Group, утверждает, что техническая поддержка – это главная забота
потенциального пользователя open source. «Кому вы звоните, если что-то идет не так? Поставщику, разумеется. А что делать в случае с open source? Перефразируя Кэрролловскую Червонную Королеву, можно сказать, что нельзя отрубить голову, когда нет самой головы. »

На практике ситуация не столь однозначна. Как указывает Хейн, у большинства проектов open-source есть большая организация разработчиков, списки электронных адресов, архивы и базы данных поддержки – все в открытом доступе и бесплатно. Это, конечно, прекрасно, но проблема в том, что не существует единого источника информации. Простой вопрос может вылиться в многосложные и противоречивые ответы в разных источниках.

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

На деле пользователи программного обеспечения open-source обычно оказываются удовлетворены организацией поддержки. Количество ресурсов по всему миру, доступных для приложений open source, так велико, что при желании в любое время дня и ночи можно получить помощь, связаться с разработчиком или скачать патч. К некоторым open-source приложениям имеется в наличии поддержка, предоставляемая изначальными разработчиками. /* Для любителей «гламура» есть еще и возможность заказать платную поддержку у производителей open source софта или у сторонних компаний. – прим. ред. */

миф четвертый: «минное поле»

Существует огромное количество open source лицензий. Объяснять CIO, как ими пользоваться и что из этого следует – отличный бизнес для юристов. Тревоги CIO в основном сосредоточены вокруг последствий использования кода, право на которое они не могут подтвердить, отмечают специалисты в области интеллектуальной собственности. «Даже если у вас есть бумажка, подтверждающая ваши права собственности на Бруклинский мост – это еще не значит, что он на самом деле принадлежит вам».

Для многих пользователей выходом являются компенсации. Некоторые компании объявляют, что будут возмещать убытки и защищать своих клиентов от судебных процессов по авторскому праву и посягательству на патент. Ряд поставщиков — включая HP, Red Hat и Novell — также предлагают разные варианты компенсаций.

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

миф пятый: open source не подходит для критически важных приложений

Трудно найти область, где бесперебойная работа приложений была бы более критична, чем в банковской сфере. Системы финансовых операций должны постоянно работать. И точка.

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

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

Едва ли найдется лучший аргумент в полемике со скептиками, полагающими, что open source не применим для бизнес-критичных приложений, чем практика использования таких решений в банковской сфере.

миф шестой: open source не годятся для рабочих ПК

Немало CIO обратились к базам данных MySQL еще несколько лет назад, как правило, в момент, когда в компаниях собирались создать банки данных. Нередко это происходит параллельно с попытками внедрить Linux для небольших и некритических приложений.

Переход к критическим приложениям стал весьма распространенной практикой использования open-source в прошлом году, когда ряд поставщиков представили новые линейки ПО, работающего на базе Linux. В результате, например в сегменте логистики, производительность работы ИТ департаментов некоторых компаний увеличилась в 10-15 раз (!)

Как же обстоит дело с рабочими ПК? Даже приблизительный подсчет, проведенный аналитиками, показал, что стоимость одного полностью оборудованного средствами Microsoft (разумеется, лицензионными) рабочего места составляет в среднем более полутора тысяч долларов. Стоимость же рабочего компьютера с Linux и средствами open-source, составляет всего лишь половину от этой суммы. Кроме того, работать стало проще. Это очень важный результат, поскольку по-прежнему немало людей думает, что использовать подобное ПО сложнее, чем решения Microsoft.

Сотрудники, в частности, могут с любого компьютера получить доступ ко всем сервисам и услугам, которые есть на их собственном рабочем месте. И, наконец, что также немаловажно, поддержка ИТ стала значительно легче. Не возникает проблем с пользователями, которые устанавливают свои персональные программы на рабочих станциях.

Многие ИТ-игроки, даже такие крупные, как Siemens Business Services или правительство Китая, также убеждены в том, что Linux вполне готов для применения на рабочих местах. Siemens, например, утверждает, что они проводили продолжительные тесты с нетехническими сотрудниками, которые позволили им заключить, что Linux теперь созрел для использования в настольных компьютерах. Тесты нарушили ожидания компании – еще недавно в Siemens даже не предполагали увидеть Linux столь заметным игроком на рынке систем для рабочих компьютеров.

Подходит ли open source любой организации? В конце концов, это вопрос отношения. Споры вокруг программного обеспечения open source еще долго не утихнут. Это вопрос не технологий, а бизнеса.

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

Урок, который нам преподнес Интернет, состоит в том, что стандартизация лучше «дифференцирования». Что хорошего в том, чтобы делать все по- другому? Что хорошего в том, чтобы делать все как все? Как показало последнее десятилетие, стандартизация с проприетарным программным обеспечением имеет свои недостатки: пробелы в вопросах безопасности, огромные денежные взносы за лицензии и не самая приятная необходимость полагаться на одного поставщика. В офисах по всему миру, возможно, начинается новая эпоха стандартизации open-source, призванная вынести всем этим недостаткам исторический приговор.

Добавить комментарий