Mailing-List: contact general-help@xml.apache.org; run by ezmlm
To: general@xml.apache.org
Subject: observations, comments & submission
Message-ID: <983665894.3aa18ce67c738@mail.parducci.net>
Date: Sat, 03 Mar 2001 16:31:34 -0800 (PST)
From: bill parducci <bill@parducci.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
User-Agent: IMP/PHP IMAP webmail program 2.2.4

i have been reading the discussion on this list with much interest and figured
that i would throw in a couple of observations from an 'outsider' (i am not a
software developer, i just try to get big companies to use the stuff you guys
write).  that is not to say that i don't consider myself 'technical', but rather
that i approach these projects in terms of how they meet the needs of my clients
in a broader sense than basic feature set. let's just say i am an
'infrastructure' type.

the following is meant only to provide a perspective that may not normally reach
this group.

<soapbox>
since i have designed and implemented (well i sat around for the first 400 being
rolled out, then left for something more fun :o) a network with 1100
apache/linux servers for a fortune 500 company and am currently working with
ford, gm, chrysler and toyota to develop an xml strategy for their retail
operations, i feel that i can speak with some confidence on what 'business' is
looking for WRT projects such as apache-xml.

first, from my perspective, the idea of rejuvenating the PMC to help guide the
overall presence and direction of the apache-xml project is an excellent idea.
there have been some very good discussions here. personally, i tend to lean
toward the view that this group be more 'business-like' and managerial than
technical. as was stated numerous times on the list, the programming experts
tend not to have a lot of spare time, and last time i checked had little
inclination to work on the 'dry' stuff (which seems to be the case with the PMC
as stated in the original request.)

second, i also agree that this group should be kept small and should have a
chair that ensures that issues remain active until resolution is achieved.  the
latter being vital to the success of the project; i have yet to work with a
group of diverse interests that has succeeded without a chair or director. not
that there need be an enforcer, but project management needs to have a focal
point, otherwise communications will have to be 'broadcast based' (and
experience says that humans tend to have a poor sense of collision detection and
retransmission when it comes to store & forward communications such as in use
here).

third, the 'b word' is unavoidable. forget the direct fiscal references for a
moment, what this organization is about is providing *value*, is it not?  (i
have yet to see a thread where someone posts that he has just finished a really
cool function that does nothing!) i believe that the business model can
successfully be applied to this endeavor by exchanging monetary value with those
aspects (speed/reliability/ portability/features) that are determined to be
benfits of the software as a whole. in other words, i submit that general
business practices are similar to software development (that should earn me a
few flames :o) in that it is a process to achieve a means.

fourth, forget about marketing.  this is not the place to worry about how to get
into corporate america, corporate america knows you are here. what it is waiting
for is a compelling reason to use/discard your technology.  the best way that i
can think of to achieve the former is to continue to improve the product, while
creating a cohesive environment that ensures that all of the projects are
compatible where possible and demonstrate a CLEAR and FOCUSED direction. i
cannot emphasize this point enough.  by and large corporate managers buy
'comfort' and the only way to counteract FUD and ignorance is to make sure that
the path is clear and execute on that plan. this, i believe is the perfect role
for the PMC. 

the PMC, however, cannot acheive this via technical means (the working groups
are there for that). to ultimately be effective in the market, i believe that
the PMC needs to put itself in the place of a corporate IS manager -- sans the
lobotomy -- and think about what it would take to support systems written with a
variety of apache products. at the same time it needs to become the keeper of
the road map so that there is no doubt as to where the project is going.  this
is very differnt from what i have perceived in most development coalitions; it
is doable, but demands a certain level of detachment from the technology.
</soapbox>

that said, i offer my time & efforts to the group. i think my practical
experience in *consuming* open source projects would be a good balance to the 
plentiful software development skills of the apache community as i see here.
finally, i am an independent consultant so i have no pressure to do other than
what i think is right for the group.

if you made it this far, thanks for your time. :o)


b