He creado un panel de control (dashboard) que lista herramientas low-code de código abierto, disponibles como repositorios públicos en GitHub. Espero que sea útil para entender mejor la evolución del mercado low-code y para ayudar a seleccionar una herramienta que se ajuste a vuestras necesidades.
El método de selección se basa en los siguientes criterios de inclusión:
- Repositorios que se declaran como proyectos low-code
- Repositorios con más de 50 estrellas
- Repositorios activos (último commit no más antiguo de 1 año)
- La herramienta debe generar algún componente de una aplicación software. Esto incluye tanto componentes IA, como interfaces de usuario o hasta aplicaciones completas
y criterios de exclusión:
- Repositorios sin información en inglés
- Repositorios creados solo para alojar el código fuente de un artículo científico
- Repositorios que son listas awesome o colecciones de recursos o de ejemplos varios
La lista final es la intersección de los criterios anteriores. También ha sido curada manualmente para eliminar proyectos que usan el término low-code en un sentido diferente al que nos referimos cuando hablamos de low-code en el contexto del desarrollo de software.
Una búsqueda inicial con los criterios de inclusión resultó en un sorprendente total de 301 candidatos. Pero hace unos años (febrero 2022) escribí un post quejándome de la falta de herramientas low-code de código abierto. ¿Me equivocaba? ¿Ha cambiado drásticamente la situación en los últimos dos años? ¿Qué está pasando?
Número real de herramientas low-code
Si bien es cierto que había 301 herramientas que satisfacían los criterios de inclusión, el panel de control solo lista 151, una vez que eliminamos aquellas que no cumplen con los criterios de exclusión. Pero 151 sigue siendo bastante comparado con lo que cubría en el post anterior. Así que decidí ver cuántas de estas herramientas low-code estaban basadas en modelos. O simplemente mencionaban la palabra modelos (o derivados).
Resulta que solo 9 de las 151 herramientas low-code afirman usar algún tipo de modelo. Ni siquiera 9 si eliminamos un par que solo se dirigen a componentes de IA y fusionamos tres repositorios de una misma plataforma. Por supuesto, BESSER es una de las pocas excepciones 😇.
Y para mí, este número mínimo es el que importa. Como sabéis, mi visión del low-code está vinculada a la de los enfoques basados en modelos, así que las herramientas llamadas low-code donde no hay control sobre cómo se genera dicho código no son lo que yo realmente llamaría low-code. Así que en este sentido, todavía creo que hay una falta de herramientas low-code de código abierto, como mínimo tal y como yo las entiendo.
Como siempre, cuando digo modelado, me refiero a “modelado explícito”. Todas las herramientas usan algún tipo de representación interna (es decir, modelo) pero solo unas pocas deciden hacer estos modelos explícitos y permitir que los usuarios los manipulen. Y aún menos de esas herramientas mencionan UML (a pesar del importante papel de UML en low-code). Solo dos de las herramientas low-code hacen referencia a UML en su descripción.
Una comunidad fragmentada
Ten en cuenta que no estoy diciendo que no haya otras herramientas model-driven o generadores de código en GitHub más allá de las herramientas en el panel de control. De hecho, hay algunas. Por ejemplo, Telosys (que también cubrimos aquí). Pero Telosys se define como un “generador de código lightweight y pragmático“, no como una herramienta low-code. Una vez más, la diversa terminología en nuestra área hace que un dominio pequeño sea aún más pequeño y oculta herramientas útiles a potenciales usuarios que están usando las palabras clave “incorrectas”.
Para leer más sobre la relación entre las comunidades low-code y model-driven, echa un vistazo a nuestro trabajo sobre la adopción de la terminología Low-Code en publicaciones de modelado.
Mucho no-code en low-code
La distinción entre low-code y no-code es difusa. Y para muchas herramientas, tiene sentido venderse a ambos mercados. No hay duda que las herramientas piensan lo mismo, ya que un tercio de las herramientas low-code también se presentan como herramientas no-code.
La IA está emergiendo
Las herramientas low-code necesitan seguir las tendencias actuales y cubrir el desarrollo de software inteligente. Y también incorporar cada vez más IA en la propia herramienta para avanzar hacia una estrategia de low-modeling. Podemos observar esta tendencia ya que un pequeño, pero significativo, número de herramientas comienzan a incluir IA en su oferta low-code (que es, como ya sabes, un enfoque clave de BESSER)
Otros aspectos interesantes
- Un número significativo de herramientas low-code son chinas y se dirigen solo a usuarios chinos (ya que no hay ningún esfuerzo por tener documentación en inglés, ni siquiera en el readme). Como no hablo chino, no puedo profundizar realmente en las características de estas herramientas, pero parece que el low-code tiene una fuerte presencia ahí. Dado los criterios de exclusión, estas herramientas no forman parte del panel de control, pero fue uno de los criterios de exclusión más utilizados para bajar de las 301 iniciales a las 151.
- Hay muy pocas herramientas low-code en Python (ver el final del panel de control para algunas estadísticas globales como ésta). La mayoría de las existentes son herramientas low-code dirigidas a componentes específicos de IA, no plataformas low-code para un desarrollo completo de aplicaciones. Una vez más, BESSER es una de las pocas excepciones, pero en un mundo cada vez más impulsado por la IA, me gustaría ver más herramientas low-code adoptando Python y, por lo tanto, facilitando la interacción con bibliotecas de machine learning e IA.
- Si miras la distribución de herramientas por año de creación, verás que algunas herramientas fueron creadas antes de que se acuñara el término low-code. Esto significa que dichas herramientas vieron la ola de marketing de low-code y decidieron cambiar su marca para ganar visibilidad.
- El propio panel de control fue construido con la ayuda de Cursor. Como de costumbre, fui más rápido que si lo hubiera hecho solo, pero todavía sufro de sus alucinaciones (Cursor sugirió usar un CellRenderer que tenía mucho sentido pero que, desafortunadamente, no existía y para un par de errores tuve que ir a la manera “tradicional” y encontrar yo mismo la solución en StackOverflow y los foros de Streamlit). Pero en todo caso, dadas mis limitaciones temporales (y, porqué no confesarlo, mis limitaciones como programador), sin la ayuda de un asistente inteligente, este dashboard estaría todavía durmiendo en un cajón.
Explora el panel de control
Explora el panel de control, juega con él y hazme saber qué piensas. Aquí o en el repositorio de GitHub
Últimos comentarios