Launching DAX-rs
“Now, it has started, because it is launched here.” A rephrasing of Frank Herbert’s original quote “Now, it’s complete because it’s ended here.” - but I think it summarizes well the feeling I have as the project is finally up on GitHub.
Why I launched DAX-rs
I have worked on this project for quite a while now, first as a small plaything, and then I picked it up again 6 months ago as I felt a genuine need for a project like this. For two main reasons:
- There is a gap between the commercial tools many professionals in finance and sales support know and the open tools data professionals use.
- Given the concern around tech sovereignty that is developing, particularly in Europe, there is a need for an auditable DAX framework.
It took a month to launch
From making the decision to share this project with the world and actually launching it, it still took more than a month. Some of the time was spent on tasks that actually needed to be done:
- Creating proper configuration options
- Upgrading packages to the latest version
- Packaging the server for Docker
- Creating baseline documentation
- Cleaning up all the tools, data extracts etc. that had been used to ensure the server spoke XMLA correctly
However, even more time was spent agonizing over how the code looks and the known issues that still lurk inside it. Knowing that your code will be available to be scrutinized by your peers is a terrifying prospect. I added a little bit of memoization, just to make it clear that I know that some code paths are slow and that I have plans to fix it. I cleaned up some of the naming, split up some functions (though they are still way too long).
No matter how many fixes I made, there were still 100 more I wanted to make. The XMLA server side is an ugly hack, created step by arduous step, to match the SOAP data not with the published spec but what Power BI actually expects. The MDX engine is my first attempt at vibe coding, as I discovered that Excel did not speak DAX at all and I simply could not code against any more Microsoft specs and still keep my will to live. It will need a rewrite before a 1.0 release, but it serves as a proof of concept.
Why I chose the AGPL
Another decision that I agonized over was that of licensing. I am not looking to turn this project into a massive business, but there have also been enough stories of tools getting adopted by massive companies without the companies contributing back.
An example is Livy, as a standalone project it is dead. However, it still exists as an internal tool in several projects / major products; however, despite how the project started out, the additions to the code are no longer available for others to benefit from.
I realize that a license such as AGPL can act as a barrier for adoption. However, I have not found any other major license that can guarantee that contributions flow back to the community. But I am open to feedback on this choice.
Test cases and AI
Recently, AI has been used to get around licenses by having a couple of AIs work together to create a very detailed spec based on the original software and then writing new code using a bot that has not seen the original code.
This might make the choice of license completely moot. DAX is a complicated language with many edge cases, so my way of trying to protect code is to hide the more than 500 tests I have written, so that the AI will have a harder time validating a new implementation.
At the same time, this makes contributing code to the project harder. I hope that the CI pipeline can somehow support this issue in a way, where the developer can get feedback without having access to the full test suite. This might prove to be a terrible idea that hurts more than it helps. But it is easier to grant access later, than it is to take back access, so let’s test if this solution can work.
With that, the code is open. I have no idea if anyone will show interest in it, but I hope there is.