Slashdot Log In
Should Open Source Content Management Interoperate?
Posted by
michael
on Fri Sep 20, 2002 12:45 PM
from the play-nicely dept.
from the play-nicely dept.
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."
This discussion has been archived.
No new comments can be posted.
Should Open Source Content Management Interoperate?
|
Log In/Create an Account
| Top
| 119 comments
| Search Discussion
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
No (Score:3, Insightful)
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 should be able to talk to one another... (Score:2, Interesting)
Ted Tschopp
PS: Isn't that the whole idea behind Open Standards?
DoD and SCORM (Score:1, Informative)
Of course, in the finest
Drupal Interops (Score:5, Interesting)
Reminds me of RPMs (Score:1)
Couldn't they make a utility that would act like CVS, but if you're using another method, it would simply look at the tree, and repackage in a way that is useful to the utility? I don't currently use CVS, so forgive me if it already does this.
Yes, It's about time. (Score:2, Interesting)
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!
Re:Yes, It's about time. (Score:4, Informative)
That is a fallicy. The truth is that the original version of WinNT contained a third party TCP stack; it turned out the people they bought it from stole it from BSD. The stack was then re-written.
The credit to the regents of the Univ. of Calif. in the Windows readme file is for the simple tcp/ip unix utilities (ftp, telnet, finger, etc) which are bsd code to ensure compatibility and similarity for unix folks when using the commandline on a windows box.
OS X (Score:2)
Like they used to say (Score:1, Interesting)
yes -- WebDAV (Score:2, Informative)
Google cache (Score:1)
What baby steps they work on? (Score:1)
The article basically asks "Should we work on interop for CMS systems?" (and answers yes). But since 100% interop is way out of reach (everyone who developed with different CMS systems will agree), and the only way is really to tackle the problem one baby step at a time, there is a missing question:
What baby steps should the OSCOM Interop project work on first?
The first steps were already taken with WebDAV and XML-RPC. What should be next?
Good idea, but try getting people to go along (Score:5, Insightful)
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.Everything is "content" (Score:4, Interesting)
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.
Content Creation and Managment System (Score:2)
Re:Content Creation and Managment System (Score:4, Insightful)
Interoperation can cripple. (Score:2)
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.
A good first step: exclusive use for files (Score:4, Insightful)
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.
interoperability (Score:1)
I think this is a place where open-source can really edge out the windows competition. It would be relatively easy to work towards a common and transparent interoperability. Let me tell you - if it was possible to do this well I would be using linux at home, the office, the laptop, you name it. And I can bet there would be a million more people who would do the same.
A complaint I often hear in my meanderings is related to this. "Why can't I take this email address from outlook and put it in act?", "Why won't these numbers from the email go into excel", etc. Interoperability within applications would make data management easier. And let's face it, most of what we do is taking data and organizing, sorting, etc.. in one way or another. Make this task easier and faster, and you've just won a major battle.
Using the right tool.... (Score:1)
In the long run this caused me to draw a few conclusions in life. First off, you need to choose a CMS product you like! Second, you can afford. Third, ine that will live till tomorrow and not die off, Fourth, one that is flexible enough to be able to handle tomorrows needs.
For me after trying HTML (combersum and static) I forget the name first CMS tool I used. It was better but failed the secoind, and by now it would've failed the first and third conclusions. I finaly settled on mod_perl! It works well, connects to my databases. Makes for light work on most content. Will never go out of date and I have a hard time believing that it will not handle my needs tomorrow.
That's my opinion for what it's worth (and it's worth a lot to me!).
Can Mozilla Interoperate with Anyone?? (Score:1)
I think the evidence clearly suggests NOT.
For instance, take look at this bug:
http://bugzilla.mozilla.org/show_bug.cgi?id=164
(you'll have to cut and paste it into a new window because bugzilla doesn't allow links from slashdot)
Asa, a highly regarded mozilla member, goes apeshit on a well reasoned suggestion for change. Worse yet, Asa doesn't even provide a good argument against the bug! When mozilla bigshots have this hostile attitude, well meaning people are bound to give mozilla the middle finger and take their skills elsewhere.
What If???? (Score:2, Interesting)
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
Well, hell yes... (Score:1)
And I guess if you're on the 'other side of the fence', you want to check out the WebDAV protocol [webdav.org].
For god's sake, DON'T go try and invent your own! We'll all end up with another KDE/Gnome/.
It is a great big ocean out there (Score:1)
I had been looking for a CMS when I was tasked with building a site for a non-technical company to do news syndication, forums, user management and content delivery. Of course, why re-invent the wheel when someone has done the work for you? That was 10 months ago and I have been working almost exclusively in this field of web development every since. I was able to deploy a modified version of PostNuke for my client in several weeks and they are very happy with it.
While I was searching for the right tool I came across about a million OS CMS systems out there....PostNuke, PHP-Nuke, myPHPNuke, Slashcode, ezCMS, just to name a few.
The only thing at this time that keeps me from going mainstream into this arena is the lack of standards. There seems to be a new release every week for some of these systems and they are seldom backwards compatible (with themes, modules, etc.). How can a company take this kind of fragmented development seriously? If they want to stay current with the latest features they have to redo their entire site. Oh wait a minute thats good for me, or so I thought at first. But the truth of the matter is that if you don't stay up witht the CVS and the release notes and actually continually test the code you could be working with a completely different system.
I personally love PostNuke. I use it on my own site and I have built many sites with it. But there are differnt forks starting every week. Sometimes due to a legitimate need for a specialized version of the system. Most of the time it is due to infighting amongst the developers and petty squabbles and power struggles.
John Cox, the former PostNuke Project manager left the project for some reason akin to this. Check out his reasons here [dinerminor.com]. I won't try to speak for him.
As such if I were a CEO trying to choose a CMS, or any other software for that matter, I would go for the system that has solid goals and a unified vision and sets some standards that are proven throughout the development history, even if I had to choose...yuck...MS crap to do it.
Its not about the cost so much as I want things that worked in this version to work in the next version. I want my development cycle to be shorter and the support better because people know how the system is supposed to work and the new features are just that...new features. Not a new core every few weeks.
OSS Content Syndication could crush M$ / DMCA. (Score:2)
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.
Re:Interoperation would be...hard (Score:1)
is porting / converting a good use of time? (Score:2, Interesting)
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 [blogger.com] 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.
Re:Interoperation would be...hard (Score:4, Interesting)
Re:Interoperation would be...hard (Score:4, Informative)
What happen? We get signal. (Score:2)
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.
What? Read the post again. (Score:2)
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.
stuff of nonsense (Score:5, Insightful)
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 [wap.org]. 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