I'll help launch anyone who wants to startup a new DNN Open Source community site as long as the focus and priority is always open source DNN. Tell me where it is and I'll go.
A new DNN Extensions Store? I'll try it and support it but that won't be an easy feat. Many people have tried to launch their own store including DNN and they all failed. Brice won that battle by having the first-mover advantage. With the DNN Store embedded into DNN itself your chances of success are even lower. However, anyone can bring down a giant with the right tools. It would definitely be valuable to everyone if there was some competition. Some of the rules in the DNN Store are a bit harsh on vendors.
Instead of Forking DNN why not improve the core design a bit to make it more extensible and allow the community to build deeper providers?
Problem #1: The problem I hear the most from DNN haters is that the install is too complicated and error prone. Another related complaint is that they want some of the new features but not all of them.
Solution for #1: Refactor the core to use a provider pattern for the installer. Let people build custom installers so that DNN Corp. doesn't have to, then they can focus on Evoq while the community builds custom installers that allow you to choose the features you want. Remove or replace the embedded store, change or remove the upgrade notice, use a custom PageBase Provider or at least allow us to replace the exception handling in BasePortalExceoptions, ModuleLoadExceptions, PageLoadExceptions, SearchExceptions, SecurityExceptions, etc. I would love to build an Exception Provider for DNN for StreamInsight.
Problem #2: DNN is too complicated to skin for creative UI designers.
Solution for #2: Move the skin class or parts of it out and create a provider pattern so that the Skin loads from an extension instead. Then we can build Skin Rendering Providers. Examples of uses would be to create Skin Providers that can take a skins for any other CMS (Joomla, WordPress, etc) and have it render in DNN without changing the markup allowing web designers to build DNN skins without having to learn a new skill.
Problem #3: Branding and other countless other issues people have posted in this thread and elsewhere on the web.
Solution for #3: Refactor out the problem area and make it extensible. Make the embedded store extensible so that other stores can start-up and offer their own version of DNN with their store in the sites. The core should always be solid and the problem components should be replaceable.
Build a solid core and then build extensions for all areas of it. If the core is unreliable then the extensions are worthless. If we always have to modify the core to get what we need then the core is handling too much. A Fork is necessary but do you really want to break apart DNN and everyone working on it? I think it would better to improve the design of the core by moving key functionality out of it and using a provider pattern.
It would also allow DNN Corp. to focus on making Evoq more valuable for their target market without the community frustrated because it no longer fits their needs or is causing issues for them.
Then... build a few community open source DNN sites and a few other DNN Extension stores and now you have yourself the ultimate next generation global technological solution. Get Microsoft involved and have them fund the new stores and community sites in return for focused advertising of Windows 8 apps for DNN, Azure or even more Azure extensions.
If you make it reliable, it's open source, with a powerful instantly accessible and highly active community and while also extremely extensible so that you could throw a wrapper around all other competing CMS code....why would anyone use anything but DNN!?!?