With anticipation building for the next generation DotNetNuke platform, as well as some general misconceptions circulating in the community, it is important to clarify some of the most important details around the impending arrival of Cambrian.
When the Cambrian plans were first announced at the OpenForce conferences in late 2007, it generated a great deal of excitement within the DotNetNuke community. The Cambrian roadmap identified a number of large scale enhancements to the DotNetNuke product, features that have been requested by various members of the community for quite some time, and which will no doubt significantly accelerate business adoption of the platform.
Although we often refer to the next generation DotNetNuke platform as the Cambrian "release", it was never intended to be a single monolithic release. Rather, as per our standard iterative development methodology, Cambrian is intended to be a series of major software releases, each containing significant new functionality and upgrade support from previous versions. The iterative approach allows us to focus on delivering specific enhancements to the community, obtaining valuable feedback, and stabilizing the product; all in very short release cycles.
The goals of Cambrian are fairly ambitious, and due to the size and scope of the work involved, are contingent upon at least one major contributing factor. Enhancements of the magnitude being contemplated require dedicated resources. I covered this topic in some detail in the first chapter of the DotNetNuke 4 book from WROX but to summarize, the widely shared notion that open source projects basically have unlimited resources at their immediate disposal is not based on reality. Now, I am not disputing the cost benefit of the open source model, as it is now a well established economic fact. However, what is not so well understood, is that not every available resource has the precise expertise required, nor can they be counted on to contruct the software in accordance to the vision or goals of the project founders, or on the desired schedule. To put this into perspective, it is similar to putting out an invitation for any stranger who owns a hammer to come over and build a portion of your new house. Now, I am sure you would end up with some type of shelter, but I am not so sure if the end result would meet your expectations of quality.
When we announced the Cambrian roadmap, we knew that resources were going to be a challenge. Serious development requires significant financial resources and to deliver the Cambrian functionality on the estimated schedule, we knew that we would need to acquire some sufficient sources of funding. Since late 2007 we have been pursuing funding from professional and institutional sources, but the results are taking longer than expected to materialize. As a result, although the scope for Cambrian has remained the same, the schedule has slipped slightly from our original plan. The original schedule included quarterly milestones aligned with each of the significant enhancement areas of the Cambrian roadmap; with the entire product offering to be delivered by the end of 2008. At this point we anticipate the schedule has slipped one quarter; although we feel that it is possible that we could achieve the original milestones if sufficent funding is confirmed in the immediate future.
Moving on to some of the specific details around Cambrian, its important to clarify one of the false assumptions which I have heard in the community in recent months. At this point, there are no concrete plans to introduce breaking changes as part of Cambrian. As a framework, we recognize the vital importance of maintaining backward compatibility with third party solutions and as a result we always try to introduce new functionality in a non-breaking manner. This is especially true as the business ecosystem evolves around DotNetNuke; as it makes no business sense for us to provide a barrier which restricts users of the platform from upgrading to Cambrian. Now, to be honest, there are sometimes scenarios where there is no practical solution which will allow us to maintain compatibility. In these cases, we always consider the number of users affected by the change, and will only proceed if the issue is isolated to edge conditions so that the conventional use cases are unaffected. As an extra precaution, we plan to work closely with module developers and skin designers to ensure we catch compatibility issues early and provide them with a chance to get prepared for the new platform ( DotNetNuke Marketplace vendors will be given first priority ).
In regards to the Cambrian roadmap, it is important to note that most of the enhancements identified previously ( ie. in my OpenForce keynote ) belong in the content management category. Enhancements such as social networking, workflow, user interface overhaul, etc... are critical to business usage scenarios and will have a large impact on platform adoption. However, before we could proceed with these enhancements, some major foundational modifications were required to the underlying web application framework in order to facilitate the content management functionality. As a result, the initial Cambrian release will not contain any of the marquee enhancements identified on the roadmap. Instead, it will contain infrastructure enhancements which provide a solid foundation for implementing the content management enhancements in future releases.
We are now 5 months into Cambrian development and are near feature complete on the initial 5.0.0 release. There are a sigificant number of framework enhancements which are already integrated and will definitely need to be described in more detail in order to comprehend their true business or technical relevance. You can expect a Beta drop in the coming weeks. I hope the community is as excited about Cambrian as I am; 2008 is going to be huge year for DotNetNuke.