The idea of this article started for a couple of reasons: The first thing that happended was that Alex Meyer released his D365FO Admin Toolkit on GitHub. The second thing that happened was that I read the brilliant article Scary dangerous creepy tools by Jonas Rapp) and 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)
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, runs on Linux, a lot of our Internet appliances (such as firewalls and routers) runs on Linux, more than half the worlds cell phones has 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 runs 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 are using at least a couple of Open Source components. That means that the actual issue is not the code itself… it is something else. In this article we will try to understand the blockers and why the might not be relevant.
Mentioning the fact that a lots 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 towards the customer. We will come back 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 and that means that we can free up time for our project and for our developers to do other things.
There is also the the quality argument. If someone has built it and many other uses it, the risk of it being broken is smaller than if everyone build 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 and that they need to solve it too.
There is also the question of missing features in the product. When Microsoft add new features to Dynamics, they need to prioritize them and if not enough organizations wants a feature, then it will not bubble to the top in the priority list and thus it will not be built. Having community developed features will help with bridging the gap and will also act as an indicator to Microsoft of what the customers want in the product. On the consumer side of tech, there is a concept called Sherlocking. 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 you let a partner build and implement your solution for you there is always someone else that assumes responsibility for the code written. But as for all contract there are always disclaimers… this applies even to to the license agreement of Dynamics. There are some thing, 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 make sure that it is maintained and updated. The main difference is that we (as an organization) can not affect Microsoft’s, the ISVs or (in some cases) the Partners Code. We are however able to make changes to the Open Source Solution.
I know that there are ISVs out there that supply the source code for their solution… Is that the same as using Open Source? Well, not exactly, but sort of… There are up and down sides of this. If we buy the solution from the vendor and we have a support agreement, we should try to stay away from editing the code; it blurs the lines of responsibilities. With that being said there is still a benefit in that we are able to speed up the troubleshooting process, because we are able to debug, and help provide the solution to the vendor. The real benefit of getting access to the codebase for an ISV solution is however if something happens the vendor and they go out of business. In that case we can choose to continue to support the solution ourselves.
The Commitments
As we have seen in this article, there are some thing 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 3rd Party Tools, always needs to be a deliberate choice and going with an Open Source Solution comes with its own challenges, but we also need to understand that building all of our own customizations from scratch, means that we will be using a “one-off” solution that 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.
