Last time: “The Old Language-Centric Products Categories,” in which I said that the old model for vendors was to specialize in one of either language engine, libraries, or developer’s tools.
Now: What would happen if we generalized this approach?
[This is an excerpt from a Lisp conference talk I gave in 2002.]
Think about that job listing for a J2EE developer. How did that company – a bank – come to require that set of skills? They didn’t pioneer the use of Java. They didn’t pay a grand or more per seat for a single-vendor programming environment that would produce unknown results. They gradually adopted Java, and the J2EE platform, and the tools available for it, and the community that comes with it. Maybe they had experience with some of the listed vendors from work with other software platforms.
Suggestion: For our fishbowl, I’d like to suggest that we think in terms of providing a “platform” for a class of applications, rather than providing a “language.” A platform is a suite of interacting tools at different levels, and used by different people, to accomplish a set of software tasks related to a given application architecture.
For example:
The J2EE and .NET platforms, as opposed to the Java and C# languages.
The target is distributed enterprise applications (though .NET might be reaching for more).
The Unix platform, as opposed to the C language.
The target is individual or small-groups of scientists and engineers. Variations on the platform have been developed for realtime systems and, accidentally, for hosting the J2EE platform or other Web servers.
The MS-Office/Windows platform, as opposed to Visual Basic.
The target is personal productivity.
A user community is a market. Notice how the emphasis is defining a community around an identifiable set of applications. This allows and even invites multiple vendors to provide different pieces. It allows for incremental adoption of products. It doesn’t count on runtime licenses. All this makes it easier for organizations to join the community in the hope of more repeatable development of the target applications.
There may well be a compiler for a single language, libraries, and tools, but this is not the emphasis. There may well be a single vendor. But the aura is that of multiple, interchangeable vendors, providing products and services to various market segments within a community built around common applications. For example tools are focused on methodology and deployment for the applications. These are language-neutral source control, project-oriented editors, deployment wizards. One reason we don’t have even de facto standards for these in Lisp is that thinking about all that we can do with the language doesn’t allow us to prioritize design features for these functional tools. Similarly for C, Java, etc. But for application domains on a given platform, such as n-tier business apps on J2EE, there are some recognizable best practices, and that’s what the tools get created for this specific problem.
OK, so we think about platforms. How does a single vendor create a platform community?
next: Can’t Make a Killing From Platforms Without Killing the Community.
Start of nine part series.
Sun seems to be following this approach, empahsizing the J2EE platform rather than the Java language. (_se_6.html” rel=”nofollow”>http://radar.oreilly.com/ar…) And they’re following the ideas on the next post, too.
Not that one example proves anything… I just cite this to illustrate.
With the hindsight of what I know do with Croquet, and what I also do wearing my enterprise software hat, it’s hard to believe that I described J2EE as being for “DISTRIBUTED enterprise applications.” Ugh. Having a bunch of Web browsers all bowing to centralized big-iron is not my idea of a distributed architecture today.