Re: [Swarm-Modelling] Something Glen said

[glen e. p. ropella]

Marcus G. Daniels wrote:
> time for that work.  Meanwhile, no one is standing in your way or
> anyone's way to improve Swarm or write a new one.  Others have.  Why not
> you, the person that insists the SDG should be volunteer organization?

What incentive do I have to volunteer my time?  I'm already volunteering
my money and I see it being wasted.  If I volunteer my time, will that
be wasted, too?

The reason I'm not improving or writing a new Swarm is two-fold:  1) the
SDG is not an open organization that takes direction from the community
and 2) because the SDG continues to waste it's meager resources, it
demonstrates that my investment would be more fruitful if I apply it
somewhere else.

My argument is that the SDG should become a more open organization that
serves the community.  Any SDG or Swarm-related technical efforts will
remain tangential and largely irrelevant until the SDG inverts its
perspective.  The community is not here to serve the development of
Swarm, which is what happens when you funnel member donations into
privately conceived and executed contracts.  Swarm is here to serve the
community.

> It all could benefit internally by being rewritten and simplified.  The
> question is how to do that and if it is worth the trouble in light of
> the existence of other productive projects.  My understanding of the
> SDG's view with the last minor release work was not to do that.  Thus
> why the SDG just bumped the release with some toolchain adjustments and
> minor fixes for existing users.

That's all completely reasonable.  A decision to avoid any refactoring
of the primary modules sounds to me like a decision to let Swarm die and
let the users migrate to other more productive tools.

The problem is that it contradicts other messages that indicate the SDG
is considering porting Swarm to other architectures _without_ doing any
of the refactoring that is needed to make Swarm relevant and useful.

> Again, by focusing this part of the conversation on "integration glue"
> I'm having to do the inference work and address your chronic problem
> with vague accusation.   If there is anything specific that you object
> to, please name it and contrast it against what it is *not* within
> Swarm, and then explain why it can't be fixed.

I've said it over and over again.  And there is no accusation.  And it's
not vague.  The original requirements for Swarm should be reexamined in
light of all that's occurred between then and now, including the pros
and cons that have been highlighted by Repast and other tools.  That
analysis should result in a new, possibly more stable, set of
requirements for ABM packages.  If those new requirements are satisfied
by an extant tool, then the SDG should adopt that tool as its reference
implementation.  If not, then the SDG should begin (or encourage) a
development project to develop a tool that satisfies those requirements.

The current Swarm _may_ satisfy those requirements just fine.  But, I
sincerely doubt it since Swarm hasn't changed much since the other
projects like Repast were launched, meaning there are still requirements
that are not satisfied.

There's nothing vague about what I'm saying, here.  Just because you
don't understand it doesn't mean it's not understandable.

> Not having any real organizational support when I worked on Swarm (and I
> was not a PI), the future I naively saw for the survival of Swarm was
> one of academic and hacker volunteers.  People that work for their own
> goals or satisfaction but without regard for what the community wanted. 
> Thus making the integration glue was more important in my mind than
> anything else.  Today, I'd say a commercial project or long term but
> lower-metabolism academic institutional project would be the way to go
> (a research project).

I don't disagree or object to your current or previous vision.  But, the
SDG is NOT a project at a think tank, which it was when you came on
board.  So, we're not talking about research projects.  We're talking
about a non-profit corporation with tax-free status.  Had Swarm found a
home after leaving the SFI, then perhaps it would have remained a
research project.  Had we incorporated a for-profit organization to fork
Swarm and develop a commercial version, then perhaps it would have
morphed into commercial project.  But, those things didn't happen.

What happened (thanks to you and many others) is that we formed a
non-profit, charitable organization to support a demographic.  If that
demographic can be supported by maintaining a reference implementation,
then that's PERFECT!  But, since fewer and fewer people are using Swarm
as it is now and there are no proposals on the table to make Swarm
_more_ useful to _more_ people in the community, then it's time to do
one of the following:

1) completely refactor it,
2) mothball it and start anew or adopt and support one of the others, or
3) mothball it, abandon the idea of a reference implementation, and
provide community support in the form of papers, howtos, etc.

>>> This implementation approach for Swarm is passe.
>>>     
>>
>> A passe approach is just _fine_ if the tool is easy to use.
> The tool would be easy to use if someone simply *worked* on making it
> so.  In any case, today, such a tool would be technically inferior to
> what Mono and .NET provide out of the box as it would not provide
> cross-language *and* cross-box code portability (only the former).   It
> still might be worth finishing if the payoff was perceived as big enough
> (like on a Cell-based supercomputer or PS3) or for embedding in Firefox
> or for interim glue to Mono. 

It's still unclear to me how any of these efforts supports the ABM
community, which is what the SDG should be doing.

-- 
glen e. p. ropella, 971-219-3846, http://tempusdictum.com
... given any rule, however "fundamental" or "necessary" for science,
there are always circumstances when it is advisable not only to ignore
the rule, but to adopt its opposite. -- Paul Feyerabend