ConCave, A Simple Content Management System

Having thought it over for a while, I am only more excited about writing a new content management system. My ever-helpful and intelligent commenters have helped me focus the idea, though, and so here I'd like to outline what I'm proposing and ask for feedback. Following this post, if there does appear to be interest in the wider community, I'll create an Open Plans project and announce it on mailing lists that I expect will be interested.

My goal is to keep the core features of the CMS to a minimum. I want to support two classes of user: content creators who want to publish something other than a blog without knowing HTML, and integrators/developers who need some content management as a part of their solution/app. I do not have any particular interest in duplicating plone or creating the ultimate user-generated content CMS. Instead, I'd like a content management system for very small sites, in the tens to hundreds of pages with maybe one to ten contributor/maintainers. By keeping things limited, it gives us an opportunity to, I hope, focus as much energy on usability testing and great documentation as on code. As a note, I realize there are already PHP solutions to this problem, but hopefully by the end of the post some of the differentiating features of ConCave will be apparent.

At its core, ConCave needs to support a page type and a folder type. I do not want tags to be the primary IA; I really think hierarchy can be simple and effective. It does, though, need to maintain metadata about the pages, and I could be argued into seeing a keyword system being useful there. Additionally, some sort of saved search (like Plone's collection) would be useful. I'd like the metadata to provide enough date information that a saved search pages into a very basic blog (not as good at Wordpress, but it's not meant to be). However, I think the saved-search is probably a nice-to-have feature and I am not totally convinced it needs to be there.

The CMS also needs to provide some basic workflows (at least private draft -> published public and back again) and probably a way to extend them. I'm interested, additionally, in supported "gated" content (content that is available only to certain users), but I'm not entirely sure it's necessary. I think search is a must-have as well. Also, as my last post mentioned, I think I'll want commenting, if not in core, at least as an addon.

I am on the fence about files (and images, which are a subset, really) -- if you're hosting the CMS somewhere, there are lots of ways to manage files, and a file type is yet another type to worry about. Then again, files are certainly a type of content that people want to manage (I've met many people who think PDFs are just better web pages), and if the CMS can make managing them dead easy, all the better.

I am interested in how much can be pushed out of the CMS and into middleware or separate WSGI apps. For example, I'd very much like to have authentication (and perhaps authorization) pushed out into WSGI middle-ware. Additionally, I think deliverance has shown that you can get at least some of the site's look-and-feel out of the CMS. The goal here is to make the CMS a small component that you can tie into (or next to) other WSGI apps. I think it may be worthwhile to see how much can be pulled out.

Finally, I've been thinking a lot about how to keep the project simple and make it appealing, and one strange, difficult, and extremely appealing feature comes to mind: a supported migration path, for the core at least, to Plone. I really, really like Plone, and I think it's a wonderful content management system that does a great job for medium to large sites that need its features. I think it's too complex and resource intensive, currently, to use on small projects, though: small nonprofits, small businesses, individuals who want something other than a blog. So, I'd like a python CMS to use on those projects that fits together nicely with other WSGI application. But, if all goes well, some of those users will necessarily outgrow the meager offerings of ConCave, and I'd like them to know that ConCave will serve them while they are small and then Plone will be waiting when they need it.

Comments are gloriously open.