In December 2004 it was decided that DotNetNuke would break out its existing core modules into separate Projects so that they could be enhanced, released, and supported independently from the core Web Application Framework. It was further decided that some additional modules would also be added as official Projects to provide an increased level of richness to the platform. The first modules that we determined were going to be added were the TTT Forum and TTT Gallery, authored by Tam Tran Minh of TTT Corporation. I was already working closely with Tam on these modules, and I volunteered to co-lead the development of these Projects and to help morph them into modules that take full advantage of the DotNetNuke Web Application Framework.

When the projects were first starting, the current DotNetNuke framework was in a transition. This transition included breaking changes that would not allow modules developed for the current released version, 2.1.2, to operate in the new upcoming version 3.0. My expectations were that Tam and I would work with members of the core team to convert the modules to work in the new 3.0 environment. After the modules were running in the 3.0 environment we would fix a few bugs that already existed in the modules and then have our first release. After this release we would start to form teams that would aid in enhancing the modules and fixing additional bugs, which I knew would surface over time. I expected it would take about three months until we were at the point of forming teams. What I expected and what actually happened were quite different.

Incubating a Third-Party Module Project
Because I was a member of the core team since its inception, I felt I had a pretty good understanding of what it would take to make these modules follow the unwritten rules of the current DotNetNuke core modules. The first part of this process was to convert the namespace and assembly names to follow the current patterns used by the other core modules. While doing this we also added in the copyright that was included in all current core .vb files to the .vb files of these modules. This process was pretty straightforward and required minimal effort; however, it took slightly longer than I had anticipated.

Once this was completed the remaining changes were not so obvious. Prior to these Projects, no outside module was ever brought into the core, so there was no preexisting checklist for us to follow. Another challenge we faced is that none of the core modules that are currently available were as complex as either one of these. After several discussions with other core team members we formed a plan. This plan was to focus on a single module - the DNN Forums - and get it released first. This decision, as we would later find out, would also speed up the development of the DNN Gallery project because it gave us a checklist to follow.

Now that we were focused on the DNN Forum project alone, we outlined what we knew had to be done prior to a release. The first item was to rename the custom class names that used a pattern not consistent with any of the core modules. At the time we thought it best to make use of the existing classes that were included in the default skins. We would later determine that because the module uses its own custom themes implementation, we should rename all classes to use a more standard ModuleName_ prefix to avoid conflicts with the preexisting classes.

Once the renaming was completed, the next item on our list was to remove any dependencies the module had on third-party assemblies. The reason this had to be done was due to licensing. Even though the only dependency was on a freely available assembly, this assembly did not have the same BSD license that is distributed with the DotNetNuke Web Application Framework. This meant that if the authors of this assembly decided to change their license, which they could do at any time, we could be forced to remove a release that was available for download to avoid legal ramifications. This dependency was on an assembly that allowed the module to interact with newsgroups. Removing support for this was no easy task because it existed throughout the entire module. This process seemed to only take a few weeks, but we would later find out that some of the remnants were causing one of the major bugs at the time.

Preparing for a First Release
When developing any project, you must determine a set of goals that should be accomplished to reach a release point. When dealing with an open source project that is constantly in development, this is even more important because you lack a well-defined set of requirements that you must achieve. Lacking these requirements makes it all too easy to keep developing and never reach a release point.

With the project now underway for almost three months, I knew the community was getting anxious to see the first official subproject release. I knew there were bugs in the existing code, but with only two of us actively working on the module, we were having difficulty filling the roles of architect, developer, and the Q&A team. We were trying to stick to the original plan of releasing then forming a team, so we decided to release a beta and use the community as our Q&A team.

Before we could release, we had to make sure that what we released is what people would expect from a DotNetNuke module. Among these expectations were the following:

• Installable as a standard packaged module
• Support the standard DotNetNuke data access layer and object qualifier
• Allow the source code version to simply be copied over on top of an installed version
• Support upgrades of this install in all future releases
• Not altering the core Web Application Framework
• Implementing ISearchable to expose to core search indexing

After the First Release
With the module now available for download to the community, I prepared myself to start answering usability questions and to start focusing on bug fixes. To support the module release, we created a set of groups and forums on DotNetNuke.com. This turned out to be the most critical part of this project's development. It allowed me and other core team members, along with a few community members, to use the module on a daily basis as users and not developers. Using the module daily brought out many usability issues that were overlooked in the local development environment. It also was a place for others who would not normally test the module to see it in action and report any feedback they had on it.

After making the module available for download, there was no shortage of feedback. During the first week or two the module was available I found myself spending roughly two hours a day in the forums and in the project's bug tracker answering support questions and logging bugs. Trying to keep up with the feedback and fix the issues logged was becoming increasingly difficult.

One of the other things this release showed us was that most of the community was having a difficult time following and understanding the code. I don't think this was because the module was overly complex; rather, I feel it was because they had only been exposed to it for a very brief period of time. Our original goal was to start forming a project team now that we released, but with so many support issues I wasn't exactly sure where I would find the time. Working a full-time job and keeping up with other aspects of DotNetNuke, when was I going to form a team, teach them about the module, and manage them?

After spending a bit of time debating what would be best for the project, it was decided to continue development of the module as we were before, and then form a team after a release came out that we felt was fairly stable. This ended up taking two more releases and three additional months. Looking back on this decision now I feel that we made the right choice because I think even with a project team we wouldn't have stabilized the module this quickly.

Forming a Team
Now that the project had a release that we felt was fairly stable, it was time to start the recruiting process to form a project team. Once again we were at a point where there were no previous examples to follow. Until now, all those involved with the core were chosen and not recruited. We gave this some thought and decided that we would recruit members using posts in forums and ask the recruits to submit resumes so that we'd have an idea of their knowledge. I felt a bit uncomfortable asking for resumes from volunteers to work on an open source project, but I wasn't sure how else we were going to measure the recruits' knowledge.