Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
×
Technology

Using The OpenDoc Methodology In Free Software? 11

TheMCP asks: "Some years back Apple got into the OpenDoc kick, and proclaimed a new era in software in which there would be no monolithic applications, but instead users would acquire tool sets and be able to apply small tools to "containers" to create documents. Tools from one vendor would have to work with tools from another, and users would get the best of all possible worlds by being able to select the tools they want to do their work. Then the vision died because Apple had forgotten to account for the fact that what's good for the user isn't necessarily good for the software vendor, and none of the software vendors wanted to be reduced to creating individual tools rather than locking users into their applications as usual." (Read on...)

"It seems to me that the OpenDoc model, or something substantially like it, would be a great paradigm for development of free software, since competition isn't an issue anyway, and the whole point is to serve the user.

Are there any projects currently working on something like this?"

This discussion has been archived. No new comments can be posted.

Using the OpenDoc Methodology in Free Software?

Comments Filter:
  • I plan to use this methodology when I have more of Mithril and IronDoc done. Right now I only have vague plans for Bolide described at (for example) the following pages: and assorted other pages near those.

    David McCusker

  • My understanding was that one of the inspirations for KOffice design was OpenDoc.
  • OpenDoc was the application-component framework for the IBM-Apple alliance that was trying to slay the Wintel dragon, going back to the pre-Win95 days. The basic idea was:
    - The CHRP-based hardware, with Motorola on board building the PowerPC CPU's
    - A microkernel-based architecture (I think), with either Mac OS, AIX, or OS/2 running on top of it (customer's choice)
    - All the OS's having the System Object Model (SOM) as underlaying glue
    - The OpenDoc framework for application components ("parts")

    The original deal with OpenDoc was that IBM would write it for AIX and OS/2, Apple would write it for the Mac, and Novell would be in charge of getting it out for Windows. Novell bailed around the same time that they sold WordPerfect to Corel, and IBM took over the Windows port. Then, things really began to unravel:
    - The OS/2 port to the PowerPC took forever and then some. By the time it was ready, Intel had caught up to the capabilities of the PowerPC chip, and IBM was ready to drop the whole PowerStation line from desktop production. Quite a few knowledgeable people feel that the OS/2 PowerPC Edition fiasco was what made IBM decide to pull the plug on Warp.
    - The Internet happened, and it made businesses think in terms of network-distributed applications rather than parts on a single machine. In conjunction with the OS/2 disaster, IBM decided to run with the JavaBean concept and abandon SOM and OpenDoc, which were OS-specific.
    - Apple, who were supposed to certify third-party CHRP models, pulled the plug on the Mac clones without ever certifying a single model as CHRP compliant.

    The final boxed release of OS/2 Warp (v. 4) includes OpenDoc support as an installable option. The Mac boasts the only known full-featured OpenDoc application: Cyberdog. IBM makes the final OpenDoc 1.2 toolkit available here [ibm.com]. They also make SOMObjects 3.0 available here [ibm.com]. Both are unsupported, with vague promises of an eventual full-source code release that IBM could probably stand to be politely reminded of.

    Here endeth the lesson. WARNING: it's late, and I might well be talking out my ass on some of the above story. This information is not intended to settle any wager of any type, and the author disclaims any and all responsibility for its misuse.
  • Although several companies were eventually involved with the development of OpenDoc Apple orginated the technology and only decided to share it when other companies got interested and there was an understanding that the technology could only thrive by becomming a standard. This added several years to its development.

    OpenDoc was not part of the original Apple-IBM alliance, although the spirit of that alliance probably lead to cooperation on OpenDoc.

    OpenDoc was one of the first technologies for which Apple released the source code (or at least parts thereof). However, this was before the days where Open Source was a buzzword and there were restrictions on the source that made it only good for learning and debugging. If Apple released the sources under the GPL perhaps OpenDoc would still be around today. OpenDoc is the sort of technology that companies find difficult to justify the development expense of, especially when belts are tightened.
  • Could somebody illuminate me about the differences among OpenDoc, Microsoft COM/DCOM and Gnome Bonobo?

    I understand that all of them are component-oriented systems. And Bonobo and OpenDoc lie on Corba.
    __
  • I think OpenDoc's failure had less to do with vendors wanting to lock cusomters into a single monolithic platform and more to do with it's inferior implementation. It was a huge, bloated, memory pig, it was slow and it was very late to market.

    In opensource, competition is very important and it will become more important in the future, we need it to keep moving forward. What we also need to do is to keep components as components and let each package focus on being the package that it is and nothing more and then tie packages together with things like bonobo, kobjects, xpcom and opendoc like technologies.

  • I worked with (not on) OpenDoc while I was at Apple, and the two biggest problems I could see were the learning curve and the oversold "cross-platform" nature.

    The learning curve was so steep in part because OpenDoc was amazingly flexible. That flexibility made for many concepts with inadequate introductory documentation. Also, the OpenDoc developers adopted a strict "OpenDoc is not a framework" rule, which meant that they would supply no default behaviors at all. Every part-editor developer had to start from scratch and understand the full API in order to create a "hello world" part editor. The OpenDoc Development Framework eventually filled this gap, but it came too late.

    The "cross-platform" nature of OpenDoc was a big disappointment to developers, because, while it abstracted out the event loop and the document storage facilities, it didn't include drawing. So, "cross-platform" part editors still needed massive ifdefs to do the stuff the user would see. Again, ODF eventually filled that gap, with recycled bits of the long-promised cross-platform "Bedrock" system co-developed with Symantec.

    I believe that OpenDoc could have caught on with developers if it had been easier to turn existing code into editors, or if the cross-platform promise had been fulfilled from the outset.

    One last thing. OpenDoc wasn't a failure at the time it was killed. When the NeXT crowd took over Apple, they loudly proclaimed, "We already have a component-based system," by which they meant NextStep. They apparently had no understanding whatsoever of the difference between a system of components that developers use to build programs, and a system of components that users use to build documents. One of the things they killed was a prototype reimplementation of OpenDoc in Java that worked surprisingly well--and might have made both technologies more exciting with a true cross-platform component system.

    The closest thing to OpenDoc alive today is Netscape plug-ins. Sad.

  • It seems to me that the OpenDoc model, or something substantially like it, would be a great paradigm for development of free software, since competition isn't an issue anyway, and the whole point is to serve the user.

    It already exists, although it's not open source. How do you suppose that you can include Excel spreadsheets, Video for Windows, and whatever else in Word documents? It's called OLE, for Object Linking and Embedding.

  • One of the things they killed was a prototype reimplementation of OpenDoc in Java that worked surprisingly well--and might have made both technologies more exciting with a true cross-platform component system.



    Do you have any references to post?

  • Apple and IBM's official position is that JavaBeans is the "successor" to OpenDoc.

    Both KDE and Gnome have their own component models under development. KDE (actually, KOffice) started out with a CORBA-based model, but last I heard they have abandoned that in favor of a more ActiveX-like model.

    The OpenDoc specification was adopted by the OMG (the CORBA folks), and I think it can be downloaded from www.omg.org.

  • Do you have any references to post? [about the Java prototype of OpenDoc]

    Nope. The only public evidence it ever happened is at the author's personal site. [mooseyard.com]

A failure will not appear until a unit has passed final inspection.

Working...