Open source в новом свете

Открытое программное обеспечение теперь не только для фанатов

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

Бретт МакЛафлин, автор и редактор, O'Reilly Media, Inc.

Бретт МакЛафлин (Brett McLaughlin) работает с компьютерами со времен Logo (помните маленький треугольник?). За последние несколько лет он стал одним из наиболее известных авторов и программистов сообщества по технологиям Java и XML. Он работал в Nextel Communications над реализацией сложных корпоративных систем, в Lutris Technologies - фактически над созданием серверов приложений, - а с недавнего времени - в O'Reilly Media, Inc., где продолжает писать и редактировать важные и содержательные книги. Его готовящаяся книга "Head Rush Ajax" продолжает отмеченный наградами инновационный подход "Вперед головой" применительно к изучению Ajax. Его недавняя книга Java 1.5 Tiger: Заметки разработчика является первой доступной книгой по новейшей версии технологии Java, а его классическая книга Java и XML остается одной из наиболее авторитетных работ по применению технологий XML в языке Java.



02.09.2011

Open source в 2010 году

Прежде чем вы решите закрыть эту статью, я хотел бы сказать, что в ней вы не столкнетесь с какой-либо пропагандой сторонников Open source. Напротив, я попытаюсь развеять мифы, вызванные такого рода отношением. Главное, что вам надо понять: выбор в пользу открытого ПО – это больше не выбор «все или ничего». Другими словами, в этой статье вас никто не будет убеждать выбросить на свалку Windows® и установить GNU Linux® или же навсегда отвернуться от Adobe или Apple.

Эта статья преследует более скромные цели – показать вам, что открытое программное обеспечение может решать определенный круг проблем, в том числе, возможно, и ваших. Итак, независимо от того, столкнулись ли вы с проблемами в Internet Explorer®, подыскиваете ли удобную интегрированную среду разработки, устали ли платить за PhotoShop или же просто хотите получать поддержку системы в реальном времени – открытое программное обеспечение вполне может стать частью вашей рабочей среды.

Гибридный подход – почти всегда наилучший

Давайте предположим, что вы используете открытое программное обеспечение не только по идейным соображениям. Это не означает, что вы исключаете возможность использования Open source, – у вас есть практическая заинтересованность в рассмотрении альтернативных решений проблем, с которыми вы сталкиваетесь. С учетом этого вы, вероятно, не станете использовать открытое ПО "на все 100". Некоторая, а возможно, даже большая часть вашего программного обеспечения останется "закрытой". Это может быть коммерческое ПО, либо у вас просто может не быть доступа к исходному коду. Замечательно. Нет ничего плохого в том, чтобы совместно использовать как открытое, так и закрытое программное обеспечение.

На практике гибридный подход к открытому ПО - это оптимальный выбор. Представим себе, что в вашей рабочей среде есть пара проблем. Предположим, например, что вы работаете в Windows и терпеть не можете Internet Explorer. Если вы начнете использовать вместо него Firefox, это будет являться гибридным подходом к открытому ПО (если вы не в курсе, Firefox является самой что ни на есть Open Source-разработкой). Получается, что вы используете коммерческое ПО, а именно Windows, совместно с открытым ПО, а именно Firefox. Вы берете все лучшее из обоих миров и не обязаны целиком оставаться в каком-либо одном из них.

Вы сами решаете, как сделать выбор между открытым и закрытым программным обеспечением. Вы можете не использовать ничего, кроме Firefox. Ну и отлично. С другой стороны, вы можете последовать подходу компании Ernie Ball, основанной Стерлингом Боллом (Sterling Ball) (ссылку на историю о компании Ernie Ball вы можете найти в разделе Ресурсы) – в которой используется почти исключительно открытое программное обеспечение. В обоих случаях, а также во всех промежуточных вариантах, вы делаете выбор в зависимости от ваших потребностей, и это прекрасно.

Open source не означает "только для разработчиков"

Являясь разработчиком открытых проектов на протяжении почти 10 лет, я прекрасно знаю, что большинство Open source-сообществ традиционно являются закрытыми и даже снобистскими. Задайте вопрос, который был кем-то задан восемь месяцев назад, и над вами посмеются – "Читай архивы, чайник"! Оставив запрос на доработку какой-либо функции, вы можете получить ответ наподобие "Хватит жаловаться, возьми и исправь это сам. Это открытый код". Это ужасно высокомерные, программистские подходы к open source.

К счастью, большинство проектов с таким отношением либо исчезли вовсе, либо сильно изменились. Даже за небольшую грубость разработчики могут быть отстранены или вовсе исключены из проекта. Сегодня, в 2010 году, большинство Open source-проектов не только имеют обширные пользовательские форумы, патрулируемые разработчиками, которые могут дать ответы на вопросы, но и интегрированы с сервисами Facebook, Twitter и LinkedIn, выступающими в качестве дополнительных средств взаимодействия. Системы отслеживания ошибок стали привычной составляющей проектов, поэтому вы можете оставить заявку на доработку функциональности или сообщение о найденной ошибке, не боясь негативной реакции. Лучшие проекты поощряют такую обратную связь, поскольку она помогает развивать и усовершенствовать проект.

В качестве примера можно привести XML-процессор Xalan-J, который содержит страницу с подробными инструкциями по обработке ошибок (рисунок 1).

Рисунок 1. Xalan-J содержит понятную страницу с подробной информацией о том, как сообщить о проблеме
Рисунок 1. Xalan-J содержит понятную страницу с подробной информацией о том, как сообщить о проблеме

Здесь имеются не только инструкции, но и призванный помочь вам форум пользователей. Несмотря на то, что на этой странице вам советуют попытаться исправить проблему, стоит отметить, что по своей природе код Xalan-J является весьма низкоуровневым. Однако на данной странице присутствует информация о том, как вы можете послать сообщение об ошибке, используя JIRA – полноценный API для обработки сообщений об обнаруженных ошибках (рисунок 2). Другими словами, вам не приходится иметь дело со сложным текстовым интерфейсом и запутанными инструкциями. Процедуры отправки сообщений об ошибках и запросов на доработку функциональности документированы и легко доступны для понимания пользователей.

Рисунок 2. JIRA имеет надежную систему обработки ошибок, полностью открытую и доступную пользователям
Рисунок 2. JIRA имеет надежную систему обработки ошибок, полностью открытую и доступную пользователям

Сообщество – хорошая вещь

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

Хотя это звучит просто и даже слишком идеалистически, из таких списков рассылки и сайтов поддержки формируется сообщество. Вы можете найти людей, которых бы вы никогда не встретили и которые могут дать вам или принять от вас совет по поводу определенных ситуаций, возникающих при работе с программным продуктом. Вновь возвращаясь к ранее упомянутой истории компании Ernie Ball, отметим, что опыт Стерлинга Болла по работе с открытым кодом не просто улучшил его бизнес, – он заставил его почувствовать желание рассказать другим людям, попадающим в такие же ситуации, о том, как он столкнулся с реальной проблемой и решил ее. В результате многие другие компании пробуют использовать различные варианты решений Стерлинга Болла.

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


Open source ПО является открытым

Я стараюсь избегать умных заглавий книг, разделов в этой статье, чего угодно – но здесь просто необходимо сказать одну вещь: слово "Open" в названии Open source не является лишним или малозначимым. Да, давайте предположим, что у вас есть менеджеры и корпоративные интересы; первый раздел этой статьи нужно подробно им пересказать.

Но раз уж вы заглядываете на сайт IBM® developerWorks, я предположу другое: по меньшей мере вы обладаете менталитетом разработчика. Может, вы и не пишете столько кода, сколько вам хотелось бы, но вы мыслите как разработчик. Это хорошо. Здесь open source сияет еще ярче. Когда вы освоите гибридный подход и войдете в сообщество, вам останется решить более технические проблемы, и подход open source здесь весьма уместен.

Самодокументирование часто запаздывает, но оно полезно

Сначала плохие новости: известно, что разработчики на редкость лениво относятся к документированию своего кода. Это означает, что если вы намерены углубиться в Xalan-J, Firefox или в ваш любимый проект на Sourceforge.net, вам не всегда удастся отыскать по-настоящему хорошую документацию (ссылки на все эти проекты вы можете найти в разделе Ресурсы). Не будет ничего удивительного, если вы обнаружите метод под названием initParser() с крайне несодержательным комментарием "инициализация парсера". Едва ли это вам что-то даст.

Однако чем более развит проект и его код, тем лучше может оказаться его документация. Взгляните на проект JDOM, которому уже несколько лет (раздел Resources). Это открытый API-интерфейс для синтаксического разбора, более дружелюбный к пользователю, чем SAX или DOM. В действительности JDOM используют множество компаний – от NASA до Sun Microsystems (сейчас Oracle). Часть этих пользователей появилась благодаря его хорошо документированному API-интерфейсу. Например, в листинге 1 приведен код лишь одного из методов интерфейса Element.

Листинг 1. Пример внутренней документации JDOM
/** * This protected constructor is provided in order to support an Element * subclass that wants full control over variable initialization. It * intentionally leaves all instance variables null, allowing a lightweight * subclass implementation. The subclass is responsible for ensuring all the * get and set methods on Element behave as documented. * <p> * When implementing an Element subclass which doesn't require full control * over variable initialization, be aware that simply calling super() (or * letting the compiler add the implicit super() call) will not initialize * the instance variables which will cause many of the methods to throw a * NullPointerException. Therefore, the constructor for these subclasses * should call one of the public constructors so variable initialization is * handled automatically. */
protected Element() { }

Для разработчика это чрезвычайно полезно. Здесь все понятно, и использовать этот класс становится на порядок проще. И, разумеется, многие языки программирования, включая Java™, позволяют превратить такую документацию исходного кода в более удобные для использования формы. На рисунке 3 показана JavaDoc-страница для интерфейса Element, сгенерированная непосредственно из вышеприведенной документации исходного кода.

Рисунок 3. JavaDoc-страница – визуальное представление документации исходного кода
Рисунок 3. JavaDoc-страница – визуальное представление документации исходного кода

Большие сообщества – большой штат поддержки

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

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

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

В результате этого процесса сообщество пользователей перерастает в сообщество поддержки. Растущие группы заинтересованных участников дают ответы на многие вопросы, хотя многим из них не платят за это, и они даже не связаны с базой исходного кода. Например, взгляните на форум проекта Eclipse для новичков (раздел Ресурсы). Это среда Open source-разработчиков. Пробегитесь по сообщениям форума, и вы удивитесь, как много ответов на поставленные вопросы, причем ответов вполне основательных, дается людьми, у которых даже нет электронной почты в домене Eclipse.org. И это не хитрые парни из IBM. То, что вы видите – это то, как open source сообщество быстро становится сообществом поддержки. Это не коммерческое программное обеспечение, не так ли?

Можете ли вы отправить электронное письмо прямо в Microsoft?

Да, это удар ниже пояса. Тем не менее надо признать: чем больше компания, тем ей сложнее обеспечивать квалифицированную поддержку. Когда вы в последний раз чувствовали, что могли бы получить персональное письмо, в котором бы содержалось решение вашей проблемы с Excel® или Mac OS X? Хотя иногда такое случается, зачастую это является больше рекламой, нежели реальной помощью – это неправильно. И хотя вы безусловно можете приобрести контракт на поддержку, на практике это лотерея, исход которой зависит от того, кто ответит на ваш звонок.

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

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

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


Открытое программное обеспечение – итеративный подход

Вам наверняка часто приходится слышать термин "итерация". Его особенно любят в кругу разработчиков программного обеспечения. В отношении открытого ПО слово итерация используется в широком смысле для обозначения тенденции к частым выпускам версий. На практике основная идея открытого ПО такова: выпускай рано, выпускай часто. Так что вы легко можете обнаружить 15 или 20 релизов между главными версиями (релиз 2.0, 2.1, 2.1.1, 2.1.2, 2.2 и т. д., пока, наконец, не выйдет версия 3.0).

Нет никаких оснований предполагать, что процесс разработки коммерческого ПО также не является итеративным. Просто эти итерации часто скрыты от большинства обычных пользователей. Даже такие продукты, как Windows и Mac OS X, хотя они и часто обновляются, маскируют эти обновления, которые выглядят как скромные незаметные пиктограммы или свернутые окошки в нижней части экрана. Почему? Потому что для большинства коммерческих продуктов модификация воспринимается как исправление ошибок. Чем больше версий необходимо выпустить, тем больше ошибок необходимо исправить.

Для открытого программного обеспечения верно обратное. Поскольку код открыт, то о возможных ошибках может знать каждый. Просто зарегистрируйтесь в списке пользователей JDOM, Xalan-J, Eclipse или Firefox. Ошибки не являются тайной. Подключите к JIRA любой проект на ваш выбор. Каким будет результат? Частые релизы и исправления, устраняющие эти ошибки. Что здесь прятать, верно? И эти частые релизы дают вам – пользователю –определенные приятные преимущества.

Вы управляете запросами на добавление функциональности

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

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

Наконец, частые выпуски версий означают частые улучшения. Устранение ошибок – это улучшение, но также является улучшением и новая функциональность. И поскольку разработка является открытой, вы оказываете большое влияние на нее. В проекте JDOM (соавтором и активным участником которого я был) большинство основных изменений были сделаны в ответ на запросы пользователей. Переход к версии, содержащей более богатый интерфейс поддержки, был выполнен по инициативе пользователя, не имеющего "официального" отношения к проекту. Он просто был его участником. Eclipse в значительной степени управляется умными программистами, которые приходят с новыми пользователями проекта.

Открытое ПО подстраивается под вас

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

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


Заключение

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

Чего не разъясняет такого рода пропаганда, так это реальных преимуществ открытого программного обеспечения. Если открытое ПО использовать разумно (это менее обидный вариант выражения "Не используйте открытое ПО везде и всегда!"), оно может снизить затраты и в некоторых случаях реально расширить функциональность. Как уже говорилось, Firefox является самым очевидным примером для большинства обычных пользователей: мало кто устанавливает Firefox только потому, что является приверженцем Open source. Просто Firefox действительно отличный браузер, имеющий больше расширений, чем все остальные браузеры вместе взятые. Почему? Да потому что этот продукт поддерживается активным, энергичным сообществом.

Возможно, лучшим аргументом в пользу применения вами открытого ПО в гибридной среде остается сама компания IBM (да, эта статья опубликована на Web-сайте IBM, но дело не в этом). Кажется, IBM неплохо зарабатывает на своих коммерческих предложениях, но в то же время у нее большой список открытого программного обеспечения, начиная от пожертвований в фонд Apache и заканчивая Eclipse и другими продуктами. Использовать открытое ПО тогда, когда в этом есть смысл, – вот подход, который я рекомендую вам.

Может быть, вам не нравится Gimp и лучший выбор для вас – это PhotoShop. Может быть, синхронизированные через Safari закладки на вашем рабочем столе и на iPhone действительно являются лучшим решением. Это замечательно. Просто не отказывайтесь от других Open source продуктов, руководствуясь лишь недальновидным возмущением (эта фраза по своей патетике достойна описываемого действия). Если вам нужны быстрые циклы обновления и самые последние функции, присмотритесь к открытым альтернативам. Если вы хотите получать поддержку, не выкидывая десятки тысяч долларов в год, узнайте, что может предложить вам открытое ПО. И что бы вы ни делали, будьте в курсе. Хороший выбор требует хорошей осведомленности. Мы все будем счастливее. И дайте нам знать, какое именно Open source-предложение вы выбираете, а от какого отказываетесь, и почему. До встречи в онлайне.

Ресурсы

Научиться

Получить продукты и технологии

  • Eclipse – одна из лучших интегрированных сред разработки, имеющая расширяемую модульную архитектуру. И что самое главное – полностью бесплатная.
  • Xalan-J – XML-процессор с открытым кодом, в состав которого входят Open source-парсеры и прочие инструменты.
  • JDOM – API-интерфейс с открытым кодом, разработанный как альтернатива существующим API. Это пример подхода Open source в его лучшем виде: если что-то не работает, исправьте это.
  • Попробуйте Mozilla Firefox – лучший в своем классе Web-браузер, с которого лучше всего начать знакомство с надежным свободным программным обеспечением.

Обсудить

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Профиль создается, когда вы первый раз заходите в developerWorks. Информация в вашем профиле (имя, страна / регион, название компании) отображается для всех пользователей и будет сопровождать любой опубликованный вами контент пока вы специально не укажите скрыть название вашей компании. Вы можете обновить ваш IBM аккаунт в любое время.

Вся введенная информация защищена.

Выберите имя, которое будет отображаться на экране



При первом входе в developerWorks для Вас будет создан профиль и Вам нужно будет выбрать Отображаемое имя. Оно будет выводиться рядом с контентом, опубликованным Вами в developerWorks.

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Вся введенная информация защищена.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Open source, Linux
ArticleID=755547
ArticleTitle=Open source в новом свете
publish-date=09022011