I'm not sure Diaspora has any enterprise specific leanings, although - to be fair - I haven't spent as much time studying Diaspora as I probably should have.
OTOH, there is another Open Source (ALv2) "enterprise social networking" project out there, and we're always happy to have other folks get involved.
A "facebook wall" like event stream for various event types, including status updates, calendar events (via iCal), business events (via our business event subscription engine), and external activities (via the activitystrea.ms protocol)
Friending / Following users
User Lists
User Groups (well, this is still being worked on)
"User Streams" (sort of like Circles in G+, but more flexible)
User profiles (this still needs a fair amount of love)
Status Updates (like "post to your wall")
ICal Subscriptions
Business Event Subscriptions (for SOA integration)
And we have a pile of other features planned or in progress. See:
Disclaimer: I freely admit that we intend to make money from this initiative eventually, but the code is (and always will be) under a true OSS license (it's ALv2 now and probably always will be) and we don't ask for copyright assignment or anything. Hack on the project with us and hopefully we can hire you full-time when we (land a couple of paying customers | raise a round of funding | win the lottery).
I guess it is not distributed (meaning I can run my own Quoddy server, and talk to users at friend's Quoddy server)?
Well... there's not exactly a notion of "distributedness" built in. That's on the wishlist (and, in fact, this project sprung out of a much older project that had that as it's core idea) but there is support for receiving and display messages from any other arbitrary system that supports the activitystrea.ms protocol. So modifying Quoddy to emit, as well as consume, activitystrea.ms messages would give you a way to achieve a degree of "distributedness." And that wouldn't be a hard change to make in and of itself.
The trickier part would be how to say "I want to receive updates from remote user $FOO when they come in" since $FOO is probably not a user on your local Quoddy instance. Once we have FOAF support implemented, it would be easier to talk about navigating the remote social graph and connect to non-local users... but a short-term way to achieve that could probably be hacked up.
