In particular, John Siracusa suggests that Microsoft:
- Catered to the enterprise even when that damaged the health of their platform.
- Failed to capitalize on the strength of their hand by moving the platform forward when their customers had nowhere else to go.
- Has tended to react to moves made by others rather than being first-mover.
These are tightly coupled with one another, there's a surprising amount of overlap between them, but they each describe some nuance that the other does not.
Each of these has a strong parallel in the history of the Java platform.
Because the control structure of Java is distributed, with Sun, IBM, Apache, open-source contributors, the JCP and so forth, I'm mostly going to talk about Java personified, as if Java itself could have made decisions. That's clearly not true, and it shapes some of that which follows, so I'll talk about that as well.
Catered to the Enterprise
Java developers, as a group, are mostly people who build server-side database-backed web applications for medium-to-large corporations for internal and public use. There are lots of exceptions to the rule in terms of desktop software, non-web-based or non-database-backed server-side code, gaming servers and so forth, but these are a small subset of the overall Java marketplace.
Those guiding the Java platform have set their sights on various markets, from client and desktop software (AWT, Swing, Applets, Java Web Start, JavaFX) to the Web (Servlets, JSP, JSF), media, gaming and the enterprise (Java EE, Enterprise Javabeans, CORBA), but it's clear that the Enterprise/Web market has always been the stronghold for Java.
Although Java would make attempts at these other markets, they were usually half-hearted and quickly abandoned. It was too easy to continue to emphasize the technologies that mattered to the enterprise and too hard to push into other markets. This also meant that any new announcement about media, gaming, or a client technology would generally be greeted by skepticism by analysts, development companies and individual developers -- each expected that these technologies, interesting though they might be, were probably going to die on the vine out of sheer neglect.
Failed to Capitalize on a Position of Strength
Java started with a number of innovations -- it really popularized namespaces with packages, garbage collection, thorough object-orientation, a virtual-machine-based platform. All of those things existed before Java, but Java really brought those to the masses, made them popular.
However, as Java became more popular, it became far more cautious about innovation, choosing to favor backwards compatibility over significant change. This caused the language to settle down, to stagnate or mature, depending on how you feel about the results. It became a language in which you could get things done, but a language about which one might cease to be excited about.
The runtime started to take on bloat as things would be added (JavaDB, CORBA), but never removed, no matter how little they were used. There has been some talk about modularizing the JVM, but it's only talk, and too little, too late at that.
In order to ensure that conservative development organizations could upgrade without having to think about it, classes and methods would be marked as deprecated, but never pruned. As a result, you could start to tell when an API was created by the age of its dependencies. For instance, HttpServlet in Java Enterprise Edition 6, delivered in 2009, still uses Enumeration despite the fact that it has been essentially replaced by Iterator in Java Standard Edition 1.2, delivered in 1998, eleven years earlier.
It didn't need to be this way. Throughout much of its history, Java was in a position of strength with its primary customer-base, the enterprise. If the guiding forces behind Java had said, "Ok, this has been deprecated for two major versions, let's get rid of it now" I'm entirely sure that their most cautious enterprise customers (e.g. major banks) would have grumbled and complained, but gone on to modify their code to remove Enumeration, Vector, Date.va getYear() and other similar pieces of outdated Java code.
Sure, it's a pain to update your code on a mature program to reflect changes in the platform, but think how much more of a pain it would be to port that mature program to .NET, let alone Ruby or Python. Where did Sun and Java think these enterprises were going to go if they pushed back a little?
Java could have capitalized on this strength and taken the opportunity to move the platform forward even when that meant some grumbling from the enterprise customer base, because the cost of switching was too high. This has to be done carefully -- you can only push so hard without alienating your customers, but Java didn't push at all.
Reactionary
Because Java has catered to its enterprise customers and failed to capitalize on a position of strength, the rate of innovation dropped off precipitously. This put Java into a reactionary mode where changes were only made as perceived threats grew stronger and reacting to those threats became vital.
This means that for years, Java hasn't been the innovator, but simply introduced changes to stem the bleeding caused by other languages and platforms innovating around it. Look at the rate of change to the C# language in the same timeframe that it's overlapped with Java. Look at Java continue to struggle with generics and closures, let alone platform modularity and aging libraries.
People don't look to Java to innovate anymore, and that means they're not excited by Java, and as they get excited by other languages and platforms, their attention wanders. Java has been ripe for disruption for years, and sooner or later another platform or language is going to make that happen.
Java's Control Structure
Java's distributed control structure and odd profit models have encouraged much of the above. Sun, Oracle and IBM, key figures in steering the Java platform, are all large businesses targeting enterprise software development. They all make most of their Java-related money from consulting rather than selling tooling, or direct sales to end-users. So it's no real surprise that these organizations would choose to cater to the enterprise.
The control structure is also very distributed, with a committee based on these organizations and individual expert contributors. This kind of control structure is good for getting consensus, but is often cautious and rarely innovates. That tends to result in making cautious moves, rather than bold ones that might capitalize on a position of strength, and this tends to lead to a reactionary approach.
Ultimately, you could probably argue successfully that much of what ails Java are a direct result of its control structure and participants. This structure is very different than Microsoft's, although you could probably also argue that their problems are structural.
In Summary
Java, like Microsoft, has not aged gracefully. As each got popular, it also got more cautious and settled into some long-term patterns that guaranteed that it would please its primary customer-base, the enterprise, at the cost of long-term health. Both are in decline and ripe for further disruption.
Neither is likely to go away any time soon -- they both have their hooks in deeply with the enterprise, which will hang on to avoid the cost of change, but both have their best days in the rear view mirror and can only hope to age gracefully, rather than find new life.
In Java's case, there's some possibility that another language will find strength while building on top of the rest of the Java platform, in particular the virtual machine. I suspect that even these are simply stop-gap measures while the libraries attached to the JVM continue to decay, but that's the subject of another post.
Ultimately, Java is still a perfectly solid environment on which to build enterprise software, but it's now the safe choice, not the interesting one. That's been true for years, and it's only a question of time before some other language and/or platform finds dominance over Java and increases the rate of decline.
No comments:
Post a Comment