replicating the Glassfish ecosystem

how-to
Mar 1, 20104 mins

There is quite a bit of built-in advantages to the Oracle machine, even if Glassfish has been relegated to “lightweight” deployments, considering the extensive support systems in place, not to mention the already established best practices on java.net….but its not inconceivable that some organization could come along and take the open source licenses that Sun supported via CDDL and GPL 2 to create a new application server company, i mean it is possible…. My contention is that the ecosystem built around the JEE Reference Implementation is worthy of sales to enterprises, while Oracle contends that status is reserved solely for WebLogic, and so the developer community is left wondering why: why would a product-line that has next-generation features in integration via Fuji with the ESB, in portal via Liferay with WebView, and in clustering via Shoal with fail-over?… What I am suggesting is that the Glassfish ecosystem could be forked and replicated and provide value-add applications and services on top of the platform while continuing to stay current with the evolution of the RI, and it wouldnt take much in the way of resources, say from a company like Google, at least initially, it would be a developer effort that would be compensated from the specialization that could be applied to an already established app server….what i envision is something that would be customized to the cloud deployments that require, at least eventually, if not inevitably a run-time, with common infrastructure…. something akin to what SAP has done with NetWeaver, that could be integrated in to Guice, Salesforce.com, EC2, and a whole host of applications that are beginning to be readily available on Google and Amazon’s cloud offerings, by just looking at what is available today, and what is going to be taking place over the coming years….the model is set already, as well, ironically through Oracle’s Enterprise Linux fork of Red Hat, where a community model has been quasi-continued with a corporate structure that takes advantage of one company’s work, like with Fedora, and replicated to provide a new run-time that can be supported by a team of developers that take in revenue based on maintenance support…. Version control and issue tracking platforms are readily available today, and my preference is Google Code, though there is JIRA and Sourceforge, as well, among others….java.net is referenceable with all of the bug fixing and issues that have arisen in the course of building an open source application server, and it would be rather straight-forward to chart a course that adheres to the standards, the development of Glassfish from Oracle’s efforts, and also additional services that could be implemented alongside the app server, such as with Access Management or Java applications or even Google’s services for consumer or ad-facing apps…. I dont mean to sound like a broken record with this initiative, but i truly feel it is only a matter of time before the roadmap is released that will relegate Glassfish to simply being an RI for JEE releases, and not being sold for deployments, and that is the essence of a fork, taking an OSS project that has lost its traction by its corporate sponsor, but has value in the marketplace for customers and developers, alike….there are limitless directions, but it does not have to start with the creation of an app server, it is already there, and established, and does not require the heavy lifting of an enterprise software vendor to get going, it can be copied… copied and taken in new directions, and i challenge anyone at Oracle or even JBoss for that matter to suggest a path for open source software that provides revenue to the developer community for their work on building an enterprise Java platform, the revenue would be directly attributable to those developers that brought deals on to the forked Glassfish, and then the entity that supports the project would be compensated enough to build new features that will eventually peel off the Oracle Glassfish radar, from lack of focus and functionality that will inevitably arise when you save all accounts for an inferior app server in WebLogic…. thats right, Glassfish is better than WebLogic in almost every way except that it is not the basis of Fusion going forward, and so i understand the decision from a corporate Oracle standpoint, but from no other vantage point does it make sense to kill off Glassfish for simply an RI implementation, it is too good, too much invested, too much game changing features to watch it die, and that is why a fork is the only logical next step….