CI Tools and Best Practices in the Cloud

Continuous Integration

Subscribe to Continuous Integration: eMailAlertsEmail Alerts newslettersWeekly Newsletters
Get Continuous Integration: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Continuous Integration Authors: Derek Weeks, Pat Romanski, Liz McMillan, Elizabeth White, Mehdi Daoudi

Related Topics: Continuous Integration

Continuous Integration: Article

Managing an Open Source Project for DotNetNuke

A first-person perspective from idea to code complete

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
Once all this criteria was met we hit another road block. Since no module had been released separately from the core before, there was no proper procedure for releasing a module independently from the core. Since DotNetNuke has always been in the habit of installing its releases on www.DotNetNuke.com prior to distributing, we took this approach with the DNN Forum module. After fixing several bugs that we determined was necessary prior to public release, we finally made the module available for download.

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.

More Stories By Chris Paterra

Chris Paterra is is the lead developer and project manager working on a variety of different DotNetNuke projects for client and internal use at AppTheory in Atlanta, GA. He is part of the DotNetNuke core team and is project lead of the Forum and Gallery sub-projects.

Comments (3) View Comments

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


Most Recent Comments
Carmen E. 02/06/06 09:39:56 PM EST

Hi.
I'm really thankful to the team of people that lead and development Dotnetnuke Project. One of my task ending last year was to develop a corporative intranet in short time including particular modules development by us(employees attendance & vacation system). When i found DOtnetnuke project, it made everything easier, intranet's schema was made, just need to setting up and add the necessary modules. I'm really interested reading forums about this open source project and i'll continue improve my development techniques.
Good Luck!!All effort worths it :)

Keith Norfleet 12/29/05 10:12:24 AM EST

I would be interested in helping out. How do I get on board?

Enterprise Open Source Magazine News Desk 12/26/05 05:04:14 PM EST

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.