( Excerpt from Professional DNN7 Open Source.NET CMS Platform by WROX Press )

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

Next: Stabilization