Early in the project history, I was approached by an individual from Germany with a request to maintain a localized DotNetNuke site for the German community. I was certainly not na�ve to the risks of another source code distribution at this point, and I told him that it would be fine so long as the site stayed consistent with the official source code base, which was under my jurisdiction. This was agreed upon, and in the coming months I had periodic communication with this individual regarding his localization efforts. However, as time wore on he became critical of the manner in which the project was being managed, in particular the sole maintainer aspect, and began to voice his disapproval in the public forum. There was a group who believed that there should be a greater degree of transparency in the project - that developers should be able to get access to the latest development source code at anytime, and that the maintenance of the application should be conducted by a team rather than an individual. He was able to convince a number of community members to collaborate with him on a modified version of DotNetNuke, a version that integrated a number of the more popular community enhancements available, and called it DotNetNuke XXL.

Emerging from the XXL dilemma, I realized that I needed to establish some legal protection for the long-term preservation of the project. Because standard copyright and the MIT license offered no real insurance from third-party threats, I began to explore intellectual property law in greater detail. After much research and legal advice, I decided that the best option was to apply for a trademark for the DotNetNuke name. Registering a trademark protects a project's name or logo, which is often a project's most valuable asset. After the trademark was approved it would mean that although an individual or company could still create a fork of the application, they legally could not refer to it by the DotNetNuke name. This appeared to be an important distinction so I proceeded with trademark registration in Canada (because this was the country in which Perpetual Motion Interactive Systems Inc. was incorporated).

In August 2003, I came to an agreement with Microsoft regarding a sponsorship proposal for the DotNetNuke project. In a nutshell, Microsoft wanted DotNetNuke to be enhanced in a number of key areas with the intent being to use the open source project as a means of demonstrating the strengths of the ASP.NET platform. Because these enhancements were completely congruent with the future goals of the project, there was little negative consequence from a technical perspective. In return for implementing the enhancements, Microsoft would provide a number of sponsorship benefits to the project including web hosting for the www.dotnetnuke.com website, weekly meetings with an ASP.NET Team representative (Rob Howard), continued promotion via the www.asp.net website, and more direct access to Microsoft resources for mentoring and guidance. It took five months for this sponsorship proposal to come together, which demonstrates the patience and perseverance required to collaborate with such an influential partner as Microsoft. Nonetheless, this was potentially a one-time offer, and at such a critical stage in the project evolution it seemed too important to ignore.

In September 2003, with the assistance of the newly formed Core Team, we embarked on an ambitious mission to implement the enhancements to DotNetNuke suggested by Microsoft. The problem at this point was that in addition to the Microsoft enhancements, there were some critical community enhancements, which I ultimately perceived as an even higher priority if the project should hope to grow to the next level. So the scope of the enhancement project began to snowball, and estimated release dates began to slip. The quality of the release code was also considered to be so crucial a factor that early beta packages were not deemed worthy of distribution. Ultimately, the code base evolved so much that there was little question the next release would need to be labeled version 2.0. During this phase of internal development, some members of the Core Team did an outstanding job of supporting the 1.x community and generating excitement about the next major release. This was critical in keeping the DotNetNuke community engaged and committed to the evolving project.

In January 2004, another interesting dilemma presented itself. I received an email from an external party, a web application security specialist who claimed to have discovered a severe vulnerability in the DotNetNuke application (version 1.0). Upon further research, I confirmed that the security hole was indeed valid and immediately called an emergency meeting of the more trusted Core Team members to determine the most appropriate course of action. At this point, we were fully focused on the DotNetNuke 2.0 development project but also realized that it was our responsibility to serve and protect the growing DotNetNuke 1.0 community. From a technical perspective, the patch for the vulnerability proved to be a simple code modification.

After six months of development, including a full month of public beta releases and community feedback, DotNetNuke 2.0 was released on March 23, 2004. This release was significant because it occurred at VS Live! in San Francisco, California, a large-scale software development event sponsored by Microsoft and Fawcette publications. Due to our strong working relationship with Microsoft, I was invited to attend official press briefings conducted by the ASP.NET Team. Essentially, this involved up to eight private sessions with the leading press agencies (Fawcette, PC Magazine, Computer Wire, Ziff Davis, and so on) where I was able to summarize the DotNetNuke project, show them a short demonstration, and answer their specific questions. The event proved to be spectacularly successful and resulted in a surge of new traffic to the community (now totaling more than 40,000 registered users).

To demonstrate the effectiveness of the skinning solution, I commissioned a local web design company, Circle Graphics in Abbotsford owned by Brad Haima, to create a compelling design for the www.dotnetnuke.com website (see Figure 1-8). As an open source project, I felt that I could get away with an unorthodox, somewhat futuristic site design and I was impressed by some of Circle Graphics' futuristic, industrial concepts I had seen.

One of the large-scale enhancements that Microsoft insisted on for DotNetNuke 2.0 also proved to be popular. The Data Access Layer in DotNetNuke had been rearchitected using an abstract factory model that effectively allowed it to interface with any number of relational databases. Microsoft coined the term "provider model" and emphasized it as a key component in the future ASP.NET 2.0 framework. Therefore, getting a reference implementation of this pattern in use in ASP.NET 1.x had plenty of positive educational benefits for Microsoft and DotNetNuke developers. DotNetNuke 2.0 included both a fully functional SQL Server and MS Access version, and the community soon stepped forward with mySQL and Oracle implementations as well. Again, the extensibility benefits of good architecture were extremely obvious and demonstrated the direction we planned to pursue in all future product development.

When researching the open source phenomenon, there are a few fundamental details that are often ignored in favor of positive marketing rhetoric. I would like to take the opportunity to bring some of these to the surface because they provide some additional insight into some of the issues we face in the DotNetNuke project.

Following the success of DotNetNuke 2.0, we focused on improving the stability and quality of the application. Many production issues were discovered after the release that we would have never anticipated during internal testing. As an application becomes more extensible, people find ingenious new ways to apply it, which often produces unexpected results. We also integrated some key Roadmap enhancements that were developed in isolation by Core Team members. These enhancements were actually quite advanced because they added a whole new level of professional features to the DotNetNuke code base, transforming it into a viable enterprise application framework.