(Referring to design of a home automation system, using hierarchies to manage )

I don't have time to go through point by point (as what you've written
is fairly verbose), so I'll try to to address what I see as the main
points.  Sorry for the somewhat abrupt tone; I don't have time to
write "nicely", but the advice is well-meant :-)  Feel free to ask for
more details.

The design as it is seems to conceptually mix
* Namespacing the modules of external authors (good idea)
* Defining interfaces they can plug into (good idea at a point)
* Using a hierarchy for these interfaces (most likely a good idea)
* Forcing every module to plug into a single point in a single
hierarchy (bad idea).

I'd separate these, and redesign a la this:

== Provide a namespace that authors can put their plug-in modules in. ==

I'd grab some area of the Ruby namespace (e.g,
HomeAutomation::Device), and then tell each author to use their e-mail
address "turned on its head" as a subnamespace they can manage
themselves.  This would give any devices I wrote the module
HomeAutomation::Device::Org::FreeBSD::Eivind::<something>.  It's long,
but it is unique.

== Define interfaces the can plug into ==

I'd grab a namespace for this (e.g. HomeAutomation::Interface, too,
and provide a bunch of plug in points/interfaces.  Every device under
HomeAutomation::Device would export a list of what interfaces it
supported.  Examples of interfaces would be ToggleSwitch or
VoltageRegulator; a device could be one of them (a pure toggle, or a
voltage regulator that had a minimum higher than 0), or both.

== Device finding ==

I'd just iterate over the namespace in HomeAutomation::Device to find
anything that's there.


I'd also start off with bringing anything written by external authors
"Into the fold" - import it into my own version control repository,
and give them commit privileges.  That way, it is possible to refactor
the code together with the rest of the system.  I'd also build the
system with heavy testing from the start, to enable that refactoring.

Remember: The standard advice is that you can't build a framework
until you've done (and deployed) three full systems.  If you're going
to be more ambitious than that, at least cover all the bases you can.

Eivind.