Re: [guppi-list] Re: use of GSL in guppi

["Asger Alstrup Nielsen" <alstrup diku dk>]

> I know there exist a lot of scientific related software, so why create a
> new one? Because I think we can make it better if we integrate 
> 
> 1.) powerful CORBA services to allow all other libraries and
>     applications be used from within "_GNU Science_" and to hide
>     different implementation details from the user.
> 2.) provide a "Visual Prototyping environment" 
> 3.) support different programming languages
> 4.) use glib as a basis for common data structures
> 5.) use GTK+/Gnome as a highly sophisticated development environment
> 6.) try to attract other scientific projects to include their code
>     
> Naturally everything would be released under the LGPL to have as much
> feedback as possible from commercial and universitary institutions.
> 
> So, what do you think?

I don't want to sound overpessimistic, but I fear that this is too ambitious,
and you run the risk of killing the project because it's more than we can
handle initially.

IMO a better approach for a young project is to start with more modest goals
and fulfill those.  Once you have something good running, you will attrack more
people to contribute to the project, and it will slowly grow from there.  If it
is a success, it might explode at some point.  But it won't explode from
nothing.

For a starting project, I think that it is more important that the project gets
positive attention rather than boast high ambitions.  Compare the two different
scenarios (in both I exagerate to make my point more clear):

1) We have very high ambitions and want to make the all-killer application for
scientific use.  Therefor, we want to use the latest technology for everything.
 We want to use Corba to tie everything together (not a bad idea), but before
this happens we have to work a lot on GSL to make it object oriented (maybe not
a bad idea either).  Of course, we want this to be LGPL, so we have to convince
the GSL people to change the license (not a bad idea), and this seems feasible.
 We also want to use the data structures from GLib, so we have to rewrite
everything to use that (that's a bad idea IMO).  Also, we want to support many
programming languages, so we have to use a free and efficient Corba
implementation that allows this.  Since this is non-existant at this point in
time, maybe we could give a hand with Orbit.  Or maybe we should use SWIG
instead.  However, SWIG is undergoing a rewrite at this point in time, and the
improvements they are boasting are worth waiting for.  But maybe another
release won't happen within the next year.
So we will start focusing on providing a visual prototyping environment,
probably using some interpreted language.  We have to go shop around for such a
creature.  Of course, using Fortran would bring a lot of benefits because of
the huge existing base of scientific Fortran code, but did anybody hear of a
free Fortran interpreter?  Hmm, maybe we could get somebody to do such a thing.
 Maybe we should use a different language instead, Python is a nice one.  But
since we want to use GTK+/Gnome, we have to get the Python GTK+/Gnome bindings
done.  Since GTK+/Gnome is a moving target that takes quite some time, but of
course it is feasible.  And while we do all this (how many people are we?), we
have to attract people from other scientific projects by demonstrating the nice
ideas we have.

Consider the alternative approach:

2) We have modest ambitions initially.  We start out with a small, but clean
and extensible code base using common data structures and well known
algorithms, and stable libraries.  On top of this, we build a nice little GUI
and take care that the basic functionality is there.  Then we make a release,
maybe not too stable, but never the less good enough to show the world what we
are planning to do. A few hackers pick it up and start tickering with it
because they need a feature for their home assignment the next day.  They send
in a patch, and the next week a new more stable release that compiles on three
more platforms is done with a few new and useful features that solve real
problems real people had.  At the same time, more and more people subscribe to
the mailing list, and the patches start flowing in from different parties. 
Somebody had written a symbolic equation solver as a school project, but don't
want to start a new project.  Instead, she will spend a week plugging it into
our project, and the leave it at that.  But since the system is useful, other
people will mend out the bugs and clean it up to be really useful.  The program
slowly grows, but constantly gains momentum because people can see that things
are happening.  At some point in time, we'd have to switch to CVS because the
maintainer can't handle all the patches, and I think you get the general idea.

IMO it is more important for a young project to gain momentum than providing
everything in the first release.  This is done by frequent releases such that
the outside can see that things are happening here.  There are so many
different projects around, and most of them have something good in them, that
it is important to profile against all.  And the best way to profile oneself is
to show that the project is alive:  Frequent releases and useful improvements
in each one.  In short:  To provide people with the first datapoints from which
they can extrapolate into the future and by that see that this is the project
to cling on to.

Of course I exagerate a lot in my description, and I'm not trying to put you
off from trying.  I just want to warn you that you might risk using a lot of
energy on things that don't really get you anywhere.  Focus on the problems at
hand, and solve those.  Maybe you would have to rewrite the code base at some
point because the original design starts to show it's shortcomings, but
hopefully, the project will have obtained so much momentum that a stable core
of developers will undertake and *succeed* in this project.
This is the way the succesful open source projects of today have been doing it.
 And they have demonstrated that this development model is succesful.

Greets,

Asger Alstrup