Until you've been burned by technology lock-in or know someone who has, it's hard to really wrap your head around it. It's a lot like all of those people who you see interviewed after major disasters who say, "We didn't have insurance... we didn't think a [insert major disaster here] could happen here."
Honestly, that's the problem with explaining lock-in to many PHB-types: not only can they not conceive of what a disaster would look like, but they can't even imagine that one could happen in the first place.
Fortunately your PHB doesn't have to understand this - your auditors will understand it.
This cuts both ways tho'. I've personally experienced being at a small company with a great product that a giant corporate customer loves - but their auditors have said, this company's this size, so you may only risk that many dollars business relying on their product.
But wouldn't "open standards" help in that situation? You could tell the auditors: "Sure we're a small company, but if we fail it won't put your business at risk because you'd be be able to swap it out with anything else complying to XYZ standard."
LOL! No, of course not! You can comply with whatever standards you like for data coming in and data going out but it's what you do with it in the middle that's what an application does.
This is one reason that even without insisting on open standards, many large companies and government contracting have insisted on a "second source" rule, where a compatible version of the technology being adopted has to be available from at least one other supplier; if it's patented, the patent-holder has to license it in a way that enables a second provider, if they want to be considered (which is how AMD got their x86 license).
Something doesn't make sense here. DC Metro's card is made[1] by Cubic Corp[2] which is not in bankruptcy. The general idea of avoiding vendor lock-in is a pretty big deal and the board member's comment in the linked article was right: "And so that we're not just funneling money to people who are real good at intellectual property, but aren't really selling us anything, except a tether to them"
If they really were in bankruptcy it would probably be easy for the DC Metro to buy the technology for pennies and (hopefully) open-source it.
The Wash Post article listed below only states that the vendor has discontinued the card - so it's still a vendor lock-in problem. The bankruptcy mention must have been a red herring.
One a related note -- if you are a contractor, don't try to lock in your customer, no undocumented magic code, secret processes, hidden ways doing things. Make it so they can get rid of you quickly and efficiently. They will love you for it, as everyone else will not do that, and you will be regarded much, much better because of it.
Just as a tangent from the "proposal" at the end of the article: for my freelance writing, I use OmmWriter with plain/Markdown text stored in a git repo. It'd be really nice if the three things (the editor, the format, and the SCM) knew about one-another, though.
TextMate comes with support for Markdown and version control (Git, Subversion, etc). OS X only, although I've heard there is a wanna-be clone for Windows.
TextMate is horrible for writing prose. Unlike programming, where you perform discrete edits (like adding/refactoring a function, changing a constant value, etc.) changes to prose are continuous; ideally, every action (add character, backspace, move cursor) should be a separate "micro-commit." Similarly, syntax highlighting is almost guaranteed to screw up when one tries to write prose with it; I have yet to see a text format (HTML, Markdown, Mediawiki markup...) where you can paste in the current plaintext draft of your novel, and the second half of the book won't become highlighted entirely in green because it's "inside" an unpaired asterisk.
Ideally, a prose editor would be a minimalistic WYSIWYG editor, where each formatting option mapped to a feature of Markdown. The "document format" would, internally, be a Markdown document stored in a git repository—but actual Markdown text would be escaped if pasted into the editor itself, so this would just be an implementation detail (except if you tried to copy-and-paste from the editor to a plain textarea—then you'd get Markdown, which is better than losing formatting altogether.) The editor would auto-commit each and every change; undoing and then typing something else would create a branch.
Other people could work on a document/repo with you; the editors would P2P-send operational transformations when they knew that others had the same document open in the editor, with eventual consistency guaranteed by committing the changes to the repo asynchronously (where each user is committing their current view of the operationally-transformed state, so no git-level non-fast-forward merges are needed, unless the users are actually working on purposefully-made separate branches.)
Honestly, that's the problem with explaining lock-in to many PHB-types: not only can they not conceive of what a disaster would look like, but they can't even imagine that one could happen in the first place.