Распределенная разработка программного обеспечения

Размещено на http://www.allbest.ru/

Содержание

Введение

1. Распределенная разработка программного обеспечения

1.1 Ключевое отличие распределенной разработки. Достоинства и недостатки

1.2 Концептуальное решение и выбор типа разработки

2. Особенности программного обеспечения с открытым исходным кодом

2.1. Идея и развитие Open Source

2.2. Наиболее важные Open Source - проекты

Заключение

Список использованной литературы



Введение

распределенная разработка программное обеспечение

Распределенная разработка программного обеспечения сегодня стала нормой: современные средства связи позволяют объединять людей, находящихся по разные стороны океана, а минимизация издержек при разработке в развивающихся странах привлекает заказчиков из стран Европы и США. Кроме того, специалистов нужной квалификации может просто не оказаться «на месте», и тогда взаимодействие с удаленными рабочими группами или внешними подрядчиками окажется просто необходимым.

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

Термин «open source» был создан вместе с определением в 1998 году Эриком Реймондом и Брюсом Перенсом, которые утверждали, что термин free software (свободное программное обеспечение) в английском языке неоднозначен и смущает многих коммерческих предпринимателей.

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

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



1 Распределенная разработка программного обеспечения

1.1 Ключевое отличие распределенной разработки. Достоинства и недостатки

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

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

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

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

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

Какое непосредственное влияние оказывает уровень взаимодействия разработчиков на выполнение проекта? Наиболее очевидным параметром является время завершения проекта. Если одним специалистам регулярно приходится ждать других для решения каких-либо вопросов, то задержки неизбежны. Они возникают и при обычной, нераспределенной, разработке, но бывают значительно меньшими по времени. Опрос разработчиков нескольких десятков компаний из Великобритании и Германии, проведенный исследовательским подразделением Lucent Technologies, дал следующие результаты. При работе в пределах одного здания каждый реципиент сталкивался в среднем с 2,1 задержки в месяц при продолжительности каждой 0,9 рабочего дня. При распределенной разработке возникало 1,9 задержки в месяц, но их средняя продолжительность составляла уже 2,1 дня. Итак, разница в количестве задержек при локальной и распределенной разработке несущественна, тогда как разница в их продолжительности достаточно ощутима.

Примерно те же результаты получены при анализе запросов на изменение проекта в целом. В среднем при локальной разработке на одно существенное изменение в проекте (исправление ошибок или добавление новых функций) требовалось 5 дней (с начала реальной работы до внесения последних изменений в код -- это называется «рабочим интервалом»). Если в создании программных продуктов участвовали несколько удаленных коллективов, такой интервал увеличивался до 12,7 дня (то есть более чем в два с половиной раза). Ситуация с полным интервалом (временем с момента поступления запроса на изменение до внесения последнего изменения в код; этот интервал несколько больше рабочего, поскольку включает в себя время, необходимое для анализа запроса, назначение приоритета и т.п.) аналогична: 20,5 дня против 12,7.

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

· Число занятых в проекте разработчиков. Логично предположить, что при увеличении числа разработчиков растет количество и продолжительность задержек.

· Распределение изменений по удаленным объектам. Чем больше количество модулей системы, затрагиваемых изменениями (особенно если эти модули разрабатываются в разных местах), тем более вероятны задержки.

· Масштаб изменений. Чем больше изменений вносится, тем больше вероятность задержек.

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

· Серьезность изменений. Данный фактор можно рассматривать как аналог приоритетности изменений. Считается, что чем более высокий приоритет назначен изменению (например, при исправлении критически важных ошибок), тем быстрее оно будет проведено. Предполагается, что внесение изменений в рамках распределенной разработки потребует больше времени, чем при работе всей команды в одном месте.

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

Для дальнейшего анализа служит графическая модель Гаусса (рис. 1).

Рисунок 1 - Графическая модель Гаусса.

Узлы здесь -- исследуемые переменные факторы, а дуги -- частная корреляция между ними. Частная корреляция между переменными отличается от обычной выборочной корреляции тем, что показывает величину взаимосвязи между переменными при фиксированных значениях других переменных, напрямую влияющих на выбранные. Толщина линии определяет значимость корреляции. В отличие от обычной корреляции (взаимозависимости величин), частная корреляция используется, если нельзя достоверно утверждать, что величины связаны между собой напрямую, а не через некоторую третью величину или группу величин. В таких случаях рассматривается так называемая «частная корреляция двух величин при неизменных значениях остальных величин». Переменные, не связанные между собой напрямую, являются независимыми при фиксированных значениях переменных, с которыми они связаны.

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

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

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

В целом опрос свидетельствует о том, что координация и взаимодействие сильно страдают при распределенной разработке.

Во-первых, значительно проще разрабатывать и осуществлять изменения в многомодульном проекте, если все модули создаются и поддерживаются в одном месте. У разработчиков появляется возможность оперативно получать всю необходимую информацию «из первых рук».

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

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

1.2 Концептуальное решение и выбор типа разработки

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

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

Распределенная разработка объективно является более сложным методом, которым, тем не менее, пользуются все чаще и чаще. Руководитель проекта должен принимать во внимание следующие факторы:

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

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

- Бюджет. Если денежный вопрос является одним из наиболее существенных в проекте, распределенная разработка может дать преимущества. Экономия средств достигается не только при выполнении аутсорсинга программных проектов в Индии, России или государствах Юго-Восточной Азии, но и при работе с удаленными коллективами внутри страны.

- Модульность проекта. Абсолютно независимых модулей в проекте не бывает, но можно легко отличить условно неделимые проекты от полностью модульных. Разработку основной системы можно поручить удаленным коллективам, а взаимодействие с ней модулей регулировать четко определенными программными интерфейсами. Чем большей модульностью отличается проект, тем легче его выполнять удаленно и тем больше причин выбрать распределенную разработку.

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

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

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

- Кадровый потенциал. Этот фактор является тяжело формализуемым, поскольку зависит от уровня зарплаты, доступности кадров на местном рынке, сложности и уникальности поставленных задач и т.п.



2 Особенности программного обеспечения с открытым исходным кодом

2.1 Идея и развитие Open Source

Open-source software -- программное обеспечение с открытым исходным кодом. Исходные коды открытых программ выпускаются либо как общественное достояние, либо на условиях «свободных» лицензий. Свободная лицензия позволяет использовать исходный код программы для своих нужд с минимальными ограничениями, не противоречащими определению OpenSource.org. Таким ограничением может быть требование ссылаться на предыдущих создателей или требование сохранять свойство открытости при дальнейшем распространении той же самой или модифицированной открытой программы. В некоторых случаях эти ограничения очень малы, в других достаточно распространять ПО вместе с исходным кодом и текстом лицензии, не изменяя её.

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

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

Существуют также программы, по мнению некоторых имеющие открытый исходный код, но не являющиеся свободными, например, UnRAR, распаковщик RAR-архивов. Его исходный код находится в открытом доступе, но лицензия запрещает использовать его для создания RAR-совместимых архиваторов. Так же существует целый класс программ, называемых коммерческим ПОс открытым исходным кодом или Open Core, которые используют термин «Open Source» применительно к несвободному программному обеспечению.

Идея, которая стоит за понятием "Open Source", чрезвычайно проста. Идея заключается в том, что программист или пользователь может, например, с помощью Internet, получить какую-нибудь программу вместе с ее исходным текстом, изменить ее, исправить ошибки и передать другим пользователям. Однако Open Sourse не означает только лишь доступность исходного текста. Существует документ (Open Source Definition), который регламентирует все стороны лицензирования ПО, которое попадает под определение Open Source. Из этого документа можно выбрать его основные положения, которые сводятся к следующему:

1. Свободная дистрибуция. Лицензия не может содержать никаких ограничений на продажу или бесплатное распространение программного продукта или его части. Кроме того, в лицензии не может оговариваться вознаграждение за продажу или распространение продукта.

2. Исходный текст должен быть включен в состав программного продукта и разрешено его распространение.

3. Целостность авторского исходного текста. Лицензия может ограничивать распространение измененного авторского исходного текста только в том случае, если в ней предусмотрено разрешение на распространение patch-файлов с исходным текстом для изменения продукта при компиляции.

4. Лицензия не должна наносить ущерб другим программам, которые распространяются вместе с лицензируемым продуктом. В частности, она не должна требовать, чтобы эти программы также были Open Source.

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

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

Мир программирования очень большой, и концепция Open Source связана со всеми его направлениями, начиная от написания операционных систем и заканчивая конечными продуктами для обычных пользователей, к числу которых можно отнести и CMS (система управления содержимым). Известно, что продукты с открытым кодом - это зачастую красивые и грамотные разработки, производимые внутри исследовательских лабораторий крупных компаний, которым выгодно вкладывать деньги в продукты, которые позволяют увеличить их продажи и укрепить влияние на рынке. Что касается CMS - сюда еще не пришли гиганты рынка и многим небольшим группам приходится вести разработки самостоятельно.

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

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

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

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

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

2.2 Наиболее важные Open Source - проекты

В 1980 году на смену эре Open Source пришла эра закрытого ПО. Многим казалось, что уже ничего нового не произойдет и эта эра останется жить вечно. Но уже в 1984 году Ричардом Столлманом был основам проект GNU (GNU'sNotUnix). Это была первая серьезная попытка возрождения Open Source.

Прошло еще немного времени и на арену "компьютерных разборок" вышел Линус Торвальдс, который в 1992 году обнародовал ядро разработанной им операционной системы Linux. С этого времени началось второе возрождение Open Source. Именно Linux выступила как яркий выразитель реализации идей "open" и "free". Размеры данного проекта не имеют равных в истории разработки ПО: в нем приняли участие примерно 40 000 человек. Нужно принять во внимание то, что формально не существует организации, которая стоит во главе этого проекта и его участники работают совершенно безвозмездно, выдавая с каждым днем новые версии. В настоящее время Linux является второй по популярности после Windows серверной операционной системой. При этом Linux не приносит сверхприбылей. Это говорит о стремительном взлете ОС Linux за сравнительно короткий период времени. Такой стремительный взлет данной операционной системы обусловлен, в первую очередь, открытостью исходного кода.

Сравнительно за короткое время много ведущих компаний сделали большой шаг в сторону модели открытого ПО. Заслуживает внимания, в первую очередь, компания Inprise, с легкой руки которой компилятор С++ 5.5 получил статус бесплатного программного продукта (хотя пока остается загадкой - будет ли опубликован сам исходный код компилятора). Продукт С++ Builder и Borland Delphi перенесены на Linux в рамках проекта Kylix. Бесплатная Linux-версия JBuilder на базе Borland Java уже доступна для загрузки. Компания Samsung выпустила первый электронный органайзер Yopy на базе Linux. Еще один немаловажный проект с точки зрения OpenSource выпустила компания Novell - NDS (Novell Directory Services) eDirectory for Linux. По словам многих аналитиков, поддержка Linux Novell'ом будет способствовать активизации применения Linux на предприятиях. Не остаются в стороне и производители аппаратных средств. Так, например, корпорация Sony использует компьютерные системы на платформе Linux при разработке приложений для своей игровой консоли нового поколения PlayStation2. Производитель персональных телевизоров TiVo выпустила видеомагнитофон под маркой Philips со специальным ПО на базе Linux. И это только меньшая часть разрабатываемых и уже воплощенных в жизнь проектов.

За истечением 2011 года, в сфере Open Source можно выделить ряд наиболее важных проектов:

1. Hadoop. Используется и/или поддерживается почти каждым предприятием. Естественно Yahoo, который и запустил проект, использует его, но он также используется и Amazon, IBM, Twitter, Facebook, а также другими компаниями, которые работают с Big Data.

Hadoop - не новый проект, но в этом году он стал почти промышленным стандартом. В этом отношении он чем-то похож на Linux. В 2011 году EMC, Oracle и даже Microsoft объявили о коммерческой поддержке или производстве продуктов, которые работают с Hadoop, а Yahoo отложил HortonWorks, чтобы сфокусироваться на Hadoop. Легче перечислить те компании, которые не работают с Hadoop, чем те, которые пользуются данным фреймворком.

2. Git. Говоря о повсеместном использовании, нельзя не вспомнить о Git. Хобби Линуса Торвальдса не только улучшило Linux, но и увеличило популярность FOSS проектов. Если ты работаешь над каким-либо проектом с открытым ходом есть большая вероятность того, что ты будешь использовать Git, а не другие DVCS.

Git - не просто популярный инструмент, это база для одного из наиболее популярных веб-проектов для open source разработчиков: GitHub. Им также пользуются Gitorious, SourceForge.net, Google Code Hosting, а также почти каждая глобальная платформа FOSS проектов.

3. Cassandra. Cassandra - это масштабная, распределенная и отказоустойчивая база данных, которая происходит от систем Amazon Dynamo и Google Big Table. Cassandra используется IBM, Netflix, Digg, Facebook, Rackspace и прочими.

4. Libre Office. Команда Libre Office проделала большую работу в поддержании OpenOffice.org после приобретения ресурса Sun. Пока Apache работает на поддержание OpenOffice.org, Libre Office спланировал и разработал проект. Этот проект производит релиз за релизом не только с учетом новых функций, но и надежных обновлений для главных версий, которые являются необходимыми для организаций, которые используют их в своей работе.

Для тех, кто интересуется внедрением Linux на рабочем месте, LibreOffice является критическим проектом. Для пользователей, которые хотят отойти от использования Microsoft Office, но все же иметь совместимость с форматом Office, необходим Libre Office.

Но Libre Office сделал скачок не только в техническом плане, но и как организация он продемонстрировал впечатляющую скорость развития.

5. Open Stack. Лишь некоторые проекты показали такой большой скачок в развитии, как OpenStack. "Облачная операционная система", которую запустили в RackSpace, уже собрала под свое крыло 144 компании, включая SUSE и Canonical.

Open Stack разработан для того, чтобы обеспечить компоненты, которые необходимы любой организации для развертывания частного или публичного облака: вычисление, хранение объектов, сервисы изображений, управление личными данными и GUI панель.

В настоящее время ты не увидишь повсеместного распространения Open Stack, но это определенно важный для облака проект с исходным открытым кодом.

Необходимо упомянуть и Eucalyptus. В то время как Open Stack получает огромное количество времени и поддержки со стороны индустрии, Eucalyptus уже настроен на промышленное распространение и совместим с Amazon Web Services. И это не является конечной точкой в распространении облачных платформ - для некоторых компаний здесь есть место, поэтому мы предполагаем, что Eucalyptus будет на плаву еще очень долгое время.

6. Nginx. Apache (более точно, Apache HTTP ServerProject) все еще правит интернетом. Apache является наиболее распространенным сервером. Но 2011 год стал феноменальным и для Nginx, альтернативному серверу, который специализируется на обработке HTTP и проксировании.

Nginx достиг своего пика в этом году с долей рынка в 8,85% по результатам опроса Netcraft Server Survey. Согласно профилю на портале Royal Pingdom, использование Nginx выросло на 300%.

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

Он используется такими сайтами, как Dropbox, WordPress.com, Facebook и 25% наиболее посещаемых сайтов мира.

7. jQuery. Каждый веб-разработчик пользуется jQuery, в этом нет сомнений. jQuery - это Java Script библиотека, которая необычайно популярна. К слову, она является наиболее используемой Java Script библиотекой в мире.

Если вы работаете с Java Script, вы наверняка сталкивались с jQuery в этом году. В последнее время ее часто критикуют, а некоторые товарищи даже отказываются работать с ней, но jQuery все еще ключевая программа для многих разработчиков.

8. Node.js. Еще одна составляющая, связанная с Java Script, попала в список 10 проектов, и ты наверняка подумал, что веб-разработка была очень важной в этом году. Node.js работает на движке V8 Java Script от Google, и разработан для "упрощенной разработки масштабных сетевых программ".

Node.js является прорывом в индустрии открытого кода. Этот проект спонсируется Joyent и используется LinkedIn и 37Signals, Rdio, Yahoo, и GitHub.

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

Puppet - "движок автоматического администрирования", первоначально разработанный для систем Linux и UNIX. Он может быть использован для выполнения административных задач на двух, двадцати или двух тысячах компьютерах (и, возможно, даже больше). Puppet неуклонно улучшался на протяжении последних лет, но в этом году он сделал прорыв, предложив Puppet Enterprise. Ему доверяют (в форме инвестиций) такие гиганты как Google Ventures, Cisco и VMware.

10. Linux. Является фундаментом для облачных сервисов, а также доминирует в списке 500 мировых суперкомпьютеров.

Google, Netflix, Facebook, Twitter, многочисленные правительственные агентства, бизнес организации и образовательные учреждения используют критические сервисы Linux.

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



Заключение

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

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

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

Условия распространения программного обеспечения с открытыми кодами должны отвечать ряду критериев:

- Свободное повторное распространение;

- Исходный код;

- Производные продукты;

- Сохранность авторского исходного кода;

- Отсутствие пристрастий по отношению к отдельным лицам или группам лиц;

- Отсутствие пристрастий к областям применения и деятельности;

- Распространение лицензии;

- Лицензия не должна специализироваться для каких-либо продуктов;

- Лицензия не должна ограничивать другое программное обеспечение;

- Лицензия должна быть нейтральной по отношению к технологии.

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



Список использованной литературы

1. http://www.osp.ru/os/2005/12/380643/

2. http://linuxrsp.ru/artic/opensource.html

3. http://preal.ru/varieties/open-source-sistemy/

4. http://www.xakep.ru/58015/

5. http://www.linuxcenter.ru/OSSCD/OSSCD/index2.html

Размещено на Allbest.ru