They are a VCS company, why would they out source their core competency? Second that kind of seems to be their MO, knock off an existing system, only do it better(their primary product is a visual source safe done right.) From what I have read, it seems like it will be away for Corporations to move to this fancy new DVCS thing while still maintaining a modicum of control and centralization(it supports file locks.)
I still can't quite wrap my head around what it means for a DVCS to have exclusive locks. It seems like either the locks aren't exclusive or the system isn't distributed.
My guess(since there is a dearth of documentation at this point) is that it is token based. When you say a file requires locking it records that the file needs to be locked and that you currently own the lock. Then as you push, knowledge of the fact that this file needs a lock is spread.
The only other option I really see working is having a designated lock node, so you are centralized only when you need to do locking.
"(their primary product is a visual source safe done right.)"
If I may quibble with this comparison, I would point out that we built Vault because SourceSafe is a deeply flawed product, whereas Git is not a deeply flawed product.
We built Veracity because we think DVCS is the future of our industry and we want to be a part of that. I don't think Git and Mercurial are the end of innovation in version control. I think the third generation of version control is just getting started.
We're not interested in trying to convince people from switching off Git or Mercurial onto Veracity. Why would we? Those people are already happy DVCS users.
But there are still millions of developers who have not yet made the switch from a centralized system to a DVCS. Git and Mercurial will get their share of those new users. We hope Veracity will be a viable option as well.