Sobre cerrar SOA4J y la resolución automática de problemas en Java


Cuando llegó la crisis pasé de trabajar 12 horas al día a trabajar solo 6, fue un palo importante porque estábamos creciendo en Artifact como la espuma pero varios proyectos se detuvieron y una carga equivalente no llegaría hasta 2015… fijaros hasta que punto crecíamos que incluso trabajando la mitad los beneficios seguirían aumentando a un ritmo de entre el 20% y el 70% anual hasta 2015… ¡y trabajabamos la mitad!.

Con ese tiempo libre que conseguí desde 2008 decidí lanzar 3 proyectos internos: la LNRC, BalanceK y SOA4J. SOA4J era un proyecto web que contenía varias aplicaciones diferentes para facilitar la resolución de problemas de aplicaciones, imagínate aquel libro médico de 1980 (azul, muy grueso) donde venían infinidad de workflows para identificar ante tus síntomas el problema físico que te estaba afectando… pues programé eso pero para aplicaciones en Java y funcionaba muy bien para los problemas típicos y bastante bien para fallos más específicos, de hecho tenia un backend donde podía tunear las soluciones a los problemas como si fuera un helpdesk pero alimentando los workflows dinamicamente para que la siguiente resolución ya contara con esa mejora… una gozada, a día de hoy (2017) no hay nada igual, el IBM Support assistant estaba a mucha distancia de lo que podías hacer con SOA4J, no solo año por año (comparando el estado de ambas apps en el mismo momento) sino que SOA4J iba dos o tres años por delante.

Eso de que no hubiera nada igual ya en 2016 me hizo pensar ¿realmente quiero esto? ¿realmente quiero permitir que cualquier programador junior o gerente sin conocimientos pueda resolver los problemas “one-shoteandolos” sin contar con expertos? NO!. De hecho puestos a pensar ¿como era posible que una solución hecha por una persona en España fuera mejor que la app oficial de IBM para este mismo tema?, y llegue a la conclusión de que solo existe un “half-hearted effort” por conseguir la resolución automática de problemas. Por ejemplo Oracle ni lo intenta y os aseguro que es más fácil de lo que parece.

Además en 2015 el resto de proyectos internos ya habían crecido (LNRC y BalanceK) y me consumían mucho tiempo, al mismo tiempo que los clientes tradicionales estaban volviendo a darnos más trabajo del que podiamos abarcar.

Así que sin verle más futuro a SOA4J decidí cerrarlo, obviamente sigo utilizando estas herramientas pero solo en proyectos para clientes… todavía alguno alucina cuando le enseño el analizador dinámico de invocaciones o el desgranador de trazas pero ¿venderías la solución a todos los problemas? ¿por cuanto? ¿lo licenciarias para que lo ripearan? ¿iba una empresa a aceptar pagar 5 millones por algo así? ¿algo que ni siquiera tiene un modelo de monetización detrás?… vivimos en un contexto corporativo donde “Compras” no se gasta 50€ en JRebel aun cuando ahorre un 20% de tiempo del programador, no es un contexto en el que nadie se plantee comprar algo como SOA4J.

Obviamente de haberse hecho SOA4J en otro contexto hubiera tenido una suerte diferente, pero este contexto es lo que hay y me gusta mucho vivir aquí, no todo es dinero.

Nota: Cuando inicialmente sacamos SOA4J lo llamamos Lady4J… no os perdáis los comentarios en TheServerSide