emece67 is right about not all of the firmware being open source. The code is arranged so that there's still a completely closed-source OS "shell" that just runs one application, a port of Thomas Okken's Free42 (which itself is properly open source and licensed under the GPL). See
https://www.hpmuseum.org/forum/archive/index.php?thread-10870.html for further discussion.
Several months ago, swissmicros did reorganize things and make available some code on github as 0xdeadbeef states, but the OS "shell" itself is still distributed only as a binary. For example, I wanted to look into the keyboard debouncing algorithm used, and change it to use something similar to what's described here:
https://summivox.wordpress.com/2016/06/03/keyboard-matrix-scanning-and-debouncing/. But the source code isn't available. All that swissmicros did was provide an "SDK" so that you can build a new application on top of their closed OS "shell".
Nonetheless, several months ago, when swissmicros reorganized things as a separate OS "shell" running Thomas Okken's Free42 application, a lot of people congratulated swissmicros for finally making things "open source", which confuses things. But they really didn't do much more than is legally required (and which they arguably should have had properly separated in the first place). There is still no way to build/modify the code for the lower-level parts of the calculator. And I do think their keyboard debounce algorithm is probably suboptimal (a lot of recent calculators that use a flash microcontroller instead of a custom ASIC or masked rom do seem to get this wrong for some reason...key debouncing just doesn't seem to be get enough attention for firmware development). The DM42 does also have keyboard issues related to the hardware itself (dirty contacts), but there's no way to verify if the debouncing algorithm makes things worse.
For comparison, finding the code for the WP-34s is incredibly easy, and I would consider it a truly open-source calculator (at least the firmware). The algorithm used is a lot simpler than what is described at
https://summivox.wordpress.com/2016/06/03/keyboard-matrix-scanning-and-debouncing/. The code for debouncing on the WP-34s can be seen at:
https://sourceforge.net/p/wp34s/code/3903/tree/trunk/main.c#l312#ifdef DEBOUNCE_ON_LOW
/*
* A key is newly pressed, if
* a) it wasn't pressed the last two times checked
* b) it is pressed now
*/
keys.ll &= ( ~last_keys & ~KbDebounce );
#else
/*
* A key is newly pressed, if
* a) it wasn't pressed last time we checked
* b) it has the same value as the debounce value
*/
keys.ll &= ( ~last_keys & KbDebounce );
#endif
Currently DEBOUNCE_ON_LOW is defined, so the code used for debouncing is the top part. The rest of the keyboard handling is a little more complicated, because it also needs to handle keys held down. (If a function key is held down, that key's function is displayed. If it's held down for even longer, eventually "null" is displayed and the key doesn't do anything when released. This is useful for when you forget what key's assigned to what with custom keyboard assignments in user mode). For me, the biggest usability issue with the WP-34s is the keyboard. The keys themselves give a nice definite click, but I can't always be 100% sure that there aren't repeated or missing keystrokes, although it's maybe fine 99.99% of the time. I think the debouncing is still slightly better than the stock HP 30b firmware (which the calculator is based on). The DM42 is far worse with missing keystrokes.
On the WP-34s though, there's also an incredibly annoying delay between when you press the key, and when it actually takes effect. I think the key function/"null" display handling is what causes the delay. It'd be interesting to see the code for the DM42. The code for swissmicro's voyager models is more freely available, although the deboucing isn't great, see dm_lpc111x_sdk/drivers/keyboard/keyboard.c line 252 in
https://www.swissmicros.com/dm_lpc111x_sdk.tar.gz if (!gpioGetValue(ROW(j)) || !gpioGetValue(ROW(j)) || !gpioGetValue(ROW(j)))
keys[press_count++]=KEY_CODE[k];
The key must be polled as being pressed down three times consecutively to register. If the DM42 is using similar code, depending on the polling interval used on the DM42, this might be a problem.