Been following this thread for a while but been out of the loop on other non DNN projects so not really focused.

But a support request from a client raised an issue which seems to me to poke at the heart of this conversation.  My clients request seemed simple enough - was it possible to make a minor change to the way that the Social Module works - open source and all that I thought - should not be an issue.

BUT ... in short ... the simple change was not possible without a complete recompile of the dnn source - forcing a problematic down the track upgrade wall.  The core elements of the Social modules are not actually stand alone - but are in fact a part of the core dnn library.

So it seems to me that not only the brands - dnn v evoq needs to develop some better separation and equal visibility - but also a long hard look needs to be taken at how the current code for DNN and EVOQ are wound together.

Right now it seems that the internal team working on EVOQ code have strangle hold on control of the code that is buried in the DNN open source platform as well.   Sure there are ways to make feature requests that may or may not ever be implemented - but that is far from an ideal situation.

It seems to me that the DNN developer community needs a better and stronger voice in what happens to the DNN open source core ... if the DNN core code it really an open source community then what is needed is a better way for developer community to contribute ... and to ensure that their ideas and feature requests - do make it into the core.

And also maybe offer a way to prevent elements such as the social feed module from simply being buried inside the core as a second class module - and instead define a core set of guidelines that mean such things don't happen in the future - if its a module - then it should be able to stand alone as such - without a recompile of the core to fix it.

Westa

 Wes, we do see "social" as a part of the core API (dnn platform), in much the same way as we see page(tab) management, user management etc. That said, we still want the social API to be easy to build off, to make your own unique implementations, so where you see something that is too hardcoded/limited, please log it at https://dnntracker.atlassian.net/ , and we can process it as we do the any other platform request e.g. remove inadvertent restriction, add alternative implementations (or other signatures), extend API etc.

I also fully agree that we need the community to take an active part in setting direction/suggesting enhancements, that's why we created http://www.dnnsoftware.com/voice so that users can suggests something and then vote on it - we can use these votes to assess the need and help them decide what we will work on - if you select top ideas you'll see that we've accepted/delivered a number of these, with many others scheduled for 7.2.0 or just beyond. We'll be using this more and more as we go on (as an alternative to submitting an enhancement in jira), so I recommend registering ideas and trying to get support for them.