In the past, Sergey has proposed several times getting a Madagascar application for the Google Summer of Code (GSOC).
I do not know about other people's reasons, but I refrained from making suggestions because I had doubts about the chances of success, due to the extremely high specialization of Madagascar, and the fact that GSOC tends to sponsor projects with wide applicability.
Madagascar attempts to provide a complete technology solution for the seismic imaging researcher, and is quite good at that. It is of course extensible to other applications, but most people who do not need the complete Madagascar stack (being either outside the field, or non-researchers) have difficulties understanding the parts and separating only what they need. Needing resources, the Madagascar project finds itself oscillating between:
- trying to expand its scope to fit as many needs at possible (only to discover the increased complexity, fragility and number of dependencies that come with that), and
- focusing on its highly specialized task that it does well, but then discovering that the number of seismic imaging researchers is incredibly small, and how that limits resources seriously.
There is however a deep core concept of Madagascar that has a very wide applicability: the fact that the RSF data format is an out-of-core extension of arrays in memory. Combining together Madagascar programs through a shell or Python script is essentially the same thing as writing a compiled program that calls procedures to act on arrays. It works on datasets too large to fit in memory, but small enough that it is not necessary to transition to a flow-based architecture, in which the memory is allocated only once, and subroutines called successively to act on it. It has its own niche.
How about then, proposing a GSOC project for 2012 to create Madagascar wrappers for the GNU Scientific Library and/or for ATLAS? With OpenMP threading and parallel I/O, to fully use the power of modern multicore architectures. That would be of immediate interest to a very large number of people. So large actually that it may be the case to spin this off as a separate sourceforge project -- depending only on the rsflib I/O core. Then we'll let the mathematicians take care of that project, and as a bonus, we will be able to use the already-existing GSL/ATLAS documentation to know what the similarly-named driver programs are doing! Double bonus, we may get to get rid of some of the current programs which duplicate functionality existing in widely-used packages. Triple bonus, this may lead some people to write Python scripts instead of monolithic driver programs, and this is a Good Thing.