open sourcing is a very much the developers decision… (so Squarp in this case)
developers spend man months/years creating their software, so rightly feel they need to protect this investment from other (hardware) manufactures just cloning thier hardware, and using that software.
others, feel thats its opportunity for the community to help grow the platform, resolve issues etc.
so open source is tempting.
Emilie from MI, whilst she open sources the firmware, its after a time which she feels has recuperated enough of her investment - however, this partly works because of how successful MI modules (esp, in recent years)
this touches on another factor…
really open sourcing only benefits users and manufactures IF open source developers pick it up and run with it.
there are only so many open source developers (with appropriate skills) for doing this kind of development, and honestly, we have to pick n’ choose which projects we spend our (free!) time on.
so for someone like Squarp, they have to ask themselves is anyone likely to want to participate in development - if not, then its just a distraction.
(e.g. Mutable modules are very popular, so that means they are more likely to attract developers, but even then, theres only a few couple of forks even for thier most succesful modules ! )
so, its a hard decision to make - and certainly not something we should expect of developers, rather be very grateful when they are generous enough to make something open source.
as for practicality with something like Hermod (or Pyramid)…
these run an MCU which dont run an OS (in the sense most users think of it) , which means that they cannot dynamically load code in the same way as something like a rPI/Organelle/Norns can.
rather, like MI modules, a developer would have to fork the entire firmware to supply a new function (e.g. midifx) - this makes combining something like midifx from multiple developers an absolute versioning nightmare.
it also means, if Squarp release a firmware update, any ‘forks’ by 3rd parties, need to at be adapted and rebuilt.
also, frankly, end-users are much less likely to use 3rd party firmware … thats just how it is, they feel more confident with factory firmwares and also ‘add-ons’
as for 3rd party developer, its also much harder…
the codebase was not designed to be ‘understood’ outside of the original development team, it also likely has little ‘development documentation’
it would be enourmous effort to do this (Mutable Instruments do NOT do this at all), which means the effort is placed on the 3rd party developer to ‘grok’ all the code, and build an understanding.
this goes beyond just ‘adding a midi fx’, a new fx, might need to inspect the timeline, it might need also having timing constraints…
finally, whilst i might have ‘great’ ideas for a midi fx, it may just not be possible/feasible given how the firmware is written. which I wouldn’t know until I know the firmware source code intimately! ( * )
I’ve written and extended both firmware (like this) and ‘add ons’ (like orgnanelle/norns etc),
sure it can be done, but its quite different…
Im a huge advocate for open source development (I actively develop for quite a few open source projects), but its not a panacea for every product/project.
( * ) this is why I always suggest people ask @squarpadmin about possibitlies - we as users, have literally no idea if our great idea is feasible/practical since we have no idea how the firmware is written - without that its pure speculation… even if you know 20 other sequencers that can do it 