“Thankful for the Era Done, and Thankful for the Opening One.” This paraphrase of John Greenleaf Whittier’s Centennial pretty well summed up my sentiments for the World of FileMaker as the year 2008 drew to a close and the year 2009 began.

Next week will be historic as the last ever MacWorld program with Apple’s presence convenes in San Francisco on Tuesday. I have heard no official announcement, but I believe it highly likely that it will be FileMaker, Inc.’s last appearance as well. I have been attending these annual events since 1996, and they have always proved interesting. FileMaker, Inc. always draws large crowds of interested users and developers to its booth. And in the past several years the FileMaker Pavilion with third party developers has been an added attraction.

I have appreciated the opportunity to be part of this excitement and energy. While I understand that markets and times are changing, I nevertheless will miss this opportunity in future years.

But there are going to be other opportunities in coming years as well. FileMaker, Inc. has a roadmap, and they seem to be adhering to it pretty well. The developer community is strong; it will grow even stronger. I look forward eagerly to being part of that growth as well.

I hope to see many FileMaker developers in San Francisco next week at FileMaker’s Booth 1225.

Steven

–

Steven H. Blackwell

Platinum Member, FileMaker Business Alliance

Partner Member, FileMaker Solutions Alliance (1997-2007)

FileMaker 9 Certified Developer

FileMaker 8 Certified Developer

FileMaker 7 Certified Developer

FileMaker Authorized Trainer

There is too much focus on passwords and not enough focus on the protection of assets and the mitigation of adverse impacts of breaches. There is also too much focus on the creation of “custom” “security” systems and not enough focus on identifying threats and the risks of their occurring. There is too much complaining about how “hard” it is to have good security and not enough appreciation about the adverse impact of having the wrong type of security.

As a result of all this, at the upcoming FileMaker Developer Conference in Phoenix I will be conducting a special session:

Assets, Vulnerabilities, Threats, and Risks:
What Type Security Is Right For You?
Tuesday, July 15th 2008
11:15 AM to 12:30 PM
Sonoran Ballroom H

This session will feature a discussion of how to determine the right type of security for your solution. It is based on a set of circumstances specific to your individual solution, but common to all FileMaker Pro solutions.

All assets are subject to threats that can exploit vulnerabilities that, in turn, can breach their Confidentiality, Integrity, and Availability. The level of adverse impact of such a breach varies situation by situation as do the risks of those threats’ occurring and the prevalence of threat agents that can trigger the exploits.

Security then must focus on closing vulnerabilities, on blocking threat agents, and on mitigating adverse impact of breaches. And a great many FileMaker Pro solutions take no cognizance whatsoever of this key requirement.

So, if you are at the Develop Conference, feel free to stop by to listen, to contribute, or to debate this very important subject.

—–
Steven H. Blackwell
Platinum Member, FileMaker Business Alliance
Partner Member, FileMaker Solutions Alliance (1997-2007)
FileMaker 9 Certified Developer
FileMaker 8 Certified Developer
FileMaker 7 Certified Developer
FileMaker Authorized Trainer

The fuss over Andy’s conditional formatting tricks, for example, is certainly well-deserved (though let’s face it, we all would have worked that stuff out on our own, right? no?).  After playing with those for a bit, a post about Ray Cologon’s “Progress Bars” ( http://www.nightwing.com.au/FileMaker/demos.html ) caught my attention, and I ended up spending a good afternoon hacking that file apart.

What I particularly love about this solution is the idea of dumping a bunch of webviewer resources (pictures, etc.) into the user’s temp folder using the get (temporarypath) function. While I’ve certainly employed some variations on this – sneaking some garbage PDFs into a my docs folder or out to the desktop prior to e-mailing, etc – I’ve been overlooking the temp folder for years (mostly I guess because there’s never been a convenient get function for it before). Now with FM 9 data URLs finally working, the webviewer has (almost) completely arrived, and a convenient place to dump huge amounts of rubbish couldn’t be more timely. [edit - just read the "dispatches from DevCon" post. Evidently this demo was a big hit there, too]

Lately, I’ve been scrambling to finish a rewrite of a scheduling solution for a school that I work for. The requirements are simple – be able to define courses in any variety of blocks and times and dynamically generate graphical student schedules with seamless handling of overlaps and conflicts. Once upon a time, I tried to achieve this using microscopic portal rows and a schedule table with zillions of records and dozens of lead-like calculations. It worked, but it was only “dynamic” from a geologic perspective and it made white smoke pour out the back of my Dell.

With the web viewer, of course, that all changed – almost. I was able to throw out the schedule table and generate a whole mess of CSS Divs instead. The schedules were coming out slicker and faster than ever, but FM was still doing all the heavy lifting of stitching together adjacent course blocks, knocking out overlaps, and sizing text based on available block sizes. Spitting out a batch of schedules was no longer an overnight project, but it was still burdened with a sluggishness that gnawed at me in light of all the extra coding and testing it took to implement.

Over the course of this project, it did occur to me to try moving the heavy lifting over to the web browser, but I hesitated for a couple of reasons:

- I hadn’t written a word of Javascript in over 3 years
- generating HTML in an FM calc or CF is painful enough. Imagine having to debug a bunch of Javascript with escaped quotations everywhere.

Finally, though, it was Ray’s sample file that gave me the kick I needed. If I could simply pack my javascript into a container file, have that dumped into the user’s temp folder, and reference it in my HTML, life would be a lot simpler.

After two days of dusting off the cobwebs in my Javascript memory (nothing like a few years of FM calc habits to help THAT along…), I’ve finally got a rough library of functions that can connect and polish several dozen disjointed, poorly formatted div tags in a split-second. It beats the pants off the custom functions I had going in FM, and only rarely does it lock up my browser in an endless loop (okay, so there’s some debugging to do).

So, three cheers for sample files, particulary Ray’s 9 for 9 collection. Looking forward to 10 for 10 - unless of course FM comes out with something boneheaded, like  ”FM Creative Suite”, “FMX”, “FM smooth ultra king 100s”…

As a fulltime educator, there’s never any shortage of new and exciting projects to inspire me and capture my interest. As an FM developer, though, it can sometimes be a bit of a stretch. Even new releases of FileMaker (like that‘ll happen any time soon…) can be a melancholy blend of “gee whiz” moments and feature request letdowns (”what?! They didn’t include facial recognition on container fields?! Damnit, I’ve been asking for that since version 4!”). Fortunately, we can sometimes count on our clients to throw something fun our way.

Recently, a client asked me if we could integrate barcode scanning into their solution. It was a simple problem – set up a workstation so that the user could scan items off a catalog and have them end up in a proposal. For me though, I have to confess a little hesitation. As far as I was concerned, barcodes are for the big boys like Walmart and my public library. Why couldn’t my client just get by with the FileMaker value lists I had painstakingly set up for them (My specialty, the “item selection club sandwich”, stacked 12 deep with key-based dropdowns, masking popup menus, scriptevent plain entry, type-aheads, conditional container fields, mayonnaise, etc.). Anyway, I’d heard of barcodes, and understood the concept, so I said what the heck.

After shopping a bit, I found a scanner, ordered it and set about reading the Wikipedia entries on barcode symbologies. When I awoke three days later, the scanner had arrived (Symbol LS2208). I recommend this unit, but if you buy it, don’t order the “multi-interface” version unless you have some clue how to make the phone-jack-looking “multi-interface” end of the cable fit into your computer. The USB version, on the other hand, is really cool, and it was only a matter of seconds before I was scanning everything in my office and marveling at the little numbers getting magically typed into notepad.

If you’re integrating barcode scanning into a solution for the first time, and are simple-minded, be sure to plan for this phase of idiotic wonder, as it can be time-consuming. If you choose to bill your clients for it, then let me save them some money and share my research notes on this phase:

• You can’t draw working barcodes freehand. Don’t try.
• You can’t scan a barcode off the screen unless you own a CCD scanner
• The characters printed under the barcodes on stuff you own are exactly what the barcode says. There are no surprises or hidden messages.
• For father’s day, get your father a t-shirt with a barcode that represents the string “A55FACE”. It will amuse him at the supermarket self checkout.

With this research out of the way, I began to think about how to integrate my scanner with FileMaker. In it’s simplest form, you could click into a field, scan a barcode, and have that code appear in the field. Time-saving and cool, but it still falls well short of the kind of functionality your local grocer takes for granted. Ideally, you want each scan to trigger a script, and you want that script to take the contents of your scan and deliver it to the right place, and you want to be able to do everything without going back to your keyboard or moving your mouse. In fact, if you could do it without looking at the screen, that would be an even bigger bonus.

Possibly the simplest approach (other than the lame one described previously) would be to have a big global field to collect your scans, along with a button to parse the collected scans when you’re all done. To do this, though, you need a way for your scans to separate with carriage returns. Enter the world of ADF (stands for: awesome dynamic fun – look it up) rules, which are little macros that you can teach your scanner to perform every time it scans something. Luckily the LS2208 Quickstart Guide comes with a series of three barcodes just for this purpose. Scan them in order, and magically, your scanner will insert a carriage return after every scan.

While I had considered this approach briefly, it felt a bit cheap and it didn’t provide the user enough feedback to let them know what they were scanning (a field full of ID codes isn’t very friendly). So, I cracked open the 400 page PDF that comes with the LS2208 and started learning more about ADF. From my initial read, it looked like the way to teach my scanner to do fancy scanner tricks was to jump around the 400-page PDF, work out the proper series of steps, represented as barcodes, and scan them in exactly the right order (and of course, from my research in the idiotic wonder phase, I knew I would have to do a lot of printing since I couldn’t scan off the screen). So while I found all these magic ADF barcodes to be really neat, in theory, I began to wonder whether the people at Symbol (Motorola) might not have bothered to write some software to handle all of this. Digging around in my LS2208 CD, I discovered exactly that, a little utility called 123Scan. I ran it, and spent an hour and a half trying to get it to talk to my scanner. A quick trip to the PDF let me know that it would only work if my scanner was connected by RS232 serial cable. I was about to resign myself to hours of tedious flipping through the PDF when I discovered that I could use 123Scan to generate a script of ADF barcodes and send them to my printer. Happy Day.

So, first order of business was to get FileMaker to execute a script when a barcode got scanned. What I figured I could do was use the ADF rules to prepend a keyboard shortcut to the front of each scan. I really wanted something out-of-the-way, like CTRL+ALT+SHIFT+6, but it didn’t seem like ADF could get that fancy. CTRL+6 would have to do. In FileMaker, I set up a custom menu for my script and gave it the CTRL+6 shortcut.

My next concern was the time lag between launching the script and handling the remaining data. I didn’t want the barcode data stream to get lost while FileMaker was trying to get a script in gear. Fortunately, ADF allows you to set pauses, so I did (with a little experimenting, it seemed like 0.4 seconds was as short as I could make it and still have it be reliable).

Finally, I knew I would need an enter key (the keypad variety, not the keyboard version), and a beep at the end to let the user know the scanner was ready to go again.

With all of that set up in 123Scan I printed up the ADF barcode instruction series, scanned it into my LS2208 and behold, it worked. What followed, of course, was another hour or so of Idiotic Wonder – “Does it really work? Wow. What happens if I scan this? Wow. What about this? Wow. What about from 2 feet away? Wow. Etc.”

Of course, you do have to think about what you want your FM script to do with its data stream. After some experimenting, I settled on having it invoke a custom dialog with the title “Gathering Barcode” and a single global variable input field. With the “Enter” key suffixed by ADF rules, this dialog only flashes for a second and I kind of like the visual feedback. With this barcode collected, I could safely process the input, manage context, error trap, etc.

Another gotcha is the possibility of unfriendly barcodes. Suppose someone accidentally (read: inquisitively) scans their gym pass. In my case, I knew all the “good” barcodes would represent ID numbers with the same common two-letter prefix. It took some fiddling, but I was able to organize my ADF rules so that barcodes without the prefix would just generate a beep and pass nothing to the computer.

Finally, what about generating the barcodes themselves? My client assures me that they have an office supply vendor who will generate sequential barcode stickers for all items going forward, but I also wanted the option of generating the occasional set of labels in-house. Working together, Google and I turned up this handy tool: http://www.barcodemill.com/index.php Which also includes a neat little image tool you could work into a web viewer: http://www.barcodemill.com/tech/index.php?load=/tech/install/millfree.php (I’m not sure the operator would look favorably on an industrial-strength application of this – they do have a commercial version – but I imagine the occasional lookup wouldn’t hurt). If someone out there knows of a better free barcode generator, please post below.

As for symbology, I settled on Code 128. It supports a full ASCII set and is relatively compact. The next phase of this project is going to involve a mobile solution for walking around a showroom floor and collecting items to upload later. I’ve set aside a full two days for idiotic wonder when that hardware comes in…

In an effort to avoid a similar fate, I recently took a week of exile from work (pretty fancy term for “vacation”, no?) and went to a location where the only internet access was dialup. Before I left, I opened my “trip packing” database, checked off the boxes for “cold, relaxing, sun” (I was going to Canada), unchecked the box for “work” and set the “willingness to smell” field to a value of 9 (out of 10). I printed the resulting packing list and closed FileMaker for a whole 7 days, possibly the longest for me in three years.

That gap gave me some time to reflect on a number of nagging personal questions. For example: “Do I want to quit my day job and be a fulltime consultant?” or “Which will ultimately be a bigger letdown: iPhone, FM9 or the Heroes finale?” One such reflection was on the issue of my various FM workarounds and techniques.

I am a big admirer of developers who spit out technique files and custom functions whose utility are matched only by the simplicity and elegance of their approach. “What’s that? You want self-documenting contextual help menus on all your layouts. Why presto! Here’s a two line startup script that will do exactly that…etc.”

My own techniques, by contrast, tend to address the most oddball situations with the most epic ensemble of steps and components. Earlier this year, for example, a school I consult for wanted to revamp their student reports in the lower grades. They wanted space for subject narratives along with checklist items tailored to specific subjects and grade levels. This was familiar turf for me, so I wasn’t sweating it… yet. As we got into it, though, it turned out the school really wanted to be able to display the checklist items in multiple, balanced columns, they wanted individual items to be able to wrap to multiple lines, and they wanted absolutely no whitespace. The issues here may be obvious, but I’ll spell them out: the checklist items exist in a related table, which means I could either build the layout with portals (and kiss the word-wrapping/sliding goodbye) or build the layout on the checklist items table with subsummaries for all the report parts (and kiss the balanced columns goodbye). I have taken both approaches for other clients and projects.

Now, these are longtime FileMaker users, and I had been clear with them that they may have to live with certain limitations, but when it comes down to it, I hate having to break it to a client that between me and FileMaker, someone’s about to come up short. So, I gave them my usual “let me play with it and see what I can do” and then set about finding a workaround. After a day or so, I worked out a way to use repeating calc fields to draw in the related data, and these behaved miraculously well in terms of sliding (btw – anyone who feels like dissing repeating fields really needs to keep it down until FileMaker dramatically improves their print offerings). If anyone is curious about this technique, I’ve put a file here: http://petervinogradov.com/TechniqueFiles/PV_PseudoPortals.zip )

To be clear, this method is far from ideal. When I generate a student report from my location, I can actually hear their server whining about it from 100 miles away. Still, the client was happy and I was just left having to figure out how I wanted to bill it. See, I’m a big fan of spiral development, but when things like this come up my spirals tend to take on a shape that would do Salvador Dali proud. As much as I don’t like telling clients that something can’t be done, it feels almost as bad telling a client that something seemingly trivial took an ungodly number of hours to accomplish. But I guess that’s fodder for a different essay.

I’ve hacked my way through many workarounds like this, and usually, I get to a point where I start to wonder whether to keep going or whether it’s time to cut my losses and turn back. Just how many plug-ins, custom functions, scripts and “utility tables” does it take to bring me to that point? Well that depends on a lot of factors, including client personality, sleep, caffeine levels, and that ubiquitous parameter, “willingness to smell”.

For a while now, I’ve been dabbling with “session model” architecture, which is basically where you have all your action take place in a “sessions” table, and hook out to your database by setting various key fields. While I won’t go into detail about my specific approach (the good people at DevCon certainly didn’t think I should…grumble…grumble…didn’t want to go to their stupid conference anyway…etc. ), I will say that it has a certain style that appeals to me and has enough compelling advantages that I decided to take the plunge and apply it to a number of big projects.

Now, unlike the sliding portal workaround, which has a discernable plug that can be pulled at any time, the decision to build an entire interface around a non-standard architecture required a pretty big leap of faith and a commitment to live with whatever limitations emerge. For one thing, session model architecture (at least my peculiar version of it), pretty much tosses out simple access to certain FileMaker fundamentals, like the flipbook, basic find controls, list view, etc. While I’m willing to live without these features (and the havoc they can wreak in the hands of uninitiated end users), there are times when I really miss them and the wonderful simplicity of what I now call “old school” FM development.

And so, since my exile, the question I keep returning to (along with a bag of maple leaf cookies) is, “am I really doing my clients a favor by designing this way, or would they be better off in the long run with a more standard design approach?” I guess I won’t really know until I’ve lived with it for a while and built up a larger time log that I can study. Until then, I suppose it’s a matter of celebrating the stuff that feels especially easy and living with the stuff that feels needlessly complicated, even if it involves clutching my chest from time to time and telling myself to “ride it straight to hell!”

Recently I had breakfast with fellow iR alumnus Andy Chase. We talked many things, tried not to talk too much about iR, when our discussion turned to the pros and cons of Joomla and Drupal. Both are full featured content management platforms with active developer communities. The primary difference between the two, and what we surmised makes Drupal the clearly better platform is architecture.

Andy has an appreciation for software architecture I haven’t seen in many, let alone a self-trained developer. It appears that in the time since I received my degree in computer science many schools have decided the "science" part isn’t worth the bother and are instead turning out degrees in computer training. No comparative languages, no algorithm analysis and design, and no compiler design. Sure, there are a few schools that continue to teach those archaic and dismal arts but it’s quite possible to get through without them. Colleges seem to be turning out fewer architects and more builders.

Andy is anecdotal evidence that those courses aren’t really needed. Architects don’t need to be made, they can be born. As another iR alumnus once told me, software architecture is a "temperament." Architects appear to have an innate interest in and appreciation of the  seemingly mundane concerns of software development. Things like performance, scalability, stability, and extensibility. It’s not enough that the application works, it needs to work reliably.

Software architecture appears to have a bad rap among some developers. Frequently I’ve heard the charge (occasionally leveled at myself) "let’s not over-architect this." Funny I’ve never heard anyone say, "let’s not under-architect this." Looking at the penalties for each, it’s surprising to me that more people aren’t concerned about under-architecture. I’ve recently had the pleasure of looking at what I would consider an under-architected FMP application. FMP isn’t particularly well-suited to developing "large" applications. In my opinion, having a well-architected solution becomes even more important with FMP. Large systems without well-defined architecture have a tendency to become "brittle." I can recall one application where temporarily changing the storage of a calculation field cascaded through the application and broke unknown and untold functionality.

As an independent developer I never had an appreciation for software architecture. Too often the major constraint was time, and that was nearly always because I had underbid the project or my attentions were necessarily diverted by the many other things required in running your own business. In my current employ I am working with a team who, happily, have an appreciation for well-archictected solutions. It is what has allowed us to work remotely and have the different modules reliably work together. Not every team member needs to be an architect, but it is important that they see some value in the art. There is still the danger of "over-architecting" something (the penalty for which, by the way, is spending too much time designing and not enough time building) but the other team members help keep that tendency in check.

In FileMaker land, we take much of this object-relational mapping for granted particularly in applications that use flatter structures.

Looks like I have a post brewing about the problem of mapping objects to FileMaker databases. Stay tuned.

1. Do not continue to use recovered files.

2. The best CPU for FileMaker Server, especially if using Server Advanced, is a "medium powered" dual processor machine with 10K RPM SCSI drives.  Use RAID where needed.

3. Be sure to turn off Disk Indexing and Shadow Copy and enable data throughput for network apps, not file services.

4. Nested or multiply referenced unstored calculations will result in many dependency re-evaluations and affect performance.  Use Let function to prevent multiple re-evaluations.

5. FileMaker Servers should be rebooted at least once a week.

6. FileMaker Server is highly dependent on the underlying OS of the Server.

7. Do not activate automatic updates (Server patches, etc.)  Automatic notification is OK, but do not install automatically as they require reboots that can cause problems for the files.

8. For the most part with modern CPU’s, set the server cache to the maximum amount and the flush interval to 1 minute. (Besides if the processor can’t handle 13 to 15MB flush per second to the drive, then you got other issues anyway.)

9. Segment the drives or use multiple drives for Server. OS on drive 1; data on drive 2; backups on drive 3.

10. Index is specific to the data type in FMP.  And for all data types data are stored as compressed Unicode.

Steven H. Blackwell

The 11th FileMaker Developer Conference concluded the other day.  It was held in Orlando, Florida, this year at a venue leagues improved from its last East Coast outing in 2001.

I learned quite a few things at this DEVCON, and I thought I’d share some of them, in no particular order of significance.

1. Developers voted with their feet and chose workshops rather than more formalized sessions except for the three “Under the Hood” ones.  This is no surprise to those in the developer community. Several of the workshops were oversubscribed by factors of 150% to 200%, even while some formal sessions were 75% empty.  Special kudos to Chris Moyer for doing an unanticipated v-rev of his workshop when he had to turn away over 100 folks from the first version.

2. The three “Under The Hood” sessions done by various of the engineers were excellent, and they imparted a good deal of useful information. And I will excerpt some of that in a separate entry.

3. Andy Gaunt of FMPUG fame is possibly the greatest showman since the late Phineas T. Barnum.  His FileMaker Excellence Award is also extraordinarily well–deserved.  See http://www.fmpug.com

4. The unfortunate theft of a laptop computer during the conference lead to detailed discussions of laptop and software security. Laptop computers are attractive items to steal. This is very bad for their owners. Such computers need multiple layers of protection for their contents and for their FileMaker Pro databases, including strong OS-level passwords and hardening and strong FileMaker Pro-level Accounts and passwords.

5. There appears to be an infinite variety of ways to serve chicken at conference meal functions, save only Southern fried.  The latter style is, of course, the one much beloved from a childhood in the mountains of East Tennessee and the one most longed for today.

6. Several FileMaker, Inc. Engineers and Product Managers could give up their careers in the software industry and become highly successful emcees of television shows or comedians in nightclubs.  Some of these guys are really funny,  and they are really good performers.

7. Some conference organizers cannot correctly count the number of conferences held over time.  On the other hand, an Exacto knife and a strip of clear tape can convert a 10 year badge to an 11 year badge, proving that the Village Elder can still improvise when needed.

8. I think I am a very honest fellow with the ability to safeguard all manner of (sometimes very highly) confidential information.  That said, and even when other people agree with my glowing opinion of my own trustworthiness, I doubt that many developers would just walk up and give me their server administrative passwords, email passwords, PIN numbers, and similar information.  I doubt they would even if they know that I can be trusted with this information.  Given that, why then did some people broadcast that very same information in clear text over an unsecured wireless network and make it susceptible to interception by some war zoner who could have been sitting outside in the guest parking lot? If they weren’t using a VPN or some method of encryption, their Account Names and passwords could have been intercepted.

9. A lightening strike on a conference center is not conducive to the proper and effective functioning of switches and Internet connections.  Nor apparently does it enhance the ability of technically trained personnel from the relevant ISP to repair them and restore Internet access functionality in a reliable fashion.  In the information security profession we refer to a concept called “defense–in–depth” that provides overlapping and redundant defenses against various threats.  Perhaps this concept ought travel over to the ISP community in Orlando as well.

10. Finally, there is supersonic.  And there is also hypersonic. And then there is Andrew LeCates, Senior Director of System Engineers.  Even if you can only catch every tenth word of a LeCates presentation, it’s still worth more than every word of 99 percent of other presentations.  There will be a special pre-DEVCON Seminar in 2007 on Hyper Listening techniques.  Andrew LeCates is beyond a treasure to the FileMaker Developer community; he is beyond a core asset.  He is the true linchpin.

Steven H. Blackwell

But let me qualify this a bit. This isn’t a critique about innovation on FileMaker Inc’s (FMI) part. In many ways, the current generation of FileMaker (7/8) is inspired. FMI has done a lot of things right. In all the essential ways, FileMaker Pro is still easy to use, and some would argue that it is even easier now. On top of this, FMI has worked hard to break the technical limitations of the product and to gain credibility among the technical community. FMI appears to have addressed many of the principal IT objections that have threatened to take the product away from the hands of its loyal customers. With the addition of a much improved security framework and serious connectivity features, FMI has made real inroads in convincing IT that it can be a good corporate citizen.

The net result is that in addition to making things better for non-technical folk, I think that the technology gains in the current shipping versions of FileMaker (v8.0, 8.5) have also helped those who are in the business of providing professional FileMaker services such as consulting or custom application development. Retail consumers of the product have benefited but so have a big chunk of career FileMaker developers on the service side of the equation. I would love to hear from those in the field, but from this vantage point, the economic symbiosis between regular-joe-working-pro and FileMaker professional guru seems as healthy as ever.

All indications are that the demand for outside expertise has increased as FileMaker Pro has become more sophisticated. Assuming that FileMaker’s market share actually expands, the long term prospects of the FileMaker service economy appear to be expanding robustly.

The FileMaker Pro we know today is far from being a "toy." Technologically, it is capable of solving many serious business problems. If there were doubts about this in the past, the improvements in FileMaker 7/8 today represents a generational leap forward in quelling those concerns. It is an ideal platform for many roles. It continues to be an ideal tool for working professionals but, in my view, it has become an even better platform for "consultingware"–at least the more practical and sensible sort.

The issue at hand, however, isn’t whether FileMaker Pro is capable of serious work. It is whether FileMaker Pro can be more than consultingware. Can FileMaker Pro support the business and practice of writing commercial software products instead of one-off solutions? I am speaking about a class of solutions that are mostly standard and often characterized as "vertical market" solutions.

It is one thing to provide highly targeted professional technical services in the form of consulting or custom software development and another to deliver products that more generally address the needs of a domain. Some of the difference has to do with the economics of "totally-custom" versus that of "mostly-standard" software. To frame this is specific terms, take the example of creating a sales report for one particular business, say "Bob’s Boat Building, Inc." versus that of creating a generic sales report that works for types of businesses. That sales report for Bob the boat-builder can be constructed with hardcoded and highly specific calculated fields that aren’t meaningful to anyone else. However, a generic sales report might require an abstraction layer manifested as additional structure or application logic. When a software application has to address patterns of problems rather than highly defined problems, it calls for a new dimension engineering complexity. In FileMaker terms, this can mean significantly extra work. There comes a point where the investment sunk into solving these problems become valuable in its own right, where application logic itself becomes a valued work-product–intellectual property that ceases to be disposable.

Beyond Consultingware

Independent developers are appealing for features that help them stay in the commercial software business: a richer, more interconnected development interface, reusable code, modular programming features, software architecture that makes it easier change, update, support and deploy and the ability to collaborate with others so that we can do more things and do them faster.

All this begs the big question, why write commercial, mostly-standard software in FileMaker Pro in the first place? There are plenty of interesting options for independent software developers including 4D, RealBasic, and now Servoy, to name a few; why FileMaker? The sensible thing to do might be to take the pragmatic tack and use FileMaker for things it is principally designed to do but look elsewhere for features that support commercial software development.

My position on this question has changed somewhat. In the past, I have been lukewarm on the idea of developing generic commercial software solutions with FileMaker Pro. Sure, you can push the limits of consultingware; and with a carefully balanced business model, it may be possible to sustain a good business with a mixture of solutions and services using FileMaker. But generally, I have questioned the wisdom of a product-only business model anchored around FileMaker because the short-term gains by getting to market relatively cheaply are offset by the significantly greater marginal costs of making changes, updating existing installations or fixing problems. Until it becomes easier to modularize code and to deploy solutions to customers, the success of a product-only business model using FileMaker will rest precariously on one’s ability to find a middle ground between scalability on one hand and unwieldy complexity on the other.

I am, however, increasingly convinced that the FileMaker community needs these sorts of commercial solutions for a couple of reasons. The first is more pragmatic and self-preservationistic; the second is more idealistic.

On the pragmatic front, unless FileMaker Pro can be bundled with every computer or be priced as an entry level product on the retail front like Quicken as compared to Quickbooks, it seems unlikely that FMI is going to grow a large direct-to-end-user customer base through retail sales. My assumption is that, short of a more drastic differentiation of the FileMaker Pro product line, it seems that more and more, people are going to get their hands on FileMaker Pro through their organization in the form of volume or site-licenses.

Growth in volume license sales is a good thing especially for FileMaker Pro developers and consultants. However, I’d argue that this market is going to need more than custom solutions (consultingware, etc.) to keep decision makers interested in the platform in the long term. The service side of the FileMaker community is necessary but the FileMaker community as a whole needs vertical market applications like AdBlocks (by AdSails, Michael Phelp’s advertising workflow management system, now rebuilt in Servoy) and New Millennium’s Genesis accounting package (Danny Mack).

Commercial solutions strengthen the FileMaker brand. While the developers of these solutions represent an extremely small fraction of FileMaker Pro sales, their solutions give decision-makers a reason to invest in volume-licenses of FileMaker. It makes the value of FileMaker Pro tangible to organizations. In other words, the productivity message reaches domain experts like Bob the Boat Builder. It empowers individuals. The solutions message gives entire organizations a reason to use FileMaker Pro. It empowers organizations, and organizations buy volume-licenses.

On the idealistic front. FileMaker Pro is a technology ecosystem in which many types of solutions can thrive to solve different but connected kinds of information problems. It occupies a unique space in the software universe in that people can be happy with the platform for different reasons. FileMaker Pro has something for everyone in an organization. Sally the sales manager can easily get her sales reports crunched; Peter the office productivity guru can whip up mailing labels with the flair of Emeril, Bam!; Brian the business owner of Bedrock Widgets can deploy a Filemaker CRM solution from The Serious Solutions Group, Inc. and take comfort in the synergy and cost savings found in having a common information platform across the company. For commercial solution developers, selling solutions into an environment that already uses FileMaker in a diverse way makes these solutions less likely to be dislodged by non-FileMaker based systems.

This story of synergy would be nice if it were completely true today. Non-consultingware, commercial grade CRM solutions in Filemaker Pro exist, but these more or less-out-of-the-box products are few and far between. Those that exists are generally not competitive with other commercial systems in and of themselves. The market for FileMaker commercial products is weak, and the lack of credible solutions such as the former Adbock erodes the confidence of decision-makers that FileMaker can play more entrenched, mission critical roles in an organization. This in turn weakens FileMaker’s overall brand as a serious piece of software.

To be fair, in some ways FMI seems to support the thinking that commercial solutions make FileMaker a more compelling product. The FileMaker website showcases solutions and FMI marketing has paid attention to things like "starter solutions" to lay the groundwork for why FileMaker has value out-of-the box. But the product itself, even with FileMaker Pro Advanced, does not fully embrace the notion that software development is a different exercise than productivity data mash-up. The existence of commercial FileMaker solutions feels a bit like a side-effect of FileMaker’s flexibility rather than a purposely intended child of the FileMaker corporate mothership. They are a nice bonus at which FMI might raised a puzzled eyebrow but are nonetheless happier to have than not.

Where to?

I have participated in my fair share of lobbying and persuasive actions behind the scenes to influence FMI’s product future. Through it all, I am struck by how the agenda and the list of feature requests posed by us professional developers are at generally at odds with the things that made FileMaker great in the first place. "At odds" may be too strong an expression, "not directly relevant" may be better. I am wary the efforts of our vocal minority will cause more harm that good. I would hate to see FileMaker Pro so fundamentally altered that it ceases to be meaningful to its core constituents. Yet, ignoring developers’ needs isn’t the answer either.

FileMaker Inc. seems to be dealing with this conundrum by trying to make everyone happy with within the same product continuum. With each new release, they seem to be trying hard to accommodate developers’ needs but they do so by casting these features in terms of end-user functionality. I am not sure why this has to be so, but I do believe that this sort of strategy is not sustainable. The current user interface of the product cannot support both types of activities equally well. My view is that the product line needs further differentiation.

To be clear, I don’t actually want FileMaker Pro to be a different kind of application. I do want FileMaker Inc. to have different kinds of products, one that allows non-technical users to discover the magic of FileMakery and another that lets developers take those discoveries to market. An actual developer’s version may be a loss-leader for FMI,  but without it, I don’t see a lot of new interest among the younger generation of entrepreneurs and developers. Combine that with attrition of existing commercial software developers and we have a bleeding of technical excellence at the top end and along with it the platform’s credibility. In the end, the real victim here will be the traditional FileMaker users such as the domain experts and information-centric working professionals. They may not aspire to be software engineers or technoratis; they just want to get their jobs done but will continue to find themselves fighting a battle to convince the powers-that-be that FileMaker Pro is not just a tool for the self-assured corporate database hero.