Ever since DotNetNuke was first released on Christmas Eve 2002, the core framework has always been developed and maintained in VB.NET. The historic reason for this language preference was because I had originally chosen to use the Visual Basic / Visual Studio version of the IBuySpy Portal reference application from Microsoft as the basis for the DotNetNuke platform. In the opening chapter of the Professional DotNetNuke 5 book from WROX Press, I stated my opinion that I felt the decision to use VB.NET was one of the key reasons for the early success of the open source project, as it provided Classic ASP developers with a simpler migration path to ASP.NET. I stand by this opinion today; however, I must also acknowledge that in the years since, the .NET development landscape has changed significantly.
One defining characteristic of the DotNetNuke open source project is that it has always tried to be more pragmatic than dogmatic. Our primary goal is to create value for our users, so if a clear and compelling business case can be made which benefits the majority of the community and mitigates the risk, we have no hesitation in making bold moves with our technology platform.
Over the past 8 years, the DotNetNuke project has had more than its fair share of critics who vocalized the fact that they felt C# was a superior development language to VB.NET for developing large-scale applications. Most of the arguments, although passionate and convincing, generally tended to be quite subjective. As a result, the language debate simmered in the background as we focused on adding deeper value to the platform.
About 1 year ago, a Chinese developer, Ben Zhong, personally went through the effort of converting the core framework to C# and posted the results of his work on Codeplex. Initially we had obvious concerns that a fork of DotNetNuke could result in confusion and fragmentation in the ecosystem, but we also recognized that a C# version was something that had been requested often in the past. We decided to reach out to the developer to determine if he would be interested in collaborating with us to provide an “official” C# source code distribution. It turned out that he was willing, and over the past year the C# source code package, which he independently maintained, resulted in thousands of additional downloads. This provided proof that there was indeed a demand for a C# version of our software, so when the question about moving to C# was raised publicly at the DotNetNuke Connections conference in Las Vegas last November, it provided the catalyst to take a deeper look at the state of VB.NET versus C# to analyze the specific business benefits and opportunities offered by each language as we look towards the future.
So without any further ado… I am pleased to announce that we decided to switch development languages for the core platform from VB.NET to C# !!
We are already in the process of performing QA on the converted C# code base and we expect to make the new C# platform available with the upcoming DotNetNuke 6.0 release which is currently scheduled to be released sometime during the second quarter of 2011. In the coming weeks a DotNetNuke 6.0 Community Technology Preview will be published which will provide early access to the product for the purpose of cultivating open source community participation to help us ensure the stability of the C# code base.
It goes without saying that this is a very significant change for us and our ecosystem, and the decision was only made after extensive research and deliberation. For your benefit, here is some of the business rationale which contributed to the decision…
First Class Citizen
The most fundamental argument in the language debate centers around citizenship. When .NET was launched way back in 2000 there was a lot of hype around the fact that it was "language agnostic". Since .NET is based on MSIL from a run-time perspective, the premise was that programming language was essentially irrelevant. In these early stages it really felt like C# and VB were first class citizens in the .NET world. However, in the years since it has become very apparent that there is much more to consider than just the run-time perspective. The fact that Microsoft itself develops the majority of its products in C# results in a far greater emphasis on the C# language in terms of innovation, tooling, examples, etc... So although Microsoft tries hard to provide decent support for VB, it generally feels like an afterthought - almost as if it is a required burden which they are forced to accept because of the size of the VB community. As a result, whether it is accurate or not, the general perception is that C# is a first class citizen and VB is a second class citizen - and this citizenship dilemma manifests itself in a variety of ways.
Availability of Source Code Examples
In the early stages of .NET, there was a commitment by Microsoft as well as other media organizations to always provide source code examples in both C# and VB.NET. This emphasized the first class citizenship of both languages and provided incredible value to developers, regardless of their language preference. However, there is no doubt there was significant time, effort, and cost associated to this practice so it is not surprising in recent years that the commitment has changed. In fact, I was recently on a conference call with a leading .NET publication and they said that they made a decision to only provide code listings in C# over a year ago. A quick search on Amazon reveals 1028 books on "C# NET" whereas only 744 books exist for "VB NET". Less code samples in VB means less useful education and reference for VB.NET developers which reduces the effectiveness of utilizing the VB.NET language.
Availability of Developers
After nearly a decade the number of developers using C# is far greater than those using VB. A quick search on a popular job site shows 858 job opportunities for "C# NET" in the past 7 days as opposed to only 371 job opportunities for "VB NET". If we want the size of the DotNetNuke ecosystem to grow dramatically in the coming years, it means that we will need to recruit new developer talent. And I am not just talking about DNN Corp; every systems integrator, module developer, etc... will need to recruit software developers and the availability of C# developers is much higher than VB.NET.
Developer Attitude
This item is somewhat subjective, but it generally feels like C# developers are less flexible and more opinionated when it comes to evaluating solutions ( as compared to their VB.NET contemporaries ). There may be a variety of reasons for this attitude but at the end of the day if C# developers have a poor first reaction to the fact the core is written in VB.NET, it limits the growth potential of the project and ecosystem. This is a very difficult item to measure, as you typically never get the opportunity to hear the reasons why someone does NOT choose a particular technology - they have already moved on to an alternative.
Perceived Performance Benefit
I have yet to see any performance metrics which validate that C# runs faster than VB.NET ( and I would have a hard time even understanding in theory how this is possible because both languages produce comparable MSIL ). But regardless, there is a perception in the .NET world that C# runs faster than VB.NET and the popular saying is that "after a while, perception is reality".
Enterprise Acceptance
In the enterprise world there are really only two technology platforms which are widely accepted as "enterprise capable". There are J2EE and .NET. And when it comes to .NET, C# is the dominant language by far. This may actually be related to the fact that C# closely resembles Java and there has been some migration of enterprise developers from one platform to the other over the past 10 years. Most enterprise organizations are savvy enough to understand that a VB.NET core framework is not a platform weakness from a technical perspective, but when they evaluate it from a business perspective and look at the availability of source code from a risk mitigation or escrow scenario, they would much prefer if it was written in the language which their developers prefer.
Competitive Landscape
When we evaluate the other .NET CMS systems available - open source or proprietary - we notice that ALL of them are developed in C#. Since CMS systems generally require some level of development to customize them to the needs of a business, it makes the technology platform more important than it is with most applications. So in the cases where a user considers switching from a competing .NET CMS to DotNetNuke, one of the items they need to consider is how to migrate their custom developed assets. If a user makes an invalid assumption that they can only use VB.NET in DotNetNuke, it could be a factor in them ruling us out because the effort to convert their C# code is too high. In addition, because DotNetNuke is written in VB.NET, there may also be incorrect assumptions that integrating DotNetNuke with other .NET C# solutions will be difficult ( which we all know is not the case ).
Strategic Direction
Currently Microsoft is interested in improving the engagement with the "breadth" or "productivity" developer community. Part of the strategy involves the new WebMatrix IDE and Razor scripting syntax. Interestingly, in a recent issue of Code Magazine, a community member raised the question as to why C# is the default language in these new tools as opposed to VB.NET ( which has always been perceived as a better "beginner" language ). Well, the answer from Microsoft was that they purposely wanted to reduce the choices which a beginner needs to make and therefore needed to give one language more weight than another. They said beginners often have experience with "C-like" languages like JavaScript so they chose C#. In addition, if a beginner learns C#, they can more easily graduate to more sophisticated development models. This is yet another indicator that Microsoft is trying to influence developers to choose C# over VB.NET.
Language Conversion
Because the C# language is based on ECMA Standard 334, it is much easier to convert code from C# to VB.NET than vice versa. In fact, the automated code conversion tools have much higher levels of accuracy for C# to VB.NET than VB.NET to C#. In addition, since Mono is developed based on the ECMA standard and its C# compiler is far more advanced than the VB.NET compiler, it offers other opportunities.
Compatibility
Because both C# and VB.NET share common characteristics, they are highly compatible with one another. This means that the DotNetNuke API will be able to preserve compatibility through the transition - which is obviously a highly important benefit in terms of serving the needs of our ecosystem.
You will notice that none of the reasons above mention that VB.NET is inferior to C# from a technical perspective. This is a very important point, as we don’t want people to get the impression that we are switching languages because there are any technical deficiencies in VB.NET. VB.NET is just as robust and powerful as C# from a design-time, compile-time, and run-time perspective and it has served us extremely well over the past 8 years. The reasons why we are moving to C# at this juncture are 100% business related.
Another question which is sure to arise, is if we will be providing official versions of DotNetNuke in both C# and VB.NET going forward. The reality is that DNN Corp is still not at the point where it could reasonably support multiple versions of the platform to the level of quality which we feel is sufficient for our users. However, we would certainly entertain a scenario where a community member is willing to step up in a similar capacity to what Ben Zhong delivered over the past year, and maintained a parallel VB.NET open source code base which we could promote alongwith our other production-quality downloads.
Lastly, it is important to understand that extensions to the DotNetNuke platform can still be written in any .NET-compliant language. Some developers will prefer to write their extensions in C# and others in VB.NET, and both languages will continue to be fully supported. This is in fact one of the most powerful aspects of the DotNetNuke framework; the flexibility for developers to write extensions using their preferred software development style for maximum productivity.
Please join me in spreading the word to the .NET developer community that DotNetNuke <3 C# !!
About The Author
