LXF83:SPIKESOURCE

Материал из Linuxformat.

ПРИВИВКА OPENSOURCE: «УКОЛОЛСЯ И ПОШЕЛ!»

Налицо стопки денег. Взаправду. Сертифицированные, интегрированные стеки открытого исходного кода. Если предприятие собирается использовать Linux, их понадобится много, а SpikeSource, под руководством Ким Полиз [Kim Polese] и Муругана Пала [Murugan Pal], их предоставляет.

Вообразите, что вы сидите на званом обеде, а рядом с вами – Майк Сондерс. И вдруг, дежурно поболтав о семье и о работе, Майк разражается комментарием по поводу Firefox, и оказывается, что вы оба – ярые поклонники открытого кода, к вящему потрясению остальных гостей. Майк рассказывает вам, насколько продвинулась современная технология, и намекает, что Linux в его нынешнем составе может сэкономить тысячи в вашем бизнесе. Но для вас это – просто хобби, и вы пока не используете его в своем бизнесе по следующей причине: кто будет интегрировать все ПО и настраивать его? Кто все проверит и сертифицирует? В конце концов, ребята из MySQL или Apache этим заниматься не будут. А кто будет осуществлять поддержку вашего программного обеспечения и сопровождение?

И тогда Майк вам поведает – если, конечно, не отвлечется на приставку Nintendo в хозяйской гостиной – что вам нужна фирма SpikeSource из Редвуд-Сити (Redwood City), Калифорния: она продает «готовые решения для бизнеса», облегчающие предприятиям задачу перехода на Open Source, и привлекла к себе большой интерес не только благодаря своим важным и интригующим услугам, но и благодаря тому, что ее поддерживают люди с громкими именами – например, Брайан Белендорф [Brian Behlendorf] и Тим О’Рейли [Tim O’Reilly]. Выстоит ли их бизнес-модель? Будет ли от нее отдача для сообщества? И вообще, что такого важного в тестировании? Пол Хадсон встретился с руководителем фирмы, Ким Полиз [Kim Polese] (той самой, которая придумала название Java – а может, это и не она придумала) и техническим директором Муруганом Палом [Murugan Pal] (на фото – в центре), чтобы во всем разобраться.

Linux Format: Итак, SpikeSource. Чем вы занимаетесь?

Ким Полиз (КП): Муруган и Рей [Лейн, Ray Lane, со-основатель SpikeSource] весной 2003 года разглядели насущную потребность, вызванную ростом популярности открытых программ: управление ими – и, в частности, организация взаимодействия – становилось все более дорогостоящим для предприятий. Муруган понял, что для решения этой проблемы необходима новая технология: автоматизированные тесты, которые обеспечивают и нам, и предприятию независимость от поставщика и дают клиенту выбор и гибкость. Целью было дать потребителю широкий выбор операционных систем, баз данных, серверов приложений, выбора языков и многие десятки компонентов, которые в то время стали появляться.

И тогда Муруган принялся создавать команду, а команда создала рабочую среду, и сегодня мы проводим 26 000 тестов по шести операционным системам, шести языковым средам исполнения, почти 80 компонентам, 189 файлам конфигурации, 273 параметрам… Перед нами – масштабная проблема, поэтому технологический процесс невозможен без автоматизации.

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

Ким Полиз [Kim Polese] и Муруган Пал [Murugan Pal]

LXF: Последние три года о SpikeSource было не слыхать. Полагаю, вы занимались хождением по инстанциям.

Mуруган Пал (МП): Точно. С мая 2003 года и до тех пор, пока Ким не вошла в Совет директоров в августе 2004, мы работали в [венчурной фирме] Kleiner Perkins и многие попросту не знали, чем мы занимаемся. А мы создавали эту нашу тестовую среду, а затем собрали команду архитекторов или основателей других компаний.

LXF: Вы позиционируете себя как лидера тестирования Open Source. Это несколько неожиданно!

КП: Не уверена, что мы это делаем. Мы не можем объявить себя лидерами тестирования Open Source, потому что тестирование требует участия коммитеров, разработчиков и проч., которые на самом деле собираются и объединяют свои знания.

MП: Мы называем это совместным тестированием. Это единственный способ достичь широкого охвата. В основном это – производное от концепции участия в архитектуре, которую проповедует Тим O’Рейли. Нам нужно, чтобы к нам приходили люди и принимали участие в тестировании вместе с нами, потому что сами мы этого сделать не можем. Как мы можем пойти и клонировать 30 лет работы и 15 000 сотрудников, работающих в Microsoft? Единственный способ – работать совместно с сообществом. Недавно к нам пришли ребята из числа работающих над тестами для Perl, и сказали: «Эй, у нас тут 900 тестов, можно, мы передадим их вам, а вы их проведете?» Еще один пришел к нам и сказал: «Я написал тесты для Perl. Если вы решите поделиться этими технологиями с потребителями, может, вы и их туда включите?» Вот именно это нам и надо.

КП: Мы не разгуливаем повсюду, объявляя себя лидерами…

LXF: А на web-сайте именно так.

MП: Я думаю, наша цель – привлечь участников.

КП: Нет, мы не…мы очень болезненно относимся к тому, что нас…

LXF: Называют лидером? Или что вы сами себя называете лидером?

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

LXF: Один из слайдов на презентации Ким, где я присутствовал, вообще-то меня запутал. Вы показали временные рамки релизов – по-моему, это были Red Hat, Apache, MySQL, Ajax и что-то еще, и я подумал: «Это бессмысленно». Ajax не тот продукт, у которого есть релизы, Red Hat уже следит за Apache и MySQL. И я хочу знать, где же вы входите в это уравнение, потому что релизы MySQL никого не волнуют, все думают о релизах Red Hat.

КП: Целью того слайда было продемонстрировать разнообразие релизов и всевозможных компонентов, и что предприятия остаются один на один с постоянной необходимостью интеграции, им приходится иметь дело с новыми релизами и заплатками. А формализованной структуры, как, например, в Microsoft, где можно собрать все заплатки, обновить их и затем предоставить, просто нет.

LXF: Ну, есть ведь Red Hat Enterprise Linux: вы платите за нее, и компания дает вам все продукты и все заплатки целых семь лет, верно?

МП: На самом деле ключевой момент здесь в том, что Red Hat осуществляет поддержку определенных продуктов, как, например, Apache, а потребители хотят получить разные программы, им нужен Geronimo для работы в их среде, и чтобы JBoss тоже работал в их среде. Red Hat этого не поддерживает, по крайней мере, не в виде интеграции.

Во-вторых, есть такая вещь, как библиотеки классов, как, например, Struts и Hibernate и микроядро Spring, на сегодняшний день официально они не продвигаются, хотя потребители ими уже пользуются. Есть несколько фирм, которые, как нам известно, используют 38 компонентов этих библиотек классов; любопытно, что наш Spike Asset Manager (это всего-навсего простой скрипт Python, инвентаризующий все компоненты с открытым кодом), когда его запускаешь для всех этих штук, обнаруживает в этих компонентах шестикратный избыток динамических библиотек, дублирующих друг друга.

Это – проблема DLL hell [ада динамических библиотек, – прим. пер.]. Вы даже не знаете, что там внутри – даже у тех версий, которые поддерживаются официально – поэтому мы их просматриваем и удаляем избыточные копии. Еще вы говорили об Ajax или Red Hat, и в том-то и красота всей модели в целом – в ней присутствует гибкость, а люди хотят сами использовать разные программы.

LXF: Red Hat может сказать, что они не поддерживают программы типа Geronimo потому, что они узко целевые. Сможете ли вы конкурировать с ними по таким базовым продуктам, как MySQL?

МП: Прежде всего, это не вопрос конкуренции. Это – вопрос сосуществования, а не замещения. Для нас Red Hat – важный партнер, есть немало серверов, работающих на Red Hat, они лидируют на рынке, и для нас очень важно партнерство с ними.

В то же время, MySQL и Red Hat… если у них уже сложились отношения, то для нас это хорошо, потому что потребителю сначала нужен Apache, а потом нужно, чтобы вместе с ним работали JK2, Tomcat, Connector/J и MySQL. И потребителям вовсе не нужны отдельные базы данных по ошибкам, им нужен один человек, которому можно позвонить. Если у потребителей уже сложились отношения с Red Hat и MySQL, и, может быть, со SpikeSource по поводу всех этих «длиннохвостых» компонентов, то они позвонят в SpikeSource, а мы будем полагаться на поддержку Red Hat, существующую для MySQL, и сами свяжемся с ними, чтобы решить вопрос.

LXF: А если кто-то из ваших клиентов отправится в Oracle, приобретет у них Oracle, Red Hat Enterprise Linux, а заодно и поддержку всего этого, а потом позвонит им и скажет: «Здравствуйте, Oracle, мой сервер не работает. У меня стоит Geronimo от SpikeSource, можете мне помочь?» А Oracle ответит: «Звоните в SpikeSource, а не нам». И, мне кажется, вряд ли кому понравится такое услышать.

МП: Видите ли, я сам из Oracle, и этого навидался. Давайте забудем пока об Open Source, и Geronimo с Tomcat. Вернемся к тому, что у нас было в 1996 году. У нас была операционная система Solaris, сервер Netscape Enterprise Server, потом еще дополнительные модули NSAP, Oracle PL/SQL, соединение с базой данных Oracle, база данных, работающая на Solaris или HP-UX. Если эта цепочка ломалась, нельзя было позвонить в одно какое-то место. Эта взаимосвязь по-прежнему остается проблемой, и в открытом коде, и в коммерческих программах. Но кое в чем открытый код дает потребителям больше возможностей: если инженер потребителя умнее или способнее наших инженеров, угадайте, что произойдет? Они сами устранят неисправность. И они сообщат нам об этом, а мы это протестируем и подтвердим. Вот почему в тестировании настолько важно участие.

LXF: А какие части вашего стека приложений действительно с открытым кодом?

КП: Все, полностью.

LXF: Java – часть вашего стека?

КП: Мы сертифицируем по Java, как и по Perl, Python, PHP...

LXF: Но это – часть вашего профессионального ядра?

МП: Если вы установите наше основное ПО на сегодня, для Java VM есть отдельная лицензия, потому что мы должны соблюдать права Sun. Но на все остальные части, как уже упоминала Ким, мы придерживаемся модели сквозного лицензирования. Это означает, что если мы имеем дело с Apache Software License (ASL), или BSD, или GPL, то мы их сохраняем.

LXF: Вашим клиентам не нужен юрист, чтобы просматривать все индивидуальные лицензии на наличие нарушений?

КП: Сейчас есть фирмы, например, Black Duck и другие, которые берут на себя эту задачу. Это не наше дело, но мы с ними сотрудничаем. Например, у нас есть инструмент asset manager, который мы интегрировали с калькулятором лицензий Black Duck.

LXF: Вы пытаетесь представиться сообществу. Какой поддержки вы ожидаете?

КП: Участия в тестировании. Мы ищем тех, кто будет участвовать в наших тестах и вносить в них свой вклад.

LXF: То есть вы хотите, чтобы люди давали свои результаты SpikeSource?

МП: Да, но взаимно. Как говорит Ким, это всегда встречное движение. Если посмотреть на тестирование, как на процесс, то имеется концепция, называемая тестирование с охватом всего кода: вы проводите тест и проверяете, сколько строк кода, или ветвей, или патчей было протестировано. Для C, C++ и Java такие инструменты есть, а для PHP такого не было. И поэтому один из инженеров [в SpikeSource] применил инструмент для охвата PHP, и открыл его исходный код; его можно найти на SourceForge. Мы списались с Энди Гутманом [Andi Gutmans] и Зеевом Сураски [Zeev Suraski], им это понравилось.

Теперь, когда этот инструмент создан, мы уже начали работу по системному применению с нашими партнерами по тестированию. Есть несколько фирм, с которыми мы работаем. Они протестировали phpMyAdmin и phpPgAdmin, это инструменты администрирования баз данных на PHP, которые раньше никогда не тестировались. Для проверки мы сгенерировали 1900 тестов, и результаты вернулись в проект. И этот инструмент Spike PHPCoverage, или написанный нами инструмент asset manager… все, что мы предлагаем, будет, как говорит Ким, с открытым исходным кодом.

LXF: Ваш совет директоров похож на издание Кто есть Кто: Брайан Белендорф, Митчелл Бейкер [Mitchell Baker], Тим О’Рейли… А что каждый из них дает?

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

МП: Ким была очень практична. Консультационный совет был задуман ею; она сразу же создала его, как только стала руководителем, и это очень способствовало нашему успеху. Мы им говорили одно: «Мы хотим, чтобы вы использовали SpikeSource, чтобы осуществить вашу страсть ускорить продвижение открытого кода, любым способом, каким пожелаете». Ларри [Розен, Larry Rosen] мог способствовать в лицензировании, Стив Вебер [Steve Weber] – с социологической точки зрения. Наша цель – помочь им реализовать свою страсть в нашей фирме.

LXF: Я думаю, люди видят венчурных капиталистов, и большие имена, проходящие в связи с фирмой, чей адрес пишется «точка-com», и слова типа «продукт», и думают: «Хмм, опять это слово, небось начался новый бум дот-комов». Что бы вы сказали для их успокоения?

КП: Я бы заподозрила то же самое, не будь реальной проблемы, для решения которой у нас имеется инструментарий. Иными словами, очень многие «дот-комовцы» [от англ. Dot-com –.com, – прим. пер.] в конце девяностых занимались созданием продуктов, которые на самом деле не решали особых проблем. В нашем случае Муруган и Рей определили проблему и поняли, что для ее решения нужен новый подход, так что с точки зрения технологии и того, как мы работаем с сообществом и строим фирму, по-настоящему основанную на архитектуре вовлечения… именно этим мы намерены заниматься.

МП: А в доказательство приведу такой вот простой пример. Sleepycat, которые выпускают Berkeley DB обратились к нам и дали нам 9 000 тестов. И мы тратим нашу электроэнергию и пропускную способность нашей сети для подтверждения работы на нескольких платформах, чтобы гарантировать взаимодействие. Вот где основной момент. Наше оправдание и наш приговор – помогать людям в этом процессе – в отличие от доткомовских компаний, наша модель – поставка программ в качестве сервиса, [так, чтобы] люди могли загрузить это интегрированное ПО.

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

КП: Если мы можем сэкономить фирме деньги, и предоставить им все преимущества и гибкость открытого кода без всякого риска; и если мы можем работать с сообществом и содействовать проектам вроде JetSpeed, Struts и Postgres, и всем прочим, в получении более широкой сертификации на многочисленных платформах; публиковать тесты, сделав их достоянием всего сообщества, чтобы все могли извлечь из них пользу, то для меня именно это и называется успешной работой. Мы будем решать настоящие проблемы с точки зрения бизнеса, и, надеюсь, поможем сообществу в создании более богатой среды для всех.

LXF: Итак, вот что вы думаете в идеале: кто-то приобретает Red Hat Enterprise Linux, потом приходит в SpikeSource – и ему дают завершенный вариант. Вы говорите, что не зависите от поставщиков, но насколько вы заинтересованы в продвижении исключительно открытого ПО? Я заметил, что почти половина ваших машин работает под Windows. Говорите ли вы: «Apache, MySQL, PHP, Windows?» Или просеиваете ПО в поиске решения с открытым кодом?

КП: Мы действительно независимы от поставщиков – если наш клиент скажет, что хочет использовать, скажем, SugarCRM на Windows, мы не будем против. Если он захочет интегрировать Apache и JBoss с Oracle, мы тоже не будем против. Мы сертифицируем любое сочетание компонентов, если оно популярно и удобно для предприятия и в мире открытого кода.

МП: Но в то же время в идеале наши инженеры работают под Linux и используют OpenOffice.org. Мы работаем на Samba, Postfix и сервере электронной почты Courier, и это экономит наши средства. Потому что в конце концов речь идет о гибкости по отношению к клиенту, но и об экономии денег тоже.

LXF: A как вам видится будущее продуктов Open Source? Кроме, конечно, того, что SpikeSource станет огромной фирмой!

КП: А что мы имеем в виду под продуктом?

LXF: Ну, точнее, как вам видится превращение открытого ПО в продукт в будущем?

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

А еще нам видится, что открытый код будет повсюду. Взгляните на новое поколение приложений с открытым кодом, например, Sugar, JasperReports, Alfresco... почти каждый день появляется что-то новенькое. На мой взгляд, любое мыслимое приложение будет так или иначе представлено в виде открытого ПО. Так что будет выбор. Нам представляется, что открытый код проникнет не только в крупные организации: от этого выиграют и малые и средние предприятия, я полагаю, это будет способствовать развитию экономики, мы увидим, как открытое ПО встраивается в новые устройства, оборудование… в моем представлении Open Source будет везде, где нужны будут программы.