Why use Open Source when Microsoft products are so cheap... 10009

snips

You know, those are, really, pretty poor reasons to claim OOo sucks. Stop and consider the implications of each, for a moment. Let's start with "slow to open".

Is OOo slow to open? Perhaps. buttume it is. Okay... so what? Exactly how many times in a day do you create documentation which requires the full force of a heavy-duty word processing application?

In the last month, I've been reading - and creating - a heck of a lot of documentation, and I haven't opened OOo Writer *or* MS Word once. I've used a variety of other things - kate, textpad, etc, several times, but not once have I used the word processors.

Why is that? Oh, right; those apps do everything from embedding OLE objects to 3D text rendering, don't they? Basically, they're no longer documentation tools, so much as multimedia presentation tools. Since what I'm doing is reading - and creating - documentation, not multimedia presentations, I haven't had much use for those apps.

Where they do come in handy, though, in the documentation arena, is when handling *large* documents. Several hundred pages. Reformatting, for example, is often simpler, more powerful, or both, in them than in the lighter tools.

Fine, fine... so when I work on a 200-page document, I use a full-blown, heavyweight, everything-plus-the-kitchen-sink word processor to do so... and does the extra few seconds of load time really matter? No, it doesn't. Be honest, it makes absolutely bugger all difference when you only use the app occasionally in the first place *and* you're using it to process large documents when you do use it.

Of course, if you're using it to do something as silly as, say, composing emails or writing quick little "Buy milk and bread" type notes, you might ask yourself why you're doing the equivalent of pulling out a Mack truck to haul a 5-pound bag of sugar around.

Now, about the ruining of .DOC files. Let's be fair, here. OOo gets a lot of .DOC files right, though it may screw some up. Exactly how many OOo format files does MS Office get right? Oh, right, that would be zero. So you're criticizing one app for doing something poorly, which the other app doesn't do at all, namely handling each others' file formats. Pretty bogus argument.

It gets even more bogus when you stop and consider actual usage; if you or your company chooses Word Perfect, or MS Office, or OOo, or something else entirely, that's what they'll create their documents in. If the other apps can't read the formats, the internal question is, more or less, so what? It only matters if you're planning on converting... and there are intermediate formats one can use for that purpose. If you're planning to conver to OOo, I'm sure you could use some intermediary format to do so, no?

Of course, there's another aspect to this, namely, *why* is OOo's handling of .DOC files so bad? After all, the .DOC file format is fully published and fully specified, so the folks over at OOo have a complete record of everything they need to do to do the job correctly, right?

Hmm... no... most of those formats seem to be closed, meaning, in essence, one must work out the details another way, and very likely introduce bugs and oversights in the process. Imagine that; despite the obstacles, OOo manages to actually get the job done, even though there are hiccups... whilst MS Office can't do the job *at all* despite having full and complete information available. Again, a pretty bogus argument against OOo.

OOo doesn't offer a database system? Okay, well, true enough... but so what? There's a wide variety of DB systems readily available if you want one. There's even several free ones. Most have multiple front ends available for managing them, too, and last I checked OOo can use most, if not all of them for its data source. Pretty bogus argument.

Perhaps your criticism of the language is valid; I don't know, if only because the notion of a programming language as peraining to a document strikes me as a bit weird; programming languages are for writing programs, not for writing documentation and spreadsheets. You might write a program which processes those documents, but that's a different matter... and if you're doing that, you can pretty much choose any language you want. The only uses I've ever seen "embedded" coding used for, to date, have all been extremely bad uses, mostly to accomplish nothing which couldn't as readily be done with an external body of processing code and the net result of which has inevitably been that the documents - never mind the uses they're supposedly put to, just the actual documents themselves - are effectively permanently bound to a single application for their use, rather than being simply documents.

The most obvious example of that sort of thing was with one company I worked for; they had a document (a spreadsheet, as I recall) which you could open and it would - thanks to embedded coding - let you figure out the values of your shares, arrange to buy or sell shares, and a mess of other goodies.

Sounds good, but if you ever tried to open this document in another vendor's spreadsheet app, you could pretty much forget about it. Not only does that tend to lock the entire system into using one specific app, it does so completely unnecessarily; the exact same job could as easily have been done on the company's internal web server, using, say, PHP on the back end. Now the interface can be any web browser, on any OS, instead of just a single app on a single OS, and better yet, the actual code that drives it can be relatively easily migrated to a different web server on a different platform.

So let's recap. OOo may load slow, but given the relative infrequency with which one actually needs to perform such an operation - and the ability to simply leave it open, if one really does need to do it often - that's really not significant. OOo may not handle all .DOC files, but the converse case is even worse; MSO won't open *any* OOo files. OOo is the clear winner. OOo doesn't come with a database, but there's enough avaliable, free and otherwise, as to render this rather meaningless. OOo's scripting language may be lacking in some way... but what the hell are you doing writing *active* documents in the first place, which is, in *every* case I've ever encountered, a very bad idea indeed?

On a side note, I've just installed OOo 1.9 beta. First run (and ignoring the time spent in the registration wizards) it took abut 45 seconds to load, though it also loaded a quicklaunch applet. Subsequent runs, from the quicklaunch applet, take 1-3 seconds for the last-run app or about 10 seconds for a different app. Hardly the end of the world, especially since this machine is a 400Mhz box with 96Mb RAM in it. Oh, and there is a database bundled.

Yes, well, four completely bogus arguments against OOo. I'm sure there was a point to your post, but it's not clear what it was.