Personal Blog of Shaun Walker


Third-Party Components

By Shaun Walker on 8/13/2015

An interesting concern that came to our attention at this time was related to our dependence on external components. To provide the most powerful application, we had leveraged a number of rich third-party controls for their expert functionality. Because each of these controls was available under its own open source license, they seemed to be a good fit for the DotNetNuke project. But the fact is there are some major risks to consider. Some open source licenses are viral in nature and have the potential to alter the license of the application with which they are combined. In addition, there is nothing that prevents third parties from changing their licensing policy at any time. If this situation occurs, then it is possible that all users of the application who reference the control could be in violation of the new license terms. That's a fairly significant issue and certainly not something that can be taken lightly. Based on this knowledge, we quickly came up with a strategy that was aimed at minimizing our dependency on third-party components. We constructed a policy whereby we would always focus on building the functionality ourselves before considering an external control. And in the cases where a component was too elaborate to replicate, we would use a provider model, much like we had in the database layer, to abstract the application from the control in such a way that it would allow for a plug-in replacement. This strategy protects the community from external license changes and also provides some additional extensibility for the application.

Core Team Reorganization

By Shaun Walker on 8/12/2015

The summer of 2004 was a restructuring period for DotNetNuke. Thirty new community members were nominated for Core Team inclusion and the Core Team itself underwent a reorganization of sorts. The team was divided into an Inner Team and an Outer Team. The Inner Team designation was reserved for those original Core Team individuals who had demonstrated the most loyalty, commitment, and value to the project over the past year. The Outer Team represented individuals who had earned recognition for their community efforts and were given the opportunity to work toward Inner Team status. Among other privileges, write access to the source code repository is the pinnacle of achievement in any source code project, and members of both teams were awarded this distinction to varying degrees.

Microsoft Membership API

By Shaun Walker on 8/11/2015

During these formative stages, I was once again approached by Microsoft with an opportunity to showcase some specific ASP.NET features. Specifically, a Membership API had been developed by Microsoft for Whidbey (ASP.NET 2.0), and it was planning on creating a backported version for ASP.NET 1.1 that we could leverage in DotNetNuke. This time the benefits were not so immediately obvious and required some thorough analysis. This is because DotNetNuke already had more functionality in these areas than the new Microsoft API could deliver. So to integrate the Microsoft components without losing any features, we would need to wrap the Microsoft API and augment it with our own business logic. Before embarking on such an invasive enhancement, we needed to understand the clear business benefit provided.

"Breaking" Changes

By Shaun Walker on 8/10/2015

The snowball effect soon revealed that the next major release would need to be labeled version 3.0. This is mostly because of "breaking" changes: modifications to the DotNetNuke core application that changed the primary interfaces to the point that plug-ins from the previous version 2.0 release would not integrate without at least some minimal changes. The catalyst for this was due to changes in the Membership API from Microsoft, but this only led to a decision of "If you are forced to break compatibility, introduce all of your breaking changes in one breaking release." The fact is there was a lot of baggage preserved from the IBuySpy Portal that we were restricted from removing due to legacy support considerations. DotNetNuke 3.0 provided the opportunity to reexamine the entire project from a higher level and make some of the fundamental changes we had been delaying for years in some cases. This included the removal of a lot of dead code and deprecated methods as well as a full namespace reorganization that finally accurately broke the project API into logical components.

Web Hosters

By Shaun Walker on 8/9/2015

Along with its many technological advances, DotNetNuke 3.0 was also being groomed for use by entirely new stakeholders: web hosters. For a number of years, the popularity of Linux hosting has been growing at a far greater pace than Windows hosting. The instability arguments of early Microsoft web servers were beginning to lose their weight as Microsoft released more resilient and higher-quality server operating systems. Windows Server 2003 had finally shed its clunky Windows NT 4.0 roots and was a true force to be reckoned with. Aside from the obvious economic licensing reasons, there was another clear reason why hosters were still favoring Linux over Windows for their clients: the availability of end-user applications.

DotNetNuke 3.0

By Shaun Walker on 8/8/2015

Much of the integration work on the Membership API and usability improvements were fueled by a much larger hosting initiative that Microsoft was preparing to unleash in May 2005. This initiative included a comprehensive program aimed at increasing awareness for Windows-based hosting solutions on an international level. Based on its strength as a framework for building consumer websites, Microsoft invited DotNetNuke to participate in the program as long as it could meet a defined set of technical criteria, including Membership API integration, Medium Trust CAS compliance, localization, and usability improvements. Nearly all of the enhancements were already identified on the product roadmap, so the opportunity to be included in the hosting program was really a win-win proposition for the project and the community. In addition, we believed that the benefit of participating in such a large-scale initiative would be enormous in terms of lending credibility to the DotNetNuke product, introducing the project to influential new stakeholders, and helping to build brand equity.

Release Schedule

By Shaun Walker on 8/7/2015

A common open source concept is referred to as "release early, release often." The justification is that the sooner you release, the sooner the open source community can validate the functionality, and the sooner you get feedback - good and bad - which helps improve the overall product. This concept is often combined with a "public daily build" paradigm, where continuous integration is used to automatically build, package, and publish a new application version every day. These concepts make a lot of sense for single-purpose applications; that is, applications that have closed APIs and have no external dependencies. But plug-in platforms such as DotNetNuke possess a different set of requirements, many of which are not complementary with the "release early, release often" model.

DotNetNuke Projects

By Shaun Walker on 8/6/2015

One of the goals of the DotNetNuke 3.0 product release that had tremendous value for the community at large was the abstraction of the modules that were traditionally bundled with the core framework. The core modules were neglected in favor of adding more functionality to the core framework services. This resulted in a set of modules that demonstrated limited functionality and were not evolving at the same pace as the rest of the project. The abstraction of the modules from the core framework led to the formation of the DotNetNuke Projects program: a new organizational concept modeled after the Apache Foundation that allowed many complementary open source projects to thrive within the DotNetNuke ecosystem. From a technical perspective, the modules were abstracted in a manner that conformed to our extensibility model for building "private assembly" modules and allowed each module to be managed as its own independent project. The benefit was that each module could form its own team of developers, with its own roadmap for enhancements, and its own release schedule. As a governing entity, DotNetNuke would provide infrastructure services such as a source code repository, issue tracker, project home page, and email services for the project as well as a highly visible and respected distribution and marketing channel.

Intellectual Property

By Shaun Walker on 8/5/2015

There are two main contributing factors when it comes to intellectual property: copyright and licensing. The copyright holder is the person who owns the rights to the intellectual property. Normally this is the creator; however, copyright can also be transferred to other individuals or companies. The copyright holder has the right to decide how his intellectual property can be used by others. When it comes to software, these usage details are generally published as a license agreement. License agreements can vary a great deal depending on the environment, but they generally resemble a standard legal contract, explicitly outlining the rights and responsibilities of each party. Copyright holders also have the right to change the license for the intellectual property at their discretion. It is this scenario that requires the most due diligence when dealing with third-party contributions.


By Shaun Walker on 8/4/2015

The success of any serious initiative must begin with the formulation of specific goals and the ability to measure progress as you work toward those goals. In terms of measuring the growth of the DotNetNuke project, we had traditionally monitored the total number of registered users on the dotnetnuke.com website, the number of new users per month, and the number of downloads per month. These metrics revealed some definite trends but were rather myopic in terms of providing a relative comparison to other open source or commercial products. As a result, we looked for some other indicators that we could use to measure our overall market impact.

Shaun Walker has 25+ years professional experience in architecting and implementing enterprise software solutions for private and public organizations. Shaun is the original creator of Oqtane and DotNetNuke, web application frameworks which have cultivated the largest and most successful Open Source community projects native to the Microsoft platform. He was one of the original founders of DNN Corp, a commercial software company providing products, services, and technical support for DotNetNuke, which raised 3 rounds of venture capital from top tier Silicon Valley investors. Based on his significant community contributions he has been recognized as a Microsoft Most Valuable Professional (MVP) as well as an ASPInsider for over 10 consecutive years. He was recognized by Business In Vancouver as a leading entrepreneur in their Forty Under 40 business awards, was a founding member of the Board of Directors of the Outercurve Foundation, and is currently the Chair of the Project Committee for Microsoft's .NET Foundation. Shaun is currently a Technical Director and Enterprise Guildmaster at Cognizant Softvision.