Open sourcing XP code product

The situation I have here is that I'm coordinating a team of, now 5 people
(plus 1 very part-time XP coach) working on wends creating a software
product using as close as we can get to XP methodology.  So far, we are the
developers and the customer, and the hats don't get switched cleanly all the
time, but we're using TDD, pair programming, and planning with story cards,
fixed iterations, fixed release dates, etc.

Anyway, we decided that due to the ad hoc, volunteer nature of the team, it
would make the most sense to release the product as open source.  That raise
s
a question, though...

It is usual, for open source projects, to accept and incorporate contributio
ns
from anywhere.  That means, however, accepting code that may not have been
written using the same processes for maintaining code quality that an XP tea
m
has.  Even if we choose to insist on code with tests (and of course anyone i
s
welcome to fork the code), we don't know if the tests were written first, or
what kind of test coverage the code has.  It probably wasn't done using pair
or even partner programming, etc.

Have other people faced this issue?  What policies did you come up with?

Thanks,

- Steve J.

On Mon, 23 Aug 2004 06:53:17 GMT, Steve Jorgensen
<nospam@nospam.nospam> wrote:

>The situation I have here is that I'm coordinating a team of, now 5 people
>(plus 1 very part-time XP coach) working on wends creating a software
>product using as close as we can get to XP methodology.  So far, we are the
>developers and the customer, and the hats don't get switched cleanly all th
e
>time, but we're using TDD, pair programming, and planning with story cards,
>fixed iterations, fixed release dates, etc.
>
>Anyway, we decided that due to the ad hoc, volunteer nature of the team, it
>would make the most sense to release the product as open source.  That rais
es
>a question, though...
>
>It is usual, for open source projects, to accept and incorporate contributi
ons
>from anywhere.  That means, however, accepting code that may not have been
>written using the same processes for maintaining code quality that an XP te
am
>has.  Even if we choose to insist on code with tests (and of course anyone 
is
>welcome to fork the code), we don't know if the tests were written first, o
r
>what kind of test coverage the code has.  It probably wasn't done using pai
r
>or even partner programming, etc.
>
>Have other people faced this issue?  What policies did you come up with?

FitNesse is a similar case.  Our experience is that very very few
people contribute.  Those few that do, we get to know pretty well.


-----
Robert C. Martin (Uncle Bob)  | email: unclebob@objectmentor.com
Object Mentor Inc.            | blog:  www.butunclebob.com
The Agile Transition Experts  | web:   www.objectmentor.com
800-338-6716


"The aim of science is not to open the door to infinite wisdom,
but to set a limit to infinite error."
-- Bertolt Brecht, Life of Galileo