The idea behind this article started for a couple of reasons. The first thing that happened was that Alex Meyer released his [D365FO Admin Toolkit] (https://github.com/ameyer505/D365FOAdminToolkit) on GitHub. The second thing that happened was that I read the brilliant article [Scary, Dangerous Creepy Tools by Jonas Rapp ] (https://jonasr.app/dangerous-tools/)) These two things made me think about the benefits and challenges of using open source in Dynamics 365 for finance and supply chain. (Since then, there have been others, such as Jonas Feddersen Melgaard‘s [D365FinanceToolbox](https://github.com/jofme/D365FinanceToolbox))
First of all, I will dive into some background… About 10 years ago, I left the “IT Infrastructure” world and ventured into the Dynamics world. On the infrastructure side, Open Source Software is a big thing. The majority of web servers on the internet run on Linux, a lot of our Internet appliances (such as firewalls and routers) run on Linux, more than half the world’s cell phones have a base in Open Source, and a lot of components such as Curl, OpenSSH, and Mermaid are used by millions of business users every day since they are all baked into commercial products. In fact, 60% of all compute cores in Microsoft Azure run some version of Linux.
So the question is, why is it OK to use Open Source Software built by the community everywhere else but not in Dynamics… “Because it is our super-duper critical ERP System, of course!!!!”. Well, I would argue that there are more important systems in your organization (not to belittle your ERP system) that use at least a couple of Open Source components. That means that the actual issue is not the code itself… it is something else. This article will try to understand the blockers and why they might not be relevant.
Mentioning the fact that a lot of commercial closed source software uses Open Source components, I agree, is a bit dis-honest. However, it makes a good point, and I think it puts a finger on the real issue here: Responsibility. When a company embeds a 3rd party component in the software, they assume responsibility for it. They agree to patch it (which is not always done), and they agree to take responsibility for the end product to the customer. We will come back to the question of responsibility later in this text.
The Benefits
There are a couple of benefits of using software made by someone else in our solution. The most obvious one is the same as the argument for ISV software. We do not need to start building something from scratch, which means we can free up time for our project and for our developers to do other things.
There is also the quality argument. If someone has built it and many others use it, the risk of it being broken is smaller than if everyone builds their own solution to a common problem. Working iteratively on a common software base over time will hopefully make it less likely to break. Another argument here will be, “But we are solving our own unique issues,” and that might be so… but not all of your challenges are unique. If you have an issue in Dynamics, then it might be that others have the same issue and that they need to solve it, too.
There is also the question of missing features in the product. When Microsoft adds new features to Dynamics, they need to prioritize them, and if not enough organizations want a feature, then it will not bubble to the top in the priority list, and thus, it will not be built. Community-developed features will help bridge the gap and also indicate Microsoft’s customers’ desire for the product. On the consumer side of tech, there is a concept called [Sherlocking (https://en.wikipedia.org/wiki/Sherlock_(software)#Sherlocked_as_a_term). That is when (In this case) Apple implements a function that a 3rd party software developer has built into iOS or MacOS.
The Challenges
Earlier, I compared Open Source Software to ISV solutions, and to be honest, there is one big difference… responsibility. When you buy an ISV solution from a vendor or let a partner build and implement your solution for you, someone else always assumes responsibility for the code written. But as for all contracts, there are always disclaimers. This applies even to Dynamics’ license agreement. There are some things that are not covered by the agreement. The responsibility always lands on the end customer in the end, and you, as an end customer, need to be ready to assume that responsibility. If we assume that the responsibility falls on the customer in the end, there is basically no difference between Microsoft, ISV, Partner, Open Source, or Customer-created code. We still need to test it and ensure it is maintained and updated. The main difference is that we (as an organization) can not affect Microsoft’s, ISVs’, or (in some cases) the Partners’ Code. We are, however, able to make changes to the Open Source Solution.
I know there are ISVs that supply the source code for their solution… Is that the same as using Open Source? Well, not exactly, but sort of… There are ups and downsides to this. If we buy the solution from the vendor and have a support agreement, we should avoid editing the code; it blurs the lines of responsibilities. With that being said, there is still a benefit in that we can speed up the troubleshooting process because we can debug and help provide the solution to the vendor. However, the real benefit of getting access to the codebase for an ISV solution is if something happens to the vendor and they go out of business. In that case, we can choose to continue supporting the solution ourselves.
The Commitments
As we have seen in this article, there are some things we need to think about when we start using Open Source Software. As always, we need to make sure the software holds up to the same level of quality that we need; we need to keep it updated (and with that comes, of course, testing and code review, in the same way as with our own code), but I also think that there is another level of commitment here and that is that if we find a bug in the code, we should also be a “good citizen” of the community and at lease report a bug (maybe even with a proposed solution) or even write a fix and submit a pull-request back to the project to get the fix into the code base… if it benefits us, it will probably benefit others.
“So that means that we should use our precious time writing code for others?” Yes, with the time we save having others write code and test it for us, we absolutely should pitch in and help. I am absolutely convinced that we will spend less time in the long run while at the same time helping others do the same.
The Conclusions
Using third-party Tools always needs to be a deliberate choice, and going with an Open-Source Solution comes with its own challenges. However, we also need to understand that building all of our own customizations from scratch means that we will use a “one-off” solution that does not always adhere to best practices. In that case, we are on our own, but when we use a solution that is built by the community, at least we can figure out the solution together.
