clinton east

There’s always a great hullabaloo when somebody uses the word ‘open’ or ‘free’; it almost as dangerous as using the word ‘irony’.

Jonathon Schwartz has had something to say about “open” lately, and naturally, the world is listening. In redefining the term “open”, Schwartz challenges what a customer really intended to mean, very convincingly. Mr Schwartz highlights several barriers to substitution; arguing that from the customer’s point of view, source in-and-of-itself, does not lower them. Rather, he asserts that there are other economic factors at play, factors which moot the issue of source availability. By the end of the entry, Mr Schwartz has presented a compelling argument, citing his company’s flagship product (J2EE) as a platform and method of minimizing subsitution risk.

I was reminded of his similarly well-written, and illuminating post some time ago which dealt with commoditization . Interestingly, here Schwartz asks us “… but what’s really commoditizing? Bandwidth. Not software, not hardware, bandwidth.” One striking feature of Mr Schwartz’s argument is that by the end of the article Mr Schwartz talks about a commoditized Java platform. Implicit for the complete argument to make sense is that earlier, when he spoke of software, really he meant applications for end-users, as opposed to architecture and playing-field levellers.

It’s interesting that Mr Schwartz doesn’t directly talk about commoditization in the former (and more recent) article. Mr Schwartz’s argument makes perfect sense viewed from the perspective of a common (in this case Java) platform. Substitution is not an issue because of Sun’s admitted ‘touchy’ position on compatibility. However to extend that to treat source as orthogonal to substitution belies the assumption of a commodity platform, namely Java. Is Java truly a commodity? Eric Raymond doesn’t think so . And if one were to accept Schwartz’s argument, wouldn’t that cede a good degree of control to Sun? Are there good alternatives? Arguably yes, with Amazon running after perl, and a similar arguments running around for PHP.

Mr Schwartz rightly points to selective-differentiation as means to success; in essence, differ where you can effectively compete. However in doing so, Mr Schwartz seems to presume using Java as a platform, rather than source and a compiler (to ensure interoperability), or some other technology. His argument for “open” seems to willingly conflate platform independence and a perceived need for the centralization of control. So I guess Raymond’s argument of control or ubiquity really depends on whether the community at large are happy to let Sun retain the stewardship of the Java platform; one comes off as perhaps idealistic, to the other’s rational-if-slightly-unfortunate pragma.

In the Sun world, you have commodity protocols, and a commodity platform (Java) which aims to eliminate subsitution risk. In Eric Raymond’s you do this with a compiler and the source code. Schwartz’s world certainly sounds more elegant, if at the price of some control for the user.

There’s always a great hullabaloo when somebody uses the word ‘open’ or ‘free’; it almost as dangerous as using the word ‘irony’.

Jonathon Schwartz has had something to say about “open” lately, and naturally, the world is listening. In redefining the term “open”, Schwartz challenges what a customer really intended to mean, very convincingly. Mr Schwartz highlights several barriers to substitution; arguing that from the customer’s point of view, source in-and-of-itself, does not lower them. Rather, he asserts that there are other economic factors at play, factors which moot the issue of source availability. By the end of the entry, Mr Schwartz has presented a compelling argument, citing his company’s flagship product (J2EE) as a platform and method of minimizing subsitution risk.

I was reminded of his similarly well-written, and illuminating post some time ago which dealt with commoditization . Interestingly, here Schwartz asks us “… but what’s really commoditizing? Bandwidth. Not software, not hardware, bandwidth.” One striking feature of Mr Schwartz’s argument is that by the end of the article Mr Schwartz talks about a commoditized Java platform. Implicit for the complete argument to make sense is that earlier, when he spoke of software, really he meant applications for end-users, as opposed to architecture and playing-field levellers.

It’s interesting that Mr Schwartz doesn’t directly talk about commoditization in the former (and more recent) article. Mr Schwartz’s argument makes perfect sense viewed from the perspective of a common (in this case Java) platform. Substitution is not an issue because of Sun’s admitted ‘touchy’ position on compatibility. However to extend that to treat source as orthogonal to substitution belies the assumption of a commodity platform, namely Java. Is Java truly a commodity? Eric Raymond doesn’t think so . And if one were to accept Schwartz’s argument, wouldn’t that cede a good degree of control to Sun? Are there good alternatives? Arguably yes, with Amazon running after perl, and a similar arguments running around for PHP.

Mr Schwartz rightly points to selective-differentiation as means to success; in essence, differ where you can effectively compete. However in doing so, Mr Schwartz seems to presume using Java as a platform, rather than source and a compiler (to ensure interoperability), or some other technology. His argument for “open” seems to willingly conflate platform independence and a perceived need for the centralization of control. So I guess Raymond’s argument of control or ubiquity really depends on whether the community at large are happy to let Sun retain the stewardship of the Java platform; one comes off as perhaps idealistic, to the other’s rational-if-slightly-unfortunate pragma.

In the Sun world, you have commodity protocols, and a commodity platform (Java) which aims to eliminate subsitution risk. In Eric Raymond’s you do this with a compiler and the source code. Schwartz’s world certainly sounds more elegant, if at the price of some control for the user.