The Next Wave

Wednesday May 17, 2006

NetBeans Day 2006 and the Future of Tools

So on Monday, I attended the NetBeans Day conference, an all-day event that was held the day before the main JavaOne event. The NetBeans event was an absolutely fantastic experience as usual, with attendance over-capacity (I noted someone who appeared to be a fire marshall counting heads at one point) and a lot of developers who were there to learn about the latest in NetBeans technology as well as related information from Sun developer tools and partners.

I was on the ticket to close the initial keynote and introduce the tracks however because we started late, what was a 10 minute slot became a 1 minute slot (try at cram 7 slides into that!) and I had to go through my presentation (which I had down to a well-timed patter prior to the presentation BTW) about as rapidly as I have ever had to do (so I don't believe I communicated well everything that I felt I needed to). As I mentioned up-front to the audience, I would post (essentially) my presentation here so the full effect would be captured. So here we go ...

The Sun Tools portfolio

The Sun Tools portfolio currently consists of 5 primary tool products, one being NetBeans, one being an add-on "pack" and the remaining three products as Sun-branded "Studio" tools which were built on or using NetBeans technology (this distinction is important ... save it for later). Before I talk about where we are going, a discussion about where we are today will provide some context to understand where we're going.

NetBeans. The core (and most significant part) is NetBeans. This, of course, is the open source and community-supported application which consists of a robust RCP (Rich Client Platform) and a set of plug-ins which transform the platform into the rich and extensible IDE (and foundation for other IDEs) that is NetBeans.

Java Studio Enterprise. This product was originally designed to be the "enterprise" toolset for Sun and initially focused primarily on J2EE (yes, that's not a typo) and then web services development and deployment. As we have made the transition from J2EE to Java EE, much of the functionality necessary to do Java enterprise development has been shifted to NetBeans which has allowed the Studio Enterprise (I'll refer to it as JSE) team to focus on Service Oriented Architecture (SOA) development tools.

Java Studio Creator. This product has a special place in my heart reserved for it as this was a project I initiated, designed and architected (I have to admit, for the first release I was a bit of a dictator ... ask any of the old project team ... but it was worth it in the end). Creator ("Project Rave") was originally designed to meet the needs of the audience of developers who were either new to Java or needed to be able to easily and rapidly create rich web applications consuming existing data and services.

Sun Studio. Unique in that this product is the only non-Java IDE product from Sun, Sun Studio exists for the developers trying to build native (meaning C, C++ and Fortran) applications for Solaris and Linux.

NetBeans Mobility Pack. The Mobility Pack is not a stand-alone IDE in the same sense as the others. It is designed as an add-on to an existing IDE installation (NetBeans) and adds the features necessary for developers to create rich MIDP (and soon CDC) applications in the Java ME space. It includes both some of the same rich visual experiences you get with Creator but also adds the ability to leverage the Wireless Tool Kit (WTK) from Sun, including the use of rich emulators for various devices.

It should be noted (and note that this is historical data) that while all of the above were built using "on" NetBeans, they were built (exception: Mobility Pack) on NetBeans source (as opposed to being simply binary plug-ins on top of an existing NetBeans installation). The issue here is that as a result, frequently features which existed in one tool (ex: Creator) were not usable in another (ex: Enterprise or NetBeans). The end-result is a series of non-interoperable products (except at the generated source level) which (understandably) led to the "big question" that I (and others) get asked wherever we go an showcase the Sun developer products.

The "big question": Why all these tools ? Why not one ?

Historically, the answer is pretty simple. Last year, I (somewhat) covered our strategy and rationale in an earlier blog ... as our overall Sun strategy around open source and tools has now become more publicly available, I can elaborate a little (or a lot!) more on what we're doing and why.

There is value (to the customer, which is a primary imperative) to have tools which are tightly aligned and delivered with the deployment environment (in our example this would include things like the Java Enterprise System, Solaris and/or individual runtimes or platforms like Java SE, EE or ME. There is also value in delivering tools for specific audiences. NetBeans fits somewhere in between (we wanted to align with the needs of the Java community as well as an open source community). So NetBeans and the Forte/Studio tools served different audiences and different platforms/runtimes (NetBeans the "community" audience/platforms, the Forte/Studio products the "Sun" audience/platforms).

For good reason, we wanted to keep this new "open source IDE thing" at arms length, untainted by any Sun-specific initiatives or products ... in short we wanted to give this project a fighting chance as an open source IDE and make it attractive externally without any Sun bias (or even the perception of such baggage). As a result, while we did indeed build commercial products from the NetBeans source, it was a decidedly one-way street ... we used NetBeans technology as the foundation for our tools, but sharing was limited to either the assignment of Sun resources to the open source NetBeans project or very infrequent contributions to the community from our commercial products.

History has proved that these goals aren't mutually exclusive. Face it, there is little value in an IDE that you charge money for. And the value of creating and delivering open sources and standards far outweighs the value in any proprietary system. The commercial value isn't the tools themselves (or even the runtimes), it's the applications that run on them as well as the associated services.

We have reached an inflection point, both in terms of an understanding and realization of how the industry and economy of software systems works and as well one where the underlying technology is ready to adapt to the new model. It has taken 2-3 years of work within the NetBeans and Sun tools group to reach a point where a strategy I initiated to build on a common binary NetBeans foundation has reached the point where we can now reverse the order on how we build and deliver our software.

The new model

In the old days (and, in fact, what we're doing today), the model was that technology and products were delivered in closed source and periodically (rarely in the past, more frequently today) that code was donated to NetBeans. It started with such initiatives as the collaboration technology contribution in June of last year and a more recent example of that was what is known as the NetBeans Enterprise Pack. This is a collection of the technology present in Java Studio Enterprise (UML modeling tools, service orchestration tools, etc.) which was bundled as a "pack" (plug-able into a given installed NetBeans binary). With this pack, a NetBeans user now had access to technology which used to be only available to someone who used or paid for a copy of the JSE product.

As time goes on, more and more of what has historically been proprietary or "closed" source will be contributed to NetBeans. Recently, you've seen announcements to that effect for such technology as C/C++ development and the contribution of Creator technology (WYSIWYG designers for rich web application development).

This is only the beginning. The only real barrier to all of the Sun tools technology from becoming part of the general NetBeans technology base is logistical in nature (legal, coordination and usability/workflow model standardization). I would expect that by this time next year, the majority of all code will be completely shared... which leads to the next step ... reversing the order (instead of contributing to NetBeans from what was closed-source, proprietary code-bases, develop in open source and use that common code for point products use).

Once we have created this centralized "repository of development technology" which is NetBeans, when we need to create those custom point products (the need to have tightly aligned tools which ship with specific runtimes like Java Enterprise System hasn't gone away), we will instead pull what technology from the repository we need, brand it appropriately, test it rigorously with the deployment environment, perhaps add features specific to that runtime and ship it with that runtime.

As shown here, the process of delivering Java Studio Enterprise will now be a process more of one extracting the relevant bits from a common NetBeans technology repository (which is developed in open source) rather than delivering that technology into NetBeans at a later date (which likely over time would lead to more logistical nightmares since the code wasn't developed in concert with the NetBeans source). As before, this process would and will apply to the other products as well.

The interesting and powerful result here is that the technology now shared between all of these products is now re-useable in all of these products (where before it was impossible, for instance, to re-use a module from Creator in say, NetBeans). The advantage here will be, for instance, the ability to create custom environments for specific vertical applications or specialized needs (the example here is perhaps contrived, but I hope it makes the point).

Over the next month or so I hope to describe some of the specific plans and vision of how this strategy will be realized in terms of timing and roadmap.

Enjoy JavaOne!

Posted by brewin May 17 2006, 12:23:59 PM PDT Permalink