glassfish is google's
with the acquisition of Sun complete, and Oracle set to announce their roadmap for Sun products and technologies, the one thing i will be looking for is how they justify investment in the set of products that fall under the Glassfish moniker...with WebLogic as the run-time for Fusion, and by extension the ERP apps, and nearly all the database deals that will be bundled with an application server, there is virtually no way Glassfish survives beyond the year, even as Oracle is obliged to keep MySQL alive for the low-end implementations....its a shame, but it makes sense, perhaps Oracle will take the ESB and take some of NetBeans, but there is not a chance they will risk diluting their investment in BEA, by supporting yet another app server, one that only has cache within the Java developer community, and has yet to penetrate the enterprise, even though it probably is a better product-line than WebLogic...the train has left the station, and there is no turning back on Fusion, this far in to the development process, which is already massively behind schedule....
so, what is a Glassfish user to do, other than wait for a fork?....i suggest that as it is the Reference Implementation of Java EE, it would be best served as a project at google, and by that i mean a project living within Google Code, so that an enterprise product could take root at the ad/search giant, and give them a way in to the minds of Java developers worldwide...this is why it makes sense:
- Google builds cloud apps, and Glassfish is the best cloud app server on the market...
- Java is still the base for Guice and other development efforts at Google, so getting their feet wet with enterprise Java, only further positions Google as a necessary counter-weight to .Net and Microsoft....
- Glassfish is feature complete, and would greatly benefit from the engineering resources at Google to make it more tailored toward consumer facing applications....
- Oracle and google are natural allies, aside from Ellison's public campaign against clouds, they do different things, and do not get in each other's way and they have a common enemy in complexity of IT, which only benefits IBM Global Services and Microsoft's one size-fits-all mentality....
- Google needs an enterprise story, and building a middleware stack from the bottom-up would take too long, and would not be accepted within the marketplace for some time, too long to stay pace with .Net....
so, Oracle should de-emphasize the investment in Glassfish, as they are determined to shake resources out of Sun and make it profitable, and give the code direction to Google to make a viable enterprise platform for the legions of developers that are now circling around Guice, Android, and Chrome, all while giving enterprise Java a needed shot in the arm following the delays of JBoss 6 and the insurgency of SpringSource to fragment component portability....
this would not necessarily be a future threat to Fusion, and would continue to give Oracle some room to bounce ideas off of a well-financed engineering team without the necessary investment in in-house resources....the product managers and engineering talent could easily transfer from Oracle to Google, as they are down the highway from each other, and would give google a lot of talent to work on their enterprise strategy all while supporting open source development, as they have been doing....
this would be a welcome transfer by Red Hat and IBM's calculation, as they do not see Google in their accounts, and Glassfish would merely be tuned to be a fine reference implementation, with future development as the base of all of Google's enterprise development to reach the Java customer base, that is looking for guidance on whether their decade-long investment in enterprise Java is worth continuing....portability would be all but guaranteed with WebSphere, WebLogic, JBoss, and Glassfish all surviving the consolidation of IT, with only an acquisition of Red hat by IBM being absent to provide a true triumvirate to compete with Microsoft via Google, IBM, and Oracle....
sooner rather than later, Google needs to get serious about its intentions within the enterprise, and Glassfish is a natural fit, as an open source platform, that is well ahead on standards and specification compliance, they could continue this leadership while building a number of projects around Glassfish that would help them better compete with Microsoft in accounts that need the enterprise capabilities...
it is likely that Oracle will pledge support for Glassfish, while at the same time beginning the process of de-emphasizing investment in its ongoing development, whether that be engineering or marketing or both...Google could bring a bridge from the past development to the future of enterprise Java, and not necessarily segment SpringSource out of the equation, as Spring runs on Glassfish, all the pieces are in place, just need to get it done....
JBoss and SpringSource
Both are owned by corporate parents that have large market shares in their respective product categories: Linux servers for Red Hat, and corporate data center virtualization for VMWare, respectively, which allows the two subsidiaries of the parents to exert some sort of free-wheeling and experimentation with messaging, such as JBoss' new non-Java EE push through other languages, and SpringSource's anti-Java EE push through their own language, of sorts....but make no mistake about the competition, it boils down to a heavily intensive fight for the mindshare of Java developers worldwide, with the eventual victor controlling what is left of the corporate IT spend that does not go to Microsoft, IBM, and Oracle...this is major terrain for the once-small start-ups to undertake....
JBoss appears to have the lead, since they held the initiative for so long, as the only open source application server vendor, that bled BEA Systems to death, and in to the arms of Oracle, all while advancing its reputation and influence within the Java community, via the JCP standardization process....but SpringSource has fought admirably, although their tactics have been suspect, in terms of deriding enterprise Java, basically on the whole, even as they adopt some of the specifications that comprise it....i find their most recent anti-application server vendor strategy around suggesting that OSGi is not ready for the enterprise to be interesting, to say the least, as Glassfish and JBoss played catch-up to delivering a micro-kernel architecture, right at the moment that they finally caught up, Spring Source pulled the rug out from underneath Glassfish, and JBoss, in particular, by saying that they are no longer interested in their customers deploying through OSGi, leaving fear, uncertainly and doubt in the minds of developers and particularly IT managers, over whether OSGi is in fact a "risky" proposition to deploy to....
JBoss has been successful with its version 5 release to coincide with JEE 5, even though it came more than a year after the specification was released, it was in keeping with its parent company's reputation of only putting out supported products that have been battle-tested and offering assurances that there would be no surprises in developing with and deploying to a Red Hat product, JBoss included....and they will do the same with JEE 6, allowing Glassfish to attract the bulk of the early adopter users, that have little influence in the decision-making process of corporate IT spend, all while developing iterations of JEE 6 to keep their foot in the game....enterprise Java needs JBoss, but JBoss is giving the message that they can manage without the latest and greatest enterprise Java for the time-being....
Spring Source is different, altogether, basically wrapping enterprise Java with proprietary extensions that they claim offer greater productivity for developers with higher assurances of reliability for IT managers, they did not even participate in the JEE 6 discussion, choosing to make their apathy to enterprise Java felt most strongly through a policy of not even voting their vote within the JCP....in one respect this is baffling, though when you are running a political operation of mindshare battles, it is not surprising, as Spring source essentially has nothing to gain from the ongoing development of a community standard that truly only benefits JBoss and perhaps Glassfish, with the latter's future still in question, considering the Oracle Fusion investment....Spring Source is better off with a fragmented community, as they are best-of-breed, apparently....
What comes next is anything but detente, as JBoss and Spring Source battle over everything from XML to integration to tools to eventually virtualization, itself....its a healthy competition, and i think the lasting impact of the EJB 2x debate is finally wearing off, as Spring Source cant say EJB is dead, as v. 3 makes clear, and EJB 3.1 takes even further with CDI, but dont count SpringSource out quite yet....this OSGi argument strikes a blow to Glassfish as they spent the past two years getting organized for it, and Spring Source is spreading successful FUD that it is not the right approach...JBoss will have to respond with assurances in v. 6 that it is enterprise ready, and can be trusted on Red Hat deployments, as VMWare certainly will carry Spring Source deep in to Linux accounts, it is going to be good....
Oracle will have to clear-up what they intend to do with Glassfish, as a stand-alone product-line, that is truly not in line with Fusion or ERP apps, and JBoss will have to respond with more than just JEE 6 marketing, and their tried-and-true open source heritage, they will have to become more of an enterprise vendor, and that may mean selling out to IBM's Global Services to get the coverage to go deeper in to accounts, as i have said....but this competition has clearly been healthy for enterprise Java, even if Spring Source turns their nose at the community...its JBoss' move with v. 6, and Spring Source will be waiting to play the antagonist of all the little holes that may add-up to a barrier to entry for JBoss in to the core of the enterprise accounts at Red Hat....
Only time will tell, but i think that this battle only makes things better for developers, more choices rather than .Net, and more innovation around Java, it will be a tough test for JBoss, but one that they can handle if execution is flawless, otherwise, look for Spring Source to drive a wedge between perceived and real advantages of JEE 6...sooner, rather than later, portability of applications will have to be demonstrated in order to counter the proprietary models, and that has not happened, Java Verified, notwithstanding....components on-the-fly, inter-operable between Glassfish and JBoss is the only way JEE 6 stares down the long-term threat that is Spring Source....
the legacy of marc fleury
marcf is the founder of JBoss, an enterprise software company that i competed with, in my time on Sun's app server, and though they whipped us for a variety of reasons, the competition has heated back-up, with Glassfish v. 3 and JBoss 6, though both Marc and myself are long gone from our respective positions....the major difference being i sold my remaining sun stock options for something like <$20K, while Marc cashed in his majority stake in JBoss, via the acquisition by red hat, but he's still around doing something cool with remote control software to make it compatible across devices, and i still write about what i see in the enterprise software industry....
one thing is for sure, the marketplace would be by magnitudes different, had JBoss not punctured a hole at the right time in the WebLogic/WebSphere duopoly that has once again made middleware industry-standards based and cheaper and more important to overall market share of IT vendors...even VMWare bought a middleware company in Spring Source, in order to provide themselves with some diversification and a growth model beyond virtualization, that is becoming heavily saturated with no real top-line growth prospects beyond organic adoption....virtualization is important but not a market category in itself, as Red hat takes the life out of the value proposition by building it in to the operating system.....
Marc and JBoss went bigger, they went after the entire Java developer community as well as deployments with enterprises, alike, and succeeded where others like Bluestone failed, simply because they were crazy good business operators on a new model of open source, and too little can be said of what JBoss' overall execution meant to the acquisition plans of Oracle, as they forced BEA in to their lap, while simultaneously providing Red hat with cover to not be acquired by oracle, and so the dance goes on with Oracle doing their best to ignore the one hole in their arsenal for enterprise software, which is a viable operating system, even considering the state of openSolaris....i have argued for IBM to acquire Red Hat, which would be interesting enough to cause a major rip tide through IT, at a lot of levels, but none of this is possible without JBoss....
i am curious as to when, how, or perhaps whether Marc will get back in to enterprise software where he honed his antagonistic skills to the maximum to provide cover to a small ATL-based start-up, outside of the valley's VC reach for so long, all while competing with IBM, BEA, Oracle, and Sun, he just has to come back someday, even if the openRemote thing blows up, there is too much at stake in the middleware wars for him to not be a part of it sometime down the road...in the course of our respective careers, we will see a Google enterprise offering on the cloud competing with Microsoft's .Net cloud offering, and hopefully Oracle and IBM are still around to talk in the same room as the new giant and the incumbent who are at war over everything...i could never see Marc take a job at one of the major companies, but there is so much innovation going on in the cloud, that somewhere he must find a niche, and build another rock-solid company....
i met him once at Java One, though he wouldnt remember, as it was 2003, and i was a lowly staffer on the floor of the show, while he was the CEO of the upstart....but cordial enough, i have written extensively over the years of why Glassfish and Sun, in general owed JBoss such a debt of being able to follow a proven model that got them back in the middleware market, and for now have fended off proprietary extensions to the core enterprise java platform, which is all that matters right now for Oracle to be competitive with WebSphere Global Services accounts, these are huge stakes....
JBoss is at a cross-roads due to its role with Red Hat, and fighting off Spring Source has been time consuming, and less lucrative than initially projected with the acquisition, but Red Hat would be nowhere without JBoss, and JBoss would not exist and have thrived without Marc Fleury, sure it sounds like an epitath, but really its just a call-to-arms for him and his supporters in the industry to begin the brainstorming sessions again that led to JBoss, in the first place, i have laid out somewhat where i think that is going with Astro Cloud, but with middleware margins becoming ever more tied to the larger platforms they sustain, surely a couple of young start-ups could shake things up again....
if i was a betting man, i would be placing some money on Marc's next move if it does come in the enterprise software realm, and i would not be alone: he entered the market at the right time, and exited gracefully with a retirement plan that allows him to dabble and think big, that is a dangerous man for anyone who thinks that the world belongs solely to the big IT vendors, i am sure that someday start-ups will move from social networking to middleware cloud opportunities, and because of what he did with JBoss, and beyond, Marc Fleury should be considered a major possibility for version 2.0 of his model of upending the software industry...
i hope i am around to see it happen.....
google code
For those in the Java industry, there are countless ways of exploring the ecosystem that nourishes developers to build the platforms and applications that counter the immense weight of Microsoft and other pseudo-proprietary solutions, and though some (not me) fret about the counter-weight of Google's influence on the community, Google Code (GC) is the best site for learning about next-gen products and tools for extending the immense success of Enterprise Java....
It all starts with open source and open participation in ideas that rely on individual contributions to a started project, which means that anyone can search the GC database, and find a wealth of solutions that may not be ready for mainstream, but are well on their way to being included in the discussion of whether Java vendors need to add additional functionality to their products based on the support a project receives on GC, along with its corresponding usefulness in real-world implementations....
i have only begun to survey the cusp of what is available, as Google started GC some time back to support their programmatic contribution to Java in the form of Guice....but from what i can see and what i have learned in the time that i have been using GC, it seems a natural location for project owners that are looking to build mind-share around an idea and gather the necessary support to turn a project in to a product....
some time back, i initiated a project around an idea i call 'astro cloud' which is basically laid out in a previous post on this blog, in the form of a brainstorming session with myself, of how existing enterprise applications could be extended to bring in the value of the cloud computing phenomenon...some, like Ellison, dont like clouds as a distinct product category, but it seems to me that the sheer weight of what Amazon EC2 and Google are doing, along with countless well-funded start-ups in the Valley and beyond, plus the economics of deploying apps to a distributed platform, here-fore known as the cloud, will make application development and deployment more efficient and simply better by getting them on platforms that scale without limit...
GC is a natural place for me to start such an idea as it costs nothing, and takes advantage of the version control and distribution capabilities of Google's developer offerings, and though i dont know the first thing about developing in Java, despite having been a product marketing manager on Sun's application server for four important years of its existence, i know there are literally thousands of Java developers using GC to do more in their spare time outside or perhaps even inside the office, to build extensions or occasional stand-alone functionality that is not in the R&D budgets of the major Java vendors....
it doesnt mean you have to turn-over intellectual property rights to Google, as far as i can tell, and it allows me to keep all of my established Google data in place, while building something that could become a Java business....i will not succeed or even start without the support of developers who share the same belief in open source development, or share the same strategic conclusions of what is needed to push enterprise java forward beyond what the application server vendor and customers do....because as we know there is a limit to what Oracle, Glassfish, JBoss, JoNas, WebSphere, Apache, and even SpringSource can do in house....
It seems to me that Google is building platforms with consumer-facing applications, and allowing their enterprise efforts to revolve around developer tools that help push AdWords as embedded functionality, and so it may be that the great Mt. View power comes in to the space of cloud apps for the enterprise in-time, i am betting that they will limit their exposure to cannibalizing what is being built on GC by individual and team development efforts, so they dont run in to a Great Plains-like scenario where all new development stops because the keeper of the platform owns the apps, as well....
In a former lifetime, as an employee of Sun, I pushed the concept of portable EJB components, that never materialized, to my surprise, but it basically was a mistake by most in the Java industry, as the whole cross-platform promise was premised on the supposed capability to plug one EJB in to any platform, and now that that vision is getting increasing viability with the JEE6 release, as component development matures, and as application spending continues to grow vis-a-vis spending on platforms, that are being dramatically reduced in cost thanks to the open source efforts of JBoss and Glassfish, it seems time for developers to begin to use their hard-won talents and market advantages to building stand-alone apps that can be portable across any Java platform....
GC is a place that i will continue to monitor for new projects that may share my belief in betting on apps or even components that can add functionality to an enterprise's IT environment, without major re-work on extensibility or integration...at the moment i am following JoNas, Multi-Verse, and some other cloud tools that seem to be good starts to the initiative to extending Java beyond the borders of the app servers, and give developers an opportunity to do something on their own, that may in fact turn in to a career, or even a company....nothing seems to be able to match the scale of Google, and combining the usability of GC with a Java application idea, could push the marketability of open source efforts at competing with existing solutions....
i am sure many of you in the Java marketplace have inspected GC at a cursory level, so i am treading on well-known territory for a lot of the Java development community, but it goes to say that by mixing and matching initiatives and functionality in a community environment, such as that found on
GC, will provide the necessary foundation to move beyond merely iterative releases of platforms, and focus the corporate Java spend on apps, which is what was promised by Enterprise Java at its inception....SpringSource was right, too much focus on just the platforms, and its time to turn control over to the developers in businesses and individuals developing on their own for real innovation to happen....i think Google Code is one of the leading contenders to lead this evolution.....
