My BBQ had to get binned because we used it so infrequently it seized up with rust - this is Britain, after all.
The key thing I think about with this kind of solution is to support how people want to use it, from the people who all want to do a collaborative thing (OFMM style) to the people who just like adding a bit of meta to their Orbiter experience (ISA-style, sorry Gary).
On both parts, I see an "in & out" solution - one component which sits outside Orbiter as a discrete application, which manages the "mission control" aspect of the VSA, assigns vehicles, generates contract missions, records flight times and mission results, and generates .SCN files to be fed into Orbiter (based on the addons you have, the vehicles in your space agency and the contract you've chosen, if your VSA can afford the launch costs, etc). The "in" portion is then an Orbiter plugin which is fed information by the outer component through that generated SCN file, which actually feeds your mission objectives to you in flight, and records when they're complete - and takes care of updating the outer component with the result, or passing the result back in some form that the external application can process.
This can then be communicated up to a central server, for the consumption of others, or not, depending on how people want to play. For collaboration, it would be prudent for users taking a contract to "lock out" a mission and a vehicle, so they can't be used simultaneously, which would lead to drift issues.
I'm expressly not talking about being able to fly the same mission in real time with your friends - that's OMP territory.