Professional DotNetNuke 4: Open Source Web Application Framework for ASP.NET 2.0 (Programmer to Programmer)

The next major milestone in the project's open source evolution occurred in the summer of 2003. Up until this point, I had been acting as the sole maintainer of the DotNetNuke code base, a task that was consuming 110% of my free time as I feverishly fixed bugs and enhanced the framework based on community feedback. Still I felt more like a bottleneck than a provider, in spite of the fact that I was churning out at least one significant release every month leading up to this point. The more active community members were becoming restless due to a lack of direct input into the progress of the project. In fact, a small faction of these members even went so far as to create their own hybrid or "fork" of the DotNetNuke code base that attempted to forge ahead and add features at a more aggressive pace than I was capable of on my own. These were challenging times from a political standpoint because I was eventually forced to confront all of these issues in a direct and public manner — flexing my "benevolent dictator" muscles for the first time — an act I was not the least bit comfortable performing. Luckily for me, I had a number of loyal and trustworthy community members who supported my position and ultimately provided the backing to form a strong and committed Core Team.

As a result of the single-threaded issues I mentioned earlier, most successful open source projects are comprised of a number of community volunteers who earn their positions of authority within the community based on their specific expertise or community support activities. This is known as a meritocracy, a term that means that an individual's influence is directly proportional to the ability that the individual demonstrates within the project. It's a well-observed fact that individuals with more experience and skills have less time to devote to volunteer activities; however, their minimal contributions prove to be incredibly valuable. Similarly, individuals with less experience may be able to invest more time but may only be capable of performing the more repetitive, menial tasks. Building a healthy balance of these two roles is exactly what is required in every successful open source project; and in fact, is one of the more challenging items to achieve from a management perspective.

The original DotNetNuke Core Team was selected based on their participation and dedication to the DotNetNuke project in the months leading up to the team's formation. In most cases this was solely based on an individual's public image and reputation established in the DotNetNuke Forum on the www.asp.net web site. And in fact, in these early stages, the online persona of each individual proved to be a good indicator of the specific skills they could bring to the project. Some members were highly skilled architects, others were seasoned developers, and others were better at discussing functionality from an end-user perspective and providing quality support to their community peers.

To establish some basic structure for the newly formed Core Team, I attempted to summarize some basic project guidelines. My initial efforts combined some of the best Extreme Programming (XP) rules with the principles of other successful open source projects. This became the basis of the DotNetNuke Manifest document:

• Development is a team effort: The whole is exponentially greater than the sum of its parts. Large-scale open source projects are only viable if a large enough community of highly skilled developers can be amassed to attack a problem. Treating your users as co-developers is your most effective option for rapid code improvement and effective debugging.

• Build the right product before you build the product right: Focus should be directed at understanding and implementing the high-level business requirements before attempting to construct the perfect technical architecture. Listen to your customers.

• Incremental development: Every software product has infinite growth potential if managed correctly. Functionality should be added in incremental units rather than attempting a monolithic implementation. Release often but with a level of quality that instills confidence.

• Law of diminishing return: The majority of the effort should be invested in implementing features that have the most benefit and widest general usage by the community.

DotNetNuke version 1.0.10 was the proving grounds for the original Core Team. The idea was to establish the infrastructure to support disconnected team development by working on a stabilization release of the current product. A lot of debate went into the selection of the appropriate source control system because, ironically enough, many of the Core Team had never worked with a formal source control process in the past (a fact that certainly emphasized the varied professional background of the Core Team members). The debate centered on whether to use a CVS or VSS model.

CVS is a source control system that is popular in the open source world that enables developers to work in an unrestricted manner on their local project files and handles any conflicts between versions when you attempt to commit your changes to the central repository. Visual SourceSafe (VSS) is a Microsoft source-control system that is supported by the Microsoft development tool suite, which requires developers to explicitly lock project files before making modifications to prevent version conflicts. Ultimately the familiarity with the Microsoft model won out and we decided to use the free WorkSpaces service on the GotDotNet web site (a new developer community site supported by Microsoft). GotDotNet also provided a simplistic Bug Tracker application that provided us with a means to manage the tracking of issues and enhancement requests. With these infrastructure components in place, we were able to focus on the stabilization of the application, correcting known defects and adding some minor usability enhancements. It was during this time that Scott Willhite stepped forward to assume a greater role of responsibility in the project; assisting in management activities, communication, prioritization, and scheduling.

A significant enhancement that was introduced in this stabilization release came from a third party who had contacted me with some specific enhancements they had implemented and wished to contribute. The University of Texas at El Paso had done extensive work making the DotNetNuke application compliant with the guidelines of the American Disabilities Association (ADA) and Section 508 of the United States Rehabilitation Act. The United States government made compliancy mandatory for most public organizations; therefore, this was a great enhancement for DotNetNuke because it allowed the application to be used in government, educational, and military scenarios. Bruce Hopkins became the Core Team owner of this item in these early stages, a role that required a great deal of patience as the rest of the team came to grips with the new concept.

Establishing and managing a team was no small challenge. On one hand, there were the technical challenges of allowing multiple team members, all in different geographic regions, to communicate and collaborate in a cost-effective, secure environment. Certainly this would have never been possible without the Internet and its vast array of online tools. On the other hand, there was the challenge of identifying different personality types and channeling them into areas where they would be most effective. Because there are limited financial motivators in the open source model, people must rely on more basic incentives to justify their volunteer efforts. Generally this leads to a paradigm where contributions to the project become the de facto channel for building a reputation within the community — a primary motivator in any meritocracy As a result of working with the team, it soon became obvious that there were two extremes in this area: those who would selflessly sacrifice all of their free time (often to their own detriment) to the open source project, and those who would invest the minimal effort and expect the maximum reward. As the creator and maintainer of the project it was my duty to remain objective and put the interests of the community first. This often caused me to become frustrated with the behavior of specific individuals, but in nearly all cases these issues could be resolved without introducing any hard feelings on either side. This is true in all cases except one.