Only a customer can define the word “open.” That’s my view.
There’s been a lot of discussion of “open systems,” “open source,” and “open standards,” over the past – well, 30 years – and I’d like to add some refinements to the current debate. Granted, I seem to spend a disproportionate amount of my time defining things, but it seems like a lot of industry rhetoric right now depends upon redefining history and vocabulary.
So let’s start with my friend David Kirkpatrick. David just wrote an interesting piece which suggests “open” is really defined by the degree to which a vendor seeks interoperability with other vendor’s products. I agree with much of the article, but my view is David’s article misses a critical subtlety.
Which is that for the most part, the definition of open that matters most is the one experienced by a customer or end user – “openness” is defined by the ease with which a customer can substitute one product for another. If you love a product, but the vendor providing it triples its prices, how easily can you move from that product to a competitive product? If it’s an open product, the customer will say it took no work. If it’s not open, the customer’s choices will be impeded – their options will be closed (and they’ll find themselves paying big bucks for products).
And although I know I’m about to (once again) annoy an entire demography on slashdot, this discussion, of enabling substitution, is largely orthogonal to whether the source code to a product is available. In the sense that by the definition above, if the barrier to entry in providing a substitute is complicated by issues other than access to source code, then the product cannot be considered open.
Let me offer two examples, and how the concept of “open” is made operational at Sun.
The two examples are the Java 2 Enterprise Edition (known as J2EE), and lest I run afoul of my good friends in the linux community, Unix.
First, let’s look at Unix (not linux, folks, relax, I said Unix).
Let’s start with a little known fact: the source code to Solaris is available. The odds are good, somewhere in your enterprise or academic institution, you have a complete copy of the source tree (especially if you’re reading this from Wall Street). And I’d like to start off by completely dismissing the relevance of that fact to the determination of whether Solaris or Unix is open.
Let’s instead look at what it takes to move off Solaris, and onto, say, IBM’s AIX.
How easy is the move? It’s not particularly easy. There are features in Solaris, like the Java Enterprise System Directory Service, N1 Grid Containers, dTrace or ZFS that don’t show up in AIX. Nor is there an industry agreed upon definition of Unix to enable a neutral test, or a certification, of what you’re using. There was, it was called POSIX, but then all the vendors (Sun among them), went well beyond POSIX in delivering operating system distributions – we added app servers and directory engines and web services infrastructure, innovations that saved customers millions of dollars, and tons of effort. But using those features made it difficult (but by no means impossible) for customers to substitute Unix vendors – and as IBM slows AIX investment, Solaris is bound to leapfrog even further. So is AIX open? Does it promote choice? Well, by that sword, is Solaris? Or moreover, Red Hat?
Ask a customer – open describes the level of effort it takes to enable substitution. If it’s tough, it ain’t open.
So what if a customer wants to move today? It takes work. Is it doable? Sure, but depending upon the sophistication of your application, or the extent to which you’ve taken advantage of Solaris’s innovation, it’s far harder to move from Solaris to AIX, or Red Hat to SuSe, than from IBM’s WebSphere to BEA’s WebLogic. Run the same analysis on moving a reasonably complete .net application (eg, not IIS) from Windows to a substitute. You have to rewrite it (which, of course, many people do – but that’s beside the point.)
To make matters worse, if you’re running your Solaris app on industry standard x86 servers, and you want to move to AIX – well, you can’t, because IBM doesn’t make its operating system available on even its own x86 servers. Of the Unix suppliers, only Sun makes Solaris available on x86. Even IBM’s x86 servers.
Open as in door, is different than open as in source. Unix, linux, Windows – none are open, I’d argue. There is no agreed upon specification, no neutral test to determine validity, and no guarantee made by vendors other than rhetoric.
Now, onto J2EE.
As you’re well aware, there are several great application servers in the world, all adhering to a publicly available specification – BEA swept the market early on, and continues to drive some extraordinary innovation; IBM has made great fanfare of WebSphere; Sun has made its application server the backbone of JES, and free as the J2EE Reference Implementation; and of late, a few open source entrants have entered the field. There are probably 20 others I’ve missed – from Oracle, Borland, Sybase, JBoss, Pramati, many many others. And for any of these vendors to fly the “J2EE” flag, to use that brand as an assurance to customers, they must pass a common compliance test, contained in a Test Compatibility Kit (TCK). Fail the test, you can’t fly the flag. That’s how we preserve compatibility, and portability (which as you probably know, we’re a bit touchy about).
So imagine you elect to move off Sun’s app server, to move to IBM’s WebSphere. To check to see if you’ve written to an instruction that isn’t in the J2EE standard, you could have your development staff run our Application Verification Kit. The AVK tests to see if you’ve inadvertently defeated portability in your application. You’ll soon realize there’s nothing stopping you from moving off of Sun’s app server to WebSphere – so you move the application over, and resume running your business.
If you think about it, industry participants are incented to enable substitution – if they impede it, they can’t fly the “J2EE” flag. In this instance, the measurement of “open” is ultimately made by a customer swapping out one app server for another.
Where’s proof? Imagine you come to your senses next quarter when IBM asks for a big license fee (did I mention Sun’s app server is free on all platforms?); you run the AVK again to see if you’re gotten hung up on any IBM “enhancements” that go beyond J2EE; and if the answer is no, you move back. Substitution is enabled.
Is the source code available? It doesn’t matter – what matters is adherence to a standard to enable substitution. An Open standard, publicly available, for which a neutral test can be supplied (the TCK/AVK). If I failed the AVK, and had source to WebSphere, would it matter? No. I’d have to invest time and resources in moving, far more than if I’d stay faithful to J2EE. Open standards promote substitution, and thus competition. They are the standardized rails of the network – and the customer’s best friend.
And before I conclude, I’d like to make one final point – one that I’ve skipped over, above. It’s that the true cost of substitution is, as Chad Dickerson points out, seldom defined simply by the technical effort to port. It is as much, or moreso defined by the economic cost of qualifying or requalifying applications running on one production stack to another production stack.
For example, as we continue porting Solaris onto IBM’s Power architecture (demo coming soon!), the real issue we have to grapple with isn’t the expense of moving our software over – it’s the expense of requalifying all our, and all our ISV’s infrastructure once the port is done.
We’re hopeful IBM will support us (there are certainly enough of their employees reading these blogs to suggest they’re paying attention) – and not close off choice and substitution to its customers.
Were I a CIO facing these issues, I’d stay focused on the one thing definitively under my control – keeping the cost of substitution, of at least application portability, as close to zero as possible.
You guessed it, I’d write to Java. And I’d keep my options…