Slashdot Mirror
Should Open Source Content Management Interoperate?
bergie writes "Advogato is running a thought-provoking article on whether open source content management systems should interoperate. This is a big question involving social issues inside the projects, but also promising huge benefits to developers deploying open source CMSs and to desktop projects like Mozilla, OpenOffice and Xopus wishing to connect with a collaborative backend. This discussion will also be a major topic on the upcoming OSCOM conference."
I don't think they should have too, but think about this: The reason people use MS Exchange, is because it interoperates with MS Office, SQL Server and MS Windows seemlessly (I know I know, so they say).
If Open Source wants to continue to be seen as valid, then I think they should move in that direction. Don't force anyone, and don't prevent anyone from taking a different direction. Who knows, the Exchange Killer might start out as a simple stand alone app that Just Does The Job- and then someone adds on the components to make it play with everyone else.
They stuck me in an institution, said it was the only solution, to...protect me from the enemy, myself
But I don't know about how much extra work that would require. There are already several different standards on content syndication. Make sure that all open source CMS tools use these open standards and that would be a amazing step in the right direction.
Ted Tschopp
PS: Isn't that the whole idea behind Open Standards?
Fantasy remains a human right; we make in our measure and in our derivative mode... -- JRR Tolkien
Quoth the poster:
:)
i think "do it yourself" very often misses the point. not everyone has the skills or time to port every software / convert data from one format to another.
im a developer myself, and i only have time / resources to work on a few projects. when i spend my spare time i want to make sure its maximally useful. i personally consider converting data / code between platforms / applications not the best or most satisfying use of my time
re: levels of interop, i believe 20% (to pick a number) is worth it. another consideration for the adoption of standards is how much effort it takes to implement them, and what implementing a standard gives you. a example: i implemented the blogger api for postnuke. it was very simple to do. it took me about one evening, with no prior experience with XML-RPC. the payoff is that i can now use various nifty tools to blog from the desktop, or from a PDA / mobile. Standards should have these characteristics in my opinion.
Drupal is an open source content management app run by sites such as DebianPlanet. A couple of examples: if you have a Jabber account, Drupal can authenticate through XML-RPC and through a Jabber server. Also, Drupal allows for utilization of the Blogger API for the posting of content.
Ok,
Let's take DCOM, PHP, ASP, XML, SQL, ActiveX, DirectX, Flash, LISP, Perl give them a whirl add a chicken for lustre some hot-peppers for muster and then dethrone eXchange, explain to people that theier only choice is Linux and make the punishment for useing windows the loss of your hands.
Realistcily people like Outlook, they like exchange and they do not like change the public containts too many windows peons for that kind of change to happen.
Oddly enough exchange is a stripped down version of X.400 with X.500 extensions thrown in for good measure (Look ma no UNIX!). Microsoft has always taken current technology, re-branded it given it a nice gui (if you like puke grey!) and re-sold it to the would be managers/ceo's/cio's and marketing people. Another perfect example of the drop re-tool and replace (BSD's 4.2 TCP stack is in both windows 2000 and WinXP). Please correct me if I am wrong.
Group Ware from a coroporate stand point should always cost money, most of the managers I know maintain the belief that a tool is as good as it's price. Or more concisely "you pay for what you get", and then you pay for what you didn't get too. Realistcly people like windows it keeps them in the comfortable world of I neither know nor care obout my antiquated kernel with crappy drivers and an HAL that reeks of 5 years ago.
P.S. HAL (Hardware Abstraction Layer).
Then again I should be one to talk, I am a OS zelot and I hope to help with this ever so monumental task of replaceing all of DCOM. But what of security? Will it be Kmail? Or Pine? Which one will get the ever so useful access to theis new form of OPENDCOM? And how long before the same problems hit all those nice mandrake/Suse/redhat installations?
I hope it works, and I hope people learn to trust open soucre, but I have been let down by OS my self a few times.
Three Letters "XML" that exists so why not just make everything comply!
Peace can only come as a natural consequence of universal enlightenment ~Tesla
Why can't WebDAV be the standard? From what I have seen WebDAV has a lot of the needed functionaility for a CMS. Jakarta Slide (Open Source Java CMS) is implementing WebDAV as their foundation.
One of the reasons that OSX is so cool (at least for me) is because all of the applications are loosely integrated together. Homogeneity is a good thing. It makes things easier to use and more efficient.
"That's great Lewis. Short, but pointless."
What you ned to thing about is all of the applikashuns that aren't beng developed bekause standarts aren't being met, or rather, you need to think about all of the applications that aren't being developed because there are no standards. In addition, you should consider the magnitude of the request. Its not really that big; most (similar) CMS systems could interoperate with only a new serialization frontend (i.e. a different export format).
I'm all for an incredibly loose standard, myself. One that is almost as flexible as a database management system (but with an addition of some form of identification-verification-ssl library).
Of course, if Apache does it, and it works...I don't see why people will want to use Exchange.
Mod me down and I will become more powerful than you can possibly imagine!
Yes, WebDAV is a protocol commonly-used by many content management systems (commercial and open-src)...See http://www.webdav.org
Why can't WebDAV [webdav.org] be the standard?
Because many people don't want a web-based solution?
Dacels Jewelers can't be trusted.
Sorry, this was another article at the same place with a similar title. Read down into the article a ways and realized me error. Apologies to all who bothered to click thru.
TH epost isn't about source code control, it is about content manamgement systems. You are comparing CVS type software to slashcode and phpnuke. They are totally different pieces of software for totally different purposes.
It is a great concept.. have a common API for posting / retrieving content, for posting comments, etc. But getting people to impliment it would be like pulling teeth. Everyone would think that the way they are currently doing it is the best way. This is one downfall of Open Source, the "ego factor".
The "ego factor" is the same reason we have 5 different office products all working on seperate import / export filters for MS Office, when the effort should be combined.Excuse me -- you don't want a web-based solution to content publishing?
-Billy
i looked at SCORM. in my opinion its a bloated mess that stands little chance of being adopted on a broad scale. typical three-letter agency standard :)
-gregor
I cannot comment on the specific articles because even Google cache is slashdotted right now.
Anyhow, the idea that web content, file management, and databases are all different things should perhaps be challenged.
Hierarchical file systems are too rigid IMO, databases charge fat bucks for document management, and web content managers assume that the web world is an island away from other company activities.
I suggest ways be found to combine all these. XML is not the answer because it is linear: you can't "index" by an aspect or relationship not covered in an XML file layout/hierarchy. (If you could, then it would be a database and not an XML file, per se, and nobody has shown that an XML database is better than a document management database or a relational database or whatever. Besides, XML is an exchange format, not really a good storage format.)
Basically, everthing can be reduced to 2 things: "documents" and "attributes". Relational databases do a pretty good job at attribute management [1], but not document management, at least not without addons.
Thus, we need to find a standard protocol for referencing and querying a "big pool of data" based on documents and attributes. Then "content databases" can be built.
[1] There is kind of a mini battle between "defined attributes" and "open-ended" attributes. RDBMS tend to want to know field names in advanced. But it does not have to be that way. But, there are pro's and con's to each approach, defined attributes usually result in better performance, but make it harder to add new fields not anticipated in advanced.
Table-ized A.I.
I've been looking for something that will allow me to create content in one format and then have it available in several formats. Here's what I mean. As an author take a template and fill in the bits of information to create an html page. Then have that data propagated to a similar template for a pdf, word doc, etc. Ideally all of this content would then be managed under a CMS. Is there any such beast out there?
In Republican America phones tap you.
I massively disagree. This article is the stuff of frustration. And I agree with them. As an old corporate guy I've been watching the various open source content management systems for years and to me they *all* look like muck.
Specifically, they look like the work of a bunch of programmers who have never for a moment on their lives run or even worked in an actual content creation environment. They program in the features that are "cool" to implement instead of what an actual publisher could use.
So they're finally talking about how poorly an aspect of this whole movement functions in the real "I need to make a living with this" world and surprise, surprise, it sucks so bad that the room is filled with (heh, heh) jabber, in which they can't even agree on what they're arguing about or what goal they're seeking.
This all looks promising to me but frankly I wrote this whole category off years ago. As far as I'm concerned the dedicated content management systems that are available or well on the way now are VisiCalc in a world where most of us need Excel. I. e., this is all very nice but I'll wait until they've putzed around for a few more years, have worked out the most egregious mistakes, and start over from scratch.
BTW, if any of you ever want to check out a *real* content management system, you know, one that complex pubs (like the New York Times, Time Magazine, JCrew, etc.) actually *use*, then study the feature list, UI, etc. of QPS. Now almost a decade old and in the hands of a succession of commerce-impaired clueless corporations, it's still more usable, easier to administer, and more powerful than anything I've seen. Now if only *that* would get open sourced (a la PostGres) we'ld be getting somewhere.
Until then I'm placing my bets on well-customized SQL-compliant systems based on rigorous adherence to rich XML schemas.
Happy days,
Rustin
Data is the lever, rigor the fulcrum, brains the force that drives it all.
WebDAV really has nothing to do with the "Web" except that it uses the HTTP protocol. I would not consider that a "web-based" solution. In other words... WebDAV has nothing to do with a browser and everything to do with HTTP.
Excuse me -- you don't want a web-based solution to content publishing?
Actually, no. There are many reasons for this. If it has a web-interface, that's fine. The structure should not be dependant on a webserver (Apache) though. Writing communication protocols isn't that hard, and they are seperate entities. Publishing to a website is easy, and can be done with minor output filtering and scripts from a CMS system.
Also, this is talking about content management, not content publishing. Similar in some regards, but very different.
Dacels Jewelers can't be trusted.
I'd mod this up if I had points today. Excellent point, which I've made on a local LUG list, and got hugely flamed for. Somehow the notion that people who develop open source projects are human and have egos is a taboo subject, but it's about the only rational explanation for the problem you described. It's certainly not 'money', because developers who release stuff as open source aren't usually in it for the money in the first place (else they'd charge for their projects).
creation science book
WebDAV has nothing to do with a browser and everything to do with HTTP.
It uses extensions based upon the http protocol, but WebDAV stands for Web-based Distributed Authoring and Versioning. Hence, it's Web-based. There are many clients, but why use HTTP for something it wasn't really designed for? Protocols are not some myseterious thing that should be piggy-backed upon. If you are going to spend the time writing RFCs why not come up with an actual CMS protocol.
Dacels Jewelers can't be trusted.
It's important to ask yourself first, What does this piece of software do? Then, how far down the list of features that are important for it achieving that goal will you find Does it work with competing CMS's? Probably at the bottom, just below Can I use it as a text editor? :-)
As long as the CMS is stable and their formats are open, anyone can come along and write a bridge that lets them work together in a minimal sense. Asking for total interoperability is looking for total convergence of features, which is the long way of asking for only one system with slightly different interfaces.
My opinion, which only matters to me, is that each different system grew up because of a shortcoming of another, as applied to a particular situation. Making them interoperate may be impossible without losing those advantages.
Any connection between your reality and mine is purely coincidental.
By comparison, all current Windows OSs have exclusive use for files, and it's widely used. So programs tend not to stomp on each other's files. This helps interoperability. Programs need only be compatible at the file level; they don't have to actively cooperate to maintain file integrity.
I'd like to see "always-on" exclusive use for Linux. If you ask for an open with exclusive use, you should be able to expect it to be available.
ok what do people mean here ?
being able to manage assets ?
(like jpegs and 3d models i.e. not text based)
first of all you need a file format (even if your going to store it in a DB or a RCS )
then you need a way to send and recive those things
solution 1 openoffice file format
solution 2 HTTP
you can browse via a browser or simply treat it as a file system (web dav does have versioning)
the problem that people have is mixing content with a publishing system and these after all are 2 differant things a publishing system will be able to manipulate the content to a certain format e.g. HTML for publishing on the web or WAP for publishing to mobile phones and should be able to deal with the data manipulation
regards
John Jones
When most people say web-based they mean browser based. I assumed that is what you meant. If you actually meant http-based, then I will have to disagree with your comment of "Because many people don't want a web-based solution?" entirely. As portrayed by web services, people don't care what protocol is used. (Unless they are network admins) People care that something works. Web Services work for distributing objects and WebDAV works for CMS. It may not be the best thing, but it is here today.
Come on it's Friday! No need to get all up-tight.
The only thing I am disagreeing with is that "many people don't want a web-based solution". I really don't think CTO of company XYZ cares what protocol is used for his CMS, just as long as it can work today. I agree that there should be a better solution, since I don't like the idea of staking tons of services on HTTP either. There should be a CMS protocol. But there isn't, so for now let's use what we can.
Between LDAP+mod_dav, WebDAV clients like the one built into MacOSX, and Subversion's use of DAV for diff'ing files and viewing repositories, it appears that not only is it a Good Idea, but a Good Idea With Actual Industry Support (ala LDAP).
Remember that what's inside of you doesn't matter because nobody can see it.
I don't think there has to be a problem with a common API for this anymore than there is for databases. Define an Adapter (driver) API and let other people code plug-ins/adapters to your system. Once there is critical mass and the corresponding demand, you'll probably want to provide an adapter yourself, or perhaps one of the external project grows up to the point of being trusted and stable.
Or are the differences in CMS implementation so radical that a driver system for communication cannot be devised?
Freedom is the freedom to say 2+2=4, everything else follows...
You mean like the way http is piggy backed on top of TCP which is piggy backed on top of IP which is piggy backed on top of ethernet?
No. Stop trying to come up with "clever" exceptions. TCP doesn't actually encapsulate structured data, whereas HTTP does. TCP is an abstract data communication protocol.
Do you have any actual critiques of webdav other than not liking that its protocol is based on top on http?
I'm not saying that I dislike WebDAV at all. I wish people would understand all I'm saying is I don't think it's a good idea to come up with a uniform CMS based off HTTP. Something of that caliber should use it's own protocol.
Dacels Jewelers can't be trusted.
Come on it's Friday! No need to get all up-tight.
:)
I'm naturally uptight, and I'll be working till probably the sun comes up tomorrow. Sleep for a bit, and do it again. So tell me again, why is Friday important?
I really don't think CTO of company XYZ cares what protocol is used for his CMS, just as long as it can work today. I agree that there should be a better solution, since I don't like the idea of staking tons of services on HTTP either. There should be a CMS protocol. But there isn't, so for now let's use what we can.
True, I'm speaking purely in regards to this being the "collaborative, interoperating, standard CMS" system. It's good, but not that good.
Dacels Jewelers can't be trusted.
True, I'm speaking purely in regards to this being the "collaborative, interoperating, standard CMS" system. It's good, but not that good.
:)
I agree 100%!
What if a large corporation sponsored it? Whould that change people perception? light a fire under some people? Also give some perspective to what is needed in a true enterprise content management system?
What is multiple large companies, possibly including one or two current commercial content mgt systems were involved? Would this be the golden egg that gets people to interop?
I think this is desperately needed and I bet if approached properly you may get buy in from some companies who are looking to jump on the Open source bandwagon.
larz
amen bro.
disclaimer im a former postnuke core dev who now works with john cox on the next generation postnuke (along with the rest of the core devs that left in corpore from postnuke)
This is a *very* interesting thought.
With digital content close to outpacing any other it would be very cool to speed up with a GPLd content syndication standard thats OSS from A to Z and is verticile enough to span everything from JBoss/Cocoon to the 1001 'Nuke forks. Something like that could prevent M$ / AOL & Co. from gaining momentum on the ever growing digital content services market and keep them from closing that market via the DMCA.
This is something really worth considering.
We suffer more in our imagination than in reality. - Seneca
Because like it or not, Vignette, Cumulus, Mediasphere, and QPS and so forth, whatever they may cost to buy, will all continue to be cheaper in the commercial world if the open source alternatives require coding to do jobs that commercial products better enable with the click of a button.
Hmm, I like what you said, but here I'm sceptical. Anyone I've talked to who did research into commercial CMS - as deep as taking courses held by the company selling the CMS - was complaining about the fact that these systems, while doing some stuff out of the box with a click of a button, always require quite a bit of customization (i.e. programming) to solve the problems the clients really have.
But you're right that commercial products are better in giving the impression of solving all problems out-of-the-box.
Aye, I'll second that. Open source projects don't generally have a PR budget, or flaks spinning ad copy designed to decieve you into buying their dog food, and they come out the worse for it. But they do nonetheless manage to compete with the big boys, when their feature sets and operational qualities become sufficiently compelling.
It's really a tribute to the ability of admittedly corrupt humanity to do something constructive without a clear greed motivation. Now if the
scale of effort applied to developing Linux,
Apache, Plone, GCC, etc., could only be harnessed
to do something *really* useful, like find loving
homes for the 50,000 AIDS orphans in Henan...
-I like my women like I like my tea: green-
Most browsers support HTTP, and being able to edit content with a browser is a high pritority in my book. Also, there are existing HTTP implementations out there for many diffrent languages.
The same could be said with databases, and I've yet to see an SQL server with a direct HTTP port. HTTP is good for what it does, but it is not meant for anything like content management.
If you ever do any hardcore CGI development you will see why.
Dacels Jewelers can't be trusted.
If that's true, Mozilla seems to be the only team that uses Bugzilla but doesn't coordinate work on suggestions with it, and they probably ought to remove the "enhancement" bug severity as inappropriate.