Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
Programming IT Technology

Should Open Source Content Management Interoperate? 119

Posted by michael 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? More

Should Open Source Content Management Interoperate?

Comments Filter:

  • No (Score:3, Insightful)

    by rppp01 ( 236599 ) on Friday September 20, 2002 @12:49PM (#4298510) Homepage
    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.

    • Re:No (Score:2, Interesting)

      by tgrasl ( 607606 )
      Interopability would be great - the benefits in terms of acceptance and ease of use are enormous. But MS have a great advantage - as a one-stop-shop, they don't have to wait for standards to appear or discuss the best way forward with anyone else. How do we get these systems to interoperate without slowing progess, and what happens when someone wants to use this cool new feature that just hasn't been introduced into the interoperability protocol yet ? It's a good goal in the long term, but it shouldn't hold back progress and new ideas in the short term.

    • Re:No (Score:2, Interesting)

      by kamasutra ( 172848 )
      Well, in the case of Exchange and co. it's not so much interoperation as integration, which is not a bad thing either.

      The catch is of course that it's hard to achieve that out in the open world of free/open software, since no one has any leverage over the other. This is one of those points coming from Microsoft, that do have some truth in it. Of course, the other problem there is that you can't achieve the same level of integration because of incomplete/misleading/missing documentation, but that's beside the point.

      My point is that going for interoperation/integration is not without a "cost". It's similar to PC and Mac situation. You can either go for relatively bigger freedom and lower price or you can choose a more integrated system.

      To achieve interoperability with something else, you have to agree on interfaces (whatever that means in particular context) and it follows from this directly that you are not completely free to choose and create them as you please and so you added another limitation on the list that you have to take account of when you design and create. How much you are limited depends on how complex the interface is and how close integration you want. And there are other issues you have to consider as well (limited time and your personal energy for example).

      It's a matter of choice.
  • 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?

    • PS: Isn't that the whole idea behind Open Standards?

      This one always makes me laugh:

      The good thing about standards is that there are so many to choose from. -- Andrew S. Tanenbaum

    • Re:They should be able to talk to one another... (Score:1, Informative)

      by Anonymous Coward
      I'd suggest that people who are interested in syndication standards check out the Information & Content Exchange (ICE) standard, at http://www.icestandard.org. They're working on a version 2.0 of the standard based on SOAP amd XML Schema (version 1.x is based on XML and a DTD). There's a web site and mailing list for interested parties...

  • DoD and SCORM (Score:1, Informative)

    by Anonymous Coward
    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.

    Of course, in the finest /. tradition, I have not read the article.
    • That is interesting. I didn't know anyone else used WebCT, but my backward University. It makes me sad to know that others are subjected to it too.

      ps. I did not read the article either ;-)
    • i looked at SCORM [adlnet.org]. in my opinion its a bloated mess that stands little chance of being adopted on a broad scale. typical three-letter agency standard :)

      -gregor

  • Drupal Interops (Score:5, Interesting)

    by quam ( 240063 ) on Friday September 20, 2002 @12:56PM (#4298569)
    Drupal [drupal.org] 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 [blogger.com] for the posting of content [drupal.org].

    • Re:Drupal Interops (Score:3, Informative)

      by bhsx ( 458600 )
      Postnuke also has an implementation of the blogger api, allowing all those little win32 desktop apps (as well as PDA, cellphone) access to your postnuke site. I personall think postnuke is the way, with tons of modules available. I'm waiting for PostSHOP to get going again (there was a shopping cart for older versions of pustnuke, but it was deemed unstable/insecure, iirc). With just about as many themes available for postnuke as there are for KDE, and even a template generator for the upcoming 8.0 release, that's where I see the future. You can check out my somewhat new site (nice theme) at bhsx.yi.org [yi.org]. I'd say it took about 20 minutes to setup and about half-an-hour's worth of content so far. Super simple.
  • 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.

  • Yes, It's about time. (Score:2, Interesting)

    by hazen_vs ( 244808 )
    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!

    • Re:Yes, It's about time. (Score:4, Informative)

      by cscx ( 541332 ) on Friday September 20, 2002 @01:11PM (#4298694) Homepage
      (BSD's 4.2 TCP stack is in both windows 2000 and WinXP). Please correct me if I am wrong.


      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.
      • They didn't "steal" it from BSD. It was used, nice and legal - that's the BSD license. And the Regents copyright was included for the TCP stack.

        Anyway, you don't often steal code (unless you make off with the only copy of it rather than copying it), you can infringe on the copyright of code. Not the same thing, despite the propaganda put out by the proprietary software industry and (some) lawyers.

        If I had a magic cloning ray, and I cloned your car, would I have stolen it? Of course not. Now you have a car, I have a car, everyone's better off...

    • X.400/500 are protocols, not implementations. Protocols are pretty worthless without implemenations.
  • 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.

  • yes -- WebDAV (Score:2, Informative)

    by claud9999 ( 412067 )
    Yes, WebDAV is a protocol commonly-used by many content management systems (commercial and open-src)...See http://www.webdav.org
    • 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).

  • 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)

    by brunes69 ( 86786 ) <slashdot AT keirstead DOT org> on Friday September 20, 2002 @01:23PM (#4298784)

    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'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).
      • I think that reinventing the wheel is fun. Useless, but fun. I want to create a MS export filter (not really, just an example...) because it represents a challenge to me. Using someone else code would work, but where's the FUN in that?

        Call it ego if you will, but if there was no fun (or ego), there would be no reason to spend so much time doing those things, for free.

        Now, for commercially developped OSS, it's different...

    • Perhaps the solution is to gather a SWAT team of 2nd world programmers and organize a programming equivalent to this [slashdot.org]. An influx of 10 developers paid at Romania or Ukraine average wages is likely to be of sufficient mass to put through most interoperability changes. This also shouldn't piss off most people because interoperability isn't something that most people care about so if it's just added nicely and is easily maintainable, why not?

      So let's say you take a couple of months to work out a common, extensible standard that should fit all the extant projects, join each project, bolt that model onto the existing code so it works, and then move on to the next project. In a year you get through the main CMS efforts and can then move on to the next set of interoperability challenges.

      All it needs is funding ($400/month/programmer). A large 10 man SWAT team could be put together to solve this for under $50k.

    • 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?

    • 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.

      To be honest, that's the wrong example: if there was just one codebase for this, it would be too easy for Microsoft to break it hard, i.e. by changing their formats in a way that requires a complete redesign from scratch of the code of the filter. Past experience proves that Microsoft is expecially good at breaking hard other's designs.

      OTOH, by having multiple implementations, there is a chance that at least one of them fits well within the new scheme, and can be easily expanded to handle the new format, thus plugging the hole while other implementations catch up.

      To some degree, this is applicable even to the Gnome/KDE, Emacs/Vi(m), GNU Emacs/XEmacs etc. situations: if something is discovered which greatly improves their usability, there is a chance that at least in one of them it is easy to implement, so it may seem the light, and others will start to catch up. Lots of features were added to projects just because the "other implementations" had them and it seemed a good idea...

      Would Mozilla have tabbed browsing, mouse gestures and several other useful things if the only other browser out there was IE (instead of Opera and Galeon)? I'd dare to say yes, but not here and now.

      Briefly said, "monocoltures" are not always a good idea.

  • Everything is "content" (Score:4, Interesting)

    by Tablizer ( 95088 ) on Friday September 20, 2002 @01:37PM (#4298899) Journal
    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.
    • RDBMS is primitive for content managemen as it help to manege mostly only attributes. I agree.

      XML is not the answer as it good only for hierarchical data and the real world is more complicated than a tree. Let's say its more like a graph.

      Perhaps, RDF is way to go as:

      • RDF is good manage relationships in a way similar to Prolog predicates;
      • RDF, being still XML, is still good to manage trees.
      • Ontology is a better way (than DOM and than ERD) to describe "unpredicted" data, which is a typical case for content syndications.
      The problems of RDF:
      • it is more complicated to be understood by most average programmers;
      • there are not enough of effective and stable RDF-based databases;
      Finally, I'd like to comment the original statement:

      Everithing is "content"

      I'd like to add here: ... and everything in content is functional and/or logical and/or object-based. It means that "content" might be a data, it might be a program and it might be both at the same time.

      That's why when I do some content management programming I usually look for solutions at functional and logical paradigms. Which is also helpful when you work with RDF :)

    • Heh.

      I am currently consulting on a legislation management system -- basically a giant content management/document searching/complex document creation system. And they are dealing with *all* of the issues you mention. Plus more!

      Sadly, they have already done their DB design and have mapped a very complex XML DTD (derived from an older SGML DTD) to a set of relational tables with defined attributes. They attempted to define a table for every node using sequence numbers for nodes that could occur in multiples and single ID numbering for table keys across *all* tables to avoid duplicate keys when a node type can be contained by multiple other node types.

      As a result they have a very complicated set of tables mapping hierarchical relationships which isn't even a good relational design (try doing an ERD for it and I will garauntee you will start wibbling your lips). And it needs to be optimized for searching and retrieving, which they are thinking right now will mean a second database, or even just flat files, which must be flowed from the first DB. YEESH!

      I would love to have been there during the DB design process so I could have convinced them to try something different there, even if it *isn't* open source. Instead I am tasked with figuring out how to provide some *very* advanced search features on the existing system. (Insert wry grin here.)

      Oh well, that is why they are paying me the big, *cough* *cough*, bucks.

      Jack William Bell
    • It wasn't slashdotted when I got to it. My problem with many sites (particularly after following the author links with this one) is that they don't respect my settings to make the fonts bigger. As a forty-something hacker, this is becoming a really anoying problem for me.

      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 [twiki.org] 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 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?

    • Re:Content Creation and Managment System (Score:4, Insightful)

      by Phoukka ( 83589 ) on Friday September 20, 2002 @02:21PM (#4299235)
      Let me reformulate your question a bit. You wrote:
      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.
      What you really want is not a template, fill in the bits to make an html page. What you really want is to do the exact same thing, but substitute XML for HTML. Once you are using a dialect of XML as your source, you can use XSL to transform the source into other formats, including HTML, PDF, and RTF. Take a look at the Apache XML project [apache.org] for technologies that will help you. Apache FOP will generate PDF for you, and Cocoon will give you a framework in which to do all this XML manipulation. You can use Xindice as your XML data store. But buy a couple of really good books on XML before you start...
    • We've designed a system similar to what you are thinking about. Where I work we are beginning to use ZOPE for content management. We have some content that needed to be shared between multiple front ends. What we've done is used ZOPE to store static content, and then used ZOPE with a relational DB to store individual field data via a web form. This way the other front ends can pull the individual fields that they need without accessing ZOPE and ZOPE can use the same data to generate XML. It can then be transformed into other XML, XHTML, WML, PDF, TXT, etc. That's one of the main benefits of XML when it's partnered with XSLT.
  • 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.

  • A good first step: exclusive use for files (Score:4, Insightful)

    by Animats ( 122034 ) on Friday September 20, 2002 @02:13PM (#4299168) Homepage
    One of the big weaknesses of Unix/Linux is that file systems don't have reliable exclusive use. Some versions of UNIX don't have mandatory exclusive use at all. On Linux it's a mount-time option. Unix has traditionally had lousy locking primitives, and NFS made it even worse. "Advisory locking" is sometimes available in various flavors, ranging from bad to worse. Lock files are still used, even though they're unreliable under NFS and orphaned lock files often lock up programs. Overall, it's a mess.

    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.

  • 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.
  • 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!).

  • I'm not familiar with OpenOffice development, but a big question in my mind is if Mozilla can interoperate with anyone.

    I think the evidence clearly suggests NOT.

    For instance, take look at this bug:

    http://bugzilla.mozilla.org/show_bug.cgi?id=1644 40
    (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.
    • ***Parent is Off Topic. this is too. moderate as you see fit***

      You do not seem to understand the distinction between a bug and a suggestion. A bug is when the program is not behaving as designed. A suggestion is when you would like it to behave differently than designed. You have a suggestion and that's great. There are various apropriate forumns where suggestions are welcomed and debated. Bugzilla is not one of these. Bugzilla is a bug tracking database. Entering non-bugs is just adding noise, and apropriately generates the same feelings and reactions as spam or telemarketing.
      • No, I disagree.

        This bug (#164440) is pointing out bugs in the implementation of the menu specification. Read the example about View Image. If you are viewing an image, would the most likely thing you want to do is view image again?!?!?

        And what about all the RFEs?? Should these be verbally assulted because they are suggestions, not real bugs? Puh-lease.
      • The name Bugzilla just implies it is a bug management syste. It is really an "Issue" Management system and so it is valid to make posts like the one mentioned. It wass quite clear that Asa was having a bad day and could have been nicer to the user. Anyway, we all have good days and bad days. First we should at least get the clipboard to work interoperately then worry about the harder stuff.
      • 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.
        • Well, you (and the other responder who noted it) are quite correct that tracking suggestions as "enhancement" severity bugs is entirely appropriate. The bug in question, however, is marked "blocker". It looks to me like this very issue was the subject of extensive disscussion, after which a decision was made, and implemented. Someone didn't like that decision, so they entered their view as a bug, got rightly slammed, and now they're complaining about it in other inapropriate places (this thread).

  • What If???? (Score:2, Interesting)

    by larzgold ( 516304 )
    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
  • If you're in the Java world, check out JSR 170 [jcp.org].

    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/.

  • 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.

  • 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.

Slashdot Top Deals

The moon is a planet just like the Earth, only it is even deader.

Close