Hi Karel,
This is a topic that I strongly agree with, has been discussed previously, as you may be aware:
https://community.smartbear.com/t5/SoapUI-Open-Source/Do-i-have-to-sign-my-plugin-from-SoapUI-5-2-1-on/m-p/108694/highlight/true#M18708
When considering developing some functionality as a plugin, namely:
http://rupertanderson.com/blog/replace-teststep-request-soapui-plugin/ (solution to another feature request)
I considered packaging the code as a plugin (previous way i.e. unsigned) and adding code to to overcome the check (similarly to https://github.com/hschott/soapui-pluginloader-jailbreak), but this seemed a passively confrontational way to go about things and working together is almost always a much better option. So, because I just wanted to trial the solution, I opted to package my functionality the old way, as an extension, but this is less neat than packaging the functionality as a single file. Also, in terms of this functionality, I've no idea at this stage whether it is actually sufficiently good and useful to warrant actually getting it endorsed and signed - I just wanted to get it out there, in an 'open source' way and obtain the feedback I need to improve it.
I think the idea of optional config to disable the check is a good one, as it maintains the defensive position. An alternative might be just show a warning / disclaimer for unsigned plugins (could be just a log message, or popup, that can be optionally ignored).
Basically, as an aspiring 'open source' plugin developer I would like a life cycle like:
1) Be able to release a prototype plugin (unsigned) - gain feedback, improve or abandon.
2) If successful, optionally approach smartbear to get the plugin signed.
Again, if its just a question of finding someone to do the coding, I'd be more than happy to help on either of the above options. However, like your other feature request (re the error that is thrown loading the packed plugins), I think the first move probably needs to come from smartbear / product team to endorse any approach in keeping with any SoapUI O/S plugin strategy they might have.
Anyway, nice feature request! :-)
Thanks,
Rupert