[FRIAM] Open Source Project?

[Marcus G. Daniels]

Owen Densmore wrote:
> But the bigger picture of my wish is precisely that: we need to build  
> a far broader set of easily integrated tools for ABM.  Far more  
> important is the synergy amongst them than their ease of use.
>   
My experience with Swarm was that it was not easy to do in an 
incremental fashion or with a typical open source approach.  Neither 
newcomers nor theory people want to concern themselves with the details 
of the technology, and these are the people measuring your progress in a 
public/academic funding type scenario.   My impression of toolkits that 
have followed is that there still isn't a great deal of community 
support at the level of programming.  This is not to say projects 
haven't succeeded, but they've succeeded with focused organizational 
support, not because of loose community cooperation on improving software. 

Still you can be sure that GIS-oriented static modelers will want to use 
their familiar ArcView package, and if they can't they won't get that 
involved in dynamical modeling.  I'm sure we could make a long list of 
important technologies to support from an ABM toolkit, but it takes a 
lot of user support to get non-programmers to explore these synergies, 
even if it really isn't that hard.   It's quite possible to work very 
hard on middleware, and then have a large community of people completely 
unwilling or unable to get off the ground with it, even with intensive 
support.  (E.g. in Swarm the ability to have the scheduler issue COM 
calls or call JavaScript functions -- that stuff was effectively 
middleware and had no immediate payoff except for another programmer to 
do further development work.  The problem is that all development you do 
on a shoestring budget usually needs to become visible relatively quickly.)
 
In spite of all this, I still think technology integration is one of the 
most important things.    Software packages have to evolve with the 
times and build on other packages, or else user perception will kill 
them, if not maintenance burden. 

Another important thing is to provide leadership in new directions.  
Scientists are comfortable with this way of doing business and I think 
it is more fun anyway.  One way a small open source project could do 
this would be to explore a more mathematically tractable language that 
at once also provided all new capabilities.   The two new capabilities 
I'd like to see are 1) evolvable agent rules, provided at the language 
level, not in an ad-hoc way, so that agent behaviors could be inferred 
from observed data (sort like what Phil was talking about), and 2) real 
scalable parallelism.