Slashdot Mirror
ZDNet Reviews KOffice
Spotted over at dot.kde.org -- this review of KOffice. The review isn't overwhelmingly positive or negative -- seems like a rather balanced picture of both what's up to par, and what's still missing, for mainstream acceptance in the Normal Workplaces of the world.
If you don't like reading a three page article by starting on page two, follow the link: *click*.
According to Sun's StarOffice FAQ:
a q.html#12
12. Is StarOffice 5.2 software written in the Java language? Will Sun rewrite the StarOffice suite in Java technology?
StarOffice 5.2 software includes components written in the Java language, and provides the Java Virtual Machine for running software based on Java technology. However, the majority of the StarOffice 5.2 code is written in C++. Sun does not intend to rewrite StarOffice 5.2 in Java technology. The Sun Webtop architecture relies heavily on Java technology for the interaction between the browser-enabled client and the application services running on the portal.
The FAQ can be found here: http://www.sun.com/software/star/staroffice/5.2/f
M$ Office: $200-300
K Office: N/C (comes bundled with various distros)
That in itself is an important feature...
You're using her as bait, Master!
...KOffice/Kword to make a big hit with users:
1) Allow reading/saving of documents as *.rtf
Rich text format seems to be the preferred document format among open-source word processors, yet KWord still lacks this feature. Heck, even MS-Word can read and save RTF! Supporting a common document format--instead of just *.kwd and *.txt--is going to be important for interoperability with other OSS office suites and the MS-Office world. Same goes for spreadsheet and presentation graphics file formats.
2) KOffice needs to have provisions for English measurement parameters in KWord and its other products. Yes, the geeks out there can convert to mm, but if you wanna get users off MS-Office, simple features like this will be important.
Im still locked into m$ office for exchange server. Until someone comes out with an Exchange klone, m$ will dominate the market.
We had to install citrix clients so our NOC (running solaris on ultra 10's) could access the exchange servers. Even thou we don't use m$ products for our NOC, m$ infiltrated it via exchange.
E-Mail is at least 25% of my job, working on projects around the country, email is my ball and chain to the m$ platform. All documents open fine under StarOffice, but I still have to go back to exchange for my email. So I just run win2k on my laptop, use x-win32 for display, and samba to mount my solaris box and ssh to encrypt it. Basically Merge the two OS's into 1 via network tools.
I thought the article was very fair. It didn't seem to expect the world out of KOffice, and made the point that it was a volunteer effort.
Having recently fired up KOffice for the first time since the 1.1 release, I've got to say I'm really happy with where it's going. The team has done a great job on getting component embedding working (although it crashed on me when I started pushing it around a bit) and I really think this will shape up to be an incredibly powerful suite.
Of course, these things don't happen overnight. It took Linux about 8 or 9 years to start gaining more widespread acceptance in the server area. KOffice is a tremendous project, and it'll take a long time to get to the point where it can compete with MS Office. Remember, software like this doesn't just happen overnight, it has to evolve. MS Office has had over a decade to get to where it is. I have a feeling we'll start seeing KOffice as a real alternative to MS in a few years.
"I may not have morals, but I have standards."
Many of the issues addressed should be easy to fix. The lack of an automatic spelling checker and a thesauris in KWord, for instance, should be easy fixes. Likewise the case sensitivity in the spreadsheet program, though most UNIX people won't tend to view that sort of issue as a bug. The customer is always right and all that.
On a quick side note, I still prefer TeX/LaTeX over any GUI word processor I've ever run across. I believe our documentation people 'round these parts still use SGML. Not something a normal user will ever look at due to the learning curve, but once you get a set of styles down, you can rattle off any old document you deal with on a regular basis with almost no effort devoted to the formatting of the document -- you just work on the content.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
from the article:
/ fa q.html#12
"KOffice is natively compiled for the machine platform on which it is executing, whereas StarOffice is a Java-based application"
from the StarOffice FAQ:
However, the majority of the StarOffice 5.2 code is written in C++
http://www.sun.com/software/star/staroffice/5.2
Why do some many people think StarOffice is written in Java? Is it just because its from Sun?
--
I wish i knew how to get slashot in light mode without having to login
Lost productivity time due to malfunctioning import filters: Priceless.
-
Thats about all there is in the article. If it took the author more than 4 hours to produce this I would be surprised. Fortunately, the geeks can now read this synopsis instead of reading the author's wordy version. This way we will save hundreds of geek hours.
Now you and I both know that KOffice isn't nearly as polished and powerful as MS Office is (and Office XP is going to be).
But the thing is, when you look at how far KOffice has come in how little time, it becomes apparent that it's just a matter of time before it catches up and, provided its leadership isn't content to be "as good as" Office, surpasses Office in features and functionality.
It's the sheer rate of change and speed of development of KOffice that amazes me. In a couple of years, this free alternative to Office will most likely be at least as powerful as MSFT's product, except that it will cost nothing.
Office software is becoming like text editors and browser software: It's something you don't expect to pay for. And if MSFT continues to try to charge people for it, people will move over to the alternatives.
No, it ain't there yet, but look at where it was and where it is now. Look at how short the time was for it to get here.
And just think. Just a few months ago, people were saying that Linux would never be a viable desktop OS. A few who have their heads in the sand still say it. But it is viable now! Even my Dad, who usually lacks the time to learn anything more complicated than instructions written on a sheet of paper that he follows to the letter, could install and get running with KDE under RedHat.
All that's left is a Quicken alternative.
Exchange does something other mail servers don't do. And it does it well.
I was going to say "groupware". But that's a bit of a misnomer. It does have various groupware functionality - but its specifically scheduling that it does well. Other groupware aspects are almost a brief afterthought.
Sure - there are other scheduling competitors out there. But I watched Cisco Systems gravitate towards Exchange despite their heavy investment in a Unix mail infrastructure and the problems a diverse desktop OS user base causes for functionality with Microsoft products (Cisco endorses Win2k, Solaris, and Linux as supported desktop options for their employees).
Its a shame that Exchange forces one to pick up all the usual MS bagage along with an otherwise top tier product.
StarOffice 5.2 is so resource-hungry and slow that it might as well have been written in Java 1.1. Waiting a solid minute or so for it to fire up on a P2/300 with 192MB RAM, and running into its native widget set, it's easy to unserstand why someone might think it was written in Java. Less easy to understand is why ZDNet seems to have fired all of its fact-checkers.
The OpenOffice development snapshots are definitely peppier, so StarOffice 6.0 should be fine in this regard.. but 5.2.. eek.
Where Java does enter the StarOffice picture is that 5.2 has an open interface that lets you pick a JVM--or install one--to use as yet another macro language. This is a nice touch for all the Unix shops and others that have Java programmers on hand more readily than VBA people. You can use a nice, fast 1.3.x JVM with it, and develop with your existing tools and components. The other nice "Java" feature is SO 5.2's ability to use JDBC throughout for database access instead of native drivers or ODBC. Very useful and very elegantly cross-platform on Sun's part.
And incidentially, the "other" major SO5.2 scripting language is a VB clone, both in syntax and coding environment. SO has a different document object model, so MS Office macros won't run unmodified, but at least VBA skills can carry over. KOffice's use of DCOP for automation allows the use of any available language, potentially doing things one better--but without integration with a development tool as one gets with VBA and StarBasic, it remains at a disadvantage. Maybe bidirectional KOffice-to-KDevelop hooks (for C++) and KOffice-to-Netbeans/Forte (for Java) are a way to go.
Think internationalization. Presumably the user should be able to name files in his own language. But Unicode case normalization is expensive and complicated. (Of course, you could say that case insensitivity need only apply to ASCII, but then you get called a narrow-minded Anglo-centrist.)
Think access control, and all of the bugs that arise when there is more than one name for a resource. Granted, this is probably a software quality problem, but it is reality.
Overally, case sensitive is much simpler engineering-wise. "Normal users" shouldn't have to type exact filenames anyway, they should be using file dialogs or case-insensitive search tools or something.
The evaluation of an action as 'practical' . . . depends on what it is that one wishes to practice.