Linux: innovation platform or commoditising force?
A few days ago Matt Asay wrote a piece on
Linux's use on Wall Street in his "Open Road"
blog. He recounted how one of the MDs from Bank of New York Mellon saw "open source as the foundation of choice for their innovation". He goes on to say that this runs counter to prevailing opinion, which positions Linux (and open-source software technology in general) as a commoditising force.
It's not as straightforward as he makes out, though: in truth, Linux is BOTH a platform for innovation, and a commoditising force. It's always, in fact, been this way: there's one community that is most attracted to the fact that Linux code can be tweaked and reconfigured in extreme ways (you just have to look to
Google's widely-cited work here to see what I mean). And there's another community, less vocal but much larger in number, which is much more attracted to the fact that open-source software tends to be "free" (of charge) than it is to the ability to mess with the source code.
So Linux (like many other open-source software technologies) has two markets and two demand curves associated with it: one is populated by companies with leading edge technology use requirements; and the other is populated by companies who want to align their technology expenditure much more with the business value they receive from it, and see the lack of an up-front license fee associated with open-source software as a perfect route to do this.
When looking at technologies like this and commenting on their role in industry, we need to be careful which market we're really referring to.
Labels: industry, innovation, Linux, open source
The lore of averages
I was chatting to a friend who's a top-notch Java developer over the weekend: we were shooting the breeze about Groovy, Rails, Spring, Hibernate and various other Things That Get People Excited (let's call them TTGPEs), and discussing how far they were likely to penetrate into your average IT shop. "Why do so many people insist on following the J2EE application model and associated patterns so slavishly," said my friend, "when they're so plainly not the right tool for the job in so many scenarios?"
"The thing that you never get from reading development books," I said - he'd just finished showing me a book on Groovy - "is how difficult it can be for your average IT shop to get on board with a new development technology, when you take commercial considerations into account. You can see from looking at code samples that language A is more compact or give you more productivity than language B. But what you can't see is the bigger picture of costs and risks."
I remembered a post of Steve Jones' I'd seen a couple of months back about
development as a discipline for the masses - and also
this one from Jeff Schneider about the value of SOA governance.
You see, the problem for your average IT shop in taking on TTGPEs is that even when they have been demonstrated to save time and/or money, there are two real barriers to adoption. Both barriers exist primarily because these shops have no option but to see development resources as a commodity.
First, within an average IT shop - think of one within a small utility provider or a local government - the business can't make a case for paying top whack to hire the very best developers. So, they have to shoot for the "mass market" of developers - hopefully capable and dependable, but not likely to be stellar performers. They also don't have a lot of time or money available for recruiting, so they tend to minimise the complexity of interviewing as far as possible - asking for "industry standard", well-recognised skills. Unless they can find TTGPE skills within that "mass market", they're not going to consider bringing those skills into the organisation. J2EE skills are now mass-market skills. Groovy skills aren't (yet).
Second, within such an IT shop, work tends to follow those same "industry standards", because the risk of doing TTGPEs is that if people leave or get sick, and new people have to be brought in, they have to be able to get new resources up-and-running quickly. If new staff have to spend weeks or months trying to re-engineer glamorous but unknown technology before they can continue a project, that's a huge, ugly cost.
Regardless of whether J2EE is increasingly being revealed to be more like a VW crossed with a tractor than a Ferrari, then, the truth is that most people have little choice, for now, but to stick with it and make the best of things.
Labels: 4GL redux, development, governance, industry
Putting customers first?
Most readers will by now be familiar with the recent sparring between Oracle and BEA (just see our
del.icio.us links over the past days to get an update if you're not up to speed). There's been plenty said about this already of course, but I thought it would be fun to look past the "industry insider" angle and consider what this piece of theatre says about the IT industry and what it means for the organisations that this industry sells to.
The original (publicly stated, but unsolicited) offer to purchase BEA came from Oracle on October 12th. It was surely no coincidence that after years of alleged courting by Oracle, the offer finally came once "activist investor" Carl Icahn had acquired a significant position as a BEA shareholder. Icahn started his BEA investment run-up in early September, and now owns around 13% of the stock. As part of his initial disclosure of stock purchase, Icahn's company stated that the purpose was to attempt to get BEA to sell itself in order to deliver more value to shareholders.
[Just to put some numbers on that "value", as mentioned
here, if BEA had sold to Oracle for $17 a share, Icahn would have stood to make a $217.1m profit (that's roughly a 33% return on his $663.8m investment) in just a couple of months.]
Of course it's fair to argue that BEA has sometimes failed to capitalise on technology and business trends in ways that it might have done, and as a result its technology could deliver more. Icahn does have a point when he says that ISVs in general face an uncertain future as business models in the ICT industry change and value flows increasingly away from hardware and software (catalysed by open source and commodity hardware) and towards services.
But is Icahn's prescription for BEA (a sale) the right one?
This article appraises Icahn's record and on that reading, he's certainly been far from infallible. For one minute, let's look past shareholder value in isolation, and consider the business that BEA is in.
BEA is a company that's built its business on being a
middleware provider that can operate independently from the other technologies that middleware has to interoperate with - databases, desktop software, packaged applications, hardware, management consulting services, and so on. Indeed BEA has often said itself that its position is as "the Switzerland of enterprise software".
Not every medium or large organisation needs its middleware provider to be "Switzerland" of course. But in a large number of organisations, particularly financial services firms, telecoms providers and governments with extensive, decades-long IT legacies, there's sufficient heterogeneity to warrant building a strategic relationship with a supplier that can operate independently of all the other stuff and is less likely than others to favour one technology over another. This is a sound strategy based on sound policy (in other contexts, it's called
separation of duties).
Many companies have built relationships with BEA precisely because it could offer them this kind of relationship. And middleware isn't like vacuum cleaners, or even
airline seats: companies (particularly large companies) want long-term relationships with their middleware providers. If BEA is sold - to Oracle, or pretty much anyone else - those customers are going to have the rug pulled out from underneath them. Customers who made strategic IT bets on an independent middleware vendor will have to reappraise their investments and quite possibly spend a heap more money trying to either rejig their strategies, or build new relationships with new suppliers (although options for those wanting a slice of Swiss neutrality are limited: there are only two other software companies of any real size with similar positions -
TIBCO and
Software AG).
So - to get to the point: what's troubling me is that in the IT industry, there's often much hand-wringing about how poorly IT and IT vendors are perceived by businesses, and how everyone needs to work harder to build bridges and raise a positive profile of how IT (and IT vendors) can add value to organisations.
But if the IT industry continues to shuffle deckchairs in the name of shareholder value, to the detriment of customer value, can anyone be surprised when business wallets remain tightly controlled and IT staff, and vendors, are viewed with suspicion by the global community of business IT buyers? If Icahn wants BEA to become more competitive and deliver more value to shareholders, there are more ways to go about it than selling the company. It might be that those prescriptions take longer to kick in than Icahn's current favourite, though. That probably makes them less likely to be pursued.
Am I being hopelessly naive? Let me know your take. It would be good to start a bit of a debate here, I think.
Labels: BEA, industry, interoperability, Oracle
