[AstroPy] AstroPy Digest, Vol 58, Issue 16
jturner at gemini.edu
Tue Jun 14 16:36:55 EDT 2011
Sounds like Torvalds and the Linux kernel subsystem maintainers.
Obviously that has worked for them, but Linus has always had the
ultimate editorial control.
On 14/06/11 16:32, 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.
> On Jun 14, 2011, at 4:17 PM, Tommy Grav wrote:
>> On Jun 14, 2011, at 3:57 PM, Perry Greenfield wrote:
>>> You must remember that it was easier with these two projects,
>>> particularly numpy. numpy is essentially a pretty clear integrated
>>> whole with a series of previous owner from which it was derived. At
>>> one point it was developed primarily by Jim Hugunin, then we did
>>> numarray, then Travis essentially merged the two.
>>> Not quite so simple for scipy, but scipy started out mostly as
>>> gluing together existing libraries. As such, there weren't a lot of
>>> architectural decisions to make about interfaces (and I think some
>>> complain about the lack of consistency still as a result). These
>>> involve many, mostly mature, libraries that had their own primary
>>> developers (and still do for the most part).
>>> In this case, we are talking about remaking much of the
>>> astronomical software from scratch with many different kinds of
>>> potential users. So I think in many respects, this is much more
>>> difficult than either numpy or scipy had to deal with in
>>> organizational terms.
>> No question it is more difficult, which I think is one of the major
>> reasons current efforts have
>> not managed to gain more traction in the community. I think some
>> general guidelines before
>> packages are accepted into the library is needed, and that takes
>> some leadership by the most
>> dedicated of the developers (and also the bravery to say no to
>> packages that have a coding
>> style that clashes to much with the main part of the package). But
>> no question this is going
>> to be a challenge and lots of work and time to get to the point
>> where numpy and scipy are
>> AstroPy mailing list
>> AstroPy at scipy.org
> AstroPy mailing list
> AstroPy at scipy.org
More information about the AstroPy