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

13

Estoy considerando usar algún código de código abierto en mi aplicación web ASP.NET (específicamente dapper ). La administración no es un fan, porque el código abierto se ve como un riesgo que nos ha mordido antes. Al parecer, los desarrolladores anteriores han tenido que volver a escribir las cosas después de fallar los componentes de código abierto.

Los pros parecen ser:

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

Contras:

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

¿Cuál es el consenso aquí? ¿No es prudente utilizar código de código abierto en mi proyecto que no conozco / comprendo tan bien como hago mi propio código?

    
pregunta Mr. Jefferson 30.05.2012 - 02:40

11 respuestas

20

Es una elección que deberás tomar en función de las circunstancias específicas. Puedes mitigar tus riesgos mediante:

  • probando el marco a fondo, evitando la posibilidad de que sorpresas desagradables te muerdan en un entorno de producción, y
  • usar el acoplamiento suelto para minimizar la cantidad de código que depende directamente del marco, para que pueda cambiar a su propia implementación si es necesario sin volver a escribir todo el producto.

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

    
respondido por el StriplingWarrior 30.05.2012 - 02:53
16

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

Una vez que comience a ingresar al dominio de su negocio, será más difícil encontrar un OSS que satisfaga sus necesidades. Pero no es necesario 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 escribiendo desde cero? Además, podría (debería?) Mirar siempre fuera de la caja las soluciones NoSQL mientras está en ello.

Incluso Linus admitió que intentó encontrar una solución de 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 reescribirlo todo y quise centrarme en resolver problemas del mundo real. La mayoría de los problemas que deben resolverse en una empresa son específicos del dominio. Encuentra maneras de escribir menos código, no más.

    
respondido por el Andrew T Finnell 30.05.2012 - 04:18
15

Nota: No soy empleado de Microsoft. La opinión es completamente personal. Muchos pensamientos son de los últimos 5 a 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 el código de terceros (fuente abierta o no) a menos que no haya otra opción. El monocultivo es gratificante, ya que está siendo llevado por un gran vendedor, y la cantidad de usuarios que repiten la misma experiencia es siempre lo suficientemente grande como para obtener ayuda y encontrar una solución.

Ciudades fantasma: El problema con el código abierto en 2012 es que ya no es 2000 o 2005. La cantidad de proyectos sigue creciendo, cuando la cantidad de usuarios, las adopciones, los contribuyentes es aproximadamente la misma que hace años. Las audiencias se alargan. Muchos proyectos interesantes quedaron obsoletos, abandonados. No hay tal cosa como presupuesto de proyecto de código abierto. Entonces, cuando el interés termina, no hay nadie que anuncie honestamente que el soporte ha terminado y que se apagan las luces. Los proyectos nunca mueren para dejar la atención pública centrada en algo mejor y nuevo. Así 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 cambia a casos minoritarios. Después de tener 20 pasos, como elegir la configuración de seguridad, usar una versión particular, un marco, un complemento, etc. Su solución se convierte en una combinación única y única de detalles a nivel mundial. Buscar en Google solo ayudará a demostrar cuán raro o único es el problema. Siempre es un problema de autoservicio, puramente técnico. Ni siquiera relevante para el negocio real.

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

Consenso: Estás preguntando si hay consenso. Posiblemente no. Desafortunadamente, 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 y antitecnológico. Mi consenso personal: apégate a Microsoft.

    
respondido por el user7071 30.05.2012 - 05:14
7

He trabajado en una serie de proyectos exitosos para una gran empresa que utiliza partes sustanciales de software de código abierto. En particular, he usado Curl, SQLite y Webkit para una empresa muy grande en proyectos exitosos que se enviaron a los usuarios finales. Como han dicho otros, solo se trata de tener cuidado con las licencias y, idealmente, tener un abogado que 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 usted abra el código fuente de su propio código, y generalmente solo tiene algún tipo de cláusula de atribución. Las licencias de estilo GPL requieren que usted abra el código fuente de su propio código. La mayoría de las empresas (incluida la mía) generalmente lo ven con recelo, por lo que querrá evitar el estilo GPL. Dapper parece usar la licencia de Apache, que es 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 de borde interesante en el que puede usarlos sin abrir su propio código si restringe el acceso a un límite binario. (Es decir, acceda 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, no es más probable que el código fuente abierto tenga errores o fallos que las soluciones de pago o, en este caso, las soluciones de rollo propio. Si nos fijamos en algunas de las herramientas de código abierto más importantes, la calidad es muy alta.

Es probable que desee evitar proyectos que sean pequeños o que no estén completos. Puede ser tentador agarrar algo que parece satisfacer sus necesidades, pero si fueron algo que un par de personas armaron, nunca se completaron y no se respaldan, es probable que no valga la pena el esfuerzo. (A menos que esté dispuesto a trabajar en el código directamente).

    
respondido por el Steven Burnap 30.05.2012 - 03:31
7

¿Nunca ha fallado algún componente propietario antes? He encontrado un montón de errores en el software de empresas 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 quieres 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 establecer prioridades de madurez y criterios de respaldo al elegir una biblioteca, ya sea de código abierto o de código abierto.

Debe reconocer que está asumiendo un mayor riesgo 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.

    
respondido por el M. Dudley 30.05.2012 - 13:52
6

Suponiendo 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ínea de código legible bien documentado . Eso es

  • lo suficientemente grande como para que pueda invertir varios días o semanas para producir un código de calidad comparable haciendo lo mismo
  • lo suficientemente pequeño para que pueda entender lo que hace y corregir cualquier error en ese código si aparecen 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 de solucionar" " ya sea.

Lo que debe hacer aquí, sin embargo, si introduce una pieza de código abierto en su proyecto, entonces usted tiene que asumir toda la responsabilidad de ese código , como si lo hubieras 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, también presentamos 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 para realizar algunos cambios, corregir algunos errores, reducir el tamaño de algo, etc., pero estuvo bien, ya que esperábamos eso. Incluso el tiempo para la depuración incluido, usar código abierto nos ahorró mucho trabajo.

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

    
respondido por el Doc Brown 30.05.2012 - 08:17
2

Como yo lo veo, es un acto de equilibrio.

Si dependes de un proveedor, es casi seguro que el soporte desaparecerá en poco tiempo

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

  • Si no pueden vender lo suficiente como para justificar un modelo de negocio, lo pasan de la compañía A a la compañía B a la C, cada uno de los cuales lo modifica lo suficiente, de nuevo, no puede usar el nuevo sin reprogramación, y no puede obtener el antiguo que funciona.

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

Entonces, si quieres construir algo que no tenga que ser reescrito continuamente cada pocos años, el código abierto puede ser tu amigo.

    
respondido por el Mike Dunlavey 30.05.2012 - 14:22
1

Creo que es prudente si se realiza la diligencia debida y parece que ya has hecho algunos deberes con respecto a la historia y la actividad de un proyecto en particular. La capacidad de ampliar / agregar características en el código fuente también es un gran profesional. Con pruebas suficientes puede minimizar el riesgo en el lado de la estafa. Es difícil entender 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.

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

    
respondido por el Turnkey 30.05.2012 - 03:00
0

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 usa jquery también! Así que la preocupación es la licencia. Evitar el uso de GPL / LGPL es suficiente.

"¿Cuánto tiempo se tarda en solucionar el problema?" Después de informar el error, puede solucionarse en minutos, horas o días. Para una situación urgente, el personal puede simplemente "tirar" 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.

    
respondido por el linquize 30.05.2012 - 04:47
0

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

    
respondido por el Nemanja Trifunovic 30.05.2012 - 14:49
-1

¿Está seguro de que los problemas de gestión son problemas técnicos?

Digo esto porque mezclar el sistema operativo y la actividad comercial es un campo legal de la mina, 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 OS, son (con razón) muy cautelosos para entender completamente las situaciones legales a las que están exponiendo 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 vinculándolos.

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

Y otro punto para recordar: "Nadie fue despedido de comprar IBM". (es decir, la gerencia habla por "si gastas mucho dinero, debe ser un producto mejor que uno que sea gratis"

    
respondido por el mattnz 30.05.2012 - 03:22

Lea otras preguntas en las etiquetas