During the DotNetNuke Review process, one item that we look for is whether a module can be completely uninstalled using either automated or manual procedures (assuming the manual steps are documented). Uninstallation will be viewed by some users as a measure of quality. In addition, failing to properly remove a module poses a potential security risk for many sites.
One key identifier for malware is that it makes it difficult, if not impossible, to uninstall. Any software which resists attempts at removal presents a problem for users and administrators and is a generally frowned upon practice. One of the primary goals of the Review Program is to help improve the overall quality of modules available to users (this includes both actual and perceived quality). We feel that not hampering users ability to remove the module is a key part of meeting this goal.
More important than the quality issue however, is the issue of security. Imagine if a user were to install your module and decides to remove it. You subsequently discover a vulnerability in your module and distribute information to your user community on how to patch your module to correct the problem. What should an administrator do if they have previously uninstalled your module? What if this administrator is not the one who did the initial installation/uninstallation? The odds are pretty good, that if an administrator believes that a module has been uninstalled that they will ignore your security bulletin (how many administrators that have your module installed ignore your security bulletins - my bet is that it is a much larger number than you think). So under certain circumstances, it is possible that not properly uninstalling a module could leave you open to hackers.
So where does that leave us. I believe that this requires action by both the DotNetNuke team and Module developers. Currently, DotNetNuke attempts to execute the unistall script and delete the module folders when a module is deleted from the Module Definitions screen. However, in some cases the uninstall script may fail or the directories are not properly removed. It is also possible that a module might create additional directories in other parts of the system that is not detected by DotNetNuke. We need to make the uninstallation more robust to provide information about what steps were taken during uninstallation, and which steps were not completed due to errors in the process. We also need to provide some APIs that allow the portal to keep track of what changes a module is making to directories.
The solution must also include action by the module developer community. Module developers should include instructions for completely removing a module. This should include all files, folders and database objects. While DotNetNuke will continue to improve in this area, it is unlikely that the framework will ever be more knowledgeable of your module than you, the developer. You have intimate knowledge of the directories that are created and of the stored procedures and tables that are created or altered. By providing manual uninstallation procedures you tell your users that you are a responsible developer and increase the perception of quality in your company and your products.