В 2011 году Николь Салливан и я представили CSS Lint, первое инструментальное средство для CSS с качественным кодом. Последние две недели мы занимались разработкой кода, словно одержимые, пытаясь создать приложение, которое было бы полезным для конечных пользователей и легко поддавалось модификации. Ни один из нас не имел опыта запуска проекта с открытым исходным кодом. Мы многому научились в процессе создания данного продукта.

Изображение предоставлено: opensourceway.

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

Каковы ваши цели?

В наши дни, кажется, что любой, кто закончил создание фрагмента кода тут же выкладывает его на GitHub с лицензией открытого кода и говорит: “Я сделал его доступным для изучения”. Смысл создания открытого исходного кода заключается не только в том, чтобы код был свободно доступен для других. Прежде чем объявить всему миру, что у вас есть открытый исходный код, который не может быть использован ни в одном другом проекте кроме вашего, остановитесь и спросите себя, что вы ожидаете от проекта.

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

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

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

Эта статья о том, как начать создание проекта с открытым программным кодом ориентируясь на следующие цели:

1. Создать что-то полезное для мира.
2. Продолжить развитие программного кода в обозримом будущем.
3. Принимать стороннюю помощь.

Выбор лицензии.

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

• GPL. GNU Public License (Универсальная общественная лицензия GNU) была создана для проекта GNU и была связана с популяризацией Linux в качестве общедоступной операционной системы. Лицензия GPL требует, чтобы любой проект с использованием лицензированных компонентов должен также быть доступен под лицензией GPL. Проще говоря, любой проект с использованием GPL-лицензированных компонентов в любом случае должен быть с открытым исходным кодом под лицензией GPL. Не существует никаких ограничений на использование GPL-лицензированных приложений. Ограничения будут касаться только модификаций и распространения производных работ.
• LGPL. Lesser GPL (модифицированная версия GPL для библиотек ПО) является несколько более либеральной версией GPL. LGPL лицензированные компоненты могут быть связаны с приложением без необходимости применения открытого исходного кода под лицензией GPL. Во всех других отношениях, основные идеи LGPL подобны GPL, так что любые производные работы также должны обладать открытым исходным кодом под лицензией GPL или LGPL.
• MIT (лицензия свободного программного обеспечения разработанная Массачусетским технологическим институтом). Также применяется название X11. Эта лицензия является разрешительной и позволяет использование и распространение кода до тех пор, пока вместе с ним присутствует ссылка на лицензию и авторские права. MIT-лицензированный код может быть включен в ваш собственный код без каких-либо дополнительных ограничений. Кроме того, программный код под лицензией MIT совместим с GPL и может быть объединен с таким кодом для создания новых GPL-лицензированных приложений.
• BSD3 (Berkley Software Distribution license — Программная лицензия университета Беркли). Это также разрешительная лицензия, которая позволяет использование и распространение программного кода до тех пор, пока в нем присутствует ссылка на лицензию и авторские права. Кроме того, вся доступная документация на любое перераспределение кода в двоичной форме должна включать в себя ссылку на лицензию и авторское право. Основные принципы, которые устанавливает BSD3 (за исключением MIT) запрещают использование имени владельца авторских прав для продвижения продукта, который использует этот код. Например, если бы я создал программный код и получил на него лицензию BSD3, то приложение, которое использует этот код не может использовать свое имя для продвижения продукта без моего разрешения. BSD3-лицензированный код также совместим с GPL.

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

Изображение предоставлено: opensourceway.

Следует знать, что Creative Commons лицензии не предназначены для использования с программным обеспечением. Все лицензии Creative Commons предназначены для «продуктов творчества», в том числе аудио, изображений, видео и текста. Сама организация Creative Commons рекомендует не использовать Creative Commons лицензии на программное обеспечение. Нужно использовать специализированные лицензии, которые были разработаны для защиты программного обеспечения, как в случае четырех вариантов, рассмотренных выше.

Итак, какую лицензию лучше всего выбрать? Это во многом зависит от того, как вы собираетесь использовать свой программный код. Поскольку лицензии LGPL, MIT и BSD3 все совместимы с GPL, это не является серьезной проблемой. Если вы допускаете любые модифицированные версии вашего кода, которые будет использоваться только с открытым исходным кодом, то GPL является лучшим выбором. Если ваш код предназначен для автономных компонентов, которые могут быть включены в другие приложения без изменения, то вы можете рассмотреть вариант с использованием лицензии LGPL. Во всех остальных случаях, MIT или BSD3 лицензии являются самым популярным выбором. Физические лица склонны использовать лицензию MIT, в то время как предприятия, как правило, отдают предпочтение BSD3 лицензии, чтобы название их компании не могло быть использовано без предварительного согласия.

Чтобы помочь вам определиться с выбором, давайте посмотрим на подборку лицензий для некоторых популярных проектов с открытым исходным кодом:

• jQuery: MIT лицензия;
• YUI: BSD3 лицензия;
• Dojo Toolkit: двойное лицензирование под BSD3 и Academic Free License (Свободная академическая лицензия);
• Backbone: MIT лицензия.

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

Чтобы узнать больше о лицензиях, о правовых вопросах лицензирования и о том, как на самом деле работает весь этот механизм, пожалуйста, ознакомьтесь с публикацией Дэвида Бушелла “Понимание особенностей авторского права и лицензий“.

Организация программного кода.

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

Для Lint CSS, мы решили выбрать основную структуру каталога верхнего уровня в src для исходного кода, lib для внешних зависимостей, а tests для любого тестируемого кода. Каталог src подразделяется на каталоги, которые группируются в связанные файлы. Все установки CSS Lint находятся в подкаталоге rules; все выходные отформатированные элементы находятся в каталоге formatters и т.д. Каталог tests разделен на подкаталоги src, указывая тем самым отношения между тестируемым кодом и исходным. Со временем, по мере необходимости мы добавляли каталоги верхнего уровня, но все основные структуры остались без изменений.

Документация.

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

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

Документация конечного пользователя.

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

Руководство разработчика.

Даже если вы выложили программный код в логично структурированном порядке и обладаете всей необходи …

Если вы хотите прочитать полностью статью, посетите сайт наших спонсоров