>
> >> 3. Interactive spell-checking (kind of) works. If you have an ispell
> >> american.hash dictionary in the usual place (/usr/lib/ispell/ on Linux, or
> >> the app directory on Win32), you'll get red squiggles as you type. Still
> >> needs a bunch of work though.
> >
> >I hope this is optional,
>
> Everything is optional if you have a compiler -- it's open source. :-)
Don't assume that this is true. If you want to appeal to a large audience
you will have to make this program usable for people who don't know how or
want to mess with sources. I think one of the goals of this project is to
make open source software that is not HackerWare and benifits people who
are not hackers.
[snip]
> Regardless of your opinion, we've worked and planned very carefully to
> ensure that AbiWord does *not* suffer from bloat. We're choosing a focused
> feature set which we believe will appeal to a wide audience. You may not
> agree with every single feature we're including, but I'll offer the opinion
> that it's a bit early to cry "bloat" about a functional word processor
> which still fits on a floppy disk.
One of the problems with free software is often the speed of development.
In a commercial company, a product is totally spec'd out. A team decides
when to release version 1.0 and exactly what 1.0 can contain. With a free
project, you have hackers implementing features that appeal to them and
sending patches. You call it 1.0 when you think it's ready. Someone wants
interactive spell-checking at this stage, and he codes it. In many
commercial products, 1.0 is the best version. Consider MS Word for
example. I remember using 4.0 on a 16 mhz Macintosh. When I upgraded to a
25mhz machine, I needed to upgrade to 5.0. What was new in 5.0? It had
more toolbars that took up more space, it had a grammer checker that
didn't work well, an embedded thesarus, and a larger memory footprint.
This got 10 times worse with 6.0. The programmers had started over from
the Windows version and ported it straight to the Mac. It took up 30
megabytes on a hard disk and took up to seven minutes (!!) to load on
resopnable modern computers. It had infinite amounts of bugs. It didn't
act like a Mac version should.
Then MS forgot about the mac for several years until they made Word 98.
Word 98 crashes a lot, takes up over 100 megabytes of diskspace and 9 megs
of ram, and has many new features but none are useful.
People like ESR say that "Open Source" can eliminate bloat becuase there
is no company trying to convince people to upgrade becuase of added
features. I disagree. When hackers get bored, they will either add
features that no one wants, or rewrite things to make them "better" (Scott
Adams, the creator of Dilbert, writes that change is only good for the
person changing things, and this is definately true. If the interface in
AbiWord were to change to make it better, it would confuse and frustrate
everyone.)
What will happen when AbiWord has enough features to be near perfection?
Since there is no desire to force people to pay for upgrades, will
development simply stop eventually?
Bloatware is something like Word, which takes a lot of RAM and forever
to load no matter what options are turned on (at least on the mac this is
something that everyone seems to agree upon). Linux has escaped from this
category becuase _it knows how to manage its features_. You decide what
features you want at compile time. There are intelligent defaults and
informative help texts. Optionally, you can modualize everything and a
module will be loaded only when it is needed. Gimp is also sucessful
because of this, it builds its filters and extensions as plug-ins.
If AbiWord wants to stay slim, it should adopt one of these systems. By
the time AbiWord reaches the feature set of an old version of Word, say
5.0, the equivilent to Winword 1 or 2, many people will not want all of
this giant to be loaded into memory at the same time. For example, if
there is an interactive spelling checker, even if its turned off its code
will usually be in memory wasting valuable space. I would advise against
having anything determined at build time to be fair on a non-technical
audience and allow people to turn on a feature that they previously did
not need. If a plug-in system was created, most of Abi's features could be
loaded on the fly. People could build their own plug-ins and put them in a
central repository! No more spreading cryptic patches that refuse to
apply or compile!
For example, if a hacker wrote a plug-in for legal document work, and it
was decided that it should not be implimented in the main source tree
becuase it was for too narrow an audience, he could put it in the
repository and lawyers would download and use it. I suppose I am
envisioning the plugins a little like emacs' modes, which do syntax
checking and formatting as you type. However, it would be nice to have a
more flexible plug-in system which let plugins embed different kinds of
objects, import or export documents, highlight syntax or misspelling, and
etc. Even automatic capitalization could be turned on by getting the
module and checking a box in the Plug-ins dialog box.
One of the problems I can think of would be cross-platform trouble.
Plugins would usually only work for one out of several OS's, unless it
used the xp framework entriely.