IT Solution Blog-Top-Image1-01.png

A Fork by Any Other Name ...

What is the Truth About DNN Evoq in the Azure Cloud?

Editor's Note: This is Part 2 of a two-part series.
Read Part 1: DNN Evoq on Azure? Not so Fast ...

(Last week we published a hugely popular blog post that stirred up both cheers and jeers from the DNN community—and more than a few questions as well. Those questions and jeers deserved a response, and this is it.)

Our blog post last week—“DNN Evoq on Azure? … Not So Fast: Five Things Everyone Should Know First”— was, by far, our most widely read post of the year. We received a ton of input on it from the DNN community around the world, both positive and negative.

PQ - Managed - Spot on accurateA sampling of the positive comments includes:

  • “I think your article was spot on, and think it’s accurate.”
  • “I think you struck the right tone ….”
  • “… nice blog post …. speak your mind and speak the truth and let the chips fall where they may.”

Negative comments included:

  • “… at best mis-leading and at worst just plain wrong!“
  • “... hurts the whole DNN community.” (that one stings a bit)
  • “... I’m so p***ed right now!”

(Since these were private communications and not public comments to the blog we will keep all identities anonymous—both positive and negative)


Where Do People Disagree?

The offending blog post consisted of five points—the things that we believe that everyone should consider prior to hosting a DotNetNuke / DNN site on Azure. Interestingly, all criticism has focused on the third point only—our opinion that the installation of “Evoq for the Cloud” on Microsoft Azure represents a “fork” for the product. As of yet, no one has questioned our other four criticisms regarding the hidden costs of Azure, the lack of a formal back-up and restore method, the lower uptime SLAs, or the pitfalls of the “unlimited scalability” claim made by Microsoft Azure. We do not want to put words into anyone’s mouth, but this almost feels like universal agreement on at least four-out-of-five points.

Given that, we can move on. Those who did respond, both positively and negatively, asked why we thought the way we did regarding point #3, so let's get to it.


The Conscience of the King

It was tempting to start by including a few comments regarding our expertise with the topics at hand—listing our decades of web hosting and software development experience and the number of Microsoft deals participated in, etc. But let’s set that aside and save the blog space. Our bios are online if you want to read them. Our readers tend to be smart people too and usually have a lot of their own experience, so let’s not waste time.


They Doth Protest Too Much

PQ - Managed - Evoq same but differentThose who harshly criticized our opinion on the forking of DNN universally added a caveat. All of their comments maintained that the “Evoq in the Cloud” product is exactly the same, except … something.

One person told us that he was initially concerned about SQL differences, but that the team at DNN made him feel better about it. Another said that he was troubled that many current modules are not “Azure compatible” and we should have focused on that. A handful said that the only difference was in the DNN management interface.

Even in the opinions of the post’s harshest critics, “Evoq in the Cloud” is exactly the same … but different.

Product forks do not begin with large, wholesale changes that inspire drama and pain. They start with small modifications and customizations for specific environments, applications, or customer sets. They always start using 95% or more of the same parts, made in the same factories by the same workers. Then they experience a re-branding, perhaps with new trademarks, badges, and icon sets. This is followed by a greater divergence as the products gain their own market shares and niches. The products might still share some parts—perhaps quite a few of them—but there is no question that they are no longer the same.

If you are old enough, think about how Toyota launched Lexus back in the day. This is what a product “fork” looks like, whether it is cars, frozen dinners, an operating system (think UNIX), or the world's best Content Management System (CMS).


To Fork, or not to Fork … That is the Question for DNN / Evoq

The DNN team in Vancouver is to be commended. Making DNN work on Azure took a lot of specialized work. It is very likely that the DNN development team has a few thousand man-hours on it, and they are still tinkering with it to this day—as they should and will be for quite some time. It is a technological achievement. But this is all development work specifically for the Azure platform.

How DNN Corp chose to partner with Microsoft on an Azure installation package and—perhaps more importantly—whether they should have are not the points right now. We can sit down over a drink at DNNcon in Palm Beach and knock those topics around if you want.

Let’s review a few primary details:

  • Installing onto Azure utilizes a different installation package that is not designed to work on other servers or in other environments (in our minds, this one fact alone is virtually the definition of a fork).
  • Code exists in the Evoq in the Cloud (Azure) versions that does not exist anywhere else.
  • Databases on Azure are different. DNN is very “chatty” with its database, meaning that there are a lot of interactions. Evoq in the Cloud undoubtedly has work-arounds and—yes—perhaps even compromises to make it work. [Ref: Windows Azure Database Overview Viewed July 21, 2013]

To sum up, the current iteration of DNN Evoq in the Cloud has relevant differences.

On the code / software side:

  • Different code
  • Different installer
  • Different management interfaces
  • Different compatible modules

On the business side:

  • A captivated installation process
  • A separate, negotiated pricing model
  • A new brand, badging, and product level

It is reasonable, and to be expected, that the differences will advance and escalate over time, driven by the business needs of DNN Corp and the incumbent technical differences between Microsoft Azure and all other environments.


Full of Sound and Fury

PQ - Managed - What did the Corp doWhen we look at all of this, we see a fork. And the forking of the DNN product into Evoq in the Cloud, in our opinion, is one of the five things that everyone should know before putting their website on Microsoft Azure. Further, we think that this knowledge helps the DNN community. It is our love of the DNN Platform—especially version 7.x, which is truly exceptional—that prompts us to contribute as a part of that community.

Reasonable people can continue to disagree. But the question is not, “What did the Corp decide to do?” The real questions is, “What will you do with this knowledge, and where should your next DNN website go live?” In our opinion, and the point of the original blog post, is that the choice of where to host the best CMS for Business is becoming one between professional, open systems and an expensive, proprietary black box.

(We reached out to DNN Corp and asked them for a statement / contribution to this blog post. As of this publish we have not heard back from them. If they do, we will publish their response here as well.)


Editor's Note: This is Part 2 of a two-part series.
Read Part 1: DNN Evoq on Azure? Not so Fast ...


Editor’s Note: For the sharp reader, the various Shakespearean references in the headings are, in order: “Romeo and Juliet,” Act 2, Scene 2; “Hamlet,” Act 3, Scene 2; “Hamlet,” Act 2, Scene 2; “Hamlet,” Act 3, Scene 1; “Macbeth,” Act 5, Scene 5.


Microsoft, Azure, and Windows are trademarks of Microsoft Corporation [MSFT].
DotNetNuke, DNN, Evoq, and DNNSoftware are trademarks of DNN Software [DNN] – used with permission.



Recent Posts

Posts by Topic

see all

Subscribe to Our Blog