Когда проект с открытым исходным кодом готов к производству?

Когда вы находите новую библиотеку / проект с открытым исходным кодом, какие критерии вы смотрите перед тем, как включить ее в исходную базу.

• Есть ли юридические вопросы, на которые вам нужно ответить?

• Вы ищете определенную скорость развития?

• Достаточно ли хорошая причина для сообщества?

• Изменится ли ваше решение, если вы один на линии для проекта?

• Меняет ли сложность домена или кода ваш взгляд на это?

Вот мой контрольный список относительно зрелости проекта:

Достиг ли проект первоначального рубежа?

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

Есть ли адекватная документация?

Идеальный проект будет предлагать:

• Руководство пользователя с примерами
• Руководство по интеграции / расширению, если это библиотека
• API документация
• Полностью документированный исходный код
• Трекер общественного выпуска

Разработчики по-прежнему привержены проекту?

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

• Недавняя активность
• Последние функции (не только исправления ошибок)
• Последние действия с документацией (обновления документации, сообщения в блоге и т. Д.)

Также хорошим показателем зрелости проекта является второе поколение разработчиков, активных разработчиков, которые подключились после начальных этапов.

Разработчики доступны?

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

Теперь по вашим более конкретным вопросам:

Скорость

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

Совместимость лицензий

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

Обман сообщества

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

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

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

Мудрый BP: вводить новые вещи никогда не следует делать без какой-либо формы подготовки / обучения.