Is open systems dead? Does code portability matter?

Jeffrey Hammond and I did a Teleconference today for clients about the first release of Oracle Fusion Middleware 11g. One of the big areas of concern among attendees was an old chestnut that I actually haven't seen for awhile: Portability. The basic question: If we develop for Oracle's stack, are we locked into it?

Jeffrey and I have documented the basic risks of lock-in we see in Fusion Middleware 11g in our analysis ( I don't want to revisit that analysis here; rather, I'm more interested in why we suddenly heard this concern..

I've been writing about software technology roughly since the birth of the "open systems" movement during the late '80s. At that time, open systems meant SQL relational DBMS + Unix at its core, with DCE and CORBA sometimes tossed into the mix as well. The concern for code portability extended to Java's "write once, run ... anywhere" promise in 1995. And then I think it started to die.

In my experience, by the time we got to 2000, customer interest in portability had seriously dropped off. I almost never heard about portability as a client concern. (Nothing like the kinds of questions Jeffrey and I got today.) It seemed that customers either simply wanted the functionality they needed or had given up on portability as a goal worth pursuing. I've been wanting to figure out what was behind the change in heart about portability for a long time; hopefully I'll start getting some insights now -- from you!

Is code portability important to you? Why or why not? Should we just declare "open systems" dead and move on?


re: Is open systems dead? Does code portability matter?

If you ask me that question as a client, then I indeed could not care less. I'm buying a product that does what I need and I honestly could not care how it does what it does. All I care about is that it does its job and that it does it well on the platform it's running on. That immediately brings up an interesting aspect of "portable code": it's hard to exploit the benefits of the individual platform if you have to run in the same way on all platforms.However, if you ask me this question from a developer point of view, then portability and platform independence is important because it means I can take my building blocks and use them in different projects. This saves me time and money and improves quality since I'm now relying more on already developed components instead of having to start from scratch over and over again.The dilemma that comes from this is interesting and perhaps there is a fundamental difference here between the parts of the software that directly interact with the user (because that is 95% of what the customer sees of the software anyway) and the parts that do the actual work in the background (which are a blackbox for the user anyway, or maybe if you're lucky he forms some highly simplified mental model of it).What is also interesting is how all of this maps onto modern software, which often is web-based... even though I believe not everything can and should be web-based. Maybe even the fact that so much software is web-based is the answer to your question, namely that portability matters.

re: Is open systems dead? Does code portability matter?

John, that is a great question! And yes, Marcel's comment is valid too. Marcel is right that the operating system lock-in with your average tiered application is total as no one can afford to port all of it. Businesses do not care about portability when they should for long-term cost reasons.I experience that problem daily because Papyrus is not just portable, but it runs transparently on most flavors of Windows, Unix, Mac and z/OS. That you can simply deploy a FULL application that was created on Windows to a Unix box in peer-to-peer or n-tier mode - without a porting process - is taken with a shrug and without considering the huge amount of money just saved.As it happens, most analysts do the same thing. I have yet to encounter one who would say: 'Max, this is an amazing capability that will save the average business millions compared to Java/XML over the lifecycle of an application.'So open systems did not just die, but it was killed by allowing everything that is Java and XML to be called an OPEN STANDARD. Let's face it, software vendors and outsourcers like the lock-in of their customers and as C-level only looks to the next quarter and as vendors ticked the 'open' checkmark on the RFP, it became irrelevant.When the analyst community stopped to challenge the arbitrary claims of vendors declaring their products as 'open' they killed the open systems idea.

re: Is open systems dead? Does code portability matter?

John, let me add that this is not an accusation, but rather an observation on what influences the marketplace. Obviously, when a business choses Papyrus they do gain an indepedence from HW and operating system vendors, but the application is 'locked-in' on our platform. So we are all 'guilty' and I openly say so. What I dislike however is the duplicity of vendors claiming to be open systems and standard when that is not true.Thanks for bringing up the question. My answer? 'Open' is dead and has been for some time. Let's focus on empowering the user without locking him into an environment that reduces the dynamics he needs.

re: Is open systems dead? Does code portability matter?

I think there is a fallacy in thinking of client preferences for "open" or "closed" software (or "portable" or "non-portable") as a black-or-white absolute. A software portfolio is more like a wardrobe. You are going to want a major portion of your wardrobe to plug-and-play with as many other items as possible, but you are always going to have a few items that you like so well that you will include them even if you have to purchase other items specifically to go with that one favorite.Software is the same way. When we consider data formats, communication protocols, hardware platforms, operating systems, database managers, application middleware, and all the rest, it is impossible to be completely open and portable at all these levels. You are always going to be "locked in" to some software, and be looking for more flexibility in other areas. Where you are willing to be locked in and where you require flexibility changes over time, based to some degree on the acceptance of industry standards and to some degree on current fashion.In the case of Oracle, my perception is that many customers have been willing to be "locked in" to Oracle's database technology, but much less cautious about getting "locked in" to the rest of their technology stack, unless they are also major users of Oracle applications.

re: Is open systems dead? Does code portability matter?

John - I’m not surprised to hear that portability has re-emerged as a concern among enterprise IT buyers. The drop off in interest early in the decade was likely due to the fact that every vendor had a story, thus making it a check-box item on a buyers list. Recently however, the market’s consolidation has left us with mega-vendors offering hardware, OS, infrastructure, and application stacks. And, because vendors can offer the ‘whole’ package themselves, portability is becoming less of a necessity in product development. Unfortunately, this lack of portability presents a heightened likelihood of vendor lock-in, which can impact costs with mega-vendors charging more because choices are limited. Ultimately, cost is the driving factor behind the re-emergence of the ‘portability’ concerns and questions, and rightly so, because budgets are tight and the benefits of higher productivity that mega-vendors might deliver has to be carefully and thoughtfully measured against the long-term pitfalls and costs of vendor lock-in.