http://specify6.
I've been browsing their screenshots & they've got some nice additions. I expect this is our main competitor, and given that it's 'free' to users and so much advertising etc behind it, I expect it to become even more entrenched than it is now.
I don't really consider Specify competition - they support a completely different paradigm.
They are not very dynamic, offer little in the way of user customizations, and aren't very responsive to user needs. They provide software, but you need to maintain your own system - which typically means dicey consumer hardware and craptacular backup strategies. They don't change anything quickly, and seem to have an effective pre-release cycle, so they do release stable software.
Arctos is (potentially and increasingly) centralized, meaning you get Enterprise-caliber hardware and software, system-wide tech support from those of us who wrote it, and planned and tested backup strategies, all for a fraction of the actual cost (and perhaps even much more for much less sometime soon). We'll listen to your ideas, implement them if they're not too wacky, and even get you set up to write code if you want. We follow a release early/release often strategy (which mostly means we're too poor to pay for actual testers, but also means that you're likely to see requested changes very quickly).
Specify is software. Arctos is a system (from which you can use the software if you so desire). To implement Specify and get Arctos-like reliability, you'd need a pair of servers ($5000 each), on-site backup ($2000 + tapes [$50 per day - as many as you can afford, but at least 30]), off-site backup (Amazon's S3 would be one option - something less than $500/month), a firewall, and ideally security folks, systems administration folks (software and hardware support), and database folks. They you're still left running MySQL as a backend. That's a fabulous little database for things like retrieval speed, but I would NEVER trust it to maintain archival or sensitive data, especially in an online environment. It was not designed for that, doesn't support the tools necessary to do so securely, and will never be comparable to Enterprise-class software like Oracle (they could have at least picked PostGreSQL!). Specify's ability to run on much less does not mean that doing so is a good idea. I think fulfilling our public trust obligations demands more (and, increasingly, so does NSF). Free does not necessarily imply inexpensive when system costs are considered.
Arctos's to-user costs are significantly less than Specify's. We're currently asking for $5000 per participant per year - the cost of one decent Dell server or the ColdFusion license. We've reached a size where we can ask for additional support to further reduce that cost while simultaneously increasing resources. There is a proposal in the pipeline that would do just that, in a fairly dramatic fashion, while also bringing a major museum (and some very smart developers and users there) closer to the core Arctos development team.
We also differ in strategy. Specify maintains a fairly traditional schema, and their tables are increasingly wide (non-normalized). Arctos tends towards leaner normalized tables and more sophisticated coding to make that work. The payoff for us is extensibility - Gordon just spent 3 days in Chicago discussing with various DB folks something we implemented in around 20 minutes. The cost is programming - it's more difficult to write code to normalized structures (one of the original model architects once told me it was impossible - while staring at Arctos, interestingly enough).
Specify's new stratigraphy extension is a pretty good example of the differing development philosophies. They've added 3 wide tables which allows you to record values for a finite and pre-determined set of geological attributes. We've added one very narrow table which allows you to define any number of terms and values, along with who, when, and why. Our model is infinitely flexible, even in the absence of a programmer, and records determinations or opinions. Theirs is simpler to implement, requires code changes to support new types of data, and records assertions.
Some Museum folks aren't much interested in collaborating with peers, tracking non-traditional data (usage and such), participating in community initiatives (MaNIS et al.), having broad exposure for their data, or generally being on the frontlines of information accessibility. Those people will probably never be happy in Arctos, and, assuming they can provide long-term data and hardware security, Specify is probably where they should be. The half-dozen recovering Specify users I personally know, admittedly all very much proactive front-lines folks, have few nice things to say about Specify. In fairness, I probably wouldn't know the people who remain happy with Specify.
It's worth mentioning that Specify and Arctos share a basic model, and Jim Beach was involved in the early development efforts of that model. There's been much divergence, but the core tables still share names and the occasional field.
All that said, I'm not above blatantly stealing good ideas from anyone, and our development strategy nicely equips us to do so. Let me know if you see something you think we need in their screenshot gallery.
