Acore Design Discussion Wiki

Every once in a while I think it makes sense to have a completely on-topic, technical post!

One of the (many) things that has been on the top of my to do list is to get a discussion going about all of the challenging and deeply interesting design issues involved in creating a meta-model that supports the representation of arbitrary natural systems. You know, it's funny, but putting it that way I just had a realization of how -- ambitious? hubristic? no, I'm thinking simply ridiculous -- that particular use case is. But what the hell, let's give it a try. And you can help. Check out the document below.

http://wiki.eclipse.org/AMP/Acore_Model_Design

You don't have to be involved in agent-based modeling to contribute -- in fact, it would be really great if you weren't! There are very likely issues in the overall design that already have good solutions and we're simply not aware of them. I'm especially hopeful that the broader modeling community will have some ideas about namespace and query mechanisms. And on the other hand, you might see something here that will be helpful to your own efforts. I think AMF is doing some interesting stuff in terms of supporting general behavioral modeling and the more arbitrary and dynamic relations than can be represented in OO meta-model designs.

Though I've had many many interesting conversations about MetaABM design issues on an individual and small group basis, and though those discussion are often about the same basic issues, it's been frustratingly difficult for me to get a more open discussion going. In the past, I've tried newsgroup and mailing list postings, but somehow the discussions are never quite as interesting as the more private ad hoc ones. Incidentally, this is true at conferences as well. And it's especially true in academic conferences where -- ironically or not -- people can be the most conservative about sharing their more interesting ideas. The real action at conferences happens not in the session rooms but in the hallway. Hmm, perhaps I could have put that statement better -- the images it brings to mind are a little disturbing. But you know what I mean. OK, getting back on topic now... I'm often reduced to cc'ing folks into email discussions and that can get ideas going. But those discussions end up sort of petering out before any real conclusions are drawn. To have a real sense of community ownership in Acore and AMP, it's going to take a lot more than that.

I guess there are two aspects to this; network effects and making tools that people just spontaneously want to be involved in. But that's an iterative process, and for a tool like AMP AMF that is already pretty conceptually abstract and complex, how can I jump-start that process? That's the challenge, and I'm hoping that combining an active design process with other kinds of communication will get us past the tipping point / s-curve / [insert-your-favorite-complex-systems-buzzword-here].

I was inspired to take the Wiki approach by the effort that the P2 team made last year -- see http://wiki.eclipse.org/Equinox_p2_UI_Use_Cases. Their approach was really light-weight but it was able to capture the core issues and solutions really well, and -- here's the key and to me really surprising thing -- involve users form outside of the core P2 group to provide feedback and input. Outside of bug reports and infrequent blog posts from happy or disgruntled users, and (at least for those projects with already active user communities) gleaning newsgroup postings, it's really hard to get a discussion going about detailed design issues, so as I've mentioned here before I was impressed by the P2 team's effort. It'll be interesting to see how it works in this somewhat different context.

So, I hope you'll take a look and give feedback on the technical issues but I'd also really appreciate any advice on the technical community building challenge itself.