[Mapserver-dev] MapServer CVS access and long term support

[Mark Cave-Ayland]

> -----Original Message-----
> From: mapserver-dev-admin at lists.gis.umn.edu 
> [mailto:mapserver-dev-admin at lists.gis.umn.edu] On Behalf Of 
> Daniel Morissette
> Sent: 05 August 2004 19:52
> To: mapserver-dev
> Subject: [Mapserver-dev] MapServer CVS access and long term support
> 
> 
> The email about the mapmygis.c patch that was sent a few 
> minutes ago on 
> this list brings up an issue that is getting more important as more 
> developers are contributing to the software: long term support. It's 
> normal for people to come and go, that's life, but we need to 
> make sure 
> we don't end up with too much orphan code with no active maintainer.
> 
> I think that if you get CVS commit privileges then you also 
> have to make 
> a committment to supporting your contributions in the long run and/or 
> fixing any side-effects they may create. You also take responsibility 
> for anything you commit to CVS on behalf of someone else 
> (i.e.patches). 
> If for some reason you cannot continue to support your code then you 
> should find someone to take over responsibility for it. If 
> nobody wants 
> to take over responsibility for the code then you have a serious 
> problem. You cannot just expect that the other developers 
> will grab all 
> the lose ends if you walk away, we're all busy enought already.
> 
> What do you think? Is this asking too much from developers 
> before they 
> are allowed to contribute? I think we should have a page 
> somewhere that 
> explains what the rules are for contributing to the software and this 
> would be one of them.
> 
> Daniel


Daniel,

Having worked on many open source projects in my time, there is no
simple solution to the problem of orphaned code. Given that most
contributors to the code are volunteers who offer their time freely when
they can (and not able to work on it full time), I think this would put
off a lot of people who would otherwise like to contribute new features.

It would be ideal for developers who leave the community to announce via
their intention through the mailing lists so that other people who feel
they could fill the role can offer their help.

What seems to work well with other projects is to break the project into
individual modules and list the maintainer for each module along with an
indication of its status (i.e. whether it is being actively supported or
not). If the developers propose that a module should be removed, then
this should be emailed to lists - either someone will step up to look
after the module or it will be removed. The beauty of open source, of
course, is that if someone wants to resurrect the module in the future
then older versions can be found in CVS or previous release tarballs, so
even if a module is removed from the source, the overall loss is
negligible.


Kind regards,

Mark.

---

Mark Cave-Ayland
Webbased Ltd.
Tamar Science Park
Derriford
Plymouth
PL6 8BX
England

Tel: +44 (0)1752 764445
Fax: +44 (0)1752 764446


This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender. You
should not copy it or use it for any purpose nor disclose or distribute
its contents to any other person.