Sabiduría de usar código fuente abierto en un producto de software comercial

Estoy mirando el uso de algún código fuente abierto en mi aplicación web ASP.NET (específicamente apuesto ). La administración no es fanática, porque el código abierto es visto como un riesgo que nos ha mordido antes. Aparentemente, los desarrolladores anteriores tuvieron que reescribir cosas después de que fallaron los componentes de código abierto.

Las ventajas parecen ser:

• Hace un montón de cosas para mí que de otro modo implicarían mucho código repetitivo o la solución más lenta pero recomendada de Microsoft (Entity Framework).

Contras:

• Es lo suficientemente complejo como para que si fallara repentinamente en la producción, sería difícil arreglarlo. Sin embargo, está en uso en un sitio de mucho más tráfico que el mío, por lo que no creo que termine siendo una parte de alto riesgo del proyecto.

¿Cuál es el consenso aquí? ¿Es imprudente usar código fuente abierto en mi proyecto que no conozco / entiendo tan bien como lo hago con mi propio código?

Es una elección que tendrá que hacer en función de las circunstancias específicas. Puede mitigar sus riesgos al:

• probar el marco a fondo, evitando la posibilidad de sorpresas desagradables que lo muerden en un entorno de producción, y
• usando un acoplamiento flexible para minimizar la cantidad de código que depende directamente del marco, de modo que puede cambiar a su propia implementación si es necesario sin tener que volver a escribir todo el producto.

En última instancia, con un proyecto de código abierto muy utilizado, es probable que pases mucho más tiempo escribiendo el tuyo que solucionando los pocos problemas con los que te encuentras.

Iré tan lejos como para decir que si su reacción inicial es escribir algo usted mismo en lugar de ver si alguien más lo ha escrito, está condenado al fracaso. No tome a la ligera todas las horas de trabajo y la corrección de errores que se han incluido en los principales proyectos de código abierto.

Una vez que comience a ingresar a su dominio comercial, será más difícil encontrar OSS que satisfaga sus necesidades. Pero no hay necesidad de volver a implementar otro producto ORM. Si Dapper es lo suficientemente complejo como para no poder depurar y corregir su código, ¿cómo justificaría pasar todas las horas de trabajo escribiéndolo desde cero? Además, siempre podría (debería?) Mirar fuera de la caja las soluciones NoSQL mientras lo hace.

Incluso Linus admitió que intentó encontrar una solución SCM que cumpliera con todos sus criterios antes de desarrollar Git. Al menos pudo explicar por qué ninguna de las soluciones existentes era lo suficientemente buena.

En algún momento de mi vida, dejé de querer reescribir todo y de enfocarme en resolver problemas del mundo real. La mayoría de los problemas que deben resolverse en un negocio son específicos del dominio. Encuentre formas de escribir menos código, no más.

Nota: no soy empleado de Microsoft. La opinión es completamente personal. Muchos pensamientos son de los últimos 5-7 años de uso de código abierto en combinación con grandes proveedores como desarrollador.

El monocultivo es bueno: mi regla personal para ASP.NET es dar preferencia a Microsoft y no elegir código de terceros (código abierto o no) a menos que no haya otra opción. El monocultivo es gratificante, porque lo está llevando un gran proveedor, y la cantidad de usuarios que repiten la misma experiencia es lo suficientemente grande como para obtener ayuda y encontrar una solución.

Ciudades fantasmas: el problema con el código abierto en 2012 es que ya no es 2000 ni 2005. La cantidad de proyectos sigue creciendo, cuando la cantidad de usuarios, adopciones, contribuyentes es casi la misma que hace años. El público está muy delgado. Muchos proyectos interesantes se volvieron obsoletos, abandonados. No existe el presupuesto de proyecto de código abierto. Entonces, cuando termina el interés, no hay nadie para anunciar honestamente que el apoyo ha terminado y apagar las luces. Los proyectos nunca mueren para dejar el foco de atención pública en algo mejor y nuevo. Por lo tanto, el código abierto siempre seguirá creciendo y fragmentándose. Al no tener retroalimentación en forma de recompensa monetaria o muerte financiera, son entidades eternas que existen por el bien de la gloria eterna.

20 grados de separación: cada vez que adopta una nueva biblioteca lo separa de la corriente principal, lo traslada a una minoría de casos extremos. Después de tener 20 pasos, como elegir la configuración de seguridad, usar una versión particular, marco, complemento, etc. Su solución se convierte en una única combinación de detalles globalmente única. Buscar en Google solo ayudará a demostrar cuán raro o único es el problema. Siempre es un problema de autoservicio, puramente técnico. Nunca es relevante para negocios reales.

La calidad proviene del enfoque, el dinero es irrelevante: no hay diferencia entre el software comercial y el de código abierto. Toda la comunidad de desarrolladores es solo una comunidad como siempre lo fue. Los grandes proveedores simplemente tienen la ventaja de envejecer el código por más tiempo, en mejores condiciones, con audiencias más amplias que los grupos de código abierto.

Consenso: Usted pregunta si hay consenso. Posiblemente no. Desafortunadamente, una gran cantidad de usuarios de código abierto están demasiado politizados. Después de todo, el código abierto es un movimiento social. El código abierto es inmune a la crítica, porque muy a menudo la opinión negativa se percibirá como un ataque personal antitecnológico. Mi consenso personal: apegarse a Microsoft.

He trabajado en una serie de proyectos exitosos para una gran empresa que utilizó partes importantes de software de código abierto. En particular, he usado Curl, SQLite y Webkit, todo para una empresa muy grande en proyectos exitosos que se enviaron a los usuarios finales. Como han dicho otros, es solo cuestión de tener cuidado con las licencias e idealmente que un abogado las revise.

Hay cientos de licencias de código abierto, pero generalmente se dividen en dos categorías, estilo BSD y estilo GPL. Las licencias de estilo BSD no requieren que abra su propio código, y generalmente solo tiene algún tipo de cláusula de atribución. Las licencias de estilo GPL requieren que abra su propio código de código abierto. La mayoría de las compañías (incluida la mía) generalmente lo miran con recelo, por lo que querrá evitar el estilo GPL. Dapper parece usar la licencia de Apache, que es de estilo BSD. Siempre averigüe cuáles son los términos generales de la licencia antes de comenzar a codificar.

También está la LGPL, que es un caso interesante de borde en el que puede usarlos sin abrir su propio código si restringe el acceso a un límite binario. (Es decir, accedo a la biblioteca solo como una biblioteca dinámica). El uso de la biblioteca LGPL es muy factible, solo debe tener más cuidado.

En mi experiencia, el código fuente abierto no es más probable que resulte defectuoso o fallido que las soluciones de pago o, para el caso, las soluciones roll-your-own. Si observa algunas de las herramientas de código abierto más destacadas, la calidad es muy alta.

Probablemente desee evitar proyectos que sean pequeños o que no estén completos. Puede ser tentador tomar algo que parece satisfacer sus necesidades, pero si fueran algo elaborado por un par de personas, nunca completado y sin apoyo, probablemente no valga la pena el esfuerzo. (A menos que esté dispuesto a trabajar en el código directamente).

¿Nunca has tenido fallas en los componentes patentados? He encontrado muchos errores en el software de compañías grandes y pequeñas. Este problema no es un problema con el código abierto per se, sino que se trata más de la madurez del proyecto.

Parece que quiere usar proyectos maduros que ofrecen soporte. Algunos proyectos de código abierto ofrecen soporte pagado o tienen una comunidad lo suficientemente grande como para que pueda obtener respuestas en un foro público. Tal vez debería hacer que los criterios de madurez y soporte sean prioritarios al elegir una biblioteca, ya sea cerrada o de código abierto.

Debe reconocer que asume más riesgos si decide utilizar un proyecto inmaduro o uno con soporte limitado. Como tal, debe determinar cuál es su plan de mitigación de riesgos. Puede realizar más pruebas en el software de terceros, por ejemplo.

Supongo que los problemas de licencia no son un problema aquí: al echar un vistazo rápido a Dapper, noté que solo tenía 2255 líneas de código legible y bien documentado . Es decir

• lo suficientemente grande como para que pueda invertir varios días o semanas para producir código de calidad comparable haciendo lo mismo
• lo suficientemente pequeño como para que pueda entender lo que hace y corregir cualquier error en ese código si aparece en producción

Si va a escribir algo así por su cuenta y "reinventar la rueda", tiene un riesgo mucho mayor de que su propio código muestre errores en la producción, y será realmente "difícil solucionarlos".

Lo que tienes que hacer aquí, sin embargo, si se introduce un trozo de código abierto como en su proyecto, entonces usted tiene que tomar la responsabilidad completa para ese código, al igual que si hubiera escrito por ti mismo. Asegúrese de que el código esté en un estado en el que pueda mantenerlo, si es necesario. No culpe a "los autores" de ese código si algo no funciona como se esperaba.

En uno de nuestros proyectos, nosotros también introdujimos algunos componentes de código abierto, desde tamaños pequeños como Dapper hasta bibliotecas que tenían alrededor de 20K a 30K líneas de código. Tuvimos siempre que hacer algunos cambios, corregir algunos errores, reducir el tamaño de algo, etc., pero que estaba bien, ya que esperábamos. Incluso el tiempo para la depuración incluido, el uso de código abierto nos ahorró mucho trabajo.

Una cosa para pensar aquí: en su caso, usted menciona que existe una alternativa ampliamente aceptada de un gran proveedor disponible (MS Entity Framework, ¡por el cual no tiene que pagar ninguna tarifa de licencia adicional!). No desea usarlo debido a consideraciones de rendimiento. Realmente recomiendo no dejar que el rendimiento sea el único o principal punto a considerar. Las preguntas que debe hacer aquí: ¿Dapper tiene toda la funcionalidad que necesita ahora y durante la vida útil esperada de su software? ¿O puede prever que alcanzará los límites de Dapper rápidamente y tendrá que agregar muchas funciones faltantes a su alrededor, lo que probablemente no tendría que haber hecho si hubiera decidido usar EF en primer lugar? Si este es el caso, recomendaría no usar Dapper. También pregúntese: ¿EF realmente no es lo suficientemente rápido para su aplicación,

Según lo veo, es un acto de equilibrio.

Si se vuelve dependiente de un proveedor, es casi seguro que el soporte desaparecerá pronto.

• Debido a que tienen programadores que pagar, deben seguir haciendo nuevas versiones y asegurarse de que las antiguas sean imposibles de obtener y de que ya no funcionen (en plataformas más nuevas) para que las nuevas tengan un mercado.

• Si no pueden vender lo suficiente para justificar un modelo de negocio, lo pasan de la compañía A a la compañía B a C, cada uno de los cuales lo cambia lo suficiente, así que de nuevo, no puede usar el nuevo sin reprogramación, y puede ' No consigas el viejo que funciona.

• Simplemente deciden que ya no lo apoyarán porque es demasiado problema y no hay dinero en ello. Todo el dinero está en nuevas aplicaciones.

Entonces, si desea construir algo que no tenga que reescribirse continuamente cada pocos años, el código abierto puede ser su amigo.

Creo que es prudente si se realiza la debida diligencia suficiente y parece que ya ha hecho algunos deberes con respecto a la historia y la actividad de un proyecto en particular. La capacidad de ampliar / agregar funciones en el código fuente también es un gran profesional. Con suficientes pruebas, puede minimizar el riesgo en el lado negativo. Es difícil comprender completamente todas las dependencias en su código, pero al menos en ese caso podrá depurar completamente y ver el código si es necesario.

Pregúntele a la gerencia por qué había fallado antes, ¿se realizó la debida diligencia suficiente?

jquery tiene la opción de usar la licencia MIT, por lo que muchos sitios web comerciales y gubernamentales también usan jquery. ¡El sitio web de Microsoft también usa jquery! Entonces la preocupación es la licencia. Evitar el uso de GPL / LGPL es suficiente.

"¿Cuánto tiempo para solucionar un defecto reportado?" Después de informar el error, puede solucionarse en minutos, horas o días. Para una situación urgente, el personal puede simplemente "git pull" para obtener la fuente y compilarlo él mismo. Simplemente informa la versión como "v1.2.3-101-gd62fdae" a la administración, que es rastreable.

El código abierto es realmente sobre legalidades, no sobre la calidad del código. Hay buenos y malos productos de código abierto, así como hay buenos y malos de código cerrado. Creo que su dilema es si usar un proyecto desarrollado por una comunidad de voluntarios.

¿Está seguro de que el problema de gestión es un problema técnico?

Digo esto ya que mezclar el sistema operativo y la actividad comercial es un campo de minas legal, y más de un gerente ha recibido un "Por favor explique" del equipo legal / CEO o, lo que es peor, de otra organización. La mayoría de los gerentes que conozco, incluso aquellos que adoptan activamente el software del sistema operativo, son (con razón) muy cautelosos para comprender completamente las situaciones legales a las que exponen el origen. Si adopta el software del sistema operativo y realiza cambios, está obligado a devolver esos cambios a la comunidad. En algunos casos, esta obligación es legal, en otros moral. En algunas licencias de sistema operativo, todo lo que haces se convierte en sistema operativo simplemente al vincularlos.

Desde un punto de vista técnico, en realidad es solo una decisión entre los productos de la competencia. Haga algunas preguntas básicas. ¿Puede obtener el soporte que necesita para el paquete que elija? ¿Cuánto tiempo para solucionar un defecto reportado, cuánto costará por desarrollador, por año o uno, etc. El sistema operativo tiene muchos 0 en la columna $, pero a menudo tiene espacios en blanco en los demás, solo usted y su jefe pueden decidir si los 0 superan los espacios en blanco o no.

Y otro punto para recordar: "Nadie fue despedido comprando IBM". (es decir, la gerencia habla de "Si gasta mucho dinero, debe ser un producto mejor que uno que sea gratuito"