Independent developers invest in the platform. Access to its future should have a clear path.

By Dimitris Kokoutsidis · Axelar

During the research and development of ai2fm, we found defects in FileMaker that could silently change what a developer had written. Parameters disappeared during copying. Steps pasted across versions with different settings. Different exports of the same script disagreed.

We investigated, documented, and reported our findings. We published reproduction files, original clipboard captures, explanations, and recovery methods. When Claris asked us to check a subsequent release, we repeated the tests and documented what had changed.

We did this because reliable tools matter to our own work and to the developers who depend on the platform.

That experience is the background to my concern about how access to FileMaker’s next generation of development tools is distributed.

The asymmetry appears when independent research is shared openly, while the technical access needed to prepare for the platform’s future remains selective.

Our public bug documentation shows what contribution means in practice. It currently contains eighteen entries, including two explicitly documented without being formally filed. The downloadable suite includes FileMaker files, clipboard XML, and .fmscript results. Where a recovery is possible, we explain how it works and provide supporting examples.

Some findings required looking beyond whether a command appeared to copy successfully. A machine-learning step could change its operation when pasted between versions. An Insert from Device step could retain the correct numeric barcode selection while SaXML, the DDR, and the printed script named a different selection.

Finding those discrepancies takes time. Establishing where they originate takes more. Producing a small, reproducible case that another engineer can investigate is additional work again.

We also exercised judgment. We distinguished a localized WinSoft defect from Claris’s own defects. We acknowledged fixes. We documented limitations in our own ability to recover missing information. We credited a community member’s manual workaround for developers who do not use ai2fm.

This research also benefits our product. There is no contradiction in that. A developer can build a business and contribute useful work to the platform on which that business depends.

The contribution becomes public when we make that investigation available for others to inspect, reproduce, and use.

Claris’s work on ADT is a development I welcome. A direct interface between FileMaker and external development tools creates opportunities for automation, inspection, and AI-assisted workflows. I want that direction to succeed.

There is already public evidence of tools being built around it. Soliant’s Clockwork Inspector repository describes its current version as reading live FileMaker solutions through the Claris ADT fm command-line interface. Publishing that work is itself a useful contribution.

But access to a repository and access to its underlying platform dependency are separate things. Reading an integration can reveal useful information. Running the underlying tool allows a developer to test assumptions, discover limitations, and build against its actual behaviour.

From our position, we are examining publicly available integrations for information about a tool we do not currently have available for our own testing. Other developers are already building with it.

That difference matters commercially, even when the work being published is free.

Earlier access provides time to learn the interface, make architectural decisions, find gaps, and offer feedback while the interface is still evolving. Developers who arrive later must perform that same work later. A general release makes the tool available; it does not return the preparation time already spent by those with earlier access.

A private preview can be entirely reasonable. Unfinished software needs bounded testing, support capacity is finite, and participants may accept confidentiality and testing obligations. Reporting bugs does not automatically create an entitlement to every preview programme.

Those realities still leave a practical question: what is the clear route for an independent tool developer to participate?

Published eligibility criteria, understandable participation obligations, and a defined application route would make that question easier to answer. Documentation and representative samples could help developers prepare where distributing a working build is not yet feasible. A clear explanation of the limits would also help people plan their investment.

I would welcome those conditions. They would allow independent developers to assess the opportunity on its stated terms.

The same business discipline applies to our own research.

We have continued to find defects beyond those already documented.

For now, we are retaining those additional findings internally and using what we learn to improve ai2fm’s handling, warnings, and guidance. Our existing public documentation remains available.

Preparing further reports, maintaining public reproduction suites, and repeating verification across releases require resources.

We will decide where to commit that work according to the value of the relationship and the needs of our users.

Voluntary contribution depends on a willingness to continue. A history of sharing should never be treated as an unlimited commitment to provide more.

I remain interested in technical cooperation with Claris. Better FileMaker tooling creates opportunities for all of us. Clear participation rules and a practical route to technical access would give that cooperation a stronger foundation.

We have already demonstrated what we are willing to contribute. The question now is how independent developers can participate in building what comes next.