In 2001-2002, I was working for a medium-sized software consulting company in Abbotsford, British Columbia, that was providing outsourced software development services to a variety of large U.S. clients specializing primarily in e-Learning initiatives. The internal push was to achieve CMM 3.0 on a fairly aggressive schedule so that we could compete with the emerging outsourcing powerhouses from India and China. As a result there was an incredible amount of focus on process and procedure and somewhat less focus on the technical aspects of software engineering. Because the majority of the client base was interested in the J2EE platform, the company primarily hired resources with Java skills - leaving me with my legacy Microsoft background to assume more of an internal-development and project-management role. The process improvement exercise consumed a lot of time and energy for the company, attempting to better define roles and responsibilities and ensuring proper documentation throughout the project life cycle. Delving into CMM and the PMBOK were great educational benefits for me - skills that would prove to be invaluable in future endeavors. Ultimately, the large U.S. clients decided to test the overseas outsourcing options anyway, which resulted in severe downsizing for the company. It was during these tumultuous times that I recognized the potential of the newly released .NET Framework (beta) and decided that I would need to take my own initiative to learn this exciting new platform to preserve my long-term employment outlook.

Realizing the educational value of sample applications, Microsoft built a number of source projects that were released with the .NET Framework 1.0 Beta to encourage developers to cut their teeth on the new platform. These projects included full source code and a liberal End User License Agreement (EULA), which provided nearly unrestricted usage. Microsoft co-developed the IBuySpy Portal with Vertigo Software and promoted it as a "best practice" example for building applications in the new ASP.NET environment. Despite its obvious shortcomings, the IBuySpy Portal had some strong similarities to both the Microsoft SharePoint Portal, Content Management Server, as well as other open source CMS applications on the Linux/Apache/mySQL/PHP (LAMP) platform. The portal allowed you to create a completely dynamic website consisting of an unlimited number of virtual "tabs" (pages). Each page had a standard header and three content panes - a left pane, middle pane, and right pane (a standard layout for most portal sites). Within these panes, the administrator could dynamically inject "modules" - essentially mini-applications for managing specific types of web content. The IBuySpy Portal application shipped with six modules designed to cover the most common content types (announcements, links, images, discussions, html/text, and XML) as well as a number of modules for administrating the portal site. As an application framework, the IBuySpy Portal (see Figure 1-1) provided a mechanism for managing users, roles, permissions, tabs, and modules. With these basic services, the portal offered just enough to whet the appetite of many aspiring ASP.NET developers.

The second critical item that Microsoft delivered at this point in time was a community forums page on the www.asp.net website (see Figure 1-2). This forum provided a focal point for Microsoft developers to meet and collaborate on common issues in an open, moderated environment. Prior to the release of the forums on www.asp.net, there was a real void in terms of Microsoft community participation in the online or global sphere, especially when compared to the excellent community environments on other platforms.

On December 24, 2002, I released the full open source application by creating a simple website with a Zip file for download. The lack of foresight of what this would become was extremely evident when you consider the casual nature of this original release. However, as luck would have it, I did do a few things right. First, I thought I should leverage the IBuySpy brand in my own open source implementation so that it would be immediately obvious that the code base was a hybrid of the original IBuySpy Portal application, an application with widespread recognition in the Microsoft community. The name I chose was IBuySpy Workshop because it seemed to summarize the evolution of the original application. Rather than assume individual responsibility for the project, I released IBuySpy Workshop as a product of Perpetual Motion Interactive Systems Inc., my personal consulting company. Ironically, I did not even have the domain name resolution properly configured for www.ibuyspyworkshop.com when I released (the initial download links were based on an IP address, http://65.174.86.217/ibuyspyworkshop). The second thing I did right was to require people to register on my website before they were able to download the source code. This allowed me to track the actual interest in the application at a more granular level than simply by the total number of downloads. Third, I publicized the availability of the application in the IBuySpy Portal Forum on www.asp.net (see Figure 1-3). This particular forum was extremely popular at this time; and as far as I know, nobody had ever released anything other than small code snippet enhancements for general consumption. The original post was made on Christmas Eve, December 24, 2002, which had excellent symbolism in terms of the application being a gift to the community.

The public release of the IBuySpy Workshop (see Figure 1-4) created such a surge in forum activity that it was all I could do to keep up with the feedback; especially because this all occurred during the Christmas holidays. I had a family vacation booked for the first two weeks of January, and I left for Mexico on January 2, 2003 (one week after the initial IBuySpy Workshop release). At the time, the timing of this family vacation seemed poor because the groundswell of interest in the IBuySpy Workshop seemed like it could really use my dedicated focus. However, in hindsight the timing could not have been better, because it proved that the community could support itself - a critical element in any open source project. When I returned home from vacation, I was amazed at the massive response the release achieved. The IBuySpy Portal Forum became dominated with posts about the IBuySpy Workshop and my Inbox was full of messages thanking me for my efforts and requesting me to provide support and enhancements. This certainly validated my decision to release the application as an open source project but also emphasized the fact that I had started a locomotive down the tracks and it was going to take some significant engineering to keep it on the rails.

In late February 2003, the lack of sleep, family priorities, and community demands finally came to a head and I decided that I should reach out for help. I contacted a former employer and mentor, Kent Alstad, with my dilemma and we spent a few lengthy telephone calls brainstorming possible outcomes. However, my personal stress level at the time and my urgency to change direction on the project ultimately caused me to move too fast and with more impulsiveness than I should have. I announced that the IBuySpy Workshop would immediately become a subscription service where developers would need to pay a monthly fee to get access to the latest source code. From a personal perspective, the intent was to generate enough revenue that I could leave my day job and focus my full energy on the management of the open source project. And with 2000 registered users, a subscription service seemed like a viable model (see Figure 1-5).

Coincidentally, the political nightmare I created in the IBuySpy Workshop Forum with my subscription announcement resulted in some direct attention from the Microsoft ASP.NET product team (the maintainers of the www.asp.net site). Still trying to recover from the damage I incurred to the goodwill of the project, I received an email from none other than Scott Guthrie (co-founder of the Microsoft ASP.NET Team), asking me to reexamine my decision on the subscription model and making suggestions on how the project could continue as a free, open source venture. It seemed that Microsoft was protective of its evolving community and did not want to see the progress in this area splinter and dissolve just as it seemed to be gaining momentum. Scott Guthrie made no promises at this point but he did open a direct dialogue that ultimately led to some fundamental discussions on sponsorship and collaboration. In fact, this initial email led to a number of telephone conversations and ultimately an invitation to Redmond to discuss the future of the IBuySpy Workshop.

One of the topics that Scott Guthrie and I discussed in our early conversations was the issue of product branding. IBuySpy Workshop achieved its early goals of providing a public reference to the IBuySpy Portal community. This resulted in an influx of ASP.NET developers who were familiar with the IBuySpy Portal application and were interested in this new open source concept. But as the code bases diverged, there was a need for a new project identity - a unique brand that would differentiate the community and provide the mechanism for building an internationally recognized ecosystem. Research of competing portal applications on other platforms revealed a strong tendency toward the "nuke" slogan.

A secondary issue that was not addressed during the early stages of the project was licensing. The original IBuySpy Portal was released under a liberal Microsoft EULA license that allowed for unrestricted usage, modification, and distribution. However, the code base underwent such a major transformation that it could hardly be compared with its predecessor. Therefore, when the IBuySpy Workshop application was released, I did not include the original Microsoft EULA, nor did I include any copyright or license of my own. Essentially this meant that the application was in the public domain. This is certainly not the most accepted approach to an open source project and eventually some of the more legal-savvy community members brought the issue to a head. I was forced to take a hard look at open source licensing models to determine which license was most appropriate for the project.

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 percent 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.