Re: Open source? -> Need to read source to model?

[Marcus G. Daniels]

>>>>> "RLR" == Rick Riolo <address@hidden> writes:

RLR> It just struck me as not obvious that all people using a system
RLR> like Swarm should be expected to, or regularly need to, read the
RLR> source for Swarm.

The constraints I want to satisfy are these:

1a) Swarm comes with source code.  This is not because users `ought'
    to look at it, but simply because it can make life easier when
    instrumentation (or fixes) can be applied to Swarm itself.  

1b) Source code is not a substitute for internal technical
    documentation or user guides, etc. but in the absence of that
    documentation, it is the real story, after all.  If you're stuck,
    sometimes the source code is not that hard to understand.  
    Other times, swarm-support may be more efficient.

 2) I would like to see a subset of the community (or a larger staff
    at the SDG) that built features for Swarm relevant to different
    domains, and that by virtue of this there would be distributed
    expertise and know-how.  For example, visualization and analysis
    tools could easily be decoupled from Swarm.  With some work, we
    could even put observation features in a separate application that
    would be attached to a model.  The next release of Swarm will
    provide dynamic loading for features like HDF5, and this approach may
    be a small step towards reducing the amount of coordination that is needed
    to do distributed development.

3a) The core part of the package, common to all domains would get
    highly focused attention (with documentation, education, and
    development).  If the goal is to have an accessible package, I
    believe it is better to have one or two complete and
    well-documented features than ten that constantly result in having
    people ask or try to rationalize source code.

    The Swarm Development Group was created with the realization that
    Swarm is not just about blue sky scientific dreaming, it is a
    program that is supposed to provide specific features that serve
    the common needs of the agent-based modeler.  The main specific
    feature it was designed to provide is the ability to describe
    agents in in a bottom-up, local and individualized way so that the
    dynamics of communities of agents so-described can be studied.
    Concretely, this means the most important feature of Swarm is the
    activity library. 

    Unfortunately, what happens now is that when a helpful person 
    like Paul Johnson comes along and wants to help build a user guide,
    he is confronted with too much stuff, some of it (analysis, space, 
    simtools, simtoolsgui) is weak enough that time would be better spent
    improving the code.
    
    Frankly, I don't think it is feasible to have it both ways.
    Either one works on the assumption that Swarm (or a package like
    Swarm) should be usable by many kinds of people, or you go in
    exactly the opposite direction and make a flexible package with
    many features that can be used by few skilled people.  And I mean
    "we" broadly, not just the Swarm community but
    agent-based-modelers in general. 
  
3b) Even if the Swarm software as a whole goes toward the `solid'
    state and away from the `liquid' or `gas' state, clearly the Swarm
    project needs to be able to do conceptual and technical
    development in these other states.




                  ==================================
   Swarm-Modelling is for discussion of Simulation and Modelling techniques
   esp. using Swarm.  For list administration needs (esp. [un]subscribing),
   please send a message to <address@hidden> with "help" in the
   body of the message.
                  ==================================