Tech
NetBeans may be a hedge for ISVS against messy client choices
These are just the sorts of things that Oracle is thinking over as it decides what to do about NetBeans.
I just had an intriguing analyst briefing with some NetBeans folks at Sun Microsystems, and I'm beginning to think the public discussion on the Eclipse-NetBeans thing (or is it mostly the SWT-Swing thing?) is missing the larger strategic perspective. From the vantage of an architect or CIO -- and not necessarily strictly from the view of developers -- there could be a lot more to NetBeans and its tools progeny, Creator and Studio, than meets the eye.
My new-found interest in NetBeans 5.0 comes as a result of the different fundamental directions that software development is now faced with. These are just the sorts of things that Oracle is thinking over as it decides what to so about NetBeans. Indeed, there are multiple imperatives that factor into how to best plan for future software development, and they are not well aligned. They are actually increasingly at odds. Smart ISVs will seek a way to mitigate risk, and avoid being led down a garden path to less than optimal addressable markets.
One imperative (let's call it the legacy client support one) suggests that planners should designate tools, frameworks, and platform targeting based on applications that must for a considerable period of time target and span multiple and divergent native client targets -- from PDAs to cell phones to the usual gang of PC platforms, Windows, Mac, Unix, and Linux. The largest camp here is Windows-based clients, and there are a lot of them and they are not going away any time soon.
Another imperative (let's call it the client-agnostic one) suggests that planners should move beyond legacy clients and make their strategic development choices based on the primary concerns of server-side logic and frameworks as targets, of moving as quickly as possible to applications that reach the end users via server-managed clients, browsers/portals, and the rich mix from AJAX, REST, and the Web 2.0 stuff. There's a lot of momentum here, and enough client-side Java and browsers across the legacy clients to make this a compelling philosophy.
Anticipating these imperatives are the Eclipse ecology constituencies, which certainly seems to favor the move away from native client targets and the messy plug-ins process that entails toward applications of, by, and for the server. This direction was given a boost this week when IBM at Lotusphere announced that the latest multi-purpose clients, WorkPlace 2.6 and the forthcoming Hannover version of Notes, will not only both be server-managed clients but that the WorkPlace 2.6 client plus IBM's portal server will become the preferred GUI-tier for SOA and composite applications for all of IBM development. Java on the client is, of course, supported, but multi-purpose is the key. This is significant.
One can surmise that new levels of extended enterprise productivity and business process automation will become the strong breeze in the sails of the Eclipse community toward the tightening embrace of the client-agnostic imperative. The strategic development tools choices, then, should focus on how to organize, attach, and manage the services among and between the servers, not the clients.
Also anticipating these imperatives are Windows ecology constituencies, which certainly seem to favor the "connected computing" approach enabled by the Microsoft Visual Studio 2005/.NET/Vista/Indigo/Avalon assortment. Their direction seems to re-encourage a tightly coupled client (especially Office 11/12), and to a lesser extent support browsers and AJAX-like GUIs. The convulsion in terms of how to balance the fat client with the rich client for Microsoft was evident at last October's PDC, and the subsequent memos and reorganization announcements. It has not been settled yet, and the market will ultimately decide (this time).
And then there is NetBeans, which seems to have quite a bit to support both of the imperatives, and also has the lynchpinadvantage that it deeply supports Java at every twist and turn. And it turns out that Java has a strong and encompassing role to play for the legacy client support imperative. And Java has a strong and encompassing role to play in the client agnostic/server-supreme imperative. I'd say that Java has quite a bit more to offer the server development productivity side of the equation, but using Java as the means to target clients from Mars rovers to the latest JVMs on cellphones, PDAs, Windows, Mac, Unix, and Linux is a strong plus too.
I have not changed my take that Java is heading toward legacy status, and that the future is all about SOA. And that the Java community is putting their resources elsewhere. But Java has not yet played out its transformative role for software development and deployment, and that means its influence is still highly significant.
So has the discussion of Eclipse vs. NetBeans, or SWT vs. Swing, or GPL vs. CDDL, missed the point? For those enterprise developers, and especially ISVs, that need to hedge their bets by being able to move on a dime regardless of how the world plays out -- fat client, rich client, thin client, no client -- is NetBeans a risk reducer? Is the common denominator of Java to NetBeans a strategic advantage that no one but Sun can manage and extend, and which is neither controlled by Microsoft nor IBM? If you embrace NetBeans as an ISV in addition to Eclipse and .NET can you be more fleet toward the largest addressable markets for your goods and services?
Now that NetBeans 5.0 has some strong feature-function strengths -- Matisse's GUI creation, better profiler, editor enhancements, plug-in support -- does the unique ability to straddle the divide between where Microsoft needs to go (fat client) and where IBM wants to go (rich client) make a sizable difference? Does it now make good sense to make sure, if you're a Microsoft shop, to embrace NetBeans and train some of your developers on the free Creator tools? Does it now make good sense, if you're an Eclipse shop, to make sure you have a handle on NetBeans to ensure that you have an end-to-end Java strength (as that becomes finally possible) and while IBM walks away from Java on the client?
These are questions I had not spent enough time on until today. I think these are just the sorts of things that Oracle is thinking over as it decides what to do about NetBeans. SAP will be focused on this too, Mendocino not withstanding. This is beginning to make me see NetBeans in an entirely new light, as an extension of what made Java so good for the industry.
My new-found interest in NetBeans 5.0 comes as a result of the different fundamental directions that software development is now faced with. These are just the sorts of things that Oracle is thinking over as it decides what to so about NetBeans. Indeed, there are multiple imperatives that factor into how to best plan for future software development, and they are not well aligned. They are actually increasingly at odds. Smart ISVs will seek a way to mitigate risk, and avoid being led down a garden path to less than optimal addressable markets.
One imperative (let's call it the legacy client support one) suggests that planners should designate tools, frameworks, and platform targeting based on applications that must for a considerable period of time target and span multiple and divergent native client targets -- from PDAs to cell phones to the usual gang of PC platforms, Windows, Mac, Unix, and Linux. The largest camp here is Windows-based clients, and there are a lot of them and they are not going away any time soon.
Another imperative (let's call it the client-agnostic one) suggests that planners should move beyond legacy clients and make their strategic development choices based on the primary concerns of server-side logic and frameworks as targets, of moving as quickly as possible to applications that reach the end users via server-managed clients, browsers/portals, and the rich mix from AJAX, REST, and the Web 2.0 stuff. There's a lot of momentum here, and enough client-side Java and browsers across the legacy clients to make this a compelling philosophy.
Anticipating these imperatives are the Eclipse ecology constituencies, which certainly seems to favor the move away from native client targets and the messy plug-ins process that entails toward applications of, by, and for the server. This direction was given a boost this week when IBM at Lotusphere announced that the latest multi-purpose clients, WorkPlace 2.6 and the forthcoming Hannover version of Notes, will not only both be server-managed clients but that the WorkPlace 2.6 client plus IBM's portal server will become the preferred GUI-tier for SOA and composite applications for all of IBM development. Java on the client is, of course, supported, but multi-purpose is the key. This is significant.
One can surmise that new levels of extended enterprise productivity and business process automation will become the strong breeze in the sails of the Eclipse community toward the tightening embrace of the client-agnostic imperative. The strategic development tools choices, then, should focus on how to organize, attach, and manage the services among and between the servers, not the clients.
Also anticipating these imperatives are Windows ecology constituencies, which certainly seem to favor the "connected computing" approach enabled by the Microsoft Visual Studio 2005/.NET/Vista/Indigo/Avalon assortment. Their direction seems to re-encourage a tightly coupled client (especially Office 11/12), and to a lesser extent support browsers and AJAX-like GUIs. The convulsion in terms of how to balance the fat client with the rich client for Microsoft was evident at last October's PDC, and the subsequent memos and reorganization announcements. It has not been settled yet, and the market will ultimately decide (this time).
And then there is NetBeans, which seems to have quite a bit to support both of the imperatives, and also has the lynchpinadvantage that it deeply supports Java at every twist and turn. And it turns out that Java has a strong and encompassing role to play for the legacy client support imperative. And Java has a strong and encompassing role to play in the client agnostic/server-supreme imperative. I'd say that Java has quite a bit more to offer the server development productivity side of the equation, but using Java as the means to target clients from Mars rovers to the latest JVMs on cellphones, PDAs, Windows, Mac, Unix, and Linux is a strong plus too.
I have not changed my take that Java is heading toward legacy status, and that the future is all about SOA. And that the Java community is putting their resources elsewhere. But Java has not yet played out its transformative role for software development and deployment, and that means its influence is still highly significant.
So has the discussion of Eclipse vs. NetBeans, or SWT vs. Swing, or GPL vs. CDDL, missed the point? For those enterprise developers, and especially ISVs, that need to hedge their bets by being able to move on a dime regardless of how the world plays out -- fat client, rich client, thin client, no client -- is NetBeans a risk reducer? Is the common denominator of Java to NetBeans a strategic advantage that no one but Sun can manage and extend, and which is neither controlled by Microsoft nor IBM? If you embrace NetBeans as an ISV in addition to Eclipse and .NET can you be more fleet toward the largest addressable markets for your goods and services?
Now that NetBeans 5.0 has some strong feature-function strengths -- Matisse's GUI creation, better profiler, editor enhancements, plug-in support -- does the unique ability to straddle the divide between where Microsoft needs to go (fat client) and where IBM wants to go (rich client) make a sizable difference? Does it now make good sense to make sure, if you're a Microsoft shop, to embrace NetBeans and train some of your developers on the free Creator tools? Does it now make good sense, if you're an Eclipse shop, to make sure you have a handle on NetBeans to ensure that you have an end-to-end Java strength (as that becomes finally possible) and while IBM walks away from Java on the client?
These are questions I had not spent enough time on until today. I think these are just the sorts of things that Oracle is thinking over as it decides what to do about NetBeans. SAP will be focused on this too, Mendocino not withstanding. This is beginning to make me see NetBeans in an entirely new light, as an extension of what made Java so good for the industry.