angle-uparrow-clockwisearrow-counterclockwisearrow-down-uparrow-leftatcalendarcard-listchatcheckenvelopefolderhouseinfo-circlepencilpeoplepersonperson-fillperson-plusphoneplusquestion-circlesearchtagtrashx

No dude en reinventar la rueda si quiere que su software con componentes open source viva más tiempo

La vida útil de muchos componentes de open source puede ser corta. Escribe el tuyo si quieres asegurarte de que tu software siga vivo.

10 marzo 2020
En Flask
post main image
https://unsplash.com/@neilsoniphotography

El problema: un cliente quiere una aplicación con una cierta funcionalidad y la quiere para ayer. Lo que hace es buscar una solución plug-and-play, librerías y/o extensiones. Le dices a tu cliente que puedes hacerlo, el cliente está contento, lo haces. Por ejemplo, tomas Wordpress, seleccionas y configuras algunos plugins. ¿Problema resuelto o no?

Sí, el problema está resuelto, pero ¿por cuánto tiempo? Después de algunos meses, Wordpress se actualiza debido a una vulnerabilidad. Entonces, de repente, algunos plugins o temas ya no funcionan. Entonces PHP se mueve a PHP 7.4 y de nuevo algunos plugins o temas ya no funcionan. Al final esto obliga a usted o a su cliente a ejecutar versiones de software más antiguas, a menudo vulnerables. Pero esto también puede ser su modelo de negocio, las actualizaciones.

Las grandes empresas de tecnología obligan a cambiar para eliminar la competencia

Desarrollar un software que dure un par de años es muy difícil. Los cambios de estándares a menudo son iniciados por grandes compañías de tecnología. Por supuesto que quieren cambiar los estándares. Lo llaman mejora, lo llaman progreso, pero es simplemente esencial para su negocio añadir nuevas características, y descontinuar las antiguas. Es una manera perfecta y legítima de eliminar la competencia.

Por ejemplo, miren lo que Google está haciendo con Android. Cada año lanzan una nueva versión. Y todos los fabricantes de teléfonos deben seguir. ¿La nueva versión es mejor? La mayoría de las veces, no! Hacen grandes reescrituras de ciertas partes del código, así que si has tratado de entender y te has acostumbrado a las partes internas de la versión X, tu conocimiento no vale nada cuando salga la siguiente versión. Sí, también introducen nuevas vulnerabilidades, pero son sólo errores. Una compañía de software multimillonaria, por supuesto, no tiene los recursos para analizar y probar a fondo su software. Google también obligó a los sitios web a usar HTTPS. Lo sé, para mucha gente no tecnológica esto es una buena idea. Pero ahora muchos sitios web usan certificados de Letsencrypt, otra dependencia. Y los competidores de Letsencrypt no están permitidos, ¡gracias a todos!

Los desarrolladores de Open source crean el cambio

Quiero declarar que estoy muy contento con la disponibilidad del software open source . Respeto mucho a los desarrolladores y comunidades de open source . Sin ellos, el software que estamos usando hoy en día sería totalmente diferente. El software Open source obliga a las grandes empresas tecnológicas a pensar en los cambios, a seguir desarrollando nuevas versiones, a seguir adelante. De muchas maneras, los desarrolladores de open source crean cambios a menudo sin que ellos lo sepan.

La vida útil del software open source es a menudo más corta que la del software comercial

Si usas el software open source para construir tus aplicaciones tienes muchas razones para ser muy cuidadoso. Como mucha gente ha declarado, es muy difícil hacer dinero con el software y los proyectos de open source . El software Open source a menudo es desarrollado por una o unas pocas personas porque lo necesitaban para algo y luego lo comparten con el mundo, de hecho regalándolo. Muchos desarrolladores esperan que otras personas se involucren en su proyecto, pero muchas veces este no es el caso. Después de algún tiempo el desarrollador comienza a trabajar en otros proyectos, o consigue un trabajo que consume mucho tiempo y no tiene tiempo para mantener su software. Puedes llamar a esto el lado oscuro del software open source .

Veamos el software que utilizo para este sitio web

Este sitio web está construido con Python 3, las extensiones framework Flask, algunas extensiones Flask , SQLAlchemy, Bootstrap 4, jQuery, MariaDb. ¿Sobrevivirá Python 3 los próximos cinco años? Eso espero. Python 2 fue un error porque faltó la funcionalidad esencial. Los mantenedores de Python decidieron hacer Python 3 no compatible con Python 2. Por esta razón Python 2 debería seguir viviendo como un lenguaje independiente de Python 3, pero la comunidad decidió no apoyarlo más. No es bueno, pero puedo entender esto. La razón principal es que la comunidad no está haciendo dinero para apoyar a Python así que van por Python 3. Python 2 es un muy buen ejemplo de lo que puede ir mal con el software open source .

¿Sobrevivirá Flask los próximos cinco años? Eso espero, pero tengo miedo. El creador y principal desarrollador de Flask puede querer dedicar su tiempo a otros proyectos en los próximos años. ¿Pueden otras personas hacerse cargo? No estoy convencido. Las extensiones de Flask son otra cosa. Son típicamente desarrolladas por individuos. Flask se introdujo en 2010 y ya hay un gran número de extensiones que no se han actualizado en años, ¿cuál será el destino de las extensiones que está incluyendo con su producto hoy en día?

Lo mismo ocurre con SQLAlchemy, una hermosa pieza de software, ORM como debe ser. Pero, ¿qué pasará cuando el creador decida dejarlo y hacer otra cosa? Bootstrap es open source y parece que tienen una política de avanzar rompiendo las versiones anteriores. Ahora estoy en Bootstrap 4 pero asumo que usted estaba en Bootstrap 3 y tuvo que migrar a Bootstrap 4. No es una tarea fácil. Bootstrap ya anunció la versión 5, que funcionará sin jQuery. Estoy esperando esta migración... NO.

jQuery es muy usado pero tratará de mantenerse al día con los cambios forzados por la gran tecnología. Sólo puedo esperar que tengan la capacidad de hacerlo. Proyectos como jQuery-UI y jQuery-Mobile están más o menos muertos. Y luego está MariaDb. Creo que están aquí para quedarse al menos cinco años porque entregan un producto muy bueno. También creo que Oracle quiere que existan ya que estimulan el desarrollo de Oracle MySQL . MariaDb también vende soporte, hace dinero, muy importante.

¿Debería usar el software open source para desarrollar su próxima aplicación?

¿Es mejor el software de las organizaciones comerciales? En muchos casos la respuesta es no. Pero recibes soporte y es esencial que se mantengan actualizados. Aún así, creo que es una buena elección usar componentes open source para crear nuevo software. Pero sólo si primero investigas a fondo el problema de la vida útil de los componentes. Y, por supuesto, debes comprobar la licencia antes de cualquier otra cosa.

Minimizar las dependencias de riesgo escribiendo sus propios componentes

Hace muchos años me hice cargo de un proyecto que estaba escrito en Perl. Cuando llegó PHP construí mi propio pequeño framework y lo convertí en PHP. Como no usé ninguna biblioteca, todo estaba bajo mi control. Afortunadamente PHP parecía ser razonablemente compatible con las versiones anteriores, lo que significa que no fue mucho esfuerzo para migrar a las nuevas versiones. Muchos PHP framework vinieron y se fueron, pero mi software PHP sigue funcionando. Pero, por supuesto, sólo pudo sobrevivir porque yo estaba allí. A menudo veo en sitios web como Stackoverflow comentarios de que no se debe reinventar la rueda. Pero desarrollar tus propios componentes a menudo NO es reinventar la rueda!

  • puedes usar el conocimiento de proyectos similares ya existentes
  • puedes dejar fuera la hinchazón
  • puedes añadir la funcionalidad que falta en lugar de luchar contra el código de otro.
  • puedes saltarte los códigos difíciles de entender de los demás
  • puede actualizar sus componentes usted mismo en lugar de esperar a que otros
  • se aprende mucho mirando el código de otros

Leí en Internet que algunas personas piensan que es una especie de arrogancia cuando alguien decide escribir su propio componente. Estoy totalmente en desacuerdo, no hay blanco y negro y depende de ti o de tu equipo tomar la decisión de cuándo construir tu propio componente. Hay muchas razones para no hacerlo, pero también muchas razones para hacerlo. Pésalos con cuidado.

Dos componentes que construí recientemente: datepicker y Jinja Bootstrap macro

En un proyecto anterior utilicé el datepicker jQuery . Bien, pero... después de un tiempo necesitaba una funcionalidad como pasar a otro mes sin seleccionar una fecha. Ese fue el comienzo de muchos dolores de cabeza para trabajar alrededor de esta y otras limitaciones todo el tiempo. Para este sitio web también necesito un datepicker, debe estar integrado con Flask y WTForms y debe adherirse al Content Security Policy. Esto último puede resolverse exportando los parámetros del datepicker desde Python como application/json.
El macro Jinja Bootstrap debe facilitar la generación de todo tipo de formularios, debe ser flexible y soportar un amplio rango de campos incluyendo mi propio datepicker. Odio construir formas "a mano", es decir, poner todos los campos de la forma por separado en una plantilla cuando con un poco de esfuerzo extra en el macro esto se puede hacer sólo escribiendo:

{{ bootstrap_form(demo_form, id='demo_form') }}

Porque considero que ambos componentes son vitales para mis futuros esfuerzos, decidí escribir ambos yo mismo.

Resumen

Cuando construyes tu software con componentes open source a menudo tomas más riesgos que usando componentes comerciales. No escuches a los demás, toma tus propias decisiones y no tengas miedo de escribir tus propios componentes. Cuando escribes tus propios componentes la regla principal es mantenerlos legibles para que otros puedan entenderlos. Un problema con muchos componentes open source es que están optimizados. Eso está bien, pero la optimización a menudo no se traduce en legibilidad. Las computadoras y los teléfonos de hoy en día son mucho más poderosos y las optimizaciones sólo deben ser consideradas cuando son absolutamente necesarias.

Enlaces / créditos

How to make money from open source software
https://www.cio.com/article/3178621/how-to-make-money-from-open-source-software.html

Open Source, SaaS and Monetization
https://lucumr.pocoo.org/2019/11/4/open-source-and-saas/

REINVENT THE WHEEL | meaning in the Cambridge English Dictionary
https://dictionary.cambridge.org/dictionary/english/reinvent-the-wheel

Leer más

Flask

Deje un comentario

Comente de forma anónima o inicie sesión para comentar.

Comentarios

Deje una respuesta.

Responda de forma anónima o inicie sesión para responder.