Re: Help wanted: more qualified developers

[Ted Leung <tw...@sauria.com>]

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


>
> Matthew Brandabur <ma...@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 <Ar...@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
it
> 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
(I
> 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
involve
extra effort on the part of the full-timers.  I know that can be difficult
to
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,
many
> 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
fund
myself to do this full time.

> "COFFMAN Steven" <SC...@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
users
> > 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
could
> 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
it
> 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
plan
 - 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
now.
The point of the release plan is to telegraph the set of features and defect
repairs
to be put into the next release.  It can also serve as a mechanism that
allows
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
this,
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
hope
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
think
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
constructive
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,
and
part-timers).   I know that this is a challenge for the folks working in a
product
delivery environment, but I believe that the payback in increased developer
participation would outweigh the initial effort.   One notion that I'm
particularly
fond of is something that is done on the Debian distribution of Linux.
People
that want to become Debian developers are assigned a mentor who helps
them learn the ropes of the Debian packaging system & policy, etc.   I
wonder
if we could have some kind of arrangement like that.  I'm a little wary of
making
it a formal thing, but I've had correspondence from people that leads me to
believe
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.
I
> 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.
>
Agreed.

Ted


---------------------------------------------------------------------
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

Re: Help wanted: more qualified developers

[James Melton <ja...@cylogix.com>]

Ted Leung wrote:
> 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

This sounds so cool to me. 

I don't think it needs to be as much work as it sounds for the full-time
people already involved. What if you had a new developer assigned to
your team who worked only one day a week (or who worked very slowly :) 
They wouldn't necessarily take up that much of your time. You just need
to pull off what seems to you like a relatively simple problem and say
"Here you go". Eventually the new person comes back with a solution, and
progress continues. I think this model could work for non-developer
contributors as well. It relies on someone familiar with what needs to
be done taking time to pass that work on to someone else.

Am I being too idealistic?

Jim.


____________________________________________________________
James Melton                 CyLogix
609.750.5190                 609.750.5100
james.melton@cylogix.com     www.cylogix.com

---------------------------------------------------------------------
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