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.

We received about 10 submissions for the Forum Project. I wasn't really sure how many people we should have on the team, so I took the approach of accepting the eight applicants who seemed qualified. I e-mailed those whom I accepted and sent them the documents required to be a member of a DotNetNuke Project (an NDA and a Contributor License Agreement), and informed them that they were on a probationary period. The probationary period functioned to avoid their announcing publicly until we received all necessary agreements. Out of the eight, two never returned the agreements and two more resigned.

Managing an Open Source Project Team
It is my belief that regardless of whether your project is big or small, managing a development team in a commercial environment and managing one in an open source project are very similar. There are a few things, however, which are distinctly different. I think the aspect that is the most obvious, as well as the most difficult, is that you are managing volunteers.

In the commercial environment there is accountability. If someone is given a task, that person must complete it within a reasonable amount of time and if not, he or she must account for the reasons why it was not done on time. If the person fails to deliver repeatedly, there are some consequences that he or she might suffer. In an open source project, what consequences can you really dish out to volunteers? The only one I can think of is removing them from the team, but what do they really loose? So far I have been fortunate that all my team members contribute, but I am still unsure how I would handle it if things had gone differently.

Another one of those differences is communication. Everyone in the core team and in my projects speaks English. It may not be everyone's native tongue, but so far it has not been a barrier. Even with everyone speaking English there are still communication issues. Since we have no budget for traveling or phone conversations, it seemed best to use chat sessions for team meetings. This proved to be difficult because at our first chat we had one team member online at 8 p.m. Thursday and another online at 10 a.m. Friday. This wasn't so bad, except for those members who were online at 11 p.m. and 6 a.m. for a two-hour session.

The last major difference I have found between the two is how you would decide who does what. In the commercial environment I normally ask people to do things and based on their results, I let them continue doing so or replace them with someone else. I am not exactly sure why, but in the open source environment it just doesn't seem to work this way. So far, I have just let everyone do what he feels he is best at. This seems to be working because everyone is getting a better understanding of his module and the projects are moving forward faster than before. I do worry about this from time to time though, because I think I will eventually have to address it.

Despite all of the differences, there are many similarities between the two environments. One is you have a set of tools and have to get everyone adjusted to using those tools. The usage may not happen as frequently in the open source environment, but I think it is more than enough to keep the project organized. Procedure is another thing that is common between the two. I think this is even more important in the open source projects because it helps fill the communication gap.

Before becoming involved with the DotNetNuke Web Application Framework, one of the things I heard about open source projects is that they are a thankless effort. I have found this to be far from the truth. Just as with anything else, there is some negativity involved. In my experience however, this has been almost negligible compared to the praise received. This praise, combined with what I learn by doing this, makes it well worth the effort.

The Future
It has been roughly nine months since these Projects began. To the community, it may not seem as though much was accomplished. From my perspective, these Projects have come a long way. The previous release of the DNN Forum Project had over 35,000 downloads in only a three-month span. Now with the support of a team, features can be added, bugs can be fixed, and time between releases can be reduced. This increased efficiency, along with the implementation of continuous integration, should lead to more users and a better end result.