There is a lot of talk about NAV and “Open Source” these days. Lots of the talk is related to the new Extension model that Microsoft Dynamics 365 and Dynamics NAV 2016/2017 shares.
Let’s first get a few definitions in place:
“Open Source” – A piece of software where the source code is available to view and perhaps modify, but the original owner still controls vital aspects of the software.
“Free Software” – A piece of software where the source code is available for anybody to use, modify, give away, do anything you want, apart from taking ownership of the software.
“Object” – Every piece in NAV/365 is an object. That can translate to a table, a UI page, a report or other internal pieces. Each Object has an ID and the NAV/365 license defines access to the Object.
“Business Logic” – The part of NAV that is built with Objects. This is the customer table, the general journal, the sales invoice posting routine.
“Runtime” – The system that actually runs on the computers, the runtime executes the objects and makes it all comes to life.
The source code for the business logic in Dynamics NAV is available for those who has a license to that. There are several levels of source access:
- Customers can access partial sources if they have designer access to reports and pages
- Customers can access most sources if they have brought the “big” designer license.
- Partners have access nearly everything if they have a partner license.
- ISVs have access to their own “area” and can decide who (other partners) can access their objects.
That is neither open source or free software. This is privileged access to part of the source code of a closed sourced application. And the privileged is only “given” to the select few that either buy access or through employment at a NAV partner.
So stop calling it Open Source, please 🙂
There are even plenty of NAV pieces that has never been “open sourced” to anybody outside Microsoft. That includes the development environment, the runtime, the different add-ins, add-ons, ADCS, Toolbars, portals etc.
But from a practical perspective, the amount of source code access in NAV has historical been more than enough to give NAV its unique ability to be transformed into 1000s of industry solutions. And this has been a huge factor in making NAV the big success it is today, because, for many years, NAV lacked in functionality but made that up by being customizable.
Looking in from other software development platforms, the first question we are asked is: Why is source code access necessary for this? If we look at DotNet, COM Objects or other ways of building software, customization can be performed without accessing and recompiling the original code?
The answer is found the programming model, NAVs two main issues:
- NAV has (until 2016) been missing an extension framework, meaning that there has never been an official way to trigger custom code from the standard application.
- NAV does not have an “official” API layer. There is no well defined public interface to NAV processes.
With NAV 2016 we got events that can be used for triggering custom code, and with NAV 2017, we have most of the trigger points that were missing in NAV 2016. Triggers can only be accessed from NAV code; there is no abstract public API layer giving us the ability to trigger NAV business logic from external code. In the old days, we had a library called C/Front which gave us database access to the native database but no business logic, and now we have web service access, but that only give us access to data a limited set of business logic.
So the solution has always been, to dig into the source, and modify NAV to fit the current customer’s requirements.
Wielding this sword has proven a powerful weapon for many NAV developers, a good NAV developer is well traversed in the source of the standard application and can make very cools customizations in a short time frame.
Losing the “Open Source” aspect of NAV, could easily sound as you have to return the sword to Microsoft and be left with a dull little dagger that can’t even glow in the dark when there are orcs around.
But wait? Are you losing anything? Some NAV developers are worried that they will lose the ability to fix bugs in the core product, which in fairness, used to be an awesome power often wielded ten years ago. But with the rapid CU’ing going on, most bugs that I have discovered turned out to be fixed already looking at the latest CU’s change log or they turned out to be bugs in the runtime environment that I never had access to fix anyway.
The current problem with extensions is that they are objects, but do not expose an API, does not give any public interface, they just sit there in the runtime like a ghost. You can’t address them from code in any way. But the new development environment shown at Directions seems to solve this. I cannot wait for the preview at Christmas!
So, going to a “closed source, open model” world, what do I need to serve my customers?
I need access to view and address the model, the same we today can view and reference the public interface of a .NET assembly.
I need a way to modify the standard application behavior, adjust the UI, update the database schema and add my own business logic.
If I can do that, I don’t need your source to do my job 🙂
