En entornos "empresariales", he observado un fuerte prejuicio hacia el software propietario. Incluso en las grandes empresas que usan Java, es inusual encontrar MySQL o PostgreSQL, y WebSphere y WebLogic son muy preferibles a JBoss o Tomcat.
Esto es muy comprensible. Si bien muchos desarrolladores prefieren Tomcat o Postgres a WebSphere u Oracle DB, no son los que toman las decisiones finales en estos asuntos. Quien tome la decisión con respecto a qué DB y servidores de aplicaciones se utilizarán en la producción, encontrará que las tarifas de licencia parecen bastante pequeñas en comparación con el despido por elegir el software gratuito que causó que algo realmente, realmente malo sucediera.
No estoy preguntando si Postgres es tan bueno como Oracle. Ese no es el punto. Oracle no se elige sobre Postgres después de una cuidadosa consideración de características y puntos de referencia. Postgres no entra en la conversación, porque el software libre no es confiable en ciertos lugares.
Tengo curiosidad por saber si esta falta de confianza se produjo en respuesta a algún evento específico. Entonces mi pregunta es la siguiente: ¿Existen casos documentados de calamidades comerciales (fallas, pérdida significativa de ingresos, pérdida significativa de datos corporativos, etc.) que se demostró que son el resultado de deficiencias en el software de código abierto?
Aclaración: si tiene experiencia con empresas de nivel empresarial que adoptan completamente OSS, que tienen que perjudicar el asunto pero toman decisiones basadas en las necesidades de la situación particular, entonces ¡ Bien por usted! Su experiencia no cambia el hecho de que otras empresas tienen una actitud muy diferente, y mi pregunta es válida incluso si estas empresas son minoritarias.
fuente
Respuestas:
¿Hay algunos prejuicios, sí, tal vez en algunos casos. Sin embargo, para las grandes organizaciones, este camino hacia servidores de aplicaciones propietarios caros y otras suites de software costosas les dio algunas ventajas y valores que algunos rara vez piensan.
1) Soporte : por lo general, cuando una gran corporación tiene un software de un millón de dólares, el soporte está integrado en el contrato. No necesito profundizar en las ventajas de tener soporte de aplicaciones.
2) Apalancamiento : el software propietario costoso, especialmente el software de nicho, tiene menos clientes y usuarios independientes. Si un gran cliente corporativo decide no renovar un contrato, puede afectar seriamente el resultado final del proveedor. Muchos de ellos usan este apalancamiento para impulsar características y correcciones que no pueden influir en el software de código abierto. El argumento a favor del código abierto afirma que la gran corporación puede contribuir con sus propios cambios y características en el proyecto por el bien de todos, pero eso implicaría tiempo de los desarrolladores que intentan evitar.
3) Seguridad : y no me refiero a encriptación y firewalls y demás. Los proyectos de código abierto van y vienen, algunos son ampliamente compatibles y superan el software propietario. Muchos fallan o simplemente pierden contribuyentes con el tiempo. Si están atrapados con este software durante 20 años, ¿la comunidad de código abierto continuará apoyando esto? Con el software propietario, el dinero que paga como cliente alienta al vendedor a permanecer en el negocio siempre que continúe pagándole.
En cuanto a una historia en la que el código abierto explotó en la cara de mi empresa, un proyecto de larga duración que se inició en un mapeador de ORM poco común que era de código abierto. El proyecto simplemente se detuvo cuando el contribuyente principal murió o algo así, luego la empresa se quedó con un costoso esfuerzo de refactorización para mudarse a una biblioteca propietaria. Sucede y este tipo de escenarios asusta a las grandes corporaciones.
fuente
Nunca he oído hablar de ningún problema que sea el resultado del uso de un producto de código abierto. Creo que la razón de la preocupación no se debe a algún fracaso histórico, sino a otra cosa.
Cuando utiliza un producto comercial para alguna tarea, y algo sale mal, generalmente tiene a alguien a quien puede llamar para solicitar asistencia. Esa persona (y compañía) generalmente tiene un interés personal en ayudarlo a resolver el problema, porque si no ayudan, siempre existe la amenaza de que deje de darles dinero.
Con un producto de código abierto, ¿a quién puede llamar o contactar? ¿La comunidad? Como no les ha dado nada por el uso del producto, no hay nada que pueda amenazar con quitarles. Puede presentar un informe y esperar que se solucione en la próxima versión, pero es muy difícil transmitir un sentido de urgencia a una comunidad nebulosa de personas que ofrecen su propio tiempo como voluntarios .
Por lo tanto, el producto de código abierto puede ser muy superior a una alternativa comercial, pero al menos en mi experiencia, en un entorno corporativo en el que tiene que planificar las contingencias si algo sale mal, no tener a nadie para obtener apoyo es un gran problema. acuerdo.
Esa es la barrera que siempre he visto.
fuente
Sospecho que compañías como Oracle son más identificables con otras compañías "con fines de lucro"; no pueden imaginar que una organización pueda producir un producto tan bueno como Oracle sin tener también un motivo de ganancias. Por supuesto, PostGres no es completamente sin fines de lucro; Hay un ecosistema completo de proveedores de servicios disponibles que le venderán soporte.
Si realmente quiere saber cuál es el talón de Aquiles de cualquier producto, puede hacer una búsqueda en Google de "[nombre del producto] es una mierda". Funciona para cualquier producto, incluidos los de Oracle. En el caso de PostGres, encuentra el control de transacciones DDL de Postgres , en el que alguien describe una situación hipotética en la que los datos se perdieron en un servidor de prueba. Por supuesto, es posible perder datos en cualquier base de datos SQL si se maneja mal.
Dicho todo esto, no he oído hablar de ninguna calamidad real que haya sucedido a las empresas porque decidieron usar una base de datos de código abierto. La calidad del software disponible en ese espacio es bastante buena, rivalizando y (en algunos casos) superando a sus contrapartes comerciales.
fuente
Para contrarrestar el argumento de OSS como factor de riesgo, me gusta dar el contraejemplo de SAP, que a menudo se cita como un factor importante en las insolvencias de las pequeñas y medianas empresas: aquí se da un ejemplo: http: //www.intl- spectrum.com/article/359/Migration_to_SAP_from_U2_Causes_Bankruptcy_of_Company.aspx
Esta afirma ser una lista de los 10 principales errores de TI corporativos: http://www.computerworld.com/computerworld/records/images/pdf/44NfailChart.pdf
Enumera las introducciones de productos SAP tres veces.
fuente
Es un caso de usar lo que es popular / establecido versus nuevo y presumiblemente menos probado. ¿Alguien ha sido despedido por usar Apache? Estoy seguro de que algunos sitios web que lo ejecutan han sido pirateados hasta el punto de costar dinero, pero ¿culparon a Open Source o a los responsables de una instalación deficiente? ¿Cuál es la alternativa de propiedad ironclad?
La pregunta es un intento de defender una solución, entonces, ¿cuál es el problema? Su empresa no quiere usar software de código abierto y su argumento de inestabilidad no está respaldado por ninguna evidencia anecdótica. Crea un proyecto paralelo y prueba que están equivocados. Pueden pagarle el dinero que ahorran en tarifas de licencia.
La mayoría de las compañías no publican malas noticias, así que tienes suerte si puedes obtener la versión sucia de la calle.
fuente