"One Bullet is never enough" Paper

[Tim Daneliuk]

Kragen Sitaker wrote:
> 
> "Patrick" <postmisc at yahoo.com.au> writes:
> > Submitting the language to a standards body and opening it up to other
> > implementors is hardly a clever way to lock programmers into a specific
> > vendor.
> 
> It's an excellent way to get programmers to use it.  ECMA does not
> require that the standardized technology be patent-free, and Microsoft
> has declared their intention to make it not patent-free.  The ultimate
> result will be that the patents will issue in a couple of years, at
> which point you will be able to compete with Microsoft's .NET by
> producing a compatible implementation as long as Microsoft finds it
> convenient to allow you to do so, or as long as you don't need to sell
> in the US.  This is the clever way to lock programmers into a specific
> vendor.

I disagree fundamentally with the premise here that a language "locks"
anybody into anything - at least this has not been my experience in
the commercial sector (which is where all the money gets spent
on vendor offerings).  I would note several things:

1) "Lock" happens when the cost to replace the sum total of the system 
    components (hardware, software, networking, and most importantly,
    data) is not justified by some reasonable economic measure.  Inevitably
    the "lock" eventually disappears because the costs of maintaining the
    old system rise at the end of that system's life-cycle to the point
    where replacement *is* economically justified.

1A) Even pretty compelling new language implementations cannot really
    guarantee lock.  For its time, at least in commercial practice, 
    Visual Basic was a terrific innovation, particularly from the
    perspective of programmer productivity.  (Bear in mind that this
    is a *relative* judgement - VB was a huge step up from the GUI
    coding environments which it replaced.)  But as compelling as the
    IT organizations found VB, it did not, on the whole, prevent them
    from using other language technologies, not did it materially
    prevent the adoption of "new" languages like perl or TCL.  Similarly,
    Python itself is making great inroads into "pure Microsoft" shops.

2) Commercial systems routinely practice step-wise migrations away from
   proprietary components - either to standards-based solutions or another
   proprietary component which has some percieved benefit.  Most large
   IT operations are (and always will be) heterogenous in OS, languages,
   DBMS products and so on, in part, for this very reason.

3) By far the most difficult thing to migrate is the sum-total of data
   lying around an organization.  It has been my consistent experience
   that the cost of upgrading systems, languages, and the like is dwarfed
   by the cost of data maintenance, cleansing, and translation.

4) Nothwistanding all the Microsoft-bashing so fashionable these days, it
   is interesting to note that there are *more* languages, operating systems,
   and hardware platforms from which to choose than ever before.  Microsoft's
   "lock" has failed by any objective measure.  The only sense in which they
   have been able to lock things up has been on the desktop where no one 
   has been able to beat their price/value point. In other words, they provide 
   such a good overall  perceived value that its not worth considering the 
   alternatives.  (Microsoft correctly judged that there was a huge market
   for "good enough" technology on the desktop. It is why they won that
   market but still struggle for the Big Bucks from the backrooms of the
   IT department - their "good enough" isn't in those non-stop environments.)

5) Every vendor has tried to achieve account control in some manner.  MS, IBM,
   Sun, Oracle, et al play this game at fearsome levels.  However, they 
   never manage to quite succeed because per 2) above, real IT problems
   cannot be solved with a single-vendor solution. 

6) "Standards" are overrated as a means of neutralizing vendor threats of
   lockup.  Real standardization does not come from ECMA, ANSI, POSIX,
   X/Open (I have participated in both ANSI and X/Open efforts).  Real
   standards get set by *(technology) user adoption*.  Technology users
   such as IT departments usually do what is in their own best-interest in
   the short- to medium-term.  Whether or not it is "standardized" is an
   interesting checkpoint in the vendor selection process, but it falls
   *way* below the higher priorities of cost reduction, Return On Investment
   calculations, time-to-solution and a host of business-driven factors.
   It is demonstrable that proprietary solutions from Microsoft,
   IBM, Tandem, and the like get chosen for the simple expedient that
   they make lots of business sense in a given environment.  Anyone who
   limits themselves to only standards-based solutions will rapidly
   find themselves at huge competitive disadvantage.  Some industries
   like high-volume transaction process (airlines, credit card processors,
   banks, and equities trading floors) literally could not exist if
   forced to play a standards only game.

7) The forthcoming battle is not about OSs or languages.  These are merely
   the underpinnings of the real fight we are about to witness which is all
   about content interoperability.  Even with "standards-based" content
   markup like XML  (which I claim is still mostly about data syntax and
   presentation) there are deep and murky problems having to do with
   what that data *means* (a semantic problem).  Even if new data is
   properly marked up to encapsulate its semantics, there is way more
   old data than new, and making the two place nicely is lifetimes of
   work.  Microsoft gets this in a big way.  .NET is *all* about getting
   people to play *their* markup and content interoperability game.  They
   probably couldn't care less if you use C# or Python to code the endpoints
   of a data transaction.  They want to be in the *middle* directing traffic -
   well, more to the point, they want to position themselves as a toll booth.
   If they have any real threat if World Domination, it is in this area
   because, again, people do what works for now.  They have a real shot
   at making this work, IMO, because there is no meaningful alternative
   on the horizon which has the kind of grass-roots IT user support that
   .NET is clearly garnering.  By most measures, EDI was a "yawn heard
   'round the world".  Microsoft is earnestly positioning .NET to be
   the "EDI" of the 21st century, except they'll expect you to "pay by
   the drink."

So, I wouldn't worry too much about C# locking users in.  I'd worry more (if you
object to Microsoft's further success - I don't) about them using .NET as a
Trojan Horse to get their mitts around corporate data exchanges which, in turn,
leads to corporate transactions and transaction managment.  Then they *will* have
a shot a real vendor lockup because corporate data is Big, Ugly, and getting
worse every year.  Anybody who conquers *that* mountain will win, big time.

------------------------------------------------------------------------------
Tim Daneliuk
tundra at tundraware.com