Как узнать, достаточно ли зрел проект Open Source для использования в продукте?

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

Теперь, я немного обеспокоен количеством риска, которому я подвергаюсь при использовании проекта с открытым исходным кодом joe-blow. Если мне понадобится 95% пути, возможно, оставшиеся 5% легко добавить или исправить. Возможно, это нетривиально.

Как люди решают, достаточно ли зрел проект с открытым исходным кодом для использования в продукте?

Это не хобби, поэтому стабильность, ремонтопригодность и т. Д. Имеют первостепенное значение.

Критерии, которые я использую, при условии, что проект соответствует моим требованиям:

1. Существует ли активное сообщество людей, способных оказать помощь?
2. Соответствует ли лицензия моей разработке?
3. Продукт все еще находится в стадии активной разработки?
4. Это обычно используемый фреймворк?
5. Могу ли я найти какие-либо отзывы / сообщения в блоге / и т. Д. О продукте и как люди интегрировались с ним?

4 и 5 на самом деле не помогают нишевым проектам, как кажется у вас.

Самая важная вещь , это отвечает вашим требованиям? Если вы чувствуете, что это происходит, следующее, что нужно сделать, - это подготовить тестирование проекта и посмотреть, сможете ли вы сделать то, что хотите. Это даст вам представление о его API (если это библиотека) и о том, как он работает.

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

1. Что касается фреймворка, я обычно использую только большие и зрелые фреймворки с множеством предварительно написанных модулей и большим сообществом. Как правило, выбор одного фреймворка вместо другого на самом деле не сильно сократит объем работы, которую вы должны тратить на собственный код, некоторые фреймворки могут поощрять более красивый код, другие могут упростить некоторые операции, но обычно они сводятся к очень небольшая разница в общем объеме разработок. Однако популярные фреймворки будут иметь больше предварительно написанных модулей, которые вы можете использовать, и таким образом вы обычно можете сэкономить гораздо больше времени и усилий.
2. Для небольшой библиотеки не-фреймворка, как правило, вы можете вносить изменения самостоятельно, если это необходимо, без особых проблем, поэтому обычно я бы хотел добавить сообщество в качестве дополнительного бонуса. Большинство небольших библиотек управляются только одним человеком, но они все же лучше, чем создавать себя. Тем не менее, для больших библиотек важно иметь зрелое, активное сообщество и документацию, потому что вы вряд ли сможете внести изменения самостоятельно.
3. Лицензия необходима. Для библиотек с одним человеком вам, вероятно, потребуется внести изменения в библиотеку, поэтому важно, чтобы их лицензия позволяла вам делать это на условиях, с которыми вы согласились бы.

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

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

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

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

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

Новости не хорошие, но это не значит, что они неправильные: вы не знаете.

Если бы в производстве были аналогичные реализации, вы бы знали, что это выполнимо, но, как вы сказали, «основные игроки» не используют проекты.

Если бы вы развивались в доме, то вы бы знали, но, как вы сказали, у вас нет ресурсов.

Разумно хотеть знать, но ... ты не знаешь.

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

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

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

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