LXF83:SPIKESOURCE
|
|
|
ПРИВИВКА 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 будет везде, где нужны будут программы. LXF
