Re: [Swarm-Modelling] newbie question

[Paul Johnson]

Marcus G. Daniels wrote:

> alex dinovitser wrote:
>
> > It appears to me that development in the project has
> > slowed down if not stalled over the past 3 years. Is this true? if 
> > so, why?
> >  
> Quite correct!   The reason is no funding.  The reason for no funding 
> is debatable, of course, but my take is that many people in serious 
> scientific circles feel that agent based modelling is a dodgy 
> scientific activity. 

I think there is truth in that argument, but the academic view is 
changing quite a bit.

I think there is a more persuasive explanation for the funding issue.  
Funding agencies think Swarm is completed.  It runs, they can see 
Heatbugs, therefore people who have money don't see the point of 
spending it.  The people making these decisions are not programmers and 
they really don't want to understand the point that there is work still 
to be done.  And, I know from submitting funding applications, that the 
funding agency does not want to pay for Swarm Core Development as a part 
of a project on a specific substantive topic.  Its a Catch-22, then. You 
can't do the substantive project because Swarm does not have a fully 
functional feature X, and you can't get funding for feature X because it 
already exists.

I'm trying to chart out my next big research project, so perhaps I have 
been meditating on the is problem too much.  My opinion is that, if you 
are going to seek funding for a big, complicated free Software project, 
you have basically 2 options.

One way is to ignore the project altogether until somebody comes along 
and says "We'll pay for everything from start to finish."  That would 
not advance the modeling agenda, of course.  Nothing would ever happen.  
Its a really big problem that "grand framework" proposals seem to raise 
about 1/3 of the money they need, so they get part of the way there, but 
not all the way.  Then they are left with the same problem as the people 
who build highways: "We've spent all of our money and only half of the 
road is done, so give us some more."  It works for roads, but maybe not 
for academic research software.

The other option is to design the project with completely separate, 
clearly defined modules.  This requires more foresight than I actually 
have, but I know someone who has succeeded in this way.  Initially build 
only the absolute minimum thing.  Then go back every year to say "look, 
we did X, now pay for Y", and so forth.  The key, I gather from 
observing the debates among funding agency types, is to make it 
absolutely clear what is obtained for each increment of money.  Suppose 
Swarm team had initially built just the SwarmObject and the activity 
library.  Some console program would run and print out results.  Think 
of the first bug tutorial exercise.  Then you would say to a funding 
agency, please pay us X dollars to create a graphical interface for 
people who like to point and click.  Or pay us to add environment 
classes where agents can live.  Or pay for the creation of random number 
generators. Or pay for user documentation.

I've seen this strategy work in at least one case, but it is tricky 
because the designer has to be careful to make sure that each step is 
worthwhile on its own.  And, if you stop to think about the whole idea 
underlying agent-based modeling, we are almost never in the right 
mindset.  We are not "top-down",  "grand strategy" sorts of people.  
Rather, we individual, uncoordinated agents  hoping that lots of little 
efforts will accumulate into an emergent property.  To an extent, this 
works.  Bill Northcott did work to update Swarm to work with the newer 
Automake and Autoconf that I could never have done myself.  I can fiddle 
around with updates to suit changes in GCC or add methods here or there, 
but I'm not capable of understanding/maintaining the Activity library.  
If some other volunteer can do so, then we are in good shape.  As long 
as there is no part of the project that is too forbidding for a 
volunteer, the "many hands make light work" philosophy will work.  
However, when you need a big-concentrated effort to create a set of 
concepts and build them into a completely new code base, then you are in 
trouble.  You need funds to pay someone who is a gifted professional 
programmer who can actually turn the gears to take an academic idea and 
bring it to life.  There are many people working on MAs or PhDs who are 
creating Swarm things, some of which they offer on their personal web 
sites or contribute to the ftp site, but only rarely are people willing 
to make that last, challenging step of cleaning up their code and 
formalizing it into a format so that it can be added to the Swarm 
distribution itself.

Swarm reflected a paradigm-shifting set of concepts that we did not (do 
not) understand fully.  The original Swarm idea was so big and 
paradigm-changing that I doubt anybody could have had the foresight to 
carefully structure the research agenda in order to cultivate funding.  
In fact, if you go back and look at some of the initial design and 
strategy, or comments about Swarm, it seems to be designed in the 
opposite direction.  Way back when, say 1996 or 1997, Swarm had the 
"giant picture" framework in place with a lot of methods that were just 
stubs and the source code said "not implemented."  It is very difficult 
to explain to a funding agency that you want money to fill in the "not 
implemented" part.  Its even more difficult to explain why you want 
money to replace a "working prototype" with a newer, better thing.

I hope this observation does not offend or cause frustration among the 
people who have worked so incredibly hard on Swarm itself.  I do not 
intend to denigrate either the grand vision of the project or the hard 
work of many programmers along the way. 

--
Paul E. Johnson                       email: address@hidden
Dept. of Political Science            http://lark.cc.ku.edu/~pauljohn
1541 Lilac Lane, Rm 504                              
University of Kansas                  Office: (785) 864-9086
Lawrence, Kansas 66044-3177           FAX: (785) 864-5700