Adopción de software de código abierto en una organización

Question

¿Cuáles son los pros y los contras de adoptar software de código abierto para una organización? ¿Hay alguien por ahí que haya hecho esto y qué tan bien ha estado trabajando con algunos ejemplos de los softwares que adoptaron y cómo ha estado en uso?

Normalmente las contribuciones vienen porque la gente lo hace como un hobby, entonces, ¿cómo podemos asegurarnos de que habrá un apoyo continuo para ello? En mi humilde opinión, en el caso del software propietario existe un incentivo para la organización (dinero), y seguirán contratando personas para mantenerlo en desarrollo mientras el software sea rentable. Corrígeme si estoy equivocado. ¿Cuáles son los argumentos que podría esperar de un gerente que podría oponerse a la sugerencia de usar software de código abierto?

Answer 1

El término "Código abierto" solo describe un modelo de licencia. Estrictamente hablando, el único profesional que se le garantiza que tiene son las libertades otorgadas por la licencia, y no hay contras que tenga la garantía de tener.

Hay muchos productos de código abierto que también son comerciales, creados, mantenidos y respaldados por una empresa con fines de lucro. También hay muchos productos de código abierto que son mantenidos por voluntarios pero también son compatibles comercialmente. Por ejemplo, si compra Red Hat Enterprise Linux, Red Hat lo apoyará en todos los productos que lo acompañan, incluso los que mantienen los voluntarios.

En cuanto a cómo asegurarse de que habrá soporte continuo, no puede. No con Open Source, no con software propietario, no con nada. Con Open Source, si la comunidad es lo suficientemente grande, puede estar razonablemente seguro de que la comunidad continuará manteniéndola (tal vez con un nuevo nombre) incluso si los mantenedores actuales la abandonan, y usted tiene la opción de mantenerla usted mismo o contratarla. alguien más para hacerlo. Mantenerlo usted mismo puede no ser una opción atractiva, pero puede ser un salvavidas en un apuro.

Con software propietario, si el autor decide dejar de mantenerlo, simplemente no tiene suerte. Considere, por ejemplo, los miles de usuarios de Visual Basic 6.

Answer 2

El profesional principal del software de código abierto es ilustrada por su comentario:

[En el] caso del software propietario, hay un incentivo para la organización (dinero), y seguirán contratando personas para mantenerlo en desarrollo mientras el software sea rentable.

El problema es que si deja de ser rentable (por ejemplo, porque el código es tan estable que la gente lo compra y seguir utilizándolo sin necesidad de actualizaciones), entonces los usuarios de ese software se pueden varados con su buen producto estable que se ejecuta en máquinas cada vez más antiguas hasta que, un día, las máquinas fallan, o deben actualizarse a una nueva versión del sistema operativo para que puedan ejecutar otro sistema, pero como el software propietario ya no se mantiene, usted tiene renunciar a la aplicación. De hecho, no es extraño que las empresas que venden software propietario quiebren. Y, si no se aseguró de que existiera una cuenta de depósito de garantía del código para que el software lo proteja frente a la posibilidad de que el proveedor cierre, entonces está estancado.

Si el código era de código abierto y era sensato (obtuvo la fuente cuando obtuvo el producto), puede tomar el producto anterior y transferirlo al nuevo sistema. Lo difícil que será dependerá de la naturaleza y la calidad del código, pero es posible. Si el software fue propietario, es posible que nunca tenga la opción.

Answer 3

La pregunta es: ¿qué quiere decir con "adopción de software de código abierto".si planea intercambiar radicalmente cada pieza de software de fuente cerrada (CSS) con software de código abierto (OSS), fallará de manera horrible.

Puedo garantizarle que su organización ya está utilizando OSS en partes clave de su infraestructura de TI.

Desde mi punto de vista, solo necesita formalizar cómo OSS puede ingresar a la empresa y si (y de qué forma) la empresa contribuye a OSS. La mayoría de las empresas requieren un contrato de soporte para el software de misión crítica y el mandato de que OSS debe comprarse a través de proveedores que brindan soporte.

En muchos casos, la contribución de nuevo a los proyectos OSS está explícitamente prohibida y solo está permitida después de los signos de CTO/CIO de una contribución específica.

Simplemente asegúrese de que sus políticas sean lo suficientemente flexibles para permitir lo que el departamento de TI ejecuta actualmente.

Answer 4

No importa lo que esté diciendo el Administrador opuesto al Código abierto.

Tienes que saber bien el producto de Código abierto que vas a utilizar.
Debe asegurarse de que sea una solución adecuada para la empresa. Tiene que estar seguro de que puede encontrar personas en el mercado que conozcan o puedan aprender a usar ese producto. Debe conocer el TCO para ese producto.

Luego puede discutir con el gerente y darle buenas razones de cómo la compañía puede beneficiarse del código abierto.

Tenga en cuenta que la solución más económica no es la mejor solución. Las empresas necesitan ganar dinero para no ahorrar dinero.

Answer 5

Depende de la situación, pero generalmente, para un sistema interno, no crítico, sin necesidad de seguridad, como la mayoría de lo que se hace en la empresa, el código abierto es como Halloween y realmente no necesita preocuparse siempre y cuando sigas la política empresarial.

Para los otros proyectos grandes, importantes, que necesitan seguridad, es realmente simple. Debe tener una parte en los proyectos que usa y tener un repositorio interno que aloje el proyecto (para que tenga una sucursal interna que se mantenga sincronizada con la sucursal externa). El caso es que esas aplicaciones son las que toman mucho tiempo hacer y son compatibles por miles de años. Los equipos tienden a cambiar mucho y hay mucha gente involucrada. Alguien necesita y puede ser asignado a la gestión de repositorio/compilación.

Ahora bien, si solo se trata del administrador, entonces se trata solo de comunicación y argumentación. Usualmente les asusta el soporte porque es el costo a largo plazo. Tienden a escuchar sobre las mejores prácticas, les dicen que eso es lo que hacen las grandes compañías (y ejemplos) y que también tienden a participar en los proyectos y otras veces incluso o es posible encontrar apoyo para ello.

Además, cualquier contratista estará encantado de dar soporte a un OSS. ¿Quién diría que no al dinero y la capacidad de desarrollar un OSS?