¿Modifico código o hago una extensión?

Los problemas del Open Source

Con el fin de permitir la alteración del código estándar, desde siempre, Dynamics NAV ha sido open source, lo cual ha le ha otorgado una aurea de simplicidad precisamente debido a lo sencillo de alterar dicho código.

El código se alberga en la misma base de datos de Dynamics NAV sin ofuscar, con lo que el acceso a dicho código por parte de terceros, otros partners por ejemplo, ha sido siempre posible.

Éste, siempre ha sido un punto de discordia referente a la propiedad intelectual, ya que utilizar este código en beneficio propio por parte de otro distinto al creador, en España, es “causa penal”.

Como es lógico este modelo tiene ventajas e inconvenientes. La principal ventaja es la simplicidad nombrada anteriormente, además de la libertad del cliente final a la hora de sustituir a su proveedor. El principal inconveniente es el “upgrade” y cambios de versión del sistema. Recordemos que Microsoft está liberando un upgrade mensual.

Aunque Microsoft ha trabajado mucho en estos últimos tiempos en aras de favorecer la migración de código, no se ha conseguido automatizar al 100%, con lo que unos días de parada del sistema y la intervención de un técnico siempre es requerida.

Mucha parte de la “beauty of simplicity” de Dynamics NAV ha sido debido a su modelo Open Source

¿Sería Closed Source la solución?

El lenguaje de programación de Dynamics NAV, C/AL, no está orientado a objetos con lo que los programadores de Dynamics NAV no podemos ni sustituir ni complementar lo que el código estándar hace mediante la herencia de clases estándar en nuestras propias clases.

Sin embargo, C/AL está orientado a eventos, lo que significa que la mayoría de cosas que pasan durante la ejecución, desencadenan un evento, como por ejemplo: abrir o cerrar un formulario, insertar un registro en una tabla, modificar la información de un determinado campo, el registro de una factura, y así muchísimas más. Es lo que Microsoft ha denominado como Eventing.

Como programador ¿y si pudiera suscribirme a determinados eventos y asegurarme así ser llamado cuando ocurran? Esto me permitiría no tener que alterar el código estándar. Perfecto, esto son las extensiones. Es lo que se denomina decoupling, y este desacoplamiento permite que mi código sea totalmente independiente. Entonces, si es independiente ¿por qué debo hacerlo visible a los demás? Bienvenido a la discordia. Microsoft cierra el código de las extensiones, es decir, protege la propiedad intelectual del creador.

El modelo Closed Source tiene más implicaciones que las meramente técnicas, pues el creador debería depositar el código en una agencia de Escrow.

La discordia, Open vs Closed

La discordia viene porque algunos (veteranos) profesionales de Dynamics NAV estamos enamorados de esta “beauty of simplicity” que, por el hecho de ser open source, siempre ha caracterizado a Dynamics NAV, y, aunque nos encantan las extensiones, nos aterramos si pensamos que Microsoft puede algún día llegar a prohibir modificar código estándar, aunque si bien es cierto que no hay absolutamente ninguna noticia en este sentido.

Este pensamiento está fundamentado en que actualmente Dynamics 365 (Project Madeira) tiene extensiones, algunas de ellas programadas por la propia Microsoft, y es de suponer que Dynamics NAV 2017 va a seguir el mismo camino. Con esta acción, Microsoft está dejando de publicar código abierto en Dynamics NAV, que todos podíamos ver, estudiar y modificar, para pasar a liberar funcionalidades en modo de código cerrado.

¿Es Microsoft el único creador de funcionalidad que debería programar sin utilizar el modelo de extensiones?

Entonces qué, ¿modifico código o hago una extensión?

Si modifico código, va a ser rápido y simple, con lo que será barato, hasta que llegue el momento de hacer “upgrade” donde habrá un mínimo de intervención manual para poder mover dicho código. Con lo que lo de barato no va a ser cierto.

Si modifico código, va a facilitar que el cliente final pueda fácilmente cambiarse de partner, aunque esto podría entrar en conflicto con las leyes sobre protección de la propiedad intelectual.

Si hago una extensión, será algo más complejo de desarrollar, pero como anuncia la técnica del decoupling, tendré un código independiente que no altera el código estándar con lo que se está garantizando que los futuros upgrades serán 100% automáticos, sin intervención humana.

Además, como creador, estaré protegiendo mi propiedad intelectual aunque seguramente esto puede dificultar el hecho de que el cliente final pueda cambiar de partner al no tener el código fuente. Eso sí, deberé depositarlo en una agencia de Escrow.

¿Supondrá el modelo de extensiones otro cambio importante como lo fue el paso de Classic a Roles?

Mi opinión personal

Mi opinión personal es que las extensiones son fantásticas para los ISV, ya que favorecen la repetibilidad, su despliegue en multitenant y protegen la propiedad intelectual.

Son medianamente fantásticas para los VAR, ya que en ocasiones requieren lo mismo que un ISV, pero en ocasiones necesitan la “simplicity”, es decir, solucionarlo ahora, rápido y tocando código estándar que de otra manera sería imposible. Es decir, se necesita acceso al código fuente estándar para siempre. Sobre todo en los upgrades.

Son nefastas si las utiliza Microsoft, ya que desde siempre ha liberado funcionalidad en modo Open Source estándar, el cual podemos estudiar y alterar si conviene. Las extensiones, en este caso, no aportan ninguna ventaja.

Y para el cliente, depende. Si su solución se basa en un vertical especializado de un ISV seguramente le interesará el modelo de extensiones, ya que favorece la continua actualización y evolución independiente tanto de Dynamics NAV estándar como del vertical, al estar ambos “decoupled”.

Si su solución se basa en una personalización, es probable que lo que más le interese sea disponer del código fuente para asegurar la evolución de su Dynamics NAV. En este punto creo que lo más conveniente es el modelo de extensiones, por los motivos expuestos en el párrafo anterior, pero disponiendo del código fuente.

Como mantener la sincronía del código compilado que se está ejecutando con el código fuente entregado al cliente es complicado y difícil de comprobar por el cliente, éste debe ser cauteloso. Si no tiene la certeza de que este punto se va a cumplir, opte por el sistema tradicional, es decir, sin el uso de extensiones.

Bienvenido Project Madeira

project-maderia-try-preview

Aunque por el momento Project Madeira ofrece un 25% de toda la funcionalidad incluida en Dynamics NAV, me siento orgulloso de que haya sido ésta la plataforma escogida por Microsoft, de entre las muchas de las que dispone, para publicar su primer ERP en la nube junto a Office 365, Dynamics CRM y Power BI.

Lejos de parecer una amenaza, que aunque sí podría llegar a serlo para ciertos implantadores generalistas, debe tomarse como una oportunidad sobre todo para ISV o implantadores especialistas que, a través de la programación de extensiones incorporado en Dynamics NAV 2016, pueden rentabilizar su IP.