ASP.NET

The second critical item that Microsoft delivered at this point in time was a community forums page on the www.asp.net web site (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.

Figure 1-2

One discussion forum on the www.asp.net site was dedicated to the discussion of the IBuySpy Portal application, and it soon became a hotbed for developers to discuss their enhancements, share source code enhancements, and debate IT politics. I became involved in this forum early on and gradually increased my community participation as my confidence in ASP.NET and the IBuySpy Portal application grew.

To appeal to the maximum number of community stakeholders, the IBuySpy Portal was available in a number of different source-code release packages. There were VB.NET and C#.NET language versions, each containing their own VS.NET and SDK variants. Although Microsoft was aggressively pushing the newly released C# language, I did not feel a compelling urge to abandon my familiar Visual Basic roots. In addition, my experience with classic ASP 3.0 allowed me to conclude that the new code-behind model in VS.NET was far superior to the inline model of the SDK. As luck would have it, I was able to get access to Visual Studio.NET through my employer. So as a result, I moved forward with the VB.NET/VS.NET version as my baseline framework. This decision would ultimately prove to be extremely important in terms of community acceptance, as I'll explain later.

When I first started experimenting with the IBuySpy Portal application, I had some specific objectives in mind. To support amateur sports organizations, I had collected a comprehensive set of end-user requirements based on actual client feedback. However, after evaluating the IBuySpy Portal functionality, it quickly became apparent that some significant enhancements were necessary if I hoped to achieve my goals. My early development efforts, although certainly not elegant or perfectly architected, proved that the IBuySpy Portal framework was highly adaptable for building custom applications and could be successfully used as the foundation for my amateur sports hosting application.

The most significant enhancement I made to the IBuySpy Portal application during these early stages was a feature that is now referred to as "multi-portal" or "site virtualization." Effectively this was a fundamental requirement for my amateur sports hosting model. Organizations wanted to have a self-maintained web site, but they also wanted to retain their individual identity. A number of vendors emerged with semi-self-maintained web applications, but nearly all of them forced the organization to adopt the vendor's identity (that is, www.vendor.com/clientname rather than www.clientname.com). Although this may seem like a trivial distinction for some, it has some major effects in terms of brand recognition, site discovery, search engine ranking, and so on. The IBuySpy Portal application already partitioned its data by portal (site), and it had a field in the Portals database table named PortalAlias that was a perfect candidate for mapping a specific domain name to a portal. It was as if the original creators (Microsoft and Vertigo) considered this use case during development but did not have enough time to complete the implementation, so they simply left the "hook" exposed for future development. I immediately saw the potential of this concept and implemented some logic that allowed the application to serve up custom content based on domain name. Essentially, when a web request was received by the application, it would parse the domain name from the URL and perform a lookup on the PortalAlias field to determine the content that should be displayed. This site virtualization capability would ultimately become the "killer" feature that would allow the application to achieve immediate popularity as an open source project.

Over the next 8 to 10 months, I continued to enhance and refactor the IBuySpy Portal application as I created my own custom implementation (now code-named SportsManager.Net). I added numerous features to improve the somewhat limited portal administration and content management aspects. At one point, I enlisted the help of another developer, John Lucarino, and together we steadily improved the framework using whatever spare time we were able to invest. Unfortunately, because all of this was going on outside of regular work hours, there was little time that could be focused on building a viable commercial venture. So at the end of 2002, it soon became apparent that we did not have enough financial backing or a business model to take the amateur sports venture to the next level. This brought the commercial nature of the endeavor under scrutiny. If the commercial intentions were not going to succeed, I at least wanted to feel that my efforts were not in vain. This forced me to evaluate alternative non-commercial uses of the application. Coincidentally, I had released the source code for a number of minor application enhancements to the www.asp.net community forum during the year and I began to hypothesize that if I abandoned the amateur sports venture altogether, it was still possible that my efforts could benefit the larger ASP.NET community.

The fundamental problem with the IBuySpy Portal community was the fact that there was no central authority in charge of managing its growth. Although Microsoft and Vertigo developed the initial code base, there was no public commitment to maintain or enhance the product in any way. Basically the product was a static implementation, frozen in time, an evolutionary dead-end. However, the IBuySpy Portal EULA was extremely liberal, which meant that developers were free to enhance, license, and redistribute the source code in an unrestricted manner. This led to many developers creating their own customized versions of the application, sometimes sharing discrete patches with the general community, but more often keeping their enhancements private, revealing only their public-facing web sites for community recognition (one of the most popular threads at this time was titled "Show me your Portal"). In hindsight, I really don't understand what each developer was hoping to achieve by keeping his enhancements private. Most probably thought there was a commercial opportunity in building a portal application with a richer feature set than their competitor. Or perhaps individuals were hoping to establish an expert reputation based on their public-facing efforts. Either way, the problem was that this mindset was really not conducive to building a community but rather to fragmenting it — a standard trap that tends to consume many things on the Microsoft platform. The concept of sharing source code in an unrestricted manner was really a foreign concept, which is obviously why nobody thought to step forward with an organized open source plan.

I have to admit I had a limited knowledge of the open-source philosophy at this point because all of my previous experience was in the Microsoft community — an area where "open source" was simply equated to the Linux operating system movement. However, there was chatter in the forums at various times regarding the organized sharing of source code, and there was obviously some interest in this area. The concept of incorporating the best enhancements into a rapidly evolving open-source application made a lot of sense because it benefited the entire community and created a wealth of opportunities for everyone. Coincidentally, a few open-source projects had recently emerged on the Microsoft platform to imitate some of the more successful open-source projects in the LAMP community. In evaluating my amateur sports application, I soon realized that nearly all of my enhancements were generic enough that they could be applied to nearly any web site — they were not sports-related whatsoever. I concluded that I should release my full application source code to the ASP.NET community as a new open source project. So, as a matter of fact, the initial decision to open source that would eventually become DotNetNuke happened more out of frustration of not achieving my commercial goals rather than predicated philan-thropic intentions.