forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: Verbatim file copy now works also with CLI
Date Mon, 30 Dec 2002 02:27:07 GMT
Rodent of Unusual Size wrote:

> i should probably just shut up and only post concerning technical
> questions.  i'm not a developer on this project, i don't know from
> xml or cocoon or java, and therefore my input is really no more
> than kibbitzing -- and no-one really enjoys having someone commenting
> over its shoulder.

Please don't.

Your input is important *exactly* because you know very little about XML 
and almost nothing about cocoon and java... but you are interested in 
the *results* of all those millions of lines of code that hundreds have 
done in the past three years on all this.

But right because our software is attracting people that don't care 
about the software itself or its technology but about the services it 
provides, we *must* listen to them as the most precious resource of balance.

Why? because so far we are a self-selected community of elitarians who 
took their time to go thru those thousands of pages of 
documentation/specifications about all the different technologies. We 
need different views injected or we'll stall into our ivory tower of 
technicians.

This doesn't mean that we'll throw our knowledge away and run for the 
'simple and dumb' solution. No, damn it.

But the ultimate goal is to be useful.

But since we are talking a different approach to things that in the past 
were done differently, users will have to accept a little mindbending 
process of adjusting.

And the purists will have to accept a little mindbending to adjust to 
user needs that might not fit into the big scheme.

Example:

I hate DTDs and I strongly disklike XMLSchema... but most XML-authoring 
tool support DTD as input.

The purist view says: screw them and go for the perfect solution. That 
will give us a nice technology, but will scare users away (or even 
worse, fork the project)

Result: the software is better, the community is weaker.

Every technical decision should be made to improve both the community 
and the software, but if it's not possible and one has to be choosen, I 
would go for improving the community because that will give us more 
people, will give us more ideas and more direct help and will finally 
come up with a better software.

Of course, patience is king in this kind of decision making process... 
it seems to me that some here have very little patience and very little 
trust in the community dynamics.

IMHO, *this* (not lack of documentation, David) is hurting this effort.

-- 
Stefano Mazzocchi                               <stefano@apache.org>
--------------------------------------------------------------------



Mime
View raw message