If there is one frequently asked question from the "outside" to the "inside" of the DNN project, it's this. Those of us that work daily with our platform come across issues regularly. And when they linger, it can get frustrating. "Hey DNN folks, when are you going to fix this?" And where before 2018 this frustration was directed at DNN Corp, it now falls on the members of the various "Advisory Groups" to answer to this grievance. Most notably the Technology Advisory Group headed by Mitch Sellers. This group is now formally in charge of setting the road map for DNN Platform and thereby prioritizing the bugfixes and features you so desperately want.  

The short answer to your question is "Well, it turns out that running an open source project is hard". And in this post I want to try to put the finger on what has been specifically hard over the past year. What we'd like the wider community to know is that DNN Platform is going through a major transition as the community is taking charge of it. This transition can be best summed up as moving from a "free and open platform as byproduct of a commercial enterprise" to a "free and open platform that is the basis of various commercial enterprises". This shift has had enormous consequences.

What follows is a discussion of several aspects that have had a profound impact on our progress to date. And even though none of them can be seen as completely unforeseeable, no one outside DNN Corp knew quite how hard it was going to be to migrate the project so we could take charge of it. We did have a number of surprises this year and with the help of a few very knowledgeable individuals we are digging ourselves out.

For a start we discovered that actually building all aspects of the platform was tied to internals at DNN Corp. So for the first releases we had to ask DNN Corp to pull the levers so to speak. This was of course unsustainable so the entire build process needed to be redone. As is always the case in such a scenario, we also benefit from such a challenge by moving the technology to today's standards. So now we are using Cake to build DNN. Recently we hit a major milestone: DNN 9.2.2 was the first build independent from DNN Corp’s infrastructure! And we fully realize that only we are excited by this. We don't expect the entire community to do the wave. But technically it was a major step.

As we are now building ourselves we don't want this to be dependent on a single person in our community either. So a lot of work has been put into a public build process that everyone can follow. As a .net foundation project we have access to VSTS/Azure DevOps which we now use for continuous integration. This allows any one of us to keep track of the stability of the platform. Oliver Hine and others have pumped countless hours into getting this to work.

Another headache has been the various dependencies. The platform distribution consists of many assets that come from various repositories (and I’m not even talking about external dependencies here). These need to be orchestrated so that changes in one repo are reflected in the other. Again, this is taking up many, many hours to sort out and get working.

One of the core challenges we face is getting people to contribute to the project. The above changes would be unnecessary if this were an internal project at some corporation. But moving to a truly open source project means we have to get this solved or no one will be able to work on it. What we hope to achieve is to improve the experience of contributing. If you feel like you're rowing upstream through molasses you're not going to be happy and spend time on this project. It needs to be a smooth experience.

Finally there is actual code quality. Some of our time is devoted to refactor and improve code. There is a lot of old and/or sub par code in the platform and we need to weed this out. As an open source project it behooves us to ensure the code is exemplary. And there is a good secondary reason for this: coders come and go. So others must be able to understand the code and be able to take over if necessary. This also puts pressure on code quality. To beat a dead horse: this was less relevant when the platform was a byproduct of Evoq. Evoq had a rigorous release schedule and one sometimes needs to cut corners to meet those deadlines. It's understandable and no one is casting any blame here. But the priorities have now shifted.

I hope this goes some way to explain why you are not seeing a fix for your favorite itch. We are just really busy making sure the platform builds reliably and is conducive to further development.