Published by a closed-source product
This page comes from LocalType, whose code is not available to read. If inspectable source is a requirement for you rather than a preference, the answer to your search is one of the projects listed below, and no argument later changes that.
There is a practical reason the question bites harder for keyboards than for other software. A keyboard sees everything you type: passwords, messages, medical details, bank details. Android says as much in the warning it puts in front of you when you enable one.
With most apps you can reason about behaviour from the permissions they hold. With a keyboard the access is inherent to the job, so the only remaining question is intent, and source code lets you check intent for yourself. Without it you are trusting a promise.
Add a microphone key and the recording joins the list of things that promise covers. That combination is why the open-source keyboard scene is unusually busy compared with, say, open-source calculators.
FUTO, Whisper IME, Transcribro, and two keyboards to put them behind
FUTO Voice Input. Recognition on the device, source published, paid for once up front with no subscription and no account. It is a voice input service rather than a keyboard, so it plugs in behind a keyboard that can call it. The most complete answer if you want to keep the keyboard you already know.
Whisper IME. Runs Whisper on the handset, MIT licensed, free, available through F-Droid, needs Android 9 or newer, and downloads its model before first use. Recordings are capped at roughly half a minute, which suits messages more than sustained dictation.
Transcribro. On-device recognition using whisper.cpp with voice activity detection, ISC licensed, free, distributed through Accrescent and its own repository. It provides both a keyboard and a system speech recognition service, so other apps can hand it work. English.
AnySoftKeyboard and HeliBoard. Open-source keyboards with no dictation of their own, both long-running projects. Put either one in front of a voice service above and the whole stack is open, which is the answer for a phone running without Google services at all.
Assembling that stack is two installs and one pairing step. Enable both in Android's language and input settings, select the keyboard, point it at the voice service, and let the model download finish. Then switch to airplane mode and dictate a paragraph, which tells you what the readme cannot.
Set aside an afternoon and expect to read a couple of readme files on the way. For the people who want this, those are reasonable terms rather than a complaint.
Readable code is not the same as audited code
The phrase carries more weight in conversation than it does technically.
Open source guarantees the code can be read, which is genuinely valuable and is the whole point of it.
It does not guarantee anybody has read it. Plenty of projects are audited by nobody in particular, and a claim in a readme is still a claim regardless of the licence sitting above it.
It does not guarantee the app on your phone was built from the code you read, unless the build is reproducible and you went and checked, which almost nobody does.
And it does not guarantee the model is open. Several of these projects run models whose weights are published and whose training data is not, a different and weaker kind of openness than the code wrapped around them.
So apply the behavioural checks either way. Cut the network, dictate a paragraph, and watch what still works, which is the one test that answers the same way for open and closed software alike.
Small teams, and the gaps that follow from that
These are small projects doing careful work, and every gap below is structural rather than sloppy.
Languages. Multilingual models are larger, and a small team sensibly picks one language and does it properly. Several of the options above are English only, which settles the matter immediately if you write in anything else.
Polish and edge cases. Commercial keyboards have been refined against millions of handsets. An open project has not, so an unusual phone or an odd app can produce behaviour nobody has hit before.
Two projects that have to keep agreeing. A voice service plus a keyboard means two release schedules and one interface between them that both sides have to keep honouring.
Support. There is a repository and an issue tracker. For a lot of people that beats a support address; for others it is not support at all.
Distribution. Several live outside the Play Store, which is a feature for the audience that wants it and an obstacle for everyone else.
Where we ask you to trust a promise instead
The case for LocalType, which is not a case about openness.
There is one product to install, so there is no pairing step and no compatibility question between components that were built separately. Eighteen languages come out of a single multilingual model, and the language is taken from the recording itself with no menu to set first, which is exactly the gap the English-only projects leave open. It is a full keyboard in its own right, with autocorrect, next-word suggestions, a dictionary per language and the standard layouts, and you can add your own surnames and jargon by hand so they arrive spelled correctly when you dictate them. It is supported as a product, which matters on the day something misbehaves on a phone model nobody tested.
On the principle underneath there is no disagreement at all. Recognition happens on the handset, from a model file kept in storage no other app can open. The app asks for internet access for exactly one purpose, fetching the model you chose, and has no second use for it, which you can verify in airplane mode exactly as you would verify an open project. Nothing needs registering, advertising is absent, nothing inside the product records what you do with it, no archive of your recordings is kept, Android's cloud backup is deliberately denied the app's data, and over a password field no microphone key is offered.
Three sizes, at 60, 190 and 539 MB, put the speed and accuracy decision in your hands instead of ours. On the 4 GB test handset the middle one turned 6.9 seconds of speech into text in 4.1 seconds, and the largest takes roughly twice as long as you spent speaking. Only one sits on the phone at a time, so trying another size swaps the file rather than adding to it.
What you cannot do is read any of that in source form. If that is the line, the projects above are where to go, and they are good.
Verify, or get on with it
Two kinds of reader arrive at this question wanting different things.
If you need to check the claims yourself, open source is the only route and the options above are real ones, maintained by people who care about the same question you do.
If you need dictation working this afternoon, in three languages, from one install, on a phone you cannot afford to fight with, that is a finished product and it is the trade LocalType asks you to make.
Undecided readers should start with the open options. They cost nothing to try, and if they cover your languages and behave on your handset, the question is settled without you spending anything at all.