Что я заметил, так это снижение качества GEM, выпущенного через GitHub, по сравнению с общим качеством GEMS на RubyForge.
ИМХО есть как минимум два основных объяснения такому поведению:
--
До GitHub 99% Rubyist зависело от Subversion. Вы можете говорить что угодно о Subversion, но она определенно более проста в использовании по сравнению с Git, и все знают о расположении ствола/тегов/веток. Затем люди начали переходить на Git. Лишь очень ограниченный круг пользователей Subversion начал использовать Git с должным уровнем знаний, и я заметил, что люди начали забывать о тегах.
Когда-то были теги. В Subversion люди использовались для выпуска новой версии на основе определенных тегов, чтобы вы могли легко определить, какую версию вы установили и какая была стабильной ветвью.
В настоящее время я вижу множество библиотек, постоянно находящихся в разработке в главной ветке Git. Нет тегов, нет стабильных веток. В целом, когда библиотеки выпускались через RubyForge, этапу развертывания уделялось больше внимания.
--
GitHub упрощает публикацию. Тем не менее, вы можете легко опубликовать новый GEM, просто поместив спецификацию gemspec в свой репозиторий.
На мой взгляд, эта простота может привести к снижению качества. Более менее квалифицированные разработчики начали распространять GEMS, потому что это так же просто, как создать новый проект с помощью Jeweler (или аналогичной библиотеки) и отправить репозиторий git. Они мало что знали об управлении релизами, обратной совместимости, корректировках релизов, сопровождении релизов.
Часто я сталкивался с недоработанными библиотеками, упакованными как GEM, только потому, что разработчик забыл удалить файл .gemspec. Каждая фиксация приводила к созданию нового GEM без видимой согласованности и согласованности.
Я абсолютно поддерживаю практику «частых выпусков», но только тогда, когда это имеет смысл. Git обеспечивает отличную поддержку веток, вам не нужно загромождать основную ветку тоннами несвязанных коммитов и выпускать незаконченный фрагмент кода, который вы называете библиотеками.
--
И последнее, но не менее важное: что я, наверное, больше всего ненавижу, так это неограниченное дублирование одного и того же GEM. Когда RubyForge был бесспорным источником GEM, было довольно легко найти и установить новый проект.
ИМХО, GitHub ввел ненужный уровень сложности. Во-первых, у вас есть GEM, доступный через rubyforge как mygem и через GitHub как username-mygem. Часто приходится тратить время на то, чтобы выяснить, какой GEM является наиболее обновленным и держит основную разработку.
Кроме того, некоторые популярные GEM больше не обновляются на RubyForge, и многие люди продолжают их использовать только потому, что RubyGems не уведомляет вас о новых версиях. Легко понять, если вы установили coolgem версии 1.2.4 и та же самая библиотека теперь доступна как superuser-coolgem (версия 2.0), RubyGems недостаточно умен, чтобы сообщить вам о наличии нового обновления.
--
Теперь пришло время для отказа от ответственности.
Я не говорю, что пользователи GitHub производят дрянные GEMS по сравнению с RubyForge. Я пользователь GitHub, а раньше я также был пользователем RubyForge. Тысячи GEMS успешно мигрировали с RubyForge на GitHub, не оставляя конечного пользователя в подвешенном состоянии.
Лучший пример — Rails, но я могу упомянуть многие другие GEM, включая (но не ограничиваясь ими) Capistrano, Hpricot, RedCloth… Все эти библиотеки теперь размещены на GitHub, и если вы внимательно посмотрите на них, вы легко узнаете тот же уровень качество как раньше.
И последнее, но не менее важное: все эти библиотеки продолжают выпускаться через RubyForge в качестве основного исходного кода, поэтому вам не нужно перенастраивать свою среду, чтобы определить, устанавливать ли рельсы-рельсы или рельсы.
Кроме того, решения о разработке не влияют на конечного пользователя. Возьмем, к примеру, Капистрано. Пару месяцев назад Jamis объявила об окончании своего участия в разработке. Сообщество взяло на себя разработку и переместило главный репозиторий из jamis/capistrano в capistrano/capistrano. Что произойдет, если GEM будет выпущен как jamis-capistrano? Всем пользователям придется с большим трудом переключиться на новый GEM и новый репозиторий.
Этот сценарий никогда не возникал, потому что RubyForge был и остается основным центром доставки Capistrano.
--
В заключение я, к сожалению, замечаю общее снижение качества GEM, в основном вызванное тем, что все больше людей обращаются к Ruby и RubyGems без необходимого уровня знаний. То же самое относится к большому количеству плагинов Rails.
GitHub нельзя назвать виновником. Когда сложные вещи становятся более простыми и все больше людей подходят к ним без базовых знаний, это нормально, что качество может снизиться, потому что сложность — это естественный процесс отбора.
Как бы то ни было, в сообществе Ruby по-прежнему сохраняется превосходный уровень качества. Удивительно видеть, как разработчики Ruby привержены модульному тестированию и другим привычкам профессионального программирования.
20.07.2009
