Slashdot Mirror
Anatomy Of A Bug In Microsoft Office
bender writes "An insightful look at what it is like to track down and fix a bug in Microsoft Office is available from Microsoft's Blog site."
← Back to Stories (view on slashdot.org)
← Back to Stories (view on slashdot.org)
I can already fix MS Office bugs by myself!
1. Does it affect Clippy? Fix immediately!
2. Does it affect features? Fix this week.
3. Does it affect security? Fix when you get around to it.
what it is like to track down and fix a bug
:)
Track a bug? Sounds like trying to follow a single mosquito in the ranforest.
Step 1: Deny existence of bug.
Step 2: Classify bug as feature.
Step 3: Cave to user demand and try to fix bug.
Step 4: Introduce new bugs during the fix.
Step 5: Classify those bugs as features.
Step 6: Pretend bugs are fixed and continue playing Minesweeper.
Here, drive this Yugo instead.
Cretin - a powerful and flexible CD reencoder
One of my favorite Chris Mason quotes comes from that memo, "Since human beings themselves are not fully debugged yet, there will be bugs in your code no matter what you do."
Then it would seem humans working at Microsoft are less debugged than everybody else. Because *boy*, at some point Microsoft was a bug factory.
To their credit though, this is changing fast. Microsoft is a huge company that can turn on a dime, and they've understood that having shite engineers onboard won't do much good to their latest "trustworthy computing" PR stunt. Not to mention, they actually have a nice R&D shop now, not just the pretense of one anymore.
"A door is what a dog is perpetually on the wrong side of" - Ogden Nash
Humans are bugs, err, humans are viruses. Correction: Humans have bugs.
Programs are like onions. Ogres are like onions. Donkeys like cake.
Mac Office X is the red-headed step child of Microsoft development efforts
Microsoft is a lot like the police.
--
Was it the sheep climbing onto the altar, or the cattle lowing to be slain,
or the Son of God hanging dead and bloodied on a cross that told me this was a world condemned, but loved and bought with blood.
Why don't they fix that awful formatting in MS Word?
You know, push enter twice and it returns to the default font/size. That really bothers me.
Click here for a free picture of an iPod!
"And, always remember that I can't fix what I can't see. I have to be able to reproduce the problem while being able to run some kind of diagnostic tool. The key to fixing a bug is predictability. Without predictability, I can't fix it, because without predictability I have no way to understand how the complex interactions in modern software cause the specific problem to occur."
I wonder if they'll do another writeup when they fix the next bug.
___
It's the end of my comment as I know it and I feel fine.
Adding new features and abilities to Word would affect a complex system like this in totally unpredictable ways. And, trying to debug such a complex system seems like an almost impossibly complicated task.
Now I know sarcastic answers will abound to this, but I wonder how much MS invests in testing such complicated programs? It has to be way, WAY more than they invest in the development of the program.
Now, I'm no Microsoft fanboy, but I am seriously impressed with Word. It never crashes on me, features always work as expected with other features and the interface does rock. I had no idea how complex the program was, and I am even more awed.
By the way, if you don't know much about complexity or chaos theory I recommend reading the following books to give you a nice appreciation of complex systems like this: COMPLEXITY and CHAOS.
-- "A chicken is an egg's way of making another egg."
I figured out the missing step: Marketing!
Do you want it buggy today or robust tomorrow? One need only look at the overclocking community and throngs of beta-testers to work out the answer. History is littered with technically superior failures in the marketplace (Betamax, Divx, BeOS) and the reason is that the consumer is more fickle about price and features than about technical superiority or stability.
Read any book put out by Microsoft Press and it's plain there are a number of people there that are as or more capable than most open source programmers. But the open source programmer doesn't have to appease any person or schedule other than those he sets himself -- and can therefore program under much better circumstances.
Try not. Do or do not, there is no try.
-- Dr. Spock, stardate 2822-3.
From the article
But there is a benefit to discussing complexity because it does seem to impact how many bugs arise and the maintainability, upgradeability, and usability of the software.
It's not merely a philosophical issue, either. This is a real, practical issue that impacts millions of people everyday.
The complexity of interacting software components is like the dark side of Metcalfe's Law about the usefulness of networks increasing quadratically with the number of participants in the network.
The maintainability of software decreases as the number of interacting components increase and as the number of ways of interaction increases.
I've developed code for a long time and seen great ideas turn into great code with creeping useful features gradually added on until a day comes when you wonder how you ended up working on such a monstrosity.
A good friend once told me years ago
"Provided by the management for your protection."
Cut the sarcasm. It really is innovative. It makes chunks of the document independent of what file they're in, and paved the way for an efficient implementation of our beloved "multiple undo" feature. And bear in mind that this was over 20 years ago, when the desktop software industry was just getting started and there was little prior experience to draw on.
Karma: Segmentation fault (tried to dereference a null post)
Have you read about all the new bugs that are being found in SP2.
Yes, and most of what is written is junk.
There are compaints about how the SP2 security panel can be spoofed.
Yes, they are uninformed compliants.
This allows a person to trick people into thinking their firewall and virus scan are all on and working normally.
Any person?
Microsoft's response... (paraphrased quote) "We are busy with other more important bugs at the time, don't bother us with these tivialities."
Umm.. no, thats a blantant distortion.
Here is the story you don't want to know:
A program running locally on the XP SP2 machine has the ability to overwrite the data store used to track and display the various updated components in XP SP2.
This isn't a remote vulnerability. It means that, simply put, a program can constantly overwrite the data that would indicate a virus scan hasn't taken place in 15 days, or that the firewall is off or open on certain ports, etc.
To have this "vulernability" be "exploited", first the protection would have to be subverted/turned off by the user. Nothing in this "exploit" allows an application to disable the features, just make them look as though they are in place. So after a program infilitrates the system and is running as an Administrator, it would be able to make the user think that the protection they already disabled was in fact running.
This is not a big deal. For example, let's say I had a program I could find a way to get onto a box with root access. I could just easily, if not more easily, spoof the security center interface and make it say what ever I wanted. I could just as easily spoof it to say "OH NO, GO DOWNLOAD THIS PATCH".
The point being this is a hole in the design or implementation. It's a social engineering attack. To be useful, the user would have to disable the protection on the machine; the user would then have to be convinced to download the trojan; the user would have to be induced to run the trojan; and the user would have to believe that he/she was in fact protected despite knowingly disabling the protection.
The nature of any operating system is that it responds to users actions. If any person/program can convince any user on any operating system to run any malicious binary as root/Administrator/etc than that box is exploitable by means of social engineering. Big deal. That's not new, it's not a security vulnerability per se, it's not anything but human nature.
Well, it's not *that* simple.
Figuring out how to best represent a document in memory can be more complicated than it would seem. Say, the easiest way would be just to malloc a chunk of memory for the whole document, but try to insert text into the middle of a 100 page document if you do it that way.
A more workable approach is to make it be an array with one entry per line, but that can run into exactly the same problem if you write a long enough paragraph.
So perhaps you go with something even more abstract, say, some kind of structure that contains pointers to words, which allows you to insert several invisible blanks every time you need to make space for stuff to reduce the time spent on memory management.
I think the article meant something similar to that last one.
gl4ss is completely correct.
Win95 was THE MOST ADVANCED OS in the world!
Win98 fixed all the bugs in Win95.
Win98SE fixed all the bugs in Win98.
Windows2000 is crash proof and the Unix killer!
Windows XP is even more stable than Win2K and will be sure to slay *nix.
Go digging through the press releases and gushing "journalists" for every single release (except WinME) since (and including) Win95. You'll see the same quotes over and over and over.
Several bugs have been sighted near the southern perimeter and some of our QA staff have been wounded in a couple of minor skirmishes. Strategic Command said the enemy's main move will not come for weeks and certainly not in this sector, though I am beginning to doubt.
27-08-2004 08:26The skirmishes have intensified and several QA squads are trapped between an unknown number of bugs. We even had a few lightning strikes beyond our perimeter, which took out our BugTraq listening post. I tried to call in for assistence from StratCom, because I suspect the main strike is happening here as we speak. 27-08-2004 08:54
The minor skirmishes have ceased along all sectors. We are trying to evacuate the wounded and salvage what's left of some of our equipment. 3rd QA batallion took heavy losses, as did 6th QA and 8th Helpdesk. What is this, some cat and mouse game they are playing with us?
27-08-2004 09:06All hell broke loose! While we were trying to evacuate the wounded, we found our sector under attack from multiple vectors, including artillery and naval support. Whatever remained of 3rd and 6th QA that was stationed in the rear has now been wiped out. 8th Helpdesk has been decimated and I had no other option to commit 24th, 12th and 2nd Developer batallion to the battle, at least untill reinforcements arrive. The enemy seems to be using a superior number of SFU-506 "Sasser" class fighters with ActiveX payloads. I nearly begged StratCom to send some "KB900364" SAM batteries.
27-08-2004 15:56We have pulled back and regrouped in Sector 56. 3rd, 4th, 6th QA got decimated. 8th, 12th and 15th Helpdesk have been routed as well. 24th, 12th and 2nd Developer have been utterly destroyed to save the rest from annihilation. The few who remain are now en-route back home. Some are shell-shocked, one fat guy keeps jumping around yelling "Developers!"... Poor sod, this is war at it's worst.
Gee, I wonder why.
--Rob
Towards the Singularity.
Describes a huge chunk of my life in Software QA. It's an example of what is great about MS software and what is awful:
Great: dedicated test resources to chase down corner cases/non-obvious scenarios, accountability for broken scenarios, etc
Awful: Iterations of releases built on legacy code means no one (or two, or three) people can understand the problem or scope the fix.
For all the complaints here about MS code I wonder that no one has noticed the Windows weakness that is not getting exploited..? If MS software is really as bad as everyone here makes out then why doesn't someone do it better? Blah blah Linux blah blah... Build software for Windows that people can use without rebuilding their systems. If you do it well enough tell them it's even better on Platform X.
Memo to Microsoft: it may be spelled correctly, but that doesn't guarantee it's the right word.
...laura
I do understand all the complexities involved in trying to fix a bug the way the article describes. That's exactly why Open Source is superior. Instead of wasting a decade while 3 or 4 guys look at the problem from different angles, we'd have 3 or 4 hundred guys working on it not because it's their job but because they need it fixed. That's why fixes usually take days or hours on Open Source products.
OTOH, lots of people know enough programming to solve that kind of problem to their satisfaction. We don't have to submit that fix, so we don't have to worry too much about the side effects of the fix. That enables us to keep working with the product until some official (and usually better) solution comes along.
Insert predictable rant here about how there are no bugs in Free software because any user could fix the bug themselves...
I agree. No doubt there will be a few who suggest the many-eyes approach will fix all the world's evils... it won't, it will let a developer who can be bothered to sift through the thousands/millions of lines of code necessary to fix the bug - this is a dedicated programmer and deserves credit for that... the world is not full of a large number of dedicated intelligent programmers who have time to do this for all, or even a small fraction of code they encounter - if you use Open SOurce (I use BSD/Windows with open/prop apps, don't bother with the 'jokes') do really look through every line of code looking for a buffer overflow exploit, do you pro-rata what you look through with the assumed userbase, do you assume others will do the QC/QA/peer review? Sure it could be made to be ultra-secure, and for this I am all in favour of Open Source (there is absolutely no security through obscurity, as those that need to know will know), but I really have a gripe with those that blindly use the many-eyes assumption and group-think, auto-mod others who disagree. If you want to criticise MS Office, then do something about it.
MS Office is massive, MS Office may be bloated to those who does not use all those features (and who does?!), but the idea of modulising Office suites, good or bad idea that may be, died miserabley in the last 90s.
MS Office is inferior, functionality and UI wise, to specialist applications made for a certain job - I would never do serious statistical analysis in Excel nor would i distribute a Word doc, nor would I make a webpage in Word(!).
Criticise it for valid reason, not knee-jerk group think, but it does serve as a good lowest-common-denominator suite that integrates OK for an intermediate solution. Open software may also suck at many tasks, but carries the benefit it is open. If I see the 'many eyes' justification for all opensource software refered to again, without proper justification I think I will throw my computer out of the window - please mods - don't just mod something down because you disagree with it, if you disagree contribute and bring effective discussion rather than pushing an opinion out of the room - save downmods for things which are clearly Offtopic, Flamebait or Trollish (and baiting discussion is not Flamebait, it is Discussion-Bait).
Very interesting read. One thing I have to dissagree with is about needing to see/reproduce a problem in order to fix it. It's true that not being able to reproduce makes finding a bug much harder but it's not impossible. As a server programmer I frequently have to debug race condition bugs, corruption bug or other problems that are not reproduceable at will. Sometimes good detective work can lead you to a find and sometime not. Often you end up having to add some diagnostic code that hopes to gather more information on the problem the next time someone encounters it. If it happened just once, often we cant fix it but then it's not that important... If it happens "once in a while" and/or "only in production at a large customer site" then we can usually fix it given enough time to work on it. I actually enjoy these kinds of bugs :-)
-Akiba
Haha. You even got +5, Insightful. Why don't we look at the rest of the sentence?
Brodie figured out that a document is really just a collection of pieces of text, and that it didn't really matter where each piece of text is physically located within the document's file.
I.e., if you're going to have "The dog is red." appears in the document, it doesn't matter if "The" occurs in the file before "red", or vice-versa.
Maybe this seems trivial to you, but I think most of us when designing a document format would try to put "The" before "dog", by instinct. It makes sense.
So what he figured out is not as straightforward as your out-of-context quotation makes it out to be. He was, at least, being a little creative. The article then goes onto explain multiple ways in which this design was useful in Word processing software.
I realize you're just being an asshole and that you probably didn't read the article, but just looked for a way to use it to make fun of Microsoft. "Standard Operating Procedure" at Slashdot, I know.
But, moderators, this guy doesn't deserve Insightful. He should be Flamebait.
They spent years in the dark that the "disk is full" error was caused by too many open files.
You'd think that if the disk isn't actually full, you'd look at other places that can generate that error. Even though obviously the error should have been along the lines of "too many open files".
Note that this underlying problem isn't just a technical one. You get over-general error messages on windows (and with various badly designed software) all the time.
The least you can do when you pop-up an error is to give some additional information; like where it occurred ("Bad Thing Happened in somefile.c line #456"), so even if, like in this case, you can't reproduce the error in a debugger, you know where the error got kicked into being. Not quite as useful as a full stacktrace like in Java, but pretty usefull.
Compare this to how (non-Microsoft) geeks write error codes; from man ep;
ep0: 3c509 in test mode. Erase pencil mark!
This means that someone has scribbled with pencil in the test area on the card. Erase the pencil mark and reboot. (This is not a joke).
Even if you don't understand the error code, at least you can google for its pretty unique description "erase pencil mark".
SCO employee? Check out the bounty
what a bunch of morons work at M$.
Let's see...
Introduce some gobbledeegook, heath-robinson-esq software design (ala piece-tables) just so the user can copy/paste ever so fast. <quote>For example, if you copy text from one document to another, you don't have to actually copy the text from one file to another--at least not right away</quote>
yes - therein lies the screw-up!!
They then live with this dog's breakfast of a code base for upwards of 10 (yes ten!!) years until its time to fix it. And the developers cant even work out which "Open file limit" has been reached. Well not very quickly anyway.
I have seen so much of this kind of "engineering" it makes me bleed from my ears. What's more, the author of this article portrays the story with so much nobility.
Things to always bear in mind I find are:
KISS
OCCAM's RAZOR
DONT TRY TO BE TOO SMART
END_OF_RANT
Isn't it great that the Mac unit can show the Windows guys the right way to fix a bug?
Wake up.
Comment removed based on user account deletion
When I read the GoF book (patterns book), it is full of examples from the 80's and 90's of how to do multiple undo (command pattern), how to even use flyweight objects to track each individual character.
.. very few references to Microsoft anything in this book.
There are plenty of examples from NeXT, from research project,
20 years ago there was experience to draw on.. Microsoft just lives in a big bubble world where they re-invent things their own particular way.
If you have auto-save turned on (it's on by default in Word for OS X), Word saves at N-minute intervals behind your back, and you get the same buggy behavior as you do when you do it manually. All you have to do is leave a document open for a long time.
I was asked by my supervisors to try and use MS tools to minimize their grief in reading my output. So, while I was debugging a program on a remote machine (via X11), I left a Word document open for my notes. After a few days, I suddenly couldn't save any more. I gave up and started keeping my notes in an emacs buffer (which has infinite undo, and can stay up for days with no trouble - go figure).
I remember thinking at the time, "this has got to be a file-handle leak problem". I'm surprised to see I was right!
To a Lisp hacker, XML is S-expressions in drag.
have you ever actually released software into the wild?
I came across a bug in one of my active enterprise systems today that I had never seen before, and none of my 1500 users had reported it. It would have never been found had i not been just screwing around with random things.
Give the MS guys some credit here, they have a lot of things to go over with constantly looming deadlines. You can't test EVERYTHING.
?SYNTAX ERROR IN LINE 42
One one hand, I can understand bugs cropping up here-and-there, on the other I struggle.
From the article: Since human beings themselves are not fully debugged yet, there will be bugs in your code no matter what you do...
When I did compsci at Uni we had to logically prove each of our programs. This was not easy, but it made it impossible for a program to crash or have a bug - inputs clearly defined, outputs clearly reached - this was at a mid-high level, but applies bottom up - binary into assembly up the chain. It is totally possible to write bug-free code, but damn hard.
In the end of the day we are talking engineers, not scientists with their head in the clouds. Total bug-free code can be written, but a different version will have to be proved for every iteration of processor, address space, hardware combo, program interaction. This is time-consuming and costly. Mission critical apps can be proved perfect, for diverse massive office suites it's not worth the effort. I'd rather spend $200 on MS Office and have it crash now-and-again rather than spend $10k+ for a dedicated piece of hardware with millions of hours of development into getting it running on that equipment. In the latter bug-free case Open SOurce would find it incredibly hard to exist because of the wide diversification that benefits a smaller user-base.
It is a trade-off... on the one hand I suffer the odd crash and incompatibility with a cheap product with massive functionality, on the other I spend a massive portion of my income preventing problems which wouldn't be major anyway and accepting vastly reduced functionality with it. I do OK with a cheap and acceptable product and my income intact, or OO.o with even more of my income intact, MS do OK with big profits or OO.o developers enjoy more kudos and associated benefits. For apps with a higher degree of secutity necessary, such as a web browser, email client, or file/web server, I get choice of what to use - again with a whole range of trade-offs: Lynx for speed and securtiy through IE for compatibility but little security. MS doing OK with $$$ from what benefit IE has given them is less acceptable.
I'd rather my product able to do core requirements (security for a webborwser which MS fail at IMHO, to functionality for an Office suite which they have excelled at since 97) now with minor bugs (in non core/critical areas) - have you seriously encountered bugs necessary (probability and loss weighted across the population) to justify the massively higher costs of development?
Once you tie Word down, hold a knife to its throat and say "No. Really. I know what I'm doing -- back off," it's really quite good.
It's not an issue of bugs, it's an issue of features turned on by default. Unfortunately (as I said above), you need to call off the dogs in about 100 different places before Word becomes really good.
Cretin - a powerful and flexible CD reencoder
Exactly! Making things modular, and limited to single operations with no side effects, allows you think about how they interact far more easily, in no small part because it makes the actual interactions fewer.
Read The Art Of Unix Programming, particularly the chapter on compactness and orthogonality, to fully understand this.
PHEM - party like it's 1997-2003!
Crimson
I'm not drunk, I just have a speech impediment. And a stomach virus. And an inner ear infection.
Not that this wasn't entirely predictable.
Maybe this seems trivial to you, but I think most of us when designing a document format would try to put "The" before "dog", by instinct. It makes sense.
In an output format, perhaps. It's a good idea. However, you're not thinking about it properly, from a programmer's perpective.
Writing a text editor is actually quite hard, mostly because the text is not static. You can't just parse through the loaded text once, you have to keep it in memory and allow edits to it efficiently.
When writing editing software (such as vi, etc.), we programmers all thought the obvious answer was a "line table". A list of pointers to each line of text in the file. Each line is independently allocated. That way, a user can enter new text on the line, add, delete, etc., and we don't have to make a complete copy of all lines that follow it and shift them up/down in memory.
Likewise, scrolling is easy. Does the screen show lines 1250-1280? Just go to offset 1250 in the line table and get the next 30 line pointers, then render each line. You don't need to parse through then entire file to find each line.
When we moved from character-terminal line editing to wysiwyg, there's not much different, except the line table is no longer fixed to lines, but it's kind of random. It could be paragraphs, lines, pages, or a mix of all as the document gets cut-and-pasted about. Cut and paste within the document is just a case of splitting the lines on the selection borders and re-building the line table. You don't need to copy the actual text selection.
Finally, when you save to disk, you have two options:
1) Just make a nasty raw memory-dump or a fixed-up memory-dump, so it's quick to load back in. This is what Word does (or did).
2) Actually go through your document and generate a structured, easily parsable format without any of your internal gubbins. That makes loading and saving harder, but interoperability much easier.
So, because Word just makes a dump of its internal editing structures, they appear in the output format. Both having editing structures and just naively dumping your workspace to disk is very "trivial" and "obvious" to programmers.
Your right on this, and sometimes a bug just isn't worth fixing!!!
WAY back when, in the dark days of 386s and early 486s, I wrote an application that was the best selling product in it's (admittedly) small nitche vertical market.
One day, we get a call - there is a bug in printing that NO one else could duplicate. It took me a week to run down the following
It required you to:
Be running on an IBM PS/2 Model 80 (Yes, the Microchannel one)
Be using an HP Laserjet II
Be using a MICROCHANNEL HP "Jet Direct Card" (a card that allowed the raster rip to be done on the PC instead of the HPIIs memory for greater speed)
Be running with a particular resolution
As the Model 80 was never a BIG seller, and neither was the Microchannel Jet Direct Card, we determined that it just was NOT worth fixing - we DID offer to fix the bug is they would send us the hardware. If the guy used the printer port, it worked fine (I assume it was a strange driver "feature" I would have had to work around)
The client I wrote the software cheerfully offered the end user a full refund on the software.... The client decided to keep the software, and use his printer port. We never did fix that bug, and NEVER got a call from anyone else reporting it (PS/2s were going away already)
-- 73 de KG2V For the Children - RKBA! "You are what you do when it counts" - the Masso
"Since human beings themselves are not fully debugged yet, there will be bugs in your code no matter what you do." We work to minimize the bugs in the software we ship, but they'll always be there.[emphasis mine]
And Microsoft thinks they're ready for the Enterprise Market....
I did RTFA. I'm trying hard not to flame, but this guy is a downright pathetic programmer. I've fixed more complicated bugs in the last week than this. And his defense - Word is complicated - just doesn't cut it:
There used to be a time when programmers were more professional.
Quite frankly, I hate to see this attitude in programmers. If you are charging for the code you write, you should at least have the professionalism to fully debug it before release. Your customers deserve better than to have your software ruin their business.
The society for a thought-free internet welcomes you.
I see this as a pity play by M$, wanting users to just chill about bugs because they're so damned hard to fix. Well, excuse me, but last time I checked Microsoft wasn't giving Office software away for free, and if someone is going to shell out beaucoup bucks for something they have a right to demand it works as advertised.
Cry me a river, Microsoft. I'll save my pity and empathy for people who do community or open source development.
"Don't matter how New Age you get, old age is gonna kick your ass." - Utah Phillips
The funny thing is these stupid error messages exist all over the place in MS software.
Once, when writing a DX app I kept getting a "File Not Found" error trying to load a bitmap... it drove me crazy as the file WAS there and could be loaded.
Finally, after trying everything I loaded the image into Photoshop and re-saved it, and boom, it suddenly worked.
It seems that the header of the graphic had a small glitch in it, and instead of giving me a meaningful error (like Corrupt File) it decided to give me the "File Not Found" error. Sigh.
...is a pretty good analogy when you thnk about it:
* MS Word/Office is built around a big, powerful and complex engine, just like a Ferrari. Both are high-performance but tempermental and quirky.
* OpenOffice is derived from another project (StarOffice) which Sun bought (through purchase of StarDivision) rather than invented itself. The Yugo is derived from the Zastava GTL from Eastern Europe, the design of which Zastava bought (from Fiat for the Fiat 128) rather than invented itself.
* The casual MS Word user is completely mystified by its exotic internal workings. When things go wrong they must contend with clueless and/or irritated tech support people who offer incomprehensible advice. Proper support is expensive. The Ferrari driver is also mystified by the internal workings of his car, and when things go wrong must contend with a clueless and/or irritated Italian mechanic who offers incomprehensible advice. Parts and labour are expensive.
* The dealer network was always sparse and is now non-existant, so Yugo drivers must fend for themselves by searching the wrecking yards for parts. The internal workings are primitive but well known to owners--there is no fancy, proprietary technology. Tech support for OpenOffice is sparse to non-existant, so OO.o users must fend for themselves by Googling for patches on the 'net. The source is less complex than that of MS Office and is open, so it is known to many of its users.
* A lot of people know and use MS office because it is more powerful and popular than the rest, so they put up with all the annoyances and pay a lot of money for it, even though they don't use it to its full potential. Most Ferrari drivers buy a Ferrari because it is powerful and a popular status symbol, so they put up with all the annoyances and pay a fortune for it, even if they can't legally drive it anywhere NEAR it's full potential--and seldom do.
* Properly cared for, a Yugo can serve you well as basic transportation--even though it has less features than a lot of other cars and is slow to start. OpenOffice, properly used, can serve you well as a productivity suite--even though it has less features than some other office suites and is a bit slow to start.
* Both the Yugo and OpenOffice can be obtained and used for basically no money and some amount of tinkering.