The Platform Strategy

Every software entrepreneur I know dreams of building a platform business. Not just wistful “wouldn’t it be nice” stuff, no, I mean an all-consuming lust to become that which others build on. Led down the garden path by the example of Microsoft’s dominance in the desktop market, believers in the platform strategy view ubiquity and control as the backstop against comoditization and a foothold for launching new attacks against the competition. The part that’s not so obvious is that becoming a platform means that you first have to come close to winning the market on non-platform merits at which point, voila!, you’re a platform…so long as you haven’t made it impossible to build on your stuff.

I got to thinking about this because the tiny sliver of time that Java occupies in my mind these days is generally dedicated to dissecting it’s rise and fall. The more time I spend on it, the more I realize that what’s happened to Java in the last couple of years is a failure to recognize a couple of things:

  1. that Java won, despite it’s myriad warts
  2. that winning is not a god-given right
  3. that you can’t expect to win on your own terms

In fact, Java never won on its own terms. It won by having enough pluck and backing to build up a real, honest-to-god platform. The platform became a platform because it got used for enough good things that it came close (enough) to winning the market for a certain class of apps. Java the language is a pitiful mess. Java the platform? Now that’s a thing of fucking beauty. Not only did Sun build the alliances necessary to ensure that Java would be available to whoever wanted it, the “Pure Java” marketing actually worked.

The result is a system that won because it created an environment where, no matter what the OS, developers could plug in a set of Java libraries (I’m ignoring the JAR cluster-fsck for now) and know that it would all “just work” thanks to a common bytecode interpreter. Now, other languages have used a similar form of platform aikido to catapult themselves into utility. Python, PHP, Perl, and Ruby spring to mind as languages that don’t really mind their C dependency chains. Quite the contrary! The communities around these languages (rightly) consider being able to “swig up” some C or C++ hairball as something they can script as a core feature. It allows them to turn one platform win into another. Which is exactly where Sun continues to self-destruct.

Instead of understanding that they won the platform war and will inevitably lose the language skirmishes, the Java camp seems hell-bent on trying to shoehorn Java (the language) into ever more places that it doesn’t belong. JSR 290? Gimmie a freaking break.

All of this points to a bright future that Sun, currently, seems too limp-willed to exploit. There’s an amazing amount of good code that people have churned out in Java. The “Pure Java” thing actually played! Instead of allowing the partisans to throw stones at folks who want to run other, more productive, languages on top of the JVM (aka: the platform), Sun should follow through on it’s baby steps and start giving real respect to the dynamic languages folks who want to help them continue to win on a platform (not language) basis. Hiring the JRuby guys and shipping jrunscript (aka: Rhino) in Java 6 are good first steps, but they don’t go far enough. The atmosphere has to change. Acrimony needs to be turned into understanding, and real investment needs to be made in making the platform successful, even if it comes at the cost of one particular language.

It’s not too late. I hope.


  1. Michael Tildahl
    Posted September 28, 2006 at 2:32 am | Permalink

    Have you seen JSR-292?  It’s a start, but seems to me they also need support for closers in the JVM before you could get dynamic languages to run straight on the JVM.

  2. Posted September 28, 2006 at 2:56 am | Permalink

    hey Michael,

    So a hotswap operation starts to scratch the surface, and I hope it succeeds. Folks really get defensive when you bring up continuations and non-local return. There are some proposals floating around for perhaps doing more than putting lipstick on the pig ( and, but until we get something substantial like real VM-level support for enclosure, it’s gonna be hacks on top of hacks (as it is now in JRuby, Jython, Groovy, and Rhino).

    I’m tempted to see what it would take to bootstrap Java on top of Parrot. At least it’s designed for this kind of (highly productive) workload from the ground up.


  3. grumpY!
    Posted September 29, 2006 at 9:09 pm | Permalink

    alex, i am puzzled by your comment regarding perl’s portability (i cannot speak to the others with confidence). by “not minding their C dependency chains”, what do you mean? perl compiles on literally dozens of platforms, and correct perl5 code should likewise function on those platforms. of course bugs have arisen over the years, but fewer and less pernicious than those in the java world. oddly enough it is the closed nature of the jvm that has precluded its expansion to many of these same esoteric platforms…those interested parties moved on to projects like gcj et al long ago.

    as to the jvm becoming the pre-eminent vm for dynamic languages, i have my doubts, its a different problem that demands a different solution, and it is unlikely that a critical threshold of developers will shift from their native execution platforms (perl5,python,ruby) to help push forward a jvm-based alternative.

    personally, i don’t want a platform. i want standards and protocols. let me figure out the best implementation as i size up my problems individually. sometimes it is lua (i need a tiny runtime). sometimes it is haskell (i want the type system to nanny me). sometimes it is perl (regexes).

  4. Posted September 29, 2006 at 10:17 pm | Permalink

    hey GrumpY!

    What I mean by “not minding their C dependency chains” is that instead of doing the Java thing and getting all bent out of shape about potentially non-portable C dependencies, these languages just went ahead and built out the API’s that matched the underlying libc semantics without worrying about it too much. The Win32 stuff got filled in in time, and everyone lived happily ever after (as you point out). They used the ubiquity of a good (enough) standard C library to swiftly beat Java to any number of punches. As you probably know, I’m partial to Python over most other things, and the fact that my dusty memories of glibc man pages continue to serve me well when I ask myself “how do I do X?” in python continues to make me smile. What I’m suggesting is that for the millions of folks who know Java, wittingly or not, the JVM-as-platform hosting better languages could provide a similar advantage. I’m not saying it’s potentially the best way forward, but if I were in Sun’s shoes, I’d at least be throwing money at it.

    I totally agree that Sun has f’d themselves repeatedly by not opening up java development.

    As for the JVM as a basis for other languages, Sun could have made the JVM a much more inviting place for dynamic languages quite some time ago had they cared to. It’s not obvious that by better supporting dynamic languages Java will get back whatever mojo it may have had, but frankly anything would be better than the slow, self-imposed death spiral it’s now in.

    Java set out to raise the average, and it has in many ways done that. It’s not a way of working that I’ll ever willingly subject myself to, but insofar as I appreciate that it’s good in the aggregate that average programmers be writing Java and not C or C#, I support it. I’m pretty over trying to convince average programmers that they’ll be tons better with Python or Ruby. They probably won’t be. What worries me is that “raising the average” got confused with “defending one approach for raising the average”, and that Sun seems to have lost the plot of whatever good they were doing for the world.

    Hopefully that clears up some of my muddied thinking.


  5. grumpY!
    Posted September 30, 2006 at 8:56 am | Permalink


    i agree with your assertion that proselytizing to java programmers has little value. i always tell people to code in the highest level language they can get away with that they are also experienced with. for the ten year expert in java, he will get to a solution faster than were he to try ruby.

    as to the runtime issue and the appropriateness of a vm for a static-typed (not to be confused with strongly typed) language like java for tools like python is up for debate. in the long run, moore’s law solved the issue – any language on any vm. until then, it is worth noting the differences. haskell, for example, does no runtime type tagging – the compiler precludes it.

One Trackback

  1. […] forget Scala, Nice and other “non-dynamic” languages that target the JVM). But Java the platform has not gotten widespread or serious attention until recently (witness the recent resurgence of […]