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."
Its possible, I think, to agree on a workable standard, but it would be a LOT of hard work!
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
The DoD (Dept. of Defense) wants various CRMs for teaching courses online (WebCT, Blackboard, etc.) to be SCORM compliant to allow transition of teaching/content modules.
/. tradition, I have not read the article.
Of course, in the finest
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.
If any two CMSs are similiar enough to interoperate, why do they both exist in the first place? I think most of them shouldn't exist in the first place let alone interoperate with the others.
That's life in the bazaar. Didn't you say you liked the bazaar?
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.
i was being inprecise. im ready to support interop in the programs i write / contribute to (a small subset of open source programs). im not ready to go all the way for programs which i merely use (most open source programs). i was wondering how other devs make this call for their own software. is it a non-issue? what is the sweet spot for them?
Correct me if I'm wrong (which I very well may be), but this sounds like the situation with RPMs. RPMs were designed by RedHat to "easily" install programs, check dependencies, etc. Now, even though other distros have their own distribution methods (Debian's apt-get, Slackware's SlackPaks), don't they all support RPMs to a varying degree? There's even conversion utilities to convert RPMs to whatever format is used by your distro. Seems like this is the industry standard, as it were, simply because most people use RedHat, and therefore RPMs. So, while they can utilize whatever they choose for whatever reasons they choose, there is always an RPM to use.
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.
They created a spec (forgot the exact name), and 5 years later, the only tool that works well with the spec is the Interdev/SSafe combo... kind like, the only DBs that work well with ODBC are MSSQL Server and Access. they would do the same thing to an open spec.
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
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.
Their is no problems that a level of indirection can't solve.
I'd rather be sailing...
"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
Cached copy from my google search
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.
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?
I code, therefore I am.
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.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.
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
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
content-management software for any platform is abysmal right now. I think it would be exceedingly difficult for any windows-based software to pull this off.. the effort would get lost in a maze of IP,proprietary standards, and lawsuits.
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.
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...
if it needs to it will end up doing so. it is open.
I have a hard time with CMS tools. I guess the last time I tried using one, I got tied to it and couldn't leave without rewriting all of my content. I couldn't update because it was proprietary and at the time could not afford the update.
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!).
-- Many men would appreciate a woman's mind more if they could fondle it
I'm not familiar with OpenOffice development, but a big question in my mind is if Mozilla can interoperate with anyone.
4 40
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.
Although the article and this comment make some good points, I still have trouble even putting any of this in context. We all know that interoperability and good open standards are a good thing, and that one of the real challenges of the Free/Open Source movement is how to get some level of long-term, whole-system coherency into the design process. Some people seem to be frustrated that this cannot be established top down and imposed on the developer communities from the outside.
I don't even see anyone saying what is and is not a CMS for this discussion, except indirectly. Certainly, slashcode is one, and CmdrTaco and friends have their everything2 site (I've just recently checked it out and still haven't decided if it is very cool, or another time sink that could soak up hours and hours (probably both)). These two systems have radically different purposes and structures, even if they share a lot in terms of technology platforms and such.
So the questions becomes, how do you want them to interoperate? Make linking easy? Support headline applets (slashapp)? Share data infrastructures? Export and import content? And the list goes on. The easy ones that are important to someone are already happening/done. What exactly is the proposal? I can't tell from the article.
To the extent that it is possible, if the developers of indepentdent CMS projects create linkages and exploit synergies by looking at other projects and cherry picking the best parts, we all win. Those of us with unrelated projects to manage would benefit the most, particularly to the extent that this work: 1) reduces mindspace burdens in using CMS, 2) makes it easier to convert to another one of similar purpose and 3) helps us create linkages and establish synergies with other projects.
My point here is that one of the most important uses of CMS (at least for me ;-) is to implement collaboration web sites to support projects, and it sure would be a big help if moving between projects didn't mean learning a whole new set of tools to access the shared content that different projects generate. Also, it is not news to most slashdotters that projects share hosting resources often provided by third parties. As projects evolve and relationships change, your project might be forced to migrate because of changing partners and sponsors, and that might include the CMS system.
For the project that I am working on setting up these resources for (GNUbook, there is a URL, but I don't think it would stand up to slashdot yet. If someone wanted to mirror however ...), I am looking for existing CMS projects that meet my needs. I probably can use/adapt slashcode to our needs, the voting and rating aspects of it are great for allowing the community to self-regulate to a large extent. On the other hand, I really like something more like TWiki because it allows for editing content and storing revision histories is an integral part of it.
Bottom line is that if we are going to have more interop/integration between the various projects, somebody has to take it on and make it their mission. Not everyone has to scratch their itch by developing a new project, and a lot can be done by just stating your case and promoting it to the people who matter (the developers, of course). I also suggest that the developers of CMS systems should work harder at finding the best in what is out there and integrating it with their vision (only where appropriate, of course). That's what this experiment is all about after all, sharing everything, picking the best parts and propagating the best to all the situations that apply. Re-inventing the wheel is for the other guys.
I've wandered about the site a bit (I'll go back later) and immediately I'm seeing some mighty familiar stuff. As in signs of just the sort of approach that I was complaining about above.
No FAQ, just a bunch of min-FAQs on subsets of subsets of functions. I'm not too interested in any project that doesn't consider it worth their time to explain what they're doing. I have a reasonable right to expect one document that says and explains:
this is what our product does (jargon lists don't count, actual sentences written in normal english required)
this is how it does it
these are the operating system/hardware requirements (cost estimates help a lot)
this is the estimated time to get up and running, i.e. what sorts of training/familiarity are needed to administer, use, set up this system
these our intended target market segments, both current and long-term
these are similar systems and a sentence or two on how we differ from them
here is a basic list of functions/features
Next, as I've gone through the FAQs, such as they are, I'm seeing lines and lines of coding required to address basic issues. Take a look at the UI of the system I linked to in the parent post to see this sort of thing done right. If I have to write half a page of code just to define a user set them I'm so gone.
Screenshots of the thing in action? Couldn't find any. Examples of people using it and how? Nope, didn't see that either.
Well, lessee, rights management? They say they have some. Guess that I'm supposed to guess about what. File types? No se. Routing approach? Haven't a clue. Admin functions? Nope. Archiving? Nope again.
Hmmmm... other then that? Other than the many other things I'm seeing like badly documented links that could be downloads, pages, or functions, click here and guess? Looks to me like I'm expected to download the app (while hoping that my setup will support it), find a way to get it running (who *knows* how long that will take. Hours? Days? Can't say) train myself in how to use it, get it running with some of my datasets, and then decide if it's useful or not.
I'm sorry, I *have* a life. I didn't put up with this when I was paid a salary to be a full-time sysadmin. I'm certainly not putting up with it now that I run my own business.
And if you think that "Oh, we're not at version one yet; we don't have time for that sort of thing", well, tiny little companies like LemkeSoft have been managing it just fine, pre-release, for over twenty years. Back when I bought my software on five and quarter inch disks for an Osborne there were already plenty of little one-person software companies that had far more respect for the people who actually *use* their software then ANY of the open source CRM projects feel they should have to condescend to accomplish.
What do I think? Thank you for a perfect example of exactly the sort of programmer-driven amateur hour I was talking about.
Rustin
Data is the lever, rigor the fulcrum, brains the force that drives it all.
No, we shouldn't waste time making all of the patheticly underpowered Free/Open CM systems interopperate. RCS, SCCS and CVS all suck for parallel development, varriant product development, and large software products.
They should be tossed aside for a GNU license workalike based on the best features of Clearcase.
And to piss off those greedy bastards at Rational, we could call it Gnutcase (pronounced nutcase) and call the development team Irrational Software.
I'm not to familiar with the plone site or plone itself, but it's probably statement that plone is built *on top* of Zope and CMF, so you will need to refer to those two (and have a basic knowledge of them) to understand things like permissions, usermanagement, workflow and objecttypes in plone.
Actually I *had* already figured most of that stuff out. My point wasn't an ignorance of specs on my part; it was that any place that made it such a pain in the ass to figure out easy stuff like platform can't be trusted to handle the tough stuff.
CRM/content admin shouldn't require a dedicated programmer. Especially for any project clamoring for people to use their software instead of commercial offerings. 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.
On top of that, in my experience open source tools even have inferior reporting functions, making them harder to use that the geekiest thing that actually *is* an appropriate part of an asset manager's job. Give me a choice between a tool that has real built in diagnostics and something where the "support" guy just tells you to put the log file in excel and build something from there and guess what I'll choose?
Face it folks, most of us don't get up in the morning looking for excuses to write new software. We use software to do SOMETHING ELSE and have no more desire to spend our time programming then the average driver wants a car that needs you to machine new parts before it will start in the morning.
Some days the open source community reminds me of the character in Ripping Yarns who thinks it's fun when somebody drags her way in, freezing and damn-near crippled, from being stranded in winter rain out on the moors (almost dying) because it's a chance to test his new wheel alignment.
At the end of the day, believe it or not, this stuff is supposed to exist to be useful tools, not chances for endless fiddling while the poor sap depending on it to work goes bankrupt/loses their project/has their work deleted by mistake.
Data is the lever, rigor the fulcrum, brains the force that drives it all.
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
And I guess if you're on the 'other side of the fence', you want to check out the WebDAV protocol.
For god's sake, DON'T go try and invent your own! We'll all end up with another KDE/Gnome/.
So does Anonymous Coward have good karma?
One place I worked at had a GOOD acronym: GOYA. Get Off Your Ass. In other words, if you feel strongly about it, then do something! This is what I like about open source (and no, I am not sucking up here). But don't just spit venom. Try providing the anti-venom too.
So does Anonymous Coward have good karma?
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. 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.
"Laugh, and the whole world laughs with you. Cry, and they still think its funny." - Mr. Boffo
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.
Chances are that what they're calling "programming" (yeah, right!) is building the config file, which is admittedly a bitch. Personally, I always did that by wandering off to the park with the fifty or sixty pages of printout and editing it there. In other words, doing/majorly revising a config does require raw text, but in a good system it should be more like creating the accounting section of a large annual report than like, say, writing in C.
So if they're so easy (comparatively) to run, why do people get away with charging thousands of dollars? It's two things. To some extent they're just charging what the market will bear and to some extent it's simply that if a corporation plans to put somebody in charge of their crown jewels (and make no mistake, that's what content admin is) then they're perfectly content(heh), and appropriately so, to spend the extra two or three days of training to go over things the one last time that might prevent a mishap.
Personally, I once had a problem with the backup/archive application in a CMS and accidently (screen redraw problem, combined with faulty error message) put in the command to erase and zero out most of three issues of a major national magazine. Layouts, stories, photos, ad tracking logs. The works. Oops! Too bad. You didn't *really* want a Christmas issue, did you? I'm sure that General Motors won't mind letting you keep the fifty thousand dollars they paid for their ad.
The only thing that saved my butt was an absolutely obsessive awareness of how the system worked, right down to things like bugs in screen redraw, as a result of which I had built in a workaround just in case this very thing happened. I was able to cancel the command before it could fully execute (it was still running through its preparatory pre-erase automatic functions) and the editorial staff never even knew. Was this worth the extra couple thousand dollars it cost a multi-billion dollar company to get me trained to that level of knowledge? Yah, I'ld say so.
This brings up another problem. Let's say you want to offer training in a major CMS, let's say Vignette. It's the same problem airlines have when looking for experienced pilots. The gear costs a ton, there are fewer active seats to work the app in the entire world then there are PCs in one medium sized town, you can only really learn how it works with months of time managing the work of at least thirty or forty creatives/editors, and so forth.
The bottom line: how many qualified people are on the entire planet who aren't tied up in full time gigs? I know that just including my primary system (QPS) and my primary industry (large print pubs) drops me into a group of fewer than two thousand qualified admins WORLDWIDE. Reduce that down to those who are good teachers *and* aren't busy and it's slim pickins. Add to that the fact that there aren't enough customers to justify even two classes per city a month and of course it's expensive and difficult to get trainers.
Of course this is an important argument for scalable systems, where the skills learned in a three person shop apply to a seven hundred person shop. Yet another reason I'm sitting this out.
So, back to the original topic. In my experience a good CMS should be no harder to work with than a large, say, cc:mail installation. Like Go, you'll be quite busy enough working the implications of all that stuff moving around and all those users/statuses/groups to manage as it is.
Which takes us to yet another proof to me that the open source CMSes are still clueless. Look at any big production environment and you'll see at least ten different statuses that a document may be in. You've got (at least):
needs to be done but not yet assigned (as in "we'll need a turkey logo for the Thanksgiving page, see if you can give it some Flash functions")
assigned but not yet started ("Okay, Paolo, this is yours, here are the notes and template")
rough
first edit
second edit (some places have as many as six edit stages but we'll leave it at two)
ready for proof (known in my world as "blues" because they used to be run to press on special blue paper/ink)
final (no more changes allowed but not yet run)
live
archive
hold ("pull that story from this issue, we don't have the space/the interview fell through; we'll run it in another issue")
next/later specified edit cycle (the end of the year overview that's already in the works even though it's only March)
not for publication (trust me, if you don't create it, the edit staff will find a way to fake it. This is where you keep random stuff like mockups, joke documents, etc.)
Trash (yes, this is a status because a.)like the Windoze/Mac trash can sometimes you want to be able to change your mind and b.) some user classes who can be trusted to change a document status can't be trusted to permanently delete documents)
And keep in mind that a good CMS should change document characteristics (who can check it out, what aspects are still editable, who it gets default routed to) automagically when the status changes.
I could list another ten statuses and another four or five kinds of functionality without breathing hard but you get the idea. So, how is most of this stuff out there built? Rough, Final, Live, maybe one other, and usually none of them editable. Like I said, amateur hour.
Anyway, I'm late for a barbeque. See y'all later,
Rustin
Data is the lever, rigor the fulcrum, brains the force that drives it all.
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-
Sorry, Micheal Sims is busy eating Rob Malda's ass right now. Try asking Jeff Bates, though. Since Jon Katz got fired, he's been bored.