My name is Philip, I work for a software vendor and we have recently been tasked by a client of ours to help enhance KoBo with fingerprinting. The client is an international non-profit NGO.

I forked the KoboCollect repo on GitHub and read through the Java code and it seemed pretty straightforward how one would add a new field type there. I was going to model it after your barcode field, in the sense that they both have text as their ultimate output, but reading it would require an icon next to the text, and at this point I would start making calls to a fingerprint reader’s SDK.

As far as I can think, because all of the SDKs are proprietary, this work would (initially at least) only work with a single, commercial reader type. We briefly evaluated CrossMatch SDK but found their support unhelpful. So we will likely evaluate other options.

So if it’s alright, I have several questions for you:

  1. Does this sound like a reasonable approach?
  2. If we complete this work, will we be able to Pull Request this back into your main repository?
  3. Along the lines of #2, does KoBo have any opinions about being tied to a single commercial reader, or which company would you prefer going with?
  4. I have not yet studied KoBoToolbox’s backend. Given that these fields ultimately end up as text strings, is there anything that I need to be aware of there that I’m not thinking of? I was guessing only KoBoCollect needs modifying?

Any and all advise would be greatly appreciated!

Hi @philip.ross! KoBoCollect is a fork of ODK Collect, and we encourage all power users to use ODK Collect directly. Any development effort should definitely be undertaken on the ODK Collect codebase. I think Hélène Martin of ODK and Nafundi gives a good outline of what should be done to support fingerprint reading:


1 Like