

Technology Lock-In with the DC Metro - bensummers
http://sunlightlabs.com/blog/2010/technology-lock-in-with-the-dc-metro/

======
VengefulCynic
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.

~~~
gaius
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.

~~~
michaelbuckbee
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."

~~~
gaius
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.

More to the world than webservers you know...

------
_delirium
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).

------
ratsbane
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.

1 <http://en.wikipedia.org/wiki/SmarTrip>

2 <http://www.google.com/finance?q=cub>

~~~
hga
The reports are that the company that makes the cards is going out of
business; perhaps it's Cubic's card supplier?

~~~
ratsbane
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.

[http://www.washingtonpost.com/wp-
dyn/content/article/2010/09...](http://www.washingtonpost.com/wp-
dyn/content/article/2010/09/16/AR2010091606462.html)

------
rdtsc
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.

------
derefr
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.

~~~
rpavlick
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.

www.macromates.com

~~~
derefr
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.)

