О книге «Producing Open Source Software»


Давно я не писал посты о прочитанных книгах, хотя в последнее время удалось прочитать достаточно много книг, которые достойны обзора. Так уж получилось, что в этом году большинство книг по программированию, которые мне попадались, были на английском языке. В этом посте речь пойдет об одной из таких книг Карла Фогеля (Karl Fogel) — «Producing Open Source Software».

Как ясно из названия, эта книга об открытом программном обеспечении, но прежде чем говорить о книге, надо сказать пару слов об ее авторе. Карл работал (или работает) над такими известными проектами как Subversion (она же SVN, система контроля версий, которая когда-то пришла на смену CVS) и Launchpad — хостинг для открытого софта, где, например, располагается проект Ubuntu, MySQL и многие другие крупные опенсорсные проекты.

В своей книге «Producing Open Source Software», которая также распространяется с открытыми исходниками на сайте http://producingoss.com, Карл всесторонне описывает работу над софтом с открытыми исходниками. Причем, речь в ней идет не только о технической стороне, но и о социальной, ведь успешный открытый проект — это прежде всего результат взаимодействия многих людей, тем или иным образом участвующих в проекте. Причем участники могут проживать по всему миру. Это не обязательно должны быть программисты, это могут быть дизайнеры, бета-тестеры, люди, которые переводят программу на свой родной язык, да и просто пользователи, которые присылают свои пожелания и сообщения об ошибках. А может быть создание свободного софта — это ваша основная работа, тогда возникнет вопрос о том, как зарабатывать на нем, причем так, чтобы сообщество вас поддерживало.

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

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

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

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

Также рассматриваются вопросы «политического устройства» открытого проекта. Например, будет ли у вас единоличный лидер (диктатор) или вопросы развития будут решаться голосованием. Как с одной стороны стимулировать сторонних разработчиков присылать вам исправления, но в то же время не допустить хаоса в проекте, когда в приложение добавляются несвязанные между собой возможности, которые могут пригодиться лишь небольшому числу пользователей.

Книга мне очень понравилась. Во время чтения ее я себе отмечал, что нужно сделать для того же OutWiker, на какие грабли я уже наступил, а какие еще могут быть впереди.

Как я уже говорил, книгу вы можете скачать с официального сайта http://producingoss.com, при этом она постепенно переводится на разные языки, в том числе и на русский, хотя русский перевод еще не завершен.

PS. Вы можете подписаться на новости сайта через RSS, Группу Вконтакте или Канал в Telegram.

Пожалуйста, оцените запись

УжасноПлохоТак себеХорошоОтлично (Количество голосов: 1, средняя оценка: 5,00)
Загрузка...

Leave a comment

Subscribe without commenting