4 основных элемента, необходимых для бесперебойной работы производственного OSS – TechCrunch
Использование программного обеспечения с открытым исходным кодом (OSS) резко возросло, и многие компании используют его в качестве краеугольного камня своей инфраструктуры. Приобретая коммерческое программное обеспечение, поддерживаемое поставщиком, вы можете ожидать, что поставщик будет отвечать за обновления, обслуживание, интеграцию и поддержку продуктов.
Если пойти по пути OSS, это уже не так. Вместо этого вы будете взаимодействовать с компонентами, созданными разными организациями, отдельными лицами или сообществами с разными стандартами и целями. Например, недавний Лог4дж проблема безопасности привела к тому, что многомиллиардные компании запросить поддержка со стороны сопровождающих проекта, поскольку у них был контракт с ними.
Компаниям необходимо внедрить множество элементов, чтобы беспрепятственно использовать OSS в производстве. Вот как начать.
Аудит
Прежде чем приступить к использованию проекта OSS, вам сначала необходимо выполнить полный аудит: сколько участников насчитывает проект? Являются ли они физическими лицами или организациями? Большинство специалистов по сопровождению OSS — добровольцы, и уровень их участия никогда не гарантируется.
Вы напрямую вносите свой вклад в пространство с открытым исходным кодом, работая с поставщиками, гарантируя, что используемые вами инструменты OSS никуда не денутся.
Вы также должны смотреть на скорость проекта. Например, сколько имеется открытых запросов функций или сообщений об ошибках? Как быстро сообщество отвечает и продвигает их? Цель состоит в том, чтобы обеспечить поддержку и развитие проекта.
Наконец, вам нужно проверить фактический код. Это хорошо задокументировано? Может ли он справиться с вариантами использования и масштабом, которые вам нужны? Выбор неправильного проекта может стать дорогостоящей ошибкой в долгосрочной перспективе. Бесчисленные растущие стартапы, выбравшие то, что выглядело как блестящие проекты OSS, позже были вынуждены тратить огромные усилия на вывод из эксплуатации и замену проектов, которые не могли идти в ногу.