fenics team mailing list archive

["tomtzigt" <tomtzigt@xxxxxxxxxxxxxxxx>]

Rob et. al.

  Coming from the commercial world, this last paragraph hits home: you have
to solve people's problems for them to come your way. Even when you solve
their problems, you still need to 'grease the skids' to win them over. The
best way that I think open source software can do this is by having
well-defined and complete, working examples for key problems. It needs to be
interesting, but small enough so that a prospective 'client' can see what is
going on. This stuff needs to be perfect: I have a 10 minute rule for open
source software: anything that doesn't start working within 10 minutes, I
will ignore. 

  What I have found is that if the key examples have sufficient appeal,
others will jump in and smooth the rough edges, if there are any. In CMM,
the application stack is sufficiently complex that you need a handful of
very different software engineering disciplines to build out the whole
stack. I am talking here about CAD, 3D graphics, statistics, large scale
software development, and QA, and it is unlikely that a fully integrated
application can materialize without bringing in folks that have
fundamentally different views of the world. Divide and conquer is the key
here, but what components contain, and how components need to be composed is
a very difficult sw engineering problem, that will have as many answers as
there are sw architects.

  Another sobering statistics is that for every line of code in the main
branch there are three lines of code needed in the infrastructure (build
system, regression system, QA, release engineering, etc.). The bigger your
system gets the more inertia the support system exerts on the core. Given
these statistics, and limited resources, you are effectively forced to
concentrate on doing few problems well. But you can expand your world of
influence by 'solving' integration problems with other efforts. This has a
secondary benefit and that is that trying to solve the integration problem
you get a close up view of another 'interpretation' of the same problem:
both in terms of software engineering as well as in mathematics. This
experience is very valuable and is gained in much less time then if you had
to do the whole package yourself. As the saying goes: A fool learns from his
own mistakes, but a genius learns from mistakes other people make.

Theo

-----Original Message-----
From: fenics-dev-bounces@xxxxxxxxxx [mailto:fenics-dev-bounces@xxxxxxxxxx]
On Behalf Of Robert C. Kirby
Sent: Monday, September 26, 2005 2:11 PM
To: Anders Logg
Cc: Kevin Long; karpeev@xxxxxxxxxxx; Discussion of FEniCS development
Subject: Re: [fenics-dev] Re: FEniCS

>
> My point on this is that it is easier to create new standards with
> small, flexible components with limited scope. (Which does not mean we
> can't bundle things and distribute as a whole.) FIAT is one good
> example of this.
>
> Maybe (probably) we won't be able create one big system that everyone
> uses, but some of the components we develop in the process may well
> become standard and it's difficult to say at first which components
> will gain acceptance.
>

But by whatever definition of "standard" we use, we need to have  
those small flexible components and/or a system be adopted by a  
signficant user base outside of our immediate circles.  These means  
actively seeking out users and peddling our wares to high-impact  
application groups.  Setting a standard is an active, outward  
reaching activity.  I'm saying we can't just be passive and hope  
people come to us and see the light.



Rob Kirby

"Mathematical software should be mathematical."




_______________________________________________
fenics-dev mailing list
fenics-dev@xxxxxxxxxx
http://www.fenics.org/cgi-bin/mailman/listinfo/fenics-dev