[AstroPy] Proliferating py-astro-libs

[Victoria G. Laidler]

Perry Greenfield wrote:
> I wonder if the right approach is that for us a BDFL mainly ensures  
> that all the various projects have consistency of interfaces, approach  
> and such, but isn't worried about designing everything. That would  
> devolve to BDFLs at a second level to take responsibility for more  
> specific areas.
>   
That was in the suggestion Mark posted earlier, which I'm quoting here 
because it never made it into this thread:

Mark Sienkiewicz wrote:
> The most effective approach would require:
>
> - one person willing to coordinate the project -- but maybe as many 5 at 
> most.  (Unless you subdivide the project into independent parts, it 
> doesn't work as well with more.)  Basically, we need a Guido -- he acted 
> as BDFL for python at the request of (and with the consent of) the 
> python community.  He provided valuable organization that could not have 
> existed without somebody working at it.
>
> - some small number of people to act as core developers.  These people 
> design the system and coordinate contributions.  This is also a lot of 
> work, and you're looking for people with software design skills.  Maybe 
> 3 to 10 people.
>
> - a bunch of people willing be contributing developers.  These people 
> contribute subsets.  This is less work than being a core developer, but 
> still a bunch more than hacking together a custom solution for your 
> specific needs and putting it up on your web site.
>
> - users who are interested enough to overcome the learning curve.  Why 
> should I use your simple coordinate transformation when I can write my 
> own faster than I can figure out how to use yours?  But, implement and 
> document enough useful capabilities in your package, and it is worth my 
> time to use them instead of writing my own copy of everything.  
> (Remember:  The user of your package only knows what you tell them -- as 
> far as the user knows, anything that isn't documented doesn't exist.)
>
> This rough model is typical of successful free software projects.  Think 
> of examples like python, perl, linux, GCC, gnuplot, freebsd, or gnome.  
> They all work this way.
>