Gadgetopia makes an argument for building your own CMS:
"See — the problem with a full scale Content Management System is that it has too many opinions. Those opinions were though of by somebody other than you and the needs of your organization. The more developed a content management system (or any piece of software, really) the more “opinions” it has. And the more “opinions” it has, the more likely one of them is going to really tick you off."
I can relate to this. We work with one system in particular that makes an astonishing array of presumptions about how you’re going to use it, and if you try to step outside those presumptions, demons fly out of the abyss and try to suck your eyeballs out.
This goes back to a previous discussion we had about Content Management as an API. In that post, we had a great experience with hand-rolling a CMS...
The term they are looking for is Content Repository, a service that provides common APIs for content storage, retrieval, signaling and so forth. With Midgard we're following this approach, providing content retrieval and web functionality APIs first, and then building some reusable user interfaces on top of that.
In addition to Midgard some content repositories to look at include Apache CouchDB and Jackrabbit. All of them allow you to stop worrying about storage and retrieval methods and focus on the actual end user functionalities, while keeping the whole system accessible and scriptable for integration purposes.
Technorati Tags: couchdb, jcr, midgard
