I would like to join this conversation and shed some light on our dogfooding strategy. We strongly believe that dogfooding is one of the best ways to find out the strenghts and weekneses of our products. While most of our public websites may not be running Sitefinity 5.x we do dogfood the product in a number of other projects. A quick example is that every Telerik division has its own internal product portal running on Sitefinity. Futhermore in the beginning of June this year we have released the fist Telerik product division website running on 5.0: http://www.icenium.com/. This project is currently going through our testing process and will soon be running on 5.1. Apart from this product website we do run a number of other projects on Sitefinity 5.x, a quick list below:
Kendo UI Documentation
Sitefinity & Beyond
Both documentation websites relly heavily on the Dynamic Modules for building help content. Other than those projects we do have a number of other websites in the pipeline - one more conference website, and our own http://www.sitefinity.com/. Expect more news on this matter sometime in mid-September.
Let me assure you that the decision on when to start migrating the existing website to the new version of the product was never a decision based on the quality of the product. There are many other factors that dictate when to start this process. Our priorities so far have been to first cater to the needs of our customers. Furthermore the current implementation heavily relies on integration with external systems used in Telerik, which have been developed before Sitefinity (purchase process, forums, ticketing system, CRM, etc.). Instead of simply creating plugins for those systems for Sitefinity 5.x, we have decided to take a different path. Instead of reffering all proprietary bussiness logic and reffering all custom implementation of those systems in the public site, we are building a service oriented architecture which will allow us to decouple the site from the systems. This path, however also is slowing us down, as we need to first build the new architecture, and then make the site utilize it.
@Dan and @MB, indeed whitelisting IPs using the default IIS functionality is close to impossible with Sitefinity 4.x and above. The reason for this that we do relly on certain services, and route handlers including /Sitefinity in their pat. This however can be achieved with the IIS URL rewriter to crete a set of rules (which will explude service and route paths) and prevent outside users seeng the /Sitefinity login page).
A product like Sitefinity is always a work in progress. Perfection is always work in progress especially in the fast changing software world (just think about how many thinks came along - IIS is changing, Azure is changing, new windows server is comming, etc.). Sure telerik can say "we only support windows 2003 and Sql and live hapilly for years but I prefer them to shoot for the moon. It took Edison about 6000 unsuccessful trials to create a light bulb that can be used commercially. It will probably take more to make Sitefinity "the CMS holly grail" but they will make it, you watch. Meanwhile we should carefully test if Sitefinity provides what we need to avoid being disappointed (or disappointing our clients which is even worse).
OK you got me I am a huge Sitefinity fanboy :-).
Heads up :-)
Pavel @ eveliko