LXF83:SPIKESOURCE

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

Версия 18:12, 9 марта 2008

ПРИВИВКА 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 параметрам… Перед нами – масш- табная проблема, поэтому техноло- гический процесс невозможен без автоматизации.

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

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 будет везде, где нужны будут программы.