xml-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dirk-Willem van Gulik <di...@covalent.net>
Subject Volunteers for the PMC
Date Wed, 07 Mar 2001 01:29:51 GMT


Thanks everyone - here is the promised cut of volunteers ! All mistakes,
ommissions etc are mine. Let me know and I fix them.

.    Sam Ruby 
.    Davanum Srinivas 
.    Ted Leung 
.    Matthew B Brandabur
.    Kelly A. Campbell
.    Rajesh Thiharie
.    Shane Curcuru  
.    Ram Mareddy 
.    Dirk-Willem van Gulik
.    Arved Sandstrom
.    Tinny Ng
.    Luc Chamberland

As to what next - It is good to see that we have some debate over this. So
I'll try to help out by summarzing what I hear in a separate message.


Volunteers for the next PMC of the XML projects:
		(in order of appearance in my inbox):

Key to the entries:
1.   Name
2.   Apache Affiliation
3.   Professional affiliations when considered relevant
     relevant or if the need is feel to disclose them.
4.   The beef - What you bring to the table

1.    Sam Ruby 
2.    Committer xml-soap/xml-axis.  Infrequent committer to
      xml-cocoon.  Jakarta PMC Chair.  PHP Group Member.  Apache Member.
3.    IBM
4.    Focus on inter-subproject versioning and compatibility issues.

1.    Davanum Srinivas (nickname: dims)
2.    Working on Cocoon2 (C2) Apache project since last Oct/Nov
3.1   Employee of Computer Associates (working on Jasmineii - http://www.ca.com/jasmine) 
3.2   FAQ Manager of JNI-FAQ at jGuru.com (http://www.jguru.com/faq/JNI)
4.1   Integrated Xalan2's TRaX into Cocoon2(Now C2 can use SAXON too)
4.2   Integrated Batik into Cocoon2.
4.3   Looking into Turbine integration with C2 right now.
4.4   Occasionally submitted patches to Xalan2 and a couple to Xerces.

1.   Ted Leung 
2.   Committer for Xerces-J, Member of current XML PMC.  
3.   I work for myself as an independent consultant.  Previously CTO Enkubator,
     LLC (launching Internet startups atop Open Source platforms).  Previously
     Technical Lead IBM XML4J (became Xerces1 code base).
4.   I've spent some time recently trying to help the Xerces-J project get a
     little more organized.  I'm willing to do "scut work" like editing the
     website, maintaining bugzilla, etc.   I am concerned about version lock
     problems, and API consistency across the projects.  I'd also like to see
     the "infrastructure" projects (Xerces, Xalan, FOP, Batik, SOAP) move in
     the direction of an application server stack.  I think that having a small
     set of design points that the various projects are striving for will bring
     more unity in design and community.  As an example Xerces-J is
     consistently torn by people who want to turn it into an engine for writing
     incremental XML editors and people who want to turn it into a component
     suitable for production level messaging.  Often the goals of these two
     camps are opposed.

     One last thing.  Jim Allchin's recent comment about Open Source stifling
     innovation seemed particularly relevant to me.  In the past the part of
     the charter that referenced XML standards has been used as a way to keep
     features out of projects and projects out of xml.apache.org.  I think it
     is very important that the XML project be a place where innovation is both
     allowed and encouraged.  Our best example of this is Cocoon.  Jakarta has
     a few examples:  Ant and Struts.  I want to see our projects continue to
     innovate in similar fashion, so I want to be sure that whatever we do to
     the charter still allows for that.

1.   Matthew B Brandabur
2.   Working on the Oracle Internet File System which ships with Apache and
     working on a proof oc concept project to integrate IFS with Cocoon/Batik
3.   Staff member of Oracle
4.   I have been following the progress of the cocoon project for several
     months, and I would like to be involved. I am not primarily a coder,
     however. I am in charge of documenting Oracle's Internet File System for
     developers, so I have lots of experience writing for developer audiences.
     I get lots of hands-on experience with our API, including writing sample
     code and testing our example projects, so I am comfortable with enterprise
     Java and constantly practicing on my own.

1.   Kelly A. Campbell

2.   Committer on FOP. I'm also the lead developer on the Merlot XML editor
     (www.merlotxml.org) which is not an Apache project, but is released under
     a similar license. I also use a good amount of the Apache projects, XML,
     Jakarta, and otherwise, and have submitted bug reports and patches for the
     projects I use.
3.   I work with XML and Java technologies for ChannelPoint, Inc. The spectrum
     of how I use it ranges from producing basic documentation via
     XML/XSLT/XSLFO up to full web applications and frameworks.
4.   I'm interested in most aspects of XML, XSLT, and XSL FO, from development
     to a user's standpoint. I have 4 years Java experience, and almost 2 years
     of experience with XML and XSL. I'm interested in the interactions between
     our projects and the build processes Sam Ruby is working on with Gump. I
     would like to work towards standardization of runtime linking and
     deployment of java projects (using XML, Ant, and some of the Gump work)...
     sort of like a gnu autoconf/linker for Java. I'm also very interested in
     helping standardize how Apache projects test their code, either via JUnit,
     or another tool as Scott Boag suggested on this list a while back.
     Another thing I would like to promote as XML projects is UI tools for
     working with XML, XSL, etc. 

1.    Rajesh Thiharie
2.    Working on a proof of concept project that uses EJB - XML - Cocoon
      and Servlets/JSP
3.    Work for Aithent - a software development company based otu of New Delhi,
4.    I have been using Xerces - Xalan for over six months now and Cocoon for
      four months Am very interested in XML overall.  

1.    Shane Curcuru  <shane_curcuru@lotus.com> <curcuru@apache.org>
2.    xml-xalan committer, daily xml-xerces, xml-crimson, and jakarta-ant user
3.    IBM Research employee (transferred from Lotus recently, hence the email
      addr).  Note that although I do work for IBM which ships the LotusXSL
      processor (a thin wrapper on top of Xalan, mostly) I definitely feel I
      wear separate hats as Apache committer and IBM employee.  I focus my
      work on Xalan towards making it the best XSLT processor out there, and
      to be a 'good citizen' project in the Apache community.
4     Lead Java API tester and test automation creator/maintainer for Xalan
      for the past 2 years; see http://xml.apache.org/xalan-j/test/ I've been
      a Software Quality Engineer for 12 years on multiple Lotus projects
      including being the 1-2-3 database, cell engine and UI components
      testing and automation leads; was the 1-2-3 build engineer; and was the
      eSuite Automation Coordinator, where I implemented a common distributed
      testing system and trained the eSuite QE team to write their own
      Java/JavaScript automation (including many without coding experience).

      I could bring experience at helping drive more guidelines and standards
      for xml.apache.org project's organizations.  Although I usually hate to
      admit it, I can help get projects more on board with a cross-project
      build system like Sam Ruby's Gump/Alexandria/whatever we call it now.
      I'd also like to help implement Scott's idea of having common testing
      infrastructure, although I believe this will be a significant effort to
      fully implement.  We'll need both the tools to enable common automation
      as well as guidelines for how/what to test, and really good
      documentation on writing good tests.  I have to admit that one of the
      challenges for me will be applying my skills from large corporate
      projects into the Apache open source model - where you have few, if any,
      dedicated 'test' engineers, and everyone's a volunteer.  One very
      important thing will be to make our testing story both make sense to
      people and be *very* easy to implement for the average developer.  Oh,
      and a third area I'd like to focus on is improving and coordinating the
      overall xml.apache.org documentation set.  I think we do have very good
      doc now; just long term I think we need to provide even better
      documentation to allow a wider audience to quickly pickup and use Apache

1.    Ram Mareddy 
2.    I am currently working with xerces-c. While I don't have any formal role
      with Apache, I used that code a lot.
3.    Siebel Systems; Architecture Specialist (/Software Engineering -- the
      role is slightly changing). I have about ten years of industry
      experience plus the other usual qualifications like MS in Computer
      Science; along the way worked with several products, languages, and
      databases. Also, involved with the bay area Software Development Forum
4.    I work with the Connectors group. This group builds connectors from
      Siebel to all the popular ERP/other packages (this list is constantly
      growing). All this EAI infrastructure is solidly based on XML and the
      dll's from the Apache effort. So, I can provide a very unique
      perspective from the sophisticated use of these technologies. Internally
      I have an opportunity deal with a variety of departments in this
      context: from Engg to QA to tech pubs to prod mktg to services on a
      constant basis.

1.    Dirk-Willem van Gulik
2.    ASF Board member, httpd committer
3.    Not relevant - but disclosed as: VP of R&D at Covalent Technologies; a
      hybrid opensource/commercial product company that supports and
      builds upon ASF technology to make it enterprize ready.
4.    Having seen the birth of this XML and the troublesome path of
      its PMC I'd like to be part of the efford which matures this
      group into long term stability - and I'd like to help us find
      a balance and and environment in which we can work on code, hack
      protocols and standards without an overly burdensome or top
      heavy organisational framework - whilst still addressing the worries
      with cross project versioning, release methods and our ongoing
      interwovenness with other ASF projects such as java/jakarta.

1.    Arved Sandstrom
2.    FOP committer, ASF member
3.    Supportive employer (e-plicity, Halifax, Nova Scotia); no conflicting
4.    I am currently immersed in XML and Java, both here and at work. I'm very
      strongly oriented to problem-solving; my background is physics and
      scientific programming. So it's not so much XML that interests me, as the
      fact that I think it's a great data format, and I'm a data formats
      aficionado. I support the use of Java not because I love it (I don't) but
      because it is a fine GP open-source programming language. I started out
      with XML through XML::Parser porting work, back around the 2.16 version,
      both C and Perl.  
      I'm interested in describing and documenting the product/project/software
      lifecycles that we have here, with a view to understanding what we do
      well, what we don't do so well, and helping get improvements in place.
      I'm a processes guy, and have both experience and formal background in
      software engineering as opposed to programming alone. I share the
      perspective that sees us solving various problems - infrastructure, web
      publishing, print publishing, etc - and would like to explore how we can
      orient our process focus and user experience (buzzword alert!) towards
      our solutions to problem categories.  
      I'm highly cognizant that we also have open-source goals and open-source
      conditions that do not apply to business - continuous user input and
      promotion of our community are just a few of those. I think those are our
      strengths, and I think it would be really neat to capture and formalize
      (to some degree) what it is that we do (and can do) under these
      conditions. So I see part of XML Apache (projects and PMC) innovation as
      being innovation in process.  
      As others have stated about themselves, I'm not afraid to roll up the
      sleeves. I like testing (yeah, there are a few of us weirdos),
      documentation (getting worse...), and I have been known to code Webbish

1.    Tinny Ng
2.    Committer for Xerces-C
3.    IBM XML Parsers Development
4.    I have been involved in the Xerces-C project for over six months, and am
      one of the primary Xerces-C developer.    Dedicated to bring improvement
      to the Xerces-C project such as introduced the use of  Bugzilla, improved
      the Xerces-C website and its documentation.... etc.  Current ambition is
      to bring Schema support to Xerces-C.   I am also a user of Xerces-J,
      Xalan, Cocoon and FOP, and am very interested to work on the bigger

1.    Luc Chamberland
2.    Subscriber to xerces-j and xerces-c and parser licensee.
3.    IBM, XML Parsers Development Manager (IBM XML4J and XML4C)
4.    I have an extensive background in project management, and would like to
      bring those skills over to the XML sub-projects so that we can improve
      our planning, bug tracking, and coordination amongst the sub-projects. I
      currently provide similar project management to XML parser development
      occuring within IBM.  I answer a lot of questions pertaining to licensing
      of Apache technology by IBM, and would be happy to do same for Apache.

      I'm particularly interested in working with the other sub-projects to
      ensure they work well together, and maintain some level of application
      agnosticism.  Some of the closed source efforts in the industry are
      putting out compelling suites of XML tools/runtimes, and our community
      needs to better ensure our tools compliment one another. (I concur with
      Ted on the need for common design points and a technology stack.)

      As a technical writer for several years, I'd like to lend my help to
      improving our overall doc strategy, particularly by focussing on "big
      picture" scenarios that illustrate how the various sub-project
      technologies work together.  I've written similar articles for the Java
      Developer's Journal and IBM publications.

View raw message