Osmek
osmek.com
osmek.com
They are a SaaS "Create Once, Publish Everywhere" (COPE) provider. NPR popularized the term a few years back, and the use it in their production environment. I have one client actively using the same architecture in production, and they love it. They use a Django site as the backend, and node.js-powered websites to publish the content.
Some links on the topic:
http://blog.programmableweb.com/2009/10/13/cope-create-once-...
http://www.linkedin.com/groups/Do-you-COPE-Create-Once-39120...
http://www.slideshare.net/KMcGrane/adapting-ourselves-to-ada...
http://karenmcgrane.com/2012/09/04/adapting-ourselves-to-ada...
http://www.markboulton.co.uk/journal/adaptive_content_manage...
http://meetcontent.com/blog/structured-content-an-overview/
One of the uphill battles they face is the nomenclature. Most people couple their content creation tools with the publishing tools. I.e., we think of a CMS as both the editor and the content renderer. This sort of system decouples that.
I think they are smart starting with a PHP library: that seems to target a broad install base, and publishing in PHP using an API is much easier than building a solid CMS in PHP.
My understanding so far is: rather than using a CMS, I code something (not a CMS?) in whatever language I like and Osmek helps me or makes it better in some way... ?
Then the content can be published to multiple sources such as an iOS app, website, tablet app, mobile website.
I just don't understand how this is different from having your own database with the content. What's the difference between this and say Django's auto generated admin interface (setup with proper permissions) ?
Why can't my apps just pull stuff out of the database or through my own API ?
I'm sure I'm missing something because this seems expensive so it must be worth a lot to somebody. But why ?
The big unaddressed question is that most of the targets people care about aren't publish-only. Managing changes/submissions from many publishing targets [1] is one of those deceptively non-trivial tasks. [2]
[1] each with their own inconsistencies, permissions issues, etc.
[2] Not unlike dropbox's client software. It sounds easy. But try writing it.
In my opinion, the interface is a little confusing. It took me a long time to figure out how to create custom fields, and I was looking for it! From my experience with CMS, it's by far the most important feature. It should be very easy, especially for content editors to create by themselves...
Other than that, it can be very useful. I'll remember it for a time I'll need it...
Yes, there are content management systems that you can install in your own server and manage it. But this system removes that hassle from you.
I, for example only have one name.
Thanks :)
It's basically a 'content store' that provides a supposedly nice interface for people to create all sorts of content and then it exposes that content back to you via an API that you can use in other places such as a CMS.
Good idea in theory, hard to execute because there is no common interface/standard.
If there was a common interface/standard you could use/build services like this to essentially decouple your content/data from the skin on top.
For example you could just pull the plug on CMS X, and 'connect' your content to CMS Y if it has a better user experience.
Easier said than done.
So, essentially, it's a database with a shiny frontend?
I've really like http://www.silkapp.com/ for this sort of thing. I think their API (http://developer.silkapp.com/) is great, and they have neat tools for editing structured data
The idea is that the content is not locked to your CMS, like an old Joomla system where the content and meta-data are hard-coded in the schema. I would be concerned about latency, etc for hosting something like this.
There service holds and organizeds the DB storage for you. The advantage would have to come with redundnacy/latency versus rolling your own datastore. If you are doing a NoSQL or JSON type storage that allows an arbitrary format, then you are free to reuse it wherever.