However there are a few flies in the ointment, that always draw me back.
Single Sign On....
All of these packages usually ship with their own embedded user and profile management system, trying to "integrate" multiple systems together can be a nightmare. You either end up with complex and fragile "bridges" that usually involve maintaining account mapping tables, and copying user data backwards and forwards between disparate systems. Or your end up having to hack a core feature out of the system and replace it with your own interface to the user authentication and authorization system that is shared across the whole site.
What we need is a mechanism for abstracting users and profiles that can be plugged in across multiple systems. Ok, so some will say, well thats what directory solutions like LDAP etc are for, but they only solve part of the solution, putting all the data in one place, they dont help with maintaining a consistent session maintenance across disparate products.
A component SSO solution should handle all activities related to user data, signin, signup, signout, password reminder, alerting (email, im, sms), user to user communications, profile/bio maintenance and visibility controls. And preferably cope with international requirements such as regionally variable data protection rules, multisite replication etc.
One possible solution I have been examining is a new social networking core called Ringside (http://www.ringsidenetworks.com) which handles all of the above, and adds many other components such as groups, contact lists, friends networks etc too. It even supports running of facebook apps inside the core, and has a road map that will encompass OpenID and OpenSocial. It would make an ideal core platform for attaching other applications to as modular components. Its nicely architected, having separated front-end and back-end processes.
If a suitable API or standard can be evolved that gives open source package writers the option to avoid all that user management code and just plug in to a common set of apis, some very very cools setups can be evolved.
Front-ends and Templating
Almost every system i have examined uses almost completely different mechanisms for handling presentation, some use templates, some use CSS, some are table ridden nightmares, but they are all wildly different, and most are single tier applications where the back-end logic and the front-end page generation are tightly integrated together. In this day and age there is no excuse for this, if you are an author planning an open source product (or any web based product) consider true separation between your front-end and back-end systems, use a Restful interface to bind the two together, and we systems integrators will love you for it, we can chose to take your back-end engine and integrate it directly into any front-end we are using to wrap the web service.
If the Open Source movement could embrace the two principles above, you would see a lot more adoption in business and enterprises.
Almost every system i have examined uses almost completely different mechanisms for handling presentation, some use templates, some use CSS, some are table ridden nightmares, but they are all wildly different, and most are single tier applications where the back-end logic and the front-end page generation are tightly integrated together. In this day and age there is no excuse for this, if you are an author planning an open source product (or any web based product) consider true separation between your front-end and back-end systems, use a Restful interface to bind the two together, and we systems integrators will love you for it, we can chose to take your back-end engine and integrate it directly into any front-end we are using to wrap the web service.
If the Open Source movement could embrace the two principles above, you would see a lot more adoption in business and enterprises.