Sub plugins allow activity modules to be extended without having to change the module's code.
Each activity module can define a set of subplugin types in db/subplugins.php. The file must contain an array called $subplugins, with the plugin type as the key for the directory containing the plugins. For example, from mod/workshop/db/subplugins.php:
$subplugins = array( 'workshopform' => 'mod/workshop/form', 'workshopallocation' => 'mod/workshop/allocation', 'workshopeval' => 'mod/workshop/eval', );
This defines 3 plugin types, workshopform, workshopallocation, and workshopeval. The plugins themselves can be found in mod/workshop/form, mod/workshop/allocation and mod/workshop/eval, respectively. Each of these directories can contain a number of plugins, each within it's own subdirectory.
Writing a sub-plugin
A lot of the basic structure of a sub-plugin is the same as any other plugin. It can have a version.php, a lang directory, and can have a db directory with install.xml and all the others files can can go in there.
However the details of what APIs the sub-plugin has to provide depends on the type of sub-plugin it is. For example, and quiz report has to follow the rules for quiz reports that the quiz module sets, and a workshop allocation has to follow the rules set by the workshop module. When you create a new type of sub-plugin, you should document the expected API.