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 e-mail services for the project as well as a highly visible and respected distribution and marketing channel.
Obviously there are tradeoffs that need to be accepted when decomposing a monolithic system into its constituent components, but the overall benefits of this approach reaped substantial rewards for the project. For one thing, it provided a new opportunity for developer participation — basically providing a sandbox where developers could demonstrate their skills and passion for the DotNetNuke project. This helped promote the "meritocracy" model and aided in our Core Team recruitment efforts. The community benefited through the availability of powerful, free, open source components that were licensed under the standard DotNetNuke BSD license. It also allowed the modules to evolve much more rapidly and with more focus than they ever received as part of the monolithic DotNetNuke application. Abstracting the core set of modules was a good start; however, the platform was lacking some other essential modules — modules that were well integrated and provided the common functionality required by most consumer web sites. These items included a discussion forum, blog, and photo gallery.
Early in the DotNetNuke 3.0 life cycle, there were discussions with a high-profile third-party software development company that was actively developing an integrated suite of components with forum, blog, and gallery functionality. Although early indications seemed to be positive regarding collaboration, they unfortunately did not comprehend the opportunity of working with the DotNetNuke community and ultimately decided to instead focus their efforts on constructing their own proprietary solution. Because this decision was not communicated to us until late in the DotNetNuke 3.0 development cycle, it meant that we had to scramble to find a suitable alternative. Luckily, two of our own Core Team members — Tam Tram Minh of TTT Corporation and Bryan Andrews of AppTheory — had been collaborating on a comparable set of modules and had already been offering them for free download to the DotNetNuke community. Discussions with them led to the creation of three powerful new DotNetNuke Projects: the DotNetNuke Forums, Blog, and Gallery.
Integrating third-party modules is not without its share of challenges. An "incubation" period is required to make the module conform to the official DotNetNuke project standards. An official marketing name must be defined for the project and all references to the old module name need to be updated. This includes namespaces, folder names, filenames, code comments, database object names, release package metadata, and documentation. To allow legacy users of the contributed module to be able to migrate to the new DotNetNuke project, a robust upgrade mechanism must be created. The module also needs to be reviewed to ensure that it does not contain any security flaws or serious defects that could affect the general community. From an infrastructure perspective, the code needs to be uploaded to a dedicated source code repository, an issue tracker project must be created, and a project home page complete with discussion forum and blog needs to be created on dotnetnuke.com. These tasks represent the technical integration issues that need to be addressed; but an item of even greater importance for third-party modules is management of the associated intellectual property.