I'll try to describe specific cases to explain OpenSVC usefulness.
Consider a sysadmin in a corp, he sets up services for clients/users. He has about 50 services in charge. He likes FreeBSD, so he tends to deploy his services on that base. He has a good grasp of how rsnapshot works, so he created scripts to automate backups and dutifully prepared scripts to help recover from a server crash, may be even a site black-out.
The sysadmin in the next cubicle is also in charge of about 50 other services. He will have also done its homework right, but with its own style. He may prefer Linux and rsync, his recovery scripts will be in a different location (may be in its desktop). His clients may require more availabity, so he had to choose a clustering stack.
Now scale to tens of admins and thousands of services. The datacenter is a patchwork of technologies : 3 to 4 different os, 2 different storage hardware with their own replication protocol (hitachi shadow copy, emc srdf, netapp snapmirror), 2 clustering stacks (hacmp, redhat cluster, suncluster, veritas cluster), a myriad of different scripts to automate actions on small perimeters.
And picture some frequent scenarii:
o leak over a rack: 20 servers down, 50 services needing failover, 10 different admins with all their specific failover mecanisms
o site blackout : same sketch, a ten-fold
o the corp has outsourced the service monitoring: hard to trust the low-profile screener with the fine-tuned services start/stop action responsability
o sysadmins turn-over : all the fine-tuning is not easy to pass-over to the newcomer.
OpenSVC can be seen as a free, easy-to-deploy, deploy-everywhere cluster stack. Low criticity services can have only one node. Medium criticity services can have 2 nodes and no automatic failover. High criticity services, 2+ nodes with automatic failover plus a remote node for disaster recovery.
Same tool for all, respecting every sysadmins preference (os, virtualization model, filesystem, replication scheme) and every availablity target to provide the stop/start/replicate actions for such different types of integration.
I focused the example on a large scale environment to highlight OpenSVC usefulness, but in real life, many users use OpenSVC to manage 1 to 4 services, just to dish-out a lot of scripts they maintained themselves previously.
The web collector brings additional advantages, as a reporting, alerting and data-mining front-end. This component is not GPL'ed but it is not needed to benefit from the above. Free-lancers tend to use the internet collector to have a single point of reporting for services they maintain for differents clients.
Hope it help clarifying OpenSVC position in the clustering world.