[AstroPy] AstroPy Digest, Vol 58, Issue 16

[Tommy Grav]

On Jun 14, 2011, at 2:20 PM, Thomas Robitaille wrote:

>> I believe that was basically the idea of Astrolib -- a place to
>> collect key modules that others in the community would use. Do you
>> prefer the AstroPy name, or a different organization (or management)
>> from Astrolib? Or maybe you're suggesting something new to avoid
>> endorsing one existing effort over another (since there are other
>> libraries doing similar things now)? I'm just wondering what needs
>> doing differently. I know documentation was an issue last year --
>> STScI did set up a Sphinx server, but its presentation is currently
>> a bit rough around the edges. I certainly don't want to stall any
>> discussion or ideas by pushing for one particular thing -- this is
>> just a genuine question regarding what is still needed and why.
> Maybe this is controversial, but I think that no single institution should host or control the package (otherwise it would be as if we are working for free for that institution, who would ultimately get the credit). We should just be a collection of individuals, some working in our spare time, some funded to develop software, working towards a common open source project. By using a distributed versioning system (e.g. git or hg) and a free hosting solution (neutral territory, e.g. github or mercurial) we can ensure that the project will live beyond the funding for any given institution, and the distributed aspect means that if the hosting solution goes out of business, moving to another will be easy. Of course it would still be possible for institutions to support development of that package.

I also think there needs to be a certain control by certain key contributing 
people. One problem seems to be that when people just develop a package
and contribute it to something like Astrolib there is no continuity between
the package and the use of them. I think the strength of numpy is that 
is sprung from the work of a few people and any new developer has to 
adopt a certain style of coding that maintains the package overall consistency.
Scipy seems to be a little looser, but still has some central control by a
small group of developers. I think astropy/astrolib needs something similar,
making it a package in itself, not just a collection of packages gathered from
a wide variety of sources. There has to be a certain focus to make it successful
I think. 

Cheers
 Tommy