So lets start at the top and clear up a few items - right now there is no approved Roadmap. I expect to have a final approved roadmap in the next couple of days and will post it as soon as I have approval to do so.
Over a year and a half ago, we laid out a vision for the DNN 5.0 roadmap (this was talking about community edition features). That vision, as we indicated at the time was predicated on having adequate financial resources to make it happen. We did not get those resources until this past November, shortly after Open Force 08. Now that we have the needed funding, we are moving forward on delivering the community edition features that we talked about at Open Force. These features includes: 1) a much improved user experience that is more contemporary 2) Social networking features 3) Workflow 4) Dynamic Content Localization and 5) Core Module Suites
Our commitment to this feature set in the community edition has not changed one bit - the only issue we have right now is what does each of these features look like. We as a corporation have to make a decision how many hours can we allocate to implement certain features and still hit our goal of delivering all these features by the end of the year. Even with funding, we still have limited resources. They are more than what we had in the past - but still limited. This means that I cannot implement all of the FaceBook, LinkedIN, Bebo, Windows Live and Open Social features in our 5.x timeframe. Nor can I implement the full workflow experience that you have in a product like K2. or HandySoft BPM. We have to decide what are the most crucial aspects of Social Networking that are important to the broad community. What are the aspects of Workflow that will satisfy the requirements of 80% of the community. The same is true of every other feature outlined above. We will build out each of these features, to the degree that we have resources to do so in the timeframes we committed to.
One of the benefits of having a great community is that we also are able to leverage the work of community members. We have had several discussions and evaluated a lot of options for the workflow and social networking portions of our roadmap and are moving forward on getting appropriate pieces contributed for inclusion in the core. Even with those submissions there is still some work involved to get them properly integrated, and to get certain key use cases supported. We cannot just drop them in and expect them to meet our needs.
As we have indicated over and over, we absolutely have increased the number of people working on DotNetNuke Community Edition. But we also have engineers who are working on enhancements for DotNetNuke Professional and on enhancements to DotNetNuke Marketplace. We do not apologize for that. We have a right, just like every company in the ecosystem to decide how much corporate resources will be spent on developing the Open Source software and how much will be spent on our commercial endeavors. They are both important to the survival of the project. As both Shaun and Cathal have previously stated, a sound Community Edition is critical for our commercial interests. And a strong viable company is critical to the ongoing maintenace of the project. One cannot succeed without the other.
As for the roadmaps items that was originally posted. I know that some of those items are incorrect. There has been a lot of back and forth over the last several weeks about what features would be delivered, when they would be delivered, and which enhancements would be delivered for PE and which enhancements would be delivered in CE. Clearly it was not adequately communicated to sales what those features would be, and more importantly what does each of the terms mean.
For example "Caching provider for webfarms" doesn't really tell you much. What is it? How is it different from what is delivered today in CE? Why is it important to a customer? In this particular case let's answer these questions - The new caching provider enables greater scalability over the current FileBasedCaching provider. While the current FileBasedCaching provider works well for many webfarms, as you start increasing the number of servers in the farm beyond 3 or 4, the FileBasedCaching provider starts dropping in efficiency. It is still useable, but the architecture necessarily is not as scalable as is needed in some cases. Also, some customers running larger web farms want greater flexibility in the web farm configurations we support. Clearly, web farm support is not something that is used by the vast majority of our user base. However, there are a lot of larger sites that are demanding greater scalability and flexibility and it is a natural feature to be delivered in a professional level product. We will continue to support and enhance the FileBasedCaching provider, but for really demanding environments we will recommend the new caching provider and DotNetNuke Professional. (@SuperHoopsa - while this feature might benefit you, your specific issue is caused by a known limitation in the 4.9.x caching implementation which is unrelated to web farms and which is fixed in the 5.x codebase)
I won't go into each feature listed - primarily because several of them are incorrect about their delivery timeframe and about which version of the product they will go in. I will leave the clarification for each feature until after we officially publish the roadmap.
Specific answers:
@Jeff Cochran - We are still committed to including workflow and versioning in Community Edition.
@Jari - PE and CE are on the same path as they both use the same core framework. We will develop advanced modules, skin objects, providers and other extensions that plug into the core that we deliver to our Professional customers.
@Oliver - What is there to fork? People are already free to develop their own modules, skin objects, providers and extensions - and in fact they do - just look on CodePlex, SourceForge, Marketplace and SnowCovered. We are using those same extensibility points to deliver value to our Professional Customers. At the same time we are accelerating enhancement of the Community Edition platform. You do not need DotNetNuke Corp to create an enhanced Control Panel (in fact there are already advanced Control Panels available today). We provide the needed hooks for anyone to build a control panel and install it for their customers, just like we will do for our customers. This does not require a code fork, it just requires you to decide that it is a feature that is important to your customer and to spend the engineering effort building it.
@Oliver - DotNetNuke Corp does not have some secret infrastructure in place that we use that is any different from that used by the community. We use the same forums, the same bug tracker, and the same version control system as our community does. We are well aware of the limitations of each one, and in fact are working on correcting many of the deficiencies. Just because we have not sent you a personal email does not mean that no work is occuring. I know the forums team has been hard at working preping the next forums release. We have core team members that are working DNN Corp staff on the Gemini upgrade and we are in the middle of shifting our code repository so we can open it up to the entire community. It is easy to say "just do it", it is another to actually get it done, as it often takes a lot more effort than most people understand.
@Oliver - DNN 5 was the most widely tested and most widely distributed release of any major platform upgrades we have ever had. DNN 5 started with early beta releases last April (these releases were probably closer to Alpha releases). We worked through a lot of issues before we ever opened it up outside the core team. We went through a number of releases where we opened it up to more and more participants and made the release open to the entire world a full month and a half before the 5.0 release. One of the reasons it was released is because with all that exposure, we were not getting many bugs reported. In fact in both November and December we had the bug count down in single digits. I could easily have held DNN 5.0 for another month - but if no one is telling me there are bugs, what is the point of holding up the release? So why did we get a bunch of bugs reported in January that weren't reported in December. In most cases, the bugs reported in January were wholly unrelated to the bugs fixed in December. A vast majority of the bugs existed in the product going back for 3 or more months prior to the release. Having been heavily involved in tracking and monitoring the bugs, I can say without question that spending another month in beta would not have substantially improved the quality of the code. So we releaseed it. And people reported bugs - and we fixed a large number of them over the next month and a half and released 5.0.1. And yet more bugs were reported (why weren't they caught in 5.0?), and we are busy fixing as many of those as we can. 5.0.1 is more stable than 4.0.1 or 3.0.1 or even 2.0.1. Is it yet at a point where I would recommend our Professional customers move to it? No, but it is getting close. Does that mean that it is unuseable in a production environment? No. I know many people who are using it without any major issues. Yes they have found some problems, but then I have people who found problems in 4.9.2 as well.
I hope this addresses many of the questions raised in this thread. I am sure there will be more, but I would hope that people would look at our actions for the past 6 years and not automatically assume the worst. We do not benefit at all by harming the very community we spent many years building up. Our intention is to grow this community, to help other members of the ecosystem to thrive and to hopefully find a way to be rewarded ourselves for all the hard work we have put in over the years.
[EDIT] Sorry. Didn't mean to go all Nina on everyone with the 1000 page forum post but in this case I hope I was able to answer everyone's questions.