xml-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ted Leung" <twle...@sauria.com>
Subject Re: Help wanted: more qualified developers
Date Sun, 01 Apr 2001 22:27:28 GMT

----- Original Message -----
From: <Scott_Boag@lotus.com>
To: <general@xml.apache.org>
Sent: Friday, March 30, 2001 8:09 PM
Subject: RE: Help wanted: more qualified developers

> Matthew Brandabur <matthew.brandabur@oracle.com> wrote:
> > The subject line of this thread sort of backs me up.
> Matthew, sorry, you are right.  Should have been: Help wanted: more
> qualified contributers.
> Arved Sandstrom <Arved_37@chebucto.ns.ca> wrote:
> > I would go so far as to say that _all_ of
> > the FOP committers are part-time volunteers. In addition, I think it is
> > worth mentioning that all of the committers and probably most (if not
> all)
> > of the most knowledgeable developers are heavily engaged in real-world
> > stuff, and our pace of development is suffering.
> There seem to be at least several different types of contributers:
> 1) Bug fixers -- people who discover defects in the course of using the
> product.
> 2) part-time volunteers.
> 3) full time contributers who are paid for doing working on the project.
> One problem with full time contributers is that they can overwhelm
> part-time volunteers, and make them feel like they can't keep track of
> mail, code, etc.  But, as Arved said, if you only have part time
> contributers, it's hard to maintain the pace of development that we all
> want and need.  Also, if a project has several full time contributers in
> paid by XYZ company, another company that may only have one or two
> part-time contributers may feel like XYZ company is driving the project
> only for their own purposes.  Also, if several paid contributers work in
> the same office, they probably talk a lot about design issues in the
> hallway (i.e. offline), and get in the habit of exchanging private email
> know this happens a lot with the Lotus Xalan team).

I think that there are some things that could be done to improve things
between full-time and part-time contributers.   A lot of those things
extra effort on the part of the full-timers.  I know that can be difficult
justify when the company paying the full-timers has specific feature
deadlines that it is trying to acheive.

> One thing to think about is how to get companies that are using the
> software to contribute a full time contributer or two.  Unfortunately,
> small companies, and quite a few big ones these days, can't afford this.
> It would be interesting to consider some sort of co-op type thing where
> several companies could pool some funds.  (I'm sure Brian has thought of
> this at one time or the other).

I'd like to see us expand on this idea some more.  In my case, I am the
owner of my own company.  Assuming that I can meet my financial
objectives this year, I have plans to set aside substantial amounts of time
to work on ASF related stuff.  So assuming that things go according to
plan, I'll be doing this on a small scale - except that I won't be able to
myself to do this full time.

> "COFFMAN Steven" <SCoffman@COVANSYS.com> wrote:
> > Not to be overly obvious, but useful contributions that don't require
> > familiarity with large amounts of code are the most common entry of
> > into dev.
> Right.  In Xalan we have several extension mechanisms which is a really
> good place where developers can write a small code module that can do
> really useful things.  We also tried hard to localize the main code
> packages, so to debug a problem your knowledge of the whole code base
> be limited.  We only succeeded at this to a point.
> I am told that the XercesJ2 people have tried hard to get more open source
> developers involved by doing the same thing: sending out a list of things
> that people could contribute that would be fairly contained.  My
> understanding is that they are pretty frustrated that they have been
> unsuccessful.  After everyone got so hot and bothered over how important
> was to refactor the code into XercesJ2, it's pretty sad that they don't
> have more contributions from contributers.

Here's my assessment of the current state of Xerces-J.   Recently, we've
tried to adapt some ideas from Jakarta in order to open things up.  On
X1, we've done the 1.3.1 release based on a publically available release
 - prior to that, releases happened when somone at IBM decided to pull the
trigger, often with no warning.   We're working on the plan for 1.4 right
The point of the release plan is to telegraph the set of features and defect
to be put into the next release.  It can also serve as a mechanism that
people to find out what work needs to be done, and give them an opportunity
to volunteer, or add features to the list.   We are still learning how to do
and I think that there is still some room for improvement here.  But we're
moving in a good direction.

As far as X2 goes, there are a number of areas of the design which are still
wide open, and we have had a limited but growing amount of participation
from people outside IBM.   This is also an improvement.  We haven' t really
reached the point where a lot of actual code work has gone on in the X2 code
base, with the exception of some cool stuff on parser configurations.  My
is that we will have learned a bunch from the X1 release process that we can
put into practice by the time we're really ready to get going on X2.

One more bit on this:  Having been both a full-timer and now a part-timer, I
that it's easy for the full-timers to forget that the part timers are out
there or to
have an idea of things that woulde help.  I spent a lot of time last year
using hot
air to try to improve the situation by beating on people.  It wasn't until I
saw some
things that other projects were doing that I found something practical and
that we could try in Xerces-J.  One thing that I believe would help Xerces-J
at least,
would be to temporarily have some portion of some full-timer's time
allocated to
integrating new developers (both new full-timers, as Scott is hoping for,
part-timers).   I know that this is a challenge for the folks working in a
delivery environment, but I believe that the payback in increased developer
participation would outweigh the initial effort.   One notion that I'm
fond of is something that is done on the Debian distribution of Linux.
that want to become Debian developers are assigned a mentor who helps
them learn the ropes of the Debian packaging system & policy, etc.   I
if we could have some kind of arrangement like that.  I'm a little wary of
it a formal thing, but I've had correspondence from people that leads me to
that having a known person that was the "welcome wagon" for new developers
would help them ease into the project.

> All challanging problems.  I hope folks who are using the xml.apache.org
> software in commercial products will talk about some of this internally.
> believe that the only way Open Source projects will have true long range
> health is to have a true cooperative between both multiple companies and
> individuals.


In case of troubles, e-mail:     webmaster@xml.apache.org
To unsubscribe, e-mail:          general-unsubscribe@xml.apache.org
For additional commands, e-mail: general-help@xml.apache.org

View raw message