@spwoodcock
It is indeed open source (naturally!) you can find the plugin through QGIS (via 'manage and install plugins') and the repository is at:
You'll also find more information in the showcase:
As for contributions, well we don't accept denominations below $1,000 for money laundering reasons, or crypto is fine. Oh, hang on, not that type of contribution? 
Yes I would be very grateful for any contribution, although quite how perfection can be improved I know not [irony-alert-emoji].
Now... I see you are a coder, so please be gentle with me when you look at my mess! I would probably call it 'brutalist' style of coding (and that's being gentle on myself). There is no elegant pythonic code in there, but I have tried to 'rubber duck' my way through - well, actually it's the only way I can code - write what I want to happen in plain(ish) language, and then find snippets that might be adaptable! I may not have attributed every source 
or probably any 
Three things to bear in mind.
- I'm not a coder (did I mention that?)
- I haven't used GitHub for active development so don't really know how to deal with commits and pull requests. And it looks like my good friend @ahblake has been testing QuODK beyond my limits so I will have to look into those problems too!
- I am about 90% through a version that deals with Entities and I do 'development' in the privacy of my local machine rather than syncing with GitHub (mainly for embarrassment reasons) - so the released version is not up to date.
The version in development allows me to select and show Entity lists within a given project and download Entities. It can differentiate between new and updated Entities and filter (as per submissions). I have also part-written the script to prepare an Entity List / Dataset from a QGIS layer (the geometry conversion being a key success!). I am thinking of just writing to CSV and then leaving it to pyODK / API to actually interact with Central, creating Dataset, adding properties and then uploading a CSV - this is because web-users would need different access permissions in order to write to the server, and it could get messy for someone using QuODK who is not a data manager! I'm sure I could build in checks, but figuring out how someone can break in because I've opened that box starts to get scary, so maybe better to keep the functions separate.
My desire to have more fine-grained permissions (read-only) for web users in Central remains though...
PS your work on webhooks looks really interesting and picking up on the audit logs might be something to incorporate into QuODK...