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

When researching the open source phenomenon, there are a few fundamental details that are often ignored in favor of positive marketing rhetoric. I would like to take the opportunity to bring some of these to the surface because they provide some additional insight into some of the issues we face in the DotNetNuke project.

The first myth surrounds the belief that open source projects basically have an unlimited resource pool at their immediate disposal. Although this may be true from a purely theoretical perspective, the reality is that you still require a dedicated management structure to ensure that all of the resources are channeled in an efficient and productive manner. An army of developers without some type of central management authority will never consistently produce a cohesive application; and more likely, their efforts will result in total chaos. As much as the concept is often despised by hard-core programmers, dedicated management is absolutely necessary to set expectations and goals, ensure product quality, mitigate risk, recognize critical dependencies, manage scope, and assume ultimate responsibility. You will find no successful open source project that does not have an efficient and highly respected management team.

Also with regards to the unlimited resourcing myth, there are in fact few resources who become involved in an open source project that possess the level of competency and communication skills required to earn a highly trusted position in the meritocracy. More often, the resources who get involved are capable of handling more consumer-oriented tasks such as testing, support, and minor defect corrections. This is not to say that these resources do not play a critical role in the success of the project — every focused ounce of volunteer effort certainly helps sustain the health of the project. But my point is that there is usually a relatively small group on most open source projects who are responsible for the larger-scale architectural enhancements.

Yet another myth is related to the belief that anyone can make a direct and immediate impact on an open source project. Although this may be true to some degree, you generally need to build a trusted reputation within the community before you are granted any type of privilege. And there are few individuals who are ever awarded direct write access to the source code repository. Anyone has the ability to submit a patch or enhancement suggestion; however, there's no guarantee that it will be added to the open source project code base. In fact, all submissions are rigorously peer-reviewed by trusted resources, and only when they have passed all validation criteria are they introduced to the source code repository. In addition, although a specific submission may appear to be quite useful when judged in isolation, there may be higher-level issues to consider in terms of upgrade support (a situation that can lead to submitter frustration if the issues are not fully explained). From a control standpoint, this is not much different than source control management on a traditional software project. However, the open source model does significantly alter this paradigm in that everyone is able to review the source code. As a result, the sheer volume of patches submitted to this process can be massive.

There are also some interesting interpretations of open source philosophy that occasionally result in differences of opinion and, in the worst cases, all-out community revolts. This generally occurs because the guidelines for open source are quite non-explicit and subjective. One particularly hot topic that relates to DotNetNuke is source code access.

Some open source projects provide anonymous read-only access to the development source code base at all times. This full transparency is appreciated by developers who want to stay abreast of the latest development efforts — even if they are not trusted members of the inner project team. These developers accept the fact that the development code may be in various stages of stability on any given day, yet they appreciate the direct access to critical fixes or enhancements. Although this model does promote more active external peer review, it can often lead to a number of serious problems. If developers decide to use prerelease code in a production environment, they may find themselves maintaining an insecure or unstable application. This can lead to a situation in which the community is expected to support many hybrid variants rather than a consistent baseline application. Another possible issue is that a developer who succumbs to personal motivations may be inclined to incorporate some of the development enhancements into the current production version and release it as a new application version. Although the open source license may allow this, it seriously affects the ability for official project maintainer to support the community. It is the responsibility of the project maintainer to always ensure a managed migration path from one version to the next. This model can only be supported if people are forced to use the official baseline releases offered by the project maintainer. Without these constants to build from, upgrades become a manual effort and many users are left on evolutionary dead-ends. For these reasons, DotNetNuke chooses to restrict anonymous read access to the development source code repository. Instead, we choose to issue periodic point releases that allow us to provide a consistent upgrade mechanism as the project evolves.