При сравнении проектов с открытым исходным кодом с коммерческим программным обеспечением или даже с другими проектами с открытым исходным кодом, какие ситуации поднимают красный флаг и заставляют вас нажимать кнопку извлечения и искать в другом месте?
Открытый источник
Посмотрите на сайт проекта
При этом обратите внимание на следующие моменты ...
Также убедитесь, что вы приняли к сведению Лицензию, по которой распространяется программное обеспечение. Некоторые могут не подходить для ваших нужд.
Корпоративное программное обеспечение
Мне здесь особо нечего сказать, кроме ...
root. Специально если он будет прослушивать порт TCP / IP. * Глядя на репутацию продавцаroot доступ, и поэтому продукт должен поддерживать sudo. Любой, кто утверждает, что sudo не поддерживается, обычно просто дряхлеет, но они поставщики, и они будут теми, кто должен вас поддерживать - вы не хотите покупать продукт, а позже попросите их сказать вам: «Нет, вы не можете использовать sudo , вы должны использовать su для получения root-прав ".Отсутствие активности. Если в проекте не выпущен новый код, показано множество незакрытых ошибок (или очень-очень старых ошибок без новых ошибок), или если у вас есть форумы пользователей с очень высоким соотношением количества спама и сообщений, это верный запах распадающаяся кодовая база. У активных проектов есть регулярные выпуски, количество ошибок, которое указывает на то, что открываются новые, не опережают закрытые старые, и пользовательские форумы с ежедневной активностью. Все три из них жизненно важны для поддержания кода в рабочем состоянии - выпуск, обратная связь и отладка / рефакторинг, образуя полный цикл.
Активность пропорциональна размеру, сложности и зрелости кодовой базы. Чем больше программа / проект, тем реже точечные релизы, но должен быть последовательный поток точечных релизов. Для такого проекта, как Samba, с большой сложной базой кода, ожидайте точечные выпуски через месяц или около того. Для такого проекта, как gcc, который представляет собой зрелую кодовую базу с более консервативными целями дизайна, точечные релизы длиннее, но крупнее. Быстро меняющиеся цели на очень небольших объемах кода также показывают потенциальные проблемы - возможно, разработчики все еще борются с ошибками или еще не закодировали все цели / функции.
Исходный код должен быть легко доступным. В упор, если это правда открытый исходный код, не должно быть никаких волшебных рукопожатий, подношений вуду или заклинаний при свечах, чтобы увидеть исходный код. Неважно, доступен ли он через CVS, SVN, Git, Mercurial или даже через почтовый голубь, при условии, что вы можете получить к нему доступ без лицензионного соглашения. Если вы подписываете отказ, NDA или соглашаетесь с какой-то схемой лицензирования, о которой не слышали, вы имеете дело не с открытым исходным кодом, а с коммерческим поставщиком, который согласился открыть для вас свой исходный код - за определенную плату. .
Их действительно много.
Обманчивое лицензирование - Слишком много решений пытаются накинуть на меня пятак. Пакет стоит X, но если вам нужны рекламируемые варианты 1, 2 и 3, это будет на 500-1500 долларов больше за вариант. Нет, спасибо.
Никто не использует это - По крайней мере, Google не может найти, чтобы кто-нибудь об этом говорил. Это либо новенькое (в этом случае вы подопытный кролик), либо настолько плохое, что все знают лучше
Это корень нескольких вилок - Если что-то было разветвлено много раз, вероятно, для этого есть веская причина, и одна из вилок, вероятно, решила проблему лучше, чем исходный код. Вместо этого исследуйте их.
Постоянно плохой дизайн интерфейса - Я имею в виду не только графический интерфейс. Сумасшедшие, неопознанные или неправильно обозначенные флаги или параметры интерфейса командной строки сводят меня с ума
Не работает - или он делает вид, что ситуация, которую необходимо решить, не должна (или не существует) существовать, и поэтому не решает ее
Я бы также добавил, что скорость оттока кода постоянна и выполняется многими людьми, а не только некоторыми. Вы же не хотите, чтобы один человек работал над кодом неполный рабочий день, когда он в восторге от своего проекта, потом ему это надоедает, и он оставляет его на усмотрение сообщества. Drupal и Joomla - два хороших примера.
Если вы ищете программное обеспечение для своей компании, чтобы его продать, изменить и т. Д., Наиболее важным аспектом является лицензия. Глядя на включение busybox в маршрутизаторы WLAN и последующие судебные иски, компании думают, что «открытый исходный код = делайте все, что хотите».
Некоторые другие вещи: я также ищу дату последнего обновления и активное сообщество, например, форум, возможно, другие страницы, на которых программное обеспечение указано в качестве темы.
В Linux я бы проверил, какое программное обеспечение упаковано в ваш дистрибутив. Пакетное программное обеспечение не ограничивается только открытым исходным кодом / GPL - Ubuntu, Gentoo и SLES как минимум включают собственное программное обеспечение в свои списки пакетов. Хотя нет гарантии, что эти пакеты будут работать так же эффективно, как и основное программное обеспечение в дистрибутиве, кто-то потратил время и усилия на подготовку пакета.
Я бы смотрел в основном на зрелость и активность. Если он кажется достаточно зрелым и, кажется, ведется приличная активность (например, форум или вики), тогда я могу чувствовать себя довольно комфортно. Тогда я знаю, что есть большая вероятность, что ошибки будут исправлены и что я смогу получить помощь с возникающими проблемами. Я бы выбрал активный проект, который не полностью соответствует моим потребностям, а не проект, который кажется идеальным, но кажется мертвым, в любой день недели.
Когда дело доходит до зрелости, это во многом зависит от предполагаемого использования. Если это что-то, что мне нужно внедрить немедленно, и нельзя допустить, чтобы он потерпел неудачу или вызвал проблемы, зрелость, очевидно, будет довольно важным фактором. Если я могу жить с некоторыми причудами, и это не критично с некоторыми простоями, то я лучше посмотрю на будущее.