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

13

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?

Señor jefferson
fuente
15
ASP.NET y su pila son de código abierto.
Andrew T Finnell
11
"¿Es imprudente usar código fuente abierto en mi proyecto que no conozco / entiendo tan bien como lo hago con mi propio código?" ¿A diferencia de las bibliotecas de código cerrado que son cajas negras?
usuario16764
55
@ AndrewFinnell: No por la definición propia del movimiento FLOSS.
tdammers
66
wrt el proyecto de sistema operativo específico en el que está pensando, puede ser interesante que StapExchange utilice Dapper ...
Marjan Venema
44
Esta no es una pregunta técnica, no se trata de cuál es mejor. ¿Cuál saldrá mal? MFC está muerto, XP estará muerto en menos de 2 años, etc. El proyecto gratuito y de código abierto no morirá si son buenos, ya que usted u otra persona pueden hacerse cargo de ellos. Se trata de quién será culpado. Si elige Microsoft, si será imprevisto, o Microsoft fallará. Si optas por Free / opensource será tu culpa.
ctrl-alt-delor

Respuestas:

20

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.

StriplingWarrior
fuente
16

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.

Andrew T Finnell
fuente
2
+1 Estoy de acuerdo con todo eso, excepto donde dice que "(debería)" mirar NoSQL; cada solución de almacenamiento de datos NoSQL, hay muchas, tiene un conjunto particular de compensaciones con una base de datos relacional SQL "estándar", por lo que es difícil decir "debería" sin mucha información. Algunas veces son buenas compensaciones, y otras no, pero no se pueden hacer declaraciones generales al respecto. "NoSQL" es solo una marca de basura en torno a un montón de tecnologías con poco en común además de no ser el esquema de almacenamiento de datos más común.
Donal Fellows
Pero definitivamente estoy de acuerdo con todo lo demás que escribes. El buen OSS quita mucho esfuerzo de los hombros del desarrollador de trabajo común (¿y quién querría usar un mal OSS?)
Donal Fellows
Dapper es complejo porque está generalizado. Si escribiera mi propia solución, haría una gran cantidad de código de conversión de conjunto de datos a objetos (es decir MyClass.Property = set.Tables[0].Rows[i]["Property"].ToString()).
Sr. Jefferson
Una vez que comience a ingresar a su dominio comercial, será más difícil encontrar --OSS-- cualquier cosa que satisfaga sus necesidades. A menos que el negocio de Microsoft sea tu negocio. (pero me gusta el resto de lo que dijiste)
ctrl-alt-delor
@richard Algunas de mis respuestas pueden no estar claras. Su declaración es lo que también estoy diciendo. ¿Por qué centrarse en las piezas que se han resuelto una y otra vez como ORM? Centrarse en el dominio empresarial. ORM no es un dominio comercial a menos que esté vendiendo un producto ORM.
Andrew T Finnell
15

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.


fuente
3
+1: No puedo decir que estoy totalmente de acuerdo, pero se argumenta demasiado bien que no .....
mattnz
14
"No existe el presupuesto de proyecto de código abierto". es falso Google tiene un presupuesto para proyectos de código abierto, y Red Hat Inc., por ejemplo, no puede administrar su negocio si no pone suficientes codificadores en su software. ¿Y qué hay de esto? microsoft.com/opensource/directory.aspx
ONOZ
14
No estoy de acuerdo con una sola palabra que hayas dicho.
Avio
11
Todos estos puntos se aplican igualmente a proyectos de código cerrado. Agregar bibliotecas / marcos de código cerrado de nicho agrega diversidad. La tecnología patentada anterior se abandona si no les hace ganar dinero. Todavía puede configurar IIS para que sea su propia mariposa única. El comentario de calidad ignora que el proyecto de código abierto puede ser más grande que (algunos) proveedores. Y el mundo de los negocios está altamente politizado, especialmente con Microsoft.
Philip
3
He tenido la experiencia opuesta. Transportamos SQLite a un dispositivo y pudimos obtener soporte directamente del tipo que escribió la mayor parte. No hay forma de que hubiéramos obtenido ese nivel de servicio de una empresa de código cerrado. Algunos proyectos de código abierto son absolutamente más sólidos y tienen mejor soporte que algunos proyectos de código cerrado. Podría contar una historia sobre el uso del compilador de Microsoft C ++ "estándar de la industria" para OS / 2 y cómo fue el soporte para eso cuando Microsoft decidió rescatar OS / 2.
Gort the Robot
7

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).

Gort the Robot
fuente
7

¿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.

M. Dudley
fuente
6

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,

Doc Brown
fuente
1
+1 por problemas de licencia. Compruebe cuidadosamente que el uso de algún componente de código abierto no lo obligará a abrir también su propio código. No creo que este sea el caso para la mayoría de código abierto, y si solo lo está utilizando para producir u hospedar su código, habrá más disponible, pero vale la pena verificarlo.
Lunivore
Incluso si el rendimiento es menos preocupante, el EF me da menos control. Introducir el almacenamiento en caché es un poco más difícil si se hace necesario en el futuro; Dapper sería más fácil encajar en una solución más personalizada, además de impulsar la necesidad de almacenar en caché más adelante en el camino en primer lugar.
Sr. Jefferson,
Por otro lado, querer una solución personalizada sobre el EF suena un poco como NIHS. Mi esquema de datos es bastante complejo con muchas relaciones (claves foráneas), y llegar al punto en que mi solución personalizada gestiona esas relaciones, así como el EF listo para usar, tomaría un tiempo.
Sr. Jefferson,
@ Mr.Jefferson: en serio, no puedo darle un buen consejo sobre cuál es la mejor solución en su caso, eso es algo que debe resolver por su cuenta. Solo estaba tratando de darte algunas pistas sobre qué considerar.
Doc Brown
+1. Trajiste algunos puntos muy excelentes con esta publicación. @ Mr.Jefferson: He estado usando Entity Framework durante algún tiempo y he tenido bastante éxito en la gestión del rendimiento mediante el almacenamiento en caché ad-hoc en repositorios específicos después de encontrar dónde están los cuellos de botella. Además, nuestro producto es bastante complejo, pero aún no he tenido que recurrir a escribir una sola consulta SQL. Siento que EF me ha dado mucho control.
StriplingWarrior
2

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.

Mike Dunlavey
fuente
1

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?

Llavero
fuente
No sé mucho sobre lo que pasó. Fue antes de llegar aquí.
Sr. Jefferson,
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 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.

linquizar
fuente
0

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.

Nemanja Trifunovic
fuente
-1

¿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"

Mattnz
fuente
55
Es irónico que IBM sea probablemente el mayor vendedor mundial de software basado en código abierto. Servidor http Apache, Eclipse, etc., etc.
James Anderson
77
Vender OSS no es ilegal. ¿Por qué sería?
tdammers
1
IBMS httpServer es puro apache, solo viene con un acuerdo de soporte.
James Anderson
2
Las cosas estan cambiando. Ahora la gerencia comienza a pensar que si usted hace que la compañía pague por un componente que otras compañías tenían gratis, usted es un idiota.
Avio
2
Las "otras columnas" rara vez están en blanco para código abierto. Siempre puede obtener soporte de consultores o proveedores de distribución o de alguien y también puede apoyarse a sí mismo. A menudo, hay más columnas en blanco para el software comercial, porque no conoce de antemano la calidad de su soporte y rara vez es tan útil como lo necesitaría.
Jan Hudec