The question of Oqtane vs. DNN has come up numerous times in recent months. In general, it seems that people are trying to understand the rationale behind creating a completely new open source project as opposed to evolving the existing DNN project. In order to answer this question, it is helpful to step back in time and review the events which got us to where we are today.
Back in 2012 while I was still CTO at DNN Corp, we recognized that adoption of the DNN platform was declining and we identified a variety of factors which we believed were responsible for the decrease. One of the top items on the list was related to technology trends and the fact that DNN was no longer considered to be modern or relevant amongst Microsoft software developers. As a result, I created an internal company proposal titled “DNN Platform Revolution: An Application Framework For The Next 10 Years.” It was a vision on how to transform the DNN platform into an application framework for the future. Although it was authored seven years ago, it contained many of the architectural approaches which are considered to be enterprise best practices today such as separation of client and server concerns, a proper API services layer, etc. It also included a product strategy that advocated building a completely new platform from scratch which eliminated the legacy constraints of the existing DNN platform but still retained all of its key strengths and differentiators. The proposal received a lot of attention internally but ultimately the leadership of DNN Corp made a decision to not move forward with this approach and instead opted to focus on maintaining and enhancing the existing platform.
In 2017 when DNN Corp was acquired by ESW Capital there was a renewed sense of excitement in the DNN Community that it may result in a more substantial investment in the platform to make it modern and relevant again. Steering committees were formed by ESW Capital and I was asked to lead the Technical Steering Group. This was a perfect opportunity to dust off the proposal from 2012 and discuss the options for transforming the platform for the future. However, it did not take long to realize that various members of the DNN community had vastly different opinions on this topic and that it was going to be next to impossible to reach a consensus. Under the new TSG model, there was no “benevolent dictator” who was authorized to make a final decision so the discussions, although insightful, provided no actionable result.
It was during this time that I also came to another realization. For many years I had considered the DNN brand to be one of its most valuable assets. The DNN brand is recognized globally and is the foundation for a large commercial ecosystem of products and services. That being said, a brand is only as valuable as how well it is perceived by the market. And the challenge with a brand that has been around for an extended period of time is that it takes tremendous effort to shed some of its legacy characteristics. For example, it has taken over a decade for Microsoft to redefine its brand from a legacy desktop operating system vendor to a modern cloud solutions provider. In the case of DNN, the brand has many positive attributes but it also has some negative attributes related to its legacy technology stack which are slowly eroding its value. In order to solve this problem you cannot rely solely on a technology transformation alone – you would also need a significant sustained marketing effort to change the market’s perception. There are many large companies with significant financial resources and influence who have tried to reinvent their brand and failed. As a result, it may make more sense to establish a new brand.
I began developing Oqtane about a year ago as a proof of concept to explore the potential of creating a modular application framework using modern Microsoft technologies and architectural patterns. The Oqtane project was heavily influenced and inspired by DNN – partly because I was the original creator of DNN so I am intimately familiar with its core architecture, but also because the business concepts and features which exist in DNN are just as relevant today as they were 17 years ago when DNN was first released. That being said, technology has evolved significantly in the past decade and similar to many other mature software products, DNN has a variety of legacy behaviors and limitations which make it very challenging to migrate to a modern technical architecture. To be clear, the technical limitations of DNN do not necessarily impact the current everyday usage of the product by end users and developers. But as time goes by there is definitely a concern that the underlying technologies it relies upon will become unsupported; and the other more significant challenge is that the product may not be able to innovate or adapt to modern business scenarios. Oqtane takes advantage of Blazor and embraces a modern single page application (SPA) model where there is a cleanly defined client/server architecture. From a framework perspective, it was designed with modularity, extensibility, and multi-tenancy in mind. The familiarity with DNN has also been valuable in terms of allowing Oqtane to address some of DNN’s most widely acknowledged core limitations (i.e.: automated upgrades, tenancy isolation, streamlined module development, etc.).
In terms of maturity, Oqtane will reach an MVP (minimum viable product) milestone soon which will signal the release of an official 1.0 version. For additional insights into the Oqtane vs DNN discussion, please see Shaun Walker’s blog on the Oqtane website.