Unfortunately, the first draft of this post got eaten. I’m now trying again.
In response to its small but vocal constituency, I got myself briefed on the FileMaker story. My conclusion, in a nutshell, is that FileMaker sometimes is a good alternative to low-end use of a standard relational DBMS. If you do feel able to use more standard-style products, you often should, for all sorts of obvious flexibility and future-proofing reasons. But if you can’t, or if you’re really confident the project won’t grow past a certain level, the FileMaker class of products can be a very appealing alternative.
Make no mistake; FileMaker is very different from conventional DBMS/app dev tool combos (and that’s the right comparison, as it combines aspects of both product categories into one). Indeed, the whole discussion is complicated by an unfortunate terminological confusion. Way back to the days of dBase and then Paradox, the “desktop” sense of “database software” was very different from the classic IT sense. What’s worse, these often weren’t really desktop products at all. That said, FileMaker fits into the desktop-database class of products, competing much more directly with Microsoft Access than with anything else. That is, it has selected application development and database management features, tightly bundled together, but falling far short of what is found in traditional DBMS or app dev tools.
How different is it? Well,
- There’s no true FileMaker language, just macros hooking together primitives called “scripts.” There’s no chance of a FileMaker syntax error as long as you stay within those bounds. But if you want capabilities not already available, you need to get somebody to write an ActiveX control for you.
- Not coincidentally, 80-85% of FileMaker users (company estimate) are non-programmers as their main jobs. And those are the more serious users. 1 million copies are sold per year; 13 million have been sold overall; and there’s no way even close to 15-20% of those are used by professional programmers. Right now the company has 2,000 paying members to its developer network, and aggressively hopes to up that to 10,000+ in a year. The company estimates there are several thousand professional FileMaker developers overall.
- There’s no separation between UI and data. Everything’s in the “layouts.” That includes integrity checks, business rules, and so on.
- FileMaker’s team programming capabilities are pretty nonexistent. The product is oriented to lone-wolf developers, although members of small groups can of course each work on separate parts of a large overall app.
- The average number of users of a FileMaker app is 14-15. 250 concurrent users is a hard (and somewhat artificial) limit.
- FileMaker is limited in its overall website building capabilities. Alpha5′s web site is, if I recall correctly, built in its own tool. FileMaker can’t do that.
Product futures include extending ODBC, Web, and general openness capabilities, and increasing the 250 user limit.
It also may be interesting to clarify a bit about the product’s history. FileMaker was developed outside Apple, then acquired into Apple’s Claris software subsidiary. Claris had 13-14 products at its peak, but FileMaker was spun into its own unit (still an Apple subsidiary). I’m not too clear on what happened to the rest of Claris. The product is fully pixel-for-pixel compatible between the Apple Macintosh and Microsoft Windows. And there’s been less total turmoil in FileMaker’s top management than one might think.