Here's another one for consideration: Python/Django. This has similar pro/cons to Ruby on Rails. Python is slightly more popular than Ruby, but is arguably not quite as productive and doesn't have as large a community as Rails. Django is also supported on Google App Engine, which could be an interesting route to explore.

Ruby on Rails is a great option (and personally favored by myself), but I can see it might not be suitable for this particular project given the goals of ease-of-hosting and developer uptake. One thing to beware of in regards to PHP frameworks is that they can, potentially, consume too many resources for a simple shared host. This then challenges the ubiquity of PHP as you have to make sure your host can actually handle the application. At this stage, I don't think we quite know what kind of resource usage we're going to need from this application, no?

If a PHP framework were chosen, the next question would be, which one? The most popular ones are CakePHP, CodeIgniter, Symphony and Zend.

I'm fine with MySQL, but would like to be able to use PostgreSQL given the chance. One further point to recommend PostgreSQL is that ArcSDE 9.3 is compatible with it, thus tying it in nicely with the whole ArcGIS ecosystem. Making it as db agnostic as possible would seem to be a really good idea.

I'm interested in learning more about the relationship between the "core" and "user" elements of this. Could, for instance, a core instance be setup on a server, then a Rails app be plugged into that?

Main advantages and disadvantages as I can see them:

PHP (and framework - prob. CodeIngiter?): + Ubiquity, large pool of existing developers. Hosting widely available and cheap.
- Code is not known for being especially maintainable. Not the nicest language.

Ruby (and Rails): + Built in database agnosticity. Very productive environment, well suited to agile development. Largest growing language in terms of open-source projects.
- Hosting. Need at the least a virtual server. Potentially more difficult to deploy, though there are tools like Capistrano to alleviate this.

Java (and.. Struts? Some other f/w): + Powerful. Easy transition from java gives potential developers.
- Hosting more difficult than PHP. Less likely to attract open source developers than PHP or RoR.

.Net (no idea about frameworks): + Powerful. Good development tools. Hosting relatively widely available.
- Not open source. Limit the type of development/hosting platforms (unless we build against Mono, but that probably undermines the power and makes hosting more difficult).

Personally, I think we're shooting ourselves in the foot if we choose .Net and want to attract open source developers to the project (although as somebody who runs only linux systems, I'll admit to being a little biased here.) If we were going to use a non-PHP option, I think RoR is the best choice (and this is my preferred one), both in terms of the environment and attracting developers. Whether to do that is probably a question of hosting - how many places do we see the core module being deployed, and by whom?

Just to introduce myself, as I'm new on this forum: my name is Nicholas Clarke, I've worked with Charles Copp for a few years on various projects, and will be working with John on this one.

Rails has become much more cheap and easy to host in recent month due in no small part to Phusion Passenger (aka mod_rails). You can now get inexpensive, good quality shared hosting for Rails here in the UK for as little as £7 a month from the likes of Media72. This isn't much more than a decent quality PHP host. You can even get a small VPS for £10-£20 a month from the very highly rated SliceHost. Slicehost also have absolutely stellar documentation and an active, friendly community, which makes it very easy to get setup with them. If you want a UK VPS, then Brightbox seem to be good, and are not too expensive. And then there's Heroku, which is really novel and perhaps a sign of things to come (cloud computing).

Other than that I completely agree with everything else you say Nicholas (welcome to the forum, btw) :). I'd be really keen to see this project done in Rails, especially when you consider that developer productivity is an important factor. Given the very finite amount of money I imagine is available for this project, we want to get as much "bang for our buck" as it were, and I believe Rails can deliver that. Plus I believe other developers will find it very easy to pick up Rails and understand the code (because it's so structured and clean), thus encouraging participation.

One further question for consideration: given that the project is open source, where should it be hosted? I would favour either Google Code or Github. The latter of which has seen a huge surge in popularity recently with Rails itself being hosted there along with many other high-profile projects. And/or you could use something like Redmine, which is pretty easy to setup. It would be really good if, as work progresses on the project, working builds could be checked in so that those of us with an interest can get involved. This is as opposed to uploading the "final" project at launch time.

And a final point: something I didn't see mention of in the initial spec that I think should at least be considered from the start is some sort of plugin architecture. Developers are almost certainly going to want to customise this thing and it's something I think should be encouraged, so it would make sense to have some sort of official extension mechanism baked in from the start, or at least some idea of how it might be worked in at a later date.

More of a question than a comment....

I'm not too bothered about the flavour of code, we have a online recording system which works well with HTML and a little ASP to process the information. So long as any database is well structured...is there any problem with data pooling and interoperability?

For our system, point records are recorded using 10-digit OSGB LGRs, which can be entered directly, or by clicking on an interactive Virtual Earth map, again with ASP doing the coordinate transformation. We've recorded polygons (range of animals or extent of survey) using .KML files.

I would suggest that simplicity for the user and good feedback (maybe with plotting of data entered onto an aerial) is the most important driver for design. What am I missing?

Cheers,

Steve