Randomthots wrote:
On the one hand it's not "set in stone" in the sense that there's room
for maneuver, but within reason. Customer demand is only one factor.
We also have to consider the reality of limited resources and
technological trade-offs (e.g. bloat).
No different than any proprietary app in that respect.
Not terribly no. Most of the difference is that the resources available
are different (e.g. volunteers will work on what they're interested in,
not what you tell them) and the concept of customer is fuzzier.
Myth: OpenOffice.org is the product of an army of volunteer hackers
working in their basements in their spare time,
I didn't say that. Yet another example of your taking something simple
and reasonable and making it mean something it was never intended to.
Saying that you can't tell volunteers what to do doesn't mean that OOo
is 100% comprised or volunteers, or even mostly comprised of volunteers.
When dealing with a volunteer force, the concept of "customer" is a
bit blurry.
Not in this case.
I is, because they're not paying for it either. I make something and you
get it for free, it's very odd for you to call yourself my customer, and
to argue that because you're my "customer" I should listen to you. This
is true whether I am an individual hacker or a big company. You are not
a customer, you are a user. You become a customer when you start sending
me money.
StarOffice does have customers for example. So I think that the
customers of StarOffice are a lot more likely to drive the features
implemented than the "customers" of OOo.
As was pointed out in another thread, increasing the
user base is critical to the success of OOo overall.
True, and that does mean that there's a sense in listening to the users
of OOo instead of just the customers of StarOffice.
You took a statement that "OOo should only cover xyz" to mean
"OpenDocument should only cover xyz". You took a division of
applications intended for OOo (office vs communiction) and applied it
to the file format.
No, I didn't. I never even mentioned OOo except by implication with
regards to your stance against including those components.
But that's the point. You took something that was said about OOo and
applied it to ODF.
My main point
is and has always been that this division between productivity and
communication is arbitrary and mostly in your own head.
Not quite arbitrary. Perhaps a little fuzzy, but that's not the same
thing. For example, a word processing document needs to be able to have
vector graphics in it (e.g. for the sciences). So you need to make a
vector graphics engine anyways. So making a vector graphics application
to go with it seems reasonable, since most of the work is stuff you have
to do anyways. On the other hand, a calendar server doesn't offer much
opportunity for code re-use. It is a very extraneous thing. Therefore,
looking at limited resources, it seems reasonable to say that a vector
drawing application is a good idea and a calendar server is not.
Same argument for other things that you'd expect to see in an "office"
document. A spread sheet needs charts, so that goes back to vector
graphics. In some areas it's common to embed a spread sheet into a word
processing document. So word processing+spread sheet+vectors go fairly
well together. Also, once you have a vector program, making a
presentations package is not such a huge step. Impress and Draw are 99%
the same thing.
So, what I'm calling "office" is a reasonably self-contained set of
functionality. And it's reasonable for OOo to say that that's what it's
going to do, and not calendars or PIM.
You act like this judgment is the output of a mathematical equation.
My position is reasoned, and not merely a preference. I say that OOo
should have vector graphics and not a calendar because one offers more
opportunity for code reuse. To say that this is just an opinion and a
preference is silly.
You seem to say that anything that is not an absolute certainty is an
opinion, and imply that all opinions are equal and equate opinions with
preference.
I think this is ridiculous. Saying that OOo should have xyz but not abc
because xyz permits code reuse and abc doesn't is not on the same ball
park as a user who knows nothing about coding saying that OOo should
have a calendar because MS Office has one.
Around this time last year, I recall some fairly vigorous -- sometimes
even heated -- discussions regarding the development of the Base
component to more directly compete against Access. I don't recall which
side you came down on, but the arguments against it were remarkably
similar to the one's you make now.
You may need to back that up. I think the arguments put forth were very
different. A lot of people didn't like the fact that HSQLDB used Java. I
don't recall a single person saying that it shouldn't happen because it
wasn't part of office productivity.
My main point of
disagreement with you in the past has been your assertion that
communication tools fundamentally don't "belong" in an office suite.
Keep in mind that I'm thinking of a very specific instance of an office
suite. OOo has a very large core of functionality, and the things you
call Writer, Calc, Draw and Impress are really just small GUIs. It was
designed like this because those applications have a huge intersection.
Most of the code needed for each is also needed for the others. So it is
reasonable to put them together and reuse the code.
Contrast this with MS Office which is really a collection of disparate
products that happen to be sold together.
When I say "belong in an office suite" I'm thinking of the OOo sense. If
you want to put OOo and Thunderbird in the same CD and call it Bob
Office, sure, go for it. But that's not what I'm talking about here.
--
DEMAND __ __ __ http://opendocumentfellowship.org/petition/
| ||__)|__|\ | - Tell Microsoft to support it
|__|| |__| \|DOCUMENT - Sign the petition
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
