There are political advantages in vendor lock-in
Summary: Every government knows its time in office is limited. What it needs are stalwart friends and a legacy. Proprietary vendors deliver both, and it is in the nature of open source that these not be provided.
Today Matt Asay urges government buyers to support open source, open data and open standards.
Why? Because it's better. Because it promotes competition. Because it gives government flexibility.
But after watching government on every level, in various countries, for over half my lifetime, I can tell you the last thing any government wants is to make a decision its successor can overturn.
Every government knows its time in office is limited. What it needs are stalwart friends and a legacy. Proprietary vendors deliver both, and it is in the nature of open source that these not be provided.
You're probably thinking this is an attack on American politicians, so let's go offshore for our example. Let's go instead to Great Britain and, to make it a little less partisan, to the BBC. (This might be useful to Matt since he's now COO of a British-based company, Canonical.)
(Cue the flashback effects, please.)
About 15 years ago now, when I was at Interactive Age, the BBC asked us to send someone over to Radio House for a two-day conference on what it should do with "multimedia."
The plan was for our publisher to give a little speech, but then the magazine was closed, most everyone left for pastures new, and this junior reporter was left with the duty.
I gave a little talk but, having nothing better to do, stayed for the whole show. Near the end the audience was broken into working groups on various topics. Mine was on the Internet.
While everyone around me argued, I noodled around on a connected PC and found an early NPR podcast of its headlines. I turned around, got their attention, started playing the file, and told them "this is your competition."
Over the years the Beeb became an online leader. Its online budget grew. But pushback emerged from private news sources. They said the Beeb's dominance was hurting their business prospects.
The response was to try and tie the BBC's existing strengths in broadcasting tightly to its Web site. Politically the idea was to make them one and the same. The BBC needed a friend here, and it found one in Microsoft.
Microsoft was willing to do whatever the BBC wanted, support whatever draconian DRM regime was called for, in exchange for proprietary advantage. Its iPlayer gave the agency control over who could see what, reducing the inherent subsidy in Americans visiting the BBC News Web site.
One result is that the BBC is now locking out open source, verifying "rights" to view content by verifying the player. They have gone so far down the proprietary road that the interests of specific American companies -- Microsoft and Adobe -- are now the interests of the BBC.
It's crazy if you think about it. Tieing British citizens to American technology companies, when there is solid British-based competition from Matt and his bosses, right there in London.
But open source could not have enforced rules on users as the proprietary companies could. Open source could not have the politicians' backs as Microsoft might.
And open source could not have obligated the next government, which may be much less friendly to the BBC's interests, to support BBC technology, lock-in and user control the way a proprietary solution does.
Lock-in is not a bug but a feature. In any political setting -- and even a private company boardroom is a political setting -- that can be a real advantage. It's something open source can't match (thank goodness) but there it is.
Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.
Talkback
we should boycott BBC
Let them feel the power of the people!
Open source is like broken Obama promises
Irony
ZDNet is brought to you by Linux.
RE: There are political advantages in vendor lock-in
RE: There are political advantages in vendor lock-in
RE: There are political advantages in vendor lock-in
What is wrong with vendor lock-in?: Tight coupling
[b]"A colleague asked me this question today, and I'm really glad it came out in the open, because it's so much easier to deal with ideas when they're plainly stated.
I believe there are at least two strong reasons to actively avoid vendor lock-in.
The first reason, paradoxically, lies in the very justification for agreeing to be locked in - "ease of integration". If an organisation already has a product from a certain vendor and is looking for another product that needs to integrate with this one, then conventional thinking is to go back to the same vendor and buy their offering rather than a competitor's. After all, they're far more likely to be "well integrated". There are typically so many problems integrating products from different vendors that it doesn't seem worth the effort. The best-of-breed approach leads to integration problems, so customer organisations often throw in the towel and go for an "integrated stack" of products from one company.
This approach is antithetical to SOA thinking, however. What they're really saying here is that they don't mind implicit contracts between systems as long as they work. But implicit contracts are a form of tight coupling, and as we know, tight coupling is brittle. Upgrade one product and you'll very likely need to upgrade the other as well. In production systems, we have seen product upgrades delayed for years because the implicit dependencies between "well-integrated" components could cause some of them to break on an upgrade, which is unacceptable in mission-critical systems. As a result, many useful features of later versions are forfeited. That's one of the unseen, downstream costs of the tight coupling that comes from vendor lock-in.
SOA shows us the solution. For robust integration between systems, we need loose coupling between them, which seems a bit paradoxical. Shouldn't tight coupling be more robust? Hard experience has taught us otherwise. But what is loose coupling? It's a hard concept to visualise, so let's define it in terms of tight coupling, which is easier to understand. In practical terms, loose coupling between two systems can be thought of as tight coupling to a mutually agreed, rigid contract rather than to each other. Such contracts are very often nothing more than open standards.
Even though people generally nod their heads when asked about their preference for open standards, the contradiction between that stated preference and their practical choices in favour of "integrated stacks" is hard to understand. If pressed, they might say that creating contracts external to both systems and insisting on adherence to them seems like a waste of time. Why not something that just works "out of the box"? The answer is that this is not an either-or choice. A browser and a web server work together "out of the box", but they do so not because they come from the same company but because they both adhere to the same rigid contract, which is the set of IETF and W3C standards (HTTP, HTML, CSS and JavaScript).
The key is to hold vendors' feet to the fire on adherence to open standards. This isn't that hard. With Open Source products available in the market to keep vendors honest, customers have only themselves to blame if they let themselves get locked in.
The second reason why vendor lock-in is a bad idea is because it often implies vendor lock-out. Very often, customers are held hostage to the politics of vendor competition. Once you start buying into a particular vendor's stack, it will become increasingly hard to look elsewhere. Any third-party component you procure will be less likely to play well with the ones you already have, causing you more integration headaches. My favourite example from just a few years ago is Oracle Portal Server, which claimed to support authentication against LDAP. It turned out later that it wasn't just any LDAP server but just Oracle's own OID. This meant that the corporate directory server which happened to be IBM Tivoli LDAP couldn't be used. The data in it had to be painfully replicated to OID to allow Oracle Portal Server to work.
My solution to incipient vendor lock-in would be to aggressively seek standard interfaces even between products from the same company. I remember asking an IBM rep why they weren't enabling SMTP, IMAP and vCalendar as the mail protocols between Notes client and server. The rep sneered at me as if I was mad. Why would you use these protocols, he wanted to know, when Notes client and server are so "tightly integrated"? Others on my side of the fence agreed with him. Well, the answer came back to bite the company many years later, when they wanted to migrate to Outlook on the client side. Their "tight integration" had resulted in vendor lock-out, preventing them from connecting to Notes server using Outlook (which standard protocols would have allowed) and they were stuck with Notes client indefinitely. By that time, there were too many other dependencies that had been allowed to work their way in, so enabling open protocols at that stage was no longer an option. That was a great outcome for IBM, of course, but to this day, there are people in the customer organisation who don't see that what happened to them was a direct consequence of their neglect of open interfaces in favour of closed, "tight" integration.
Ultimately, vendor lock-in has implications of cost, time and effort, which basically boils down to cost, cost and cost.
As users of technology, we simply cannot afford it."[/b]
RE: There are political advantages in vendor lock-in
Let's keep working to change it!
Gov't should remember who they serve
At least in the USA those in gov't should realize they are there at the whim of the people. I think in the coming years in the USA they will be reminded of that fact by looking from the outside in.
And when outs become ins
proprietary lock-in as the ins who will then be
outs.
I'm talking about natural motivations here, not
about politics. Political ideals are fine, and I
applaud the fact you seem to like democracy, but
let's not assume it can overcome human nature
unless we're willing to give the system a lot
more attention than we do. (Which by the way is
exhausting.)
You touched on the problem, Dana
The simple cure is to vote out enough incumbents so that their replacements understand that they must play the game fairly.
We need more single-term politicians from the president on down.
Ignorant of the facts?
See my other post on the state government contracting process. Hate to burst your bubble but its not elected officials out there buying software.
This whole discussion is a red herring. Things just don't work that way.
Gov't serves who?
In Britian, people pay a tax to support TV and the production of TV content. Because of this, british tax payers are considerred to own a "share" in the produced content and therefore have the right to view it at any time, with no restrictions. This serves the people of Britian.
But allowing foriegners such as Americans to obtain the same content for free? That doesn't serve the interests of the people of Britian. Those foreigners should need to pay just as the brits do for the content.
How do you enforce this? DRM. You give everyone who pays british taxes "free" access to all content, but restrict it to everyone else. And this is what the BBC iPlayer does and has always done. But it does this to serve the interests of the people of Britian, not anyone else.
Agreed, coporate influence should never control goverment
This like all government corruption, is horrible. Companies should never sway politicians. Politicians are supposed work for the people not their campaign contributors or even their own personal "legacy."
Not only the US
Why do you think that almost no-one (anywhere) went to jail over the GFC?
Who gives the biggest election donations, "Joe Six-pack" or GE, Intel, MS, etc?
lehnerus2000
I like the thesis, but the example may not match.
I was actually looking for something along the lines of an African or South American president who signs a lock-in contract, is voted out of office, and has a nice payoff awaiting him in he Swiss bank accounts.
Why I used the example
personal knowledge. The other is subtlety --
there's no Swiss bank account, no obvious pay
off at the end of the day for the BBC or its
managers.
What there is is a degree of control over users
that no open source solution would ever offer.
And an infrastructure that can't be easily
replaced.
All the BBC wants out of this is to continue
getting tax dollars for its broadcasting.
Putting stuff on the Web is just a means to that
end. And they want control over what they put on
the Web, fearing that bandwidth costs from
outsiders (people who don't pay the tax) will
eat them up otherwise.
A Swiss bank account example gives you a handy
villain. But too many of us think only in such
simplistic ways as "good guy" and "bad guy."
It's time for us all to grow up.
That excludes 90% of ZDNet users
That's why government buyers love Blackberry and Vista.
what software the employees can install on their
computers. I can't even install a font without the IT
department's help (well, *I* can, but then I know the
little tricks that get me around the IT's
administration policies.)
Same goes for the Blackberry. I can't install any
third-party apps on my Blackberry because the IT
department has that functionality locked-out. I
presume that a smartphone with an open-source OS would
be easier to jailbreak.
RE: There are political advantages in vendor lock-in
Where does Idaho rank? We have been living in Montana for the past 5 years and I am not supri<a href=http://www.meusexshop.com>sexy shop</a>to find it #3 on the "worst" list. Considering a<a href=http://www.produtodesexshop.com.br>sexshop</a>move to Idaho to escapthe high cost of living a low income in MT. There may not be a sales tax here but they get you if you own property!