Thinking out loud after a week of Rust clones.

The week that started this #

This week a team called ArtCraft, publishing under the Storytold organization on GitHub, released open-source apps modelled on software we all know. PdfCraft goes after Acrobat. Its siblings go after Photoshop, Illustrator, Premiere, Lightroom, After Effects and InDesign.

PdfCraft already has more than 15,000 stars and 6,000 forks. It’s written in Rust, licensed MIT and Apache-2.0, and runs on macOS, Windows, Linux, FreeBSD and in the browser. The authors call it a clean-room reimplementation, and they’re upfront that it’s alpha: by their own count it’s about 55% of the way to replacing Acrobat for everyday work.

I read that and didn’t think about PDFs at all. I thought: how long until someone does this to FileMaker?

Fair warning. I’ve built on FileMaker for years and I’m part of a developer community around it. I’m not neutral here, so take this as me arguing with myself in public.

My first reaction was defensive #

It can’t happen to FileMaker. It isn’t a viewer you can rebuild from a spec. It’s a database, a layout designer, a scripting language, a server and a security model, welded together over thirty years.

Then the second thought, a few minutes later: that is exactly what someone with a lot invested would say. When I try to argue the other side honestly, my “it can’t be done” case gets thin faster than I’d like.

What changed #

Rebuilding mature software used to take a big team and years of patience. That’s no longer a safe assumption. Rust makes fast cross-platform engines realistic. WebAssembly puts the same code in the browser. Public test corpora give builders something to measure against. And AI coding agents shrink the gap between an idea and something that runs. The PdfCraft repo ships agent instruction files, which suggests that’s how it was built. That’s my reading, not something the authors say.

So “we have thirty years of engineering” is a weaker moat than it was, at least for anything you can observe, specify and test.

Why FileMaker is still harder than Acrobat #

PDF has an ISO standard. That’s a huge gift to anyone rebuilding it. FileMaker has nothing like it: no public spec for the file format, none for how calculations evaluate, how script steps behave, how layouts render or how privileges resolve. The product is the spec.

Then there’s the integration. A clone has to be decent at the database, the UI, the scripting, the server and security all at once, or it won’t feel like FileMaker to anyone who uses it. And thirty years of behavior add up: find mode, found sets, context from table occurrences, portals, script triggers. Real solutions lean on the quirks, not just the features. Add the plugins, the consultants and the community, and you’re looking at more than code.

But it’s more visible from the outside than it looks. The Data API and OData expose structure and data. The Database Design Report and the XML export describe schemas, scripts and layouts in machine-readable form. That isn’t the file format, but it’s a lot to learn from, and a model that has read thousands of those reports knows what real solutions look like.

“Clone” means three different things #

A faithful clone that opens your existing solution and runs it unchanged. That’s the hard one.

A good-enough alternative that imports structure and covers the large share of custom business apps that are really forms, lists, reports and a bit of automation. Plenty of open and low-code tools already live near there.

Or no clone at all. Teams just have AI generate a bespoke app on a commodity stack, and the platform quietly stops being necessary.

The uncomfortable part is that I think the second and third are the real threat, not the first.

So how long? #

These are guesses, not forecasts.

A faithful open-source clone that runs real solutions: I can’t see it happening in under three to five years, and I wouldn’t be shocked if nobody ever finishes one. Nobody has a strong reason to. PdfCraft exists because Acrobat’s market is enormous. FileMaker’s niche is small, which protects it and caps its growth at the same time.

A credible alternative that migrates a decent share of simpler solutions: probably much sooner, and it may never call itself a FileMaker clone.

AI-built replacements for individual solutions: already possible for small cases, and better every few months.

Feasibility is falling fast. Incentive is the part I can’t predict.

What FileMaker has going for it #

It’s one product that a non-programmer can use to get database, UI, scripts, server and security working together. That counts for a lot. People have years of business logic living inside these files, so switching costs are real. There’s a global network of experienced developers who share what they know. Claris sits inside Apple, which removes the existential worry a small vendor would carry. Deployment, backups, privilege sets and hosting have been battle-tested for decades. And Claris keeps investing: OData and the Data API, a Linux server, AI features landing inside the platform.

What works against it #

Everything depends on one vendor: the format, the roadmap, the pricing. The desktop client runs only on macOS and Windows, mobile means iOS through FileMaker Go, and the web experience has been the weak spot for years. Solutions are binary files, so there’s no natural text-based, diff-friendly way for a team to review each other’s work, which looks more dated every year. Many developers feel the core moves slower than the tools around it. Newer developers learn web stacks first and rarely run into FileMaker at all. Per-user licensing is easy to justify for a small team and harder to defend against free alternatives as you scale.

And then AI. Migration was always the great moat. If a model can read a solution’s design report and generate a working equivalent, that moat gets a lot shallower.

Where I think Claris is heading #

As I read it, the direction has three parts: AI inside the platform, connection to the outside world through standard APIs and integration services, and wider reach through web tools and more server options. It’s a sensible direction. I still have worries.

I like the bet on integration. The better FileMaker plays with everything else, the less it needs to be everything. I like putting AI where the data already lives, including search by meaning and model calls from scripts, instead of leaving customers to bolt it on. And OData and the Data API are the reason tools like MCP servers can exist at all.

What bothers me is AI treated as a feature rather than a foundation. A new script step is useful. Making the platform something an agent can inspect, reason about and safely change is a much bigger move. The web gap is the second worry: if users expect to live in the browser, the web client can’t stay a second-class citizen. The third is that the edges are open but the middle isn’t. A solution’s own definition is still locked in a binary container.

There’s a bigger point under all of this. Lock-in is a depreciating asset. Once leaving gets cheap, the only reasons left to stay are value, trust and community.

What would change my mind: a text-based, version-control-friendly representation of solutions. A first-class web client. A clear story for agents, meaning safe introspection and controlled automation. Any one of those would tell me Claris is investing in being chosen, not just in being hard to leave.

So, how long? #

I’ve come to think the question is slightly wrong. A clone, if one ever shows up, is a symptom. The real question is what keeps people choosing FileMaker once leaving is cheap.

My answer for now: the integration, the community, the maturity, and a vendor willing to open things up enough that building on FileMaker still feels like a safe bet for the next ten years. All of that is still in Claris’s hands, and in ours.

How long do you think FileMaker has? And what would keep you here anyway?