Can we learn something - or is it just uncontrolled hacking?

The organisers have contacted some of the people behind several Open Source Software projects to interview them about how they handle changes to their software.

The findings from these interviews will be presented in a summarised way to spark off the discussions.

We expect a very active and partecipating audience to stimulate the discussions. So if you have any experience from Open Source or distributed development, please prepare a short position statements. If you do not have any experience, please prepare a short position statement expressing your opion about change management aspects in that context.

Goals: To answer the following questions:

• what are the special characteristics of OSS development?
• how do they co-ordinate the contributions of many people?
• what are good and bad practices in current OSS/CM?
• what is better - a good process or a good tool?
• can we teach them anything?
• can we learn anything from OSS/CM?
• do the success stories from OSS/CM transfer to conventional SCM?

Programme:

16.30-16.50: Presentation of results from interviews
16.50-18.30: Position statements and discussions

Some questions/answers from the interviews:

> > - How many developers are contributing to the project?
>
> 350 have directly access to CVS.  An estimated 600 other people have
> submitted patches..

> > - In which way are contributions tested?
>
> We don't have a formal testing procedure.  The code is simply used..
> if it works, great.  If it doesn't, it is fixed.

> > - Are the developers divided into groups/files according to some strict
> > scheme or is it more common that many people work on the same files?
>
> Certain people tend to gravitate to specific areas.. but there is no
> strict scheme at all.  Anybody can go anywhere and do anything as long
> as they do a good job... Nothing in XXX is strict :-)

> > - Can the coordinator(s) be a bottleneck? Does the way of handling
> > contributions scale with more people?
>
> No, as I said, we let most people apply the changes directly.  We have
> removed the bottleneck in most cases because of this.