Astro Software Business Plan
Corporate Information Technology (IT) represents an
approximately $100 Billion annual spend on hardware, software and
services across the vast array of offerings. Beyond Apple, Microsoft,
IBM, SAP & Oracle, there are a wide variety of solutions. But one
technology has been a mainstay across the Global 2000 corporations since
its inception in the 1990’s, and that is Java. Enterprise Java, in
particular, has achieved deep penetration in the normally mundane IT
environments of the Global 2000, mainly through said companies
investment in Java Application Servers which often-times run web
properties, is utilized as the platform for all types of on-line
transactions, and integrates legacy applications. The Enterprise Java
specification has been and continues to be a deep and broad offering for
most kinds of IT development standards. At the heart of the continued
success of Enterprise Java platform lies the Enterprise JavaBeans (EJB)
development paradigm. EJBs are components or discreet amounts of code
to achieve a certain inter-action among software running with an
application server.
This
plan will detail the market opportunity for creating pre-built EJB
components in order to sell web functionality in to the Global 2000 who
have invested in application servers. This is not a new concept as
several small vendors sold EJB applications in the late 1990’s and early
2000’s that provided functionality for on-line business. Some of these
vendors were acquired by application server vendors, others died out in
the wake of the IT recession following 9/11/01. But the concept has
never been abandoned, as application server customers continue to
utilize the EJB standard as a way to re-use code to achieve
functionality around a wide-variety of projects. If one IT development
project can be shared without re-writing everything for new projects,
efficiencies are created as a write-once-run-anywhere concept for the
reason that Java is utilized, allows the code re-use.
The
best way to think of this is an on-line trading experience that
requires a shopping cart. If the shopping cart is either written or
acquired by an application server customer, it can be used across
multiple trading environments by writing to the EJB specification. A
customer such as P&G might have thousands of trading relationships
across its enormous IT environment, and with the right attention and
maintenance of the EJB standard, one shopping cart piece of code could
be used for all of the trading relationships. What Astro Software is
proposing is that pre-built EJB components would be sold in to
application server customer environments to offer a large head-start on a
development project. Components could be created for nearly any type
of functionality, offering an enormous opportunity to create EJBs for
nearly any type of discreet on-line inter-action, from B2B, to CRM, to
supply chain management, to on-line transactions of any sort. This
document will lay out the market opportunity, the proposed component
model and what it would look like, and the reason why this is a great
opportunity for investors to tap-in to the Global IT spend.
a. The application server market represents the base
of customers who utilize Java to develop software programs and conduct
data integration that will be deployed on the app server platform. In
2000, this market consisted of a majority of the Global 2000 businesses,
as Enterprise Java was viewed by the customers to have less likelihood
of being locked-in to a specific vendor’s offerings, as the vendors
adhered to the Java specification for cross-platform functionality.
Today, it is difficult to estimate how many of those same app server
customers continue to rely on Java as the basis of their enterprise
development, but judging from the vendors’ continued investment in
upgrading their app server offerings, there is a sizeable base
remaining. This is not to say it is a legacy market, as continued
enhancements in the Java platform have resulted in ease of development
and a straight-forward architecture for maintaining the environment.
The
main app server vendors are Oracle, IBM, JBoss and VMWare, all offering
a complete suite of tools to make running Java better than ever. The
app server suite market represents a multi-billion dollar opportunity
for the vendors which is a major reason why continued innovation
surrounds the market. When used appropriately, app servers provide a
common-runtime for Java applications to be deployed and integrated
across a customer’s IT environment. This allows developers to learn the
Java specification rather than the vendor’s specific proprietary
technology architecture. As stated this allows far less vendor lock-in,
through the write-once-run-anywhere promise of Enterprise Java. With
the plan to write EJB components that strictly adhere to the
specification, Astro looks to take the value proposition of Java
one-step further than previously sold in the marketplace by developing
components that can be used regardless of the vendor offering, as long
as it continues to adhere to the Enterprise Java specification.
The
value of this model is self-evident in that it provides pre-built
functionality for the app server customer to utilize without having to
start from scratch every time a new development project is under-taken.
Componentized software also allows a more comprehensible maintenance
strategy, as pieces of software code can be swapped in-and-out as long
as it can run on the application server, which allows developers to
focus on their key competency and in-a-way mash together code that
previously would have to be built from the ground up. Enterprise Java
components gives customers flexibility that is simply not available
through other models, as it provides the flexibility to integrate
development projects according to need rather than what can be
accomplished under other coding models. EJBs are the so-called “Holy
Grail” of software architectures as it allows developers to bring-in
pre-built components to get the project up-and-running more quickly and
in an understandable way of maintaining the architecture.
b. The three models available to Independent Software Vendors (ISVs) are basically found in three distinct strategies:
1)
Open Source (OSS) - - this model allows the free transfer and
privileges of the under-lying source code to be viewed by anyone within
the open source community for the software application. OSS has been
very popular for fledgling ideas to get up-and-running with little
resources, as developers from across the world are invited to share the
responsibilities of writing the software architecture. Red Hat is the
most successful OSS company, and has achieved a viable revenue stream
from its support and maintenance business, as its software is free to
acquire. Services are typically where OSS revenue streams, where the
OSS ISV will provide bug fixes and other support services that allow a
customer to have a contact point when things go off-plan, that is so
important in the software industry. A weakness of the OSS model is not
having intellectual property concentrated within the OSS company, but
instead is shared by the developers on the project, regardless of their
affiliation with the OSS company. A strength is the large-base of
expertise that can be drawn upon for improvements and ideas for future
iterations of the software application. This could be a route taken by
Astro Software if a base of developers can be identified who would help
write the EJB components proposed in this document, and would be a key
determination of how far and how fast the development of components
could be reached.
2)
Licenses - - this is by far the most common way that ISVs release their
product, by selling licenses, the company keeps intellectual property
and sells the functionality as well as services, potentially creating an
additional revenue stream than what can be achieved through the OSS
model. Software is traditionally not cheap to acquire so the market
penetration is often lower for a license model than an OSS model where
the software is freely distributed. In addition to the supplemental
revenue stream, license model ISVs have greater control of the
distribution of the software and for this reason there is a larger
revenue opportunity than OSS, but it comes with risks, as well. The
main risk is the degree to which a license model can get up-and-running,
for development staffs cost money and without a customer base
identified, many license model ISVs can go bust before they even regain
their initial investment, but the pay-off can concomitantly be much more
lucrative. Due to the degree of complexity of the EJB model, some
manner of in-house development staff is required, if for nothing else to
have expertise within the company to do support and gather requirements
for next generation products. This is not to pre-clude the possible
advantages of the OSS model, but it is a general assumption that more
revenue is possible with the license model.
3)
Hosted - - it is a relatively new option, as ISVs instead of delivering
software applications to its customers instead make their functionality
available via a browser, so that all of the processing is handled by
the hosted ISV company. Salesforce.com has made a nice business out of
this model by marketing itself as a hassle-free solution for those
customers that wish to get up-and-running more quickly and achieve
business results in a more direct way thatn what it typically takes to
acquire or download software and work on integration and deployment that
is required when the customer hosts its own copy of the software. The
Hosted model doesn’t have as much IT-ness to it, as a casual user of the
web can readily learn how to use the hosted software and make changes
that are processed by the Hosted ISV. Changes can be more quickly
rolled-out to customers as its just the front-end that are typically the
concerns of a user of hosted software. The downside is the lack of a
license revenue model, so Hosted can be less lucrative, like OSS.
Hosted also does not have the same capability for deep integration in
to a customer’s IT environment, as Hosted is often used for “clean-room”
deployments with minimal data integration. Even this is changing, but
the most demanding of organizations need to access legacy applications
and data to achieve business metrics for successful implementation of a
project. Hosted is easier and more cost conscious, but has a less
lucrative up-side that the traditional license model.
c.
EJB components are slices of pre-built software code that provides a
certain, discreet amount of functionality to accomplish a certain set of
requirements. EJBs can be written for such tasks as accessing a
database or running an entire on-line shopping experience. They can be
as small and short-lived or large-scale and lengthy in duration of
usefulness as needed. EJBs can be written to satisfy a credit check, a
shipping transaction, a supply chain inter-action, a customer-facing
service application or any of countless on-line experiences. There is
literally no limit to the amount of components that could be part of the
Astro sales strategy, for any type of market requirement. What you get
from an EJB is reliability and stability to match the standardized code
so there is little vendor lock-in. In time, it is easily conceivable
to think of hundreds of components being accessed by any type of
customer at one-time, meaning that a sales strategy for EJBs could
become quite lucrative with some execution toward delivering solutions
out of component software.
With
so much common sense logic that many components would offer a real
market opportunity to an ISV selling them, it begs the question of why
are there not already pre-built EJB components in the marketplace? The
EJB standard has gained a reputation for reliability but in its earliest
inception it was difficult to do, as the Enterprise Java standard was
only formally released in 1999, a short-time ago in software
architecture parlance. Over time improvements have been made with each
passing iteration of the specification and the corresponding solutions
that came out of the standard set. There have been companies that have
re-used components across projects, for this is a common software
practice, but very little has been done to make them as re-sold
components. This is what we intend to do with this company, make
pre-built components that can be sold in to the application server
customer base, as the app server vendors have made no move toward
creating their own component-based applications for sale to their
customers. It is an un-tapped market, and considering the enormous
changes that the “cloud” architecture holds for IT, EJBs have a real
chance at becoming the standard for deployment in conducting
mini-transactions on-line.
The
coming wave of cloud solutions are essentially componentized software
concepts as it is discreet and limited in scope the transactions that
are conducted on-line, even so EJBs can scale to accomplish the most
important business tasks. The cloud economy will value speed and
reliability, as well as time-to-market considerations, and this is
custom made for component software, as EJBs have a foot-hold in
corporate IT today, and could extend its reach in to the cloud
environments that so many of the Global 2000 are investing in today.
There is no clear picture for what might emerge from the cloud
architectures being built today, but adhering to a standard is certainly
one of the key requirements, so that a customer does not get locked-in
to a specific vendor’s solutions. EJBs are built for these
requirements, and it is not difficult to imagine that it could have a
real, viable market opportunity with cloud customers looking to get
up-and-running more quickly than building in-house. With the right
execution, an EJB component vendor, such as the one proposed in this
plan, could become a leader in cloud solutions, a multi-billion dollar
opportunity already. Growth of the cloud architectures is expected to
explode this decade, it would be a real opportunity to have a set of
components available for when the Global 2000 begin to think of their
architectures for the coming twenty years of IT environments.
proposal for EJB component start-up
Enterprise JavaBeans (EJB) components are discreet units of functionality in enterprise software terms, so that you can think of it as encapsulating a certain amount of lines of code to achieve a specific outcome. Components have long been something of a 'holy grail' in software coding, as it could be re-usable as well as sold as stand-alone function. EJBs came out in the late 1990s with that same promise and were mildly successful in its first generation. A few small companies even attempted to do business models off of component functionality, often-times aligning with Java application server vendors, such as BEA, Sun, ATG, and Bluestone, which all offered their own forms of EJB applications along with their app server platforms. BEA went so far as to acquire one of the component vendors, called Theory Center, and re-sold Theory Center's EJB components as the BEA WebLogic Commerce Server, which was a very popular way for BEA to demonstrate the application server's core capabilities.
The EJB specification remains the primary standard for Java application server vendors to follow in maintaining the promise of Enterprise Java for portability of applications written to the platforms that support the standard. EJB components also remain a common development paradigm for enterprise development, in terms of how to achieve application and integration development outcomes that can be re-used across a number of projects. The easiest way to think of this is the shopping cart functionality found on e-commerce web-sites. Think if a company has a goal of setting up a B2B commerce site to conduct trading with its many partners. Rather than writing a new shopping cart experience for each trading relationship, the core functionality is written once and re-used across a number of use case scenarios. This is a re-usable component example, as the shopping cart components or set of EJBs would be used for many trading relationships without the need to continuously re-write the same core functionality.
What I propose is a new set of components that could be sold to these enterprise customers that have invested in the EJB standard via their acquisition of application server platforms to serve as e-commerce conduits within IT environments. It is a tested model while also including the promise of continued support by Oracle and its many Java partners. The components would be discreet in terms of functionality, but could be sold as solutions for anything from B2B to B2C to CRM to Supply Chain Management. The target customer is your typical application server acquirer, when they are looking to see what the cloud offers their existing infrastructure, the components would serve as helping hands to get up-and-running more quickly. Components flying around, all centrally managed, but business use cases could also dictate how the components inter-act. A marketing manager could ask the supply chain team to do a query on which components are used most prominently in transactions, and the developer team could build new components or acquire new components to satisfy requirements.
It would take an enormous under-taking to compete with a company that had a head-start on delivering EJBs to the application server customer-base. With some agility, clouds could be the domain of components, and the Java standard would have a foot-hold in to the build-out of this next evolution of information technology strategies. Components, by their very nature, offer a relief from the management complexity of current solutions, while also complimenting installed base platforms, such as ERP. The market is set, the opportunity is there, developers working with focus is what is needed. I can only offer support, it is up to you to seize the chance to put a mark on enterprise software, an established and lucrative market. It may not be your calling at-the-moment, but I would like to put the thought in your brain of remembering back to the very inception of Enterprise Java. Now is the time to fulfill that early promise, EJBs are not dead they have just become boring. With some skill and execution, we could make them cool and useful again. Get a foot-hold on the cloud environments via application servers and components, and there is no telling what other opportunities will come around.
pre-built EJB components
The case is simple, and it has a history: build functional applications that are cross-platform, and revive the model of Java to be write-once-run across multiple platforms. This was done, in some form, by Theory Center before they were acquired by BEA in 1999, and it allowed WebLogic to take the early lead, that ultimately led to their sizable cash-out, in the form of the Oracle acquisition. Nothing made IT managers happier than to see something actually working on top of these Internet operating systems, that were to be known as application servers. They could see what they were investing in, if Theory Center worked, then their own development efforts could also work. I was working on iPlanet's competitor to WL, and never once did I see a deployment of Theory Center, yet many of the largest financial services firms and teleco's, deployed WebLogic in their environments. Some will say that application servers never lived up to their promise of integrating all of Java, in to one common platform, that could rival Microsoft's datacenter offerings. But that is what is available today: a belief that cloud computing will re-orient the data-center like no other offering brought forth by enterprise vendors in the last twenty years. It is the Internet taken to its natural destination, and it is custom-made for application server vendors to take their offerings in to the cloud. The vendors, themselves, are coming at from different angles. JBoss is the lead environment for Red Hat Linux, and OS that desires to see the market go cloud, it is Oracle that will lead with applications for intra-environment deployment, and IBM will offer up some customization to argue for their own tools to be deployed as cloud infrastructure. Even Spring Source is in the cloud game with VMWare having invented the enterprise cloud architecture. What do all of these have in common?
They all are lacking the Theory Center moment, when you can walk in to a customer and visibly demonstrate what is being explained in technical terms. The promise of pre-built functionality has always been on the minds of the vendors, and customers have their own in-house set of components that run certain functionality, and that can be re-used across multiple projects. What is needed is a firm, a coalition of firms, or a series of start-up moves to re-kindle the fire originally set by the promise of the EJB component model. Pre-built EJBs are what would give the cloud that discernible advantage over the Azure promise of integration across the platform. Windows Server is acquiring the enterprise, slowly but surely, with 50% of deployments worldwide having gone to WS, and 20% with Linux, and 30% other. In order for the remaining non-Windows 50% to compete, it needs these pre-built components to show the power of Java's development model, and work across the vendors to prove the deployment model. Whether that be IBM Global Services, or Oracle's Support Network, or JBoss consultants, worldwide, the component model needs a new life. This can be done in basic steps toward a full-fledged platform, that would deliver shopping cart, credit card transactions, other shopping features for consumers, B2B transactions like supply chain management, integration with all sorts of data sources are ready for pre-built functionality, and beyond.
The best way to deliver this is on top of Glassfish, as the Reference Implementation for JEE 6 and 7, it can showcase the advanced cloud features of Enterprise Java. Pre-built components would give customers something to work with as they investigate the business model of going with Java over Azure in the cloud build-out. Microsoft will be forced to retaliate, but they do not have an industry that has committed to delivering specification after another, with partners, that compete for the same accounts. The Microsoft components will be more centered at Google, anyway, their Great Plains product-set has been focused on ERP and other large functionality efforts, not micro-enough to be componentized in time for Java components to build a user base that will set them off on the cloud projects, that are certain to spring up, as IT managers look to new models to improve delivery of their respective employers' web offerings. Get EJBs back in the discussion, and integrate with other non-EJB models through JAX, and see the application server vendors regain the argument that has been eroded by years of over-hype, now is the time to deliver on the hype of Java on the server-side. Right now, it is all a process of upgrades and maintenance decisions, make it about the cloud and see new models and new opportunities rise to the surface.
This cause has been called for before, it has been dis-credited, and to be honest, is like kryptonite to IT everywhere. The promise of pre-buuilt components, a long-time Holy Grail in development, is a real possibility in deployment, today, with the clouds becoming the leading selling point of vendors, and the leading interest area of customers. How to make these clouds work? Microsoft has it figured out with their complete package of development and integration among a wide-swath of products. All Java needs is a development environment, pre-built components, and application servers to compliment the data sources and integration efforts already in place across the enterprise. There is no need to sell new platforms, or new models, the app servers are the cloud OS, always have been, they were just disguised as dot-com enablers, in their earlies incarnation, but they power the Internet. Where would IT be without enterprise Java, it would be stuck in non-standard, non-compatible environments, without any hope of achieving acquisition or other-wise integration, it would be much costlier to run an IT environment, without application servers. Re-charge the debate around Java with pre-built EJBs, that work across cloud environments, make it a competitive marketplace for selecting components, that can work together, and turn the power back to developers within enterprises. The cloud will shake out from there. Without it, there is no functionality to sell on, and allows Microsoft and Azure all the advantages of integration without standards. All of the Java vendors would benefit, and Glassfish would have a standing chance of becoming one of those deployment environments ready for the cloud. This is Oracle's best opportunity for the cloud, beyond whatever WebLogic does to become Fusion for the Oracle Cloud, a pre-built set of Java specific functionality would be a major starting point for how Java vendors are to approach the cloud. It would translate to benefits across the Java ecosystem.
Sun software spin-off
If its not going to be used to sell hardware, then it should be given its own life, outside of Oracle, its wasted value, just to be specification Reference Implementations, that is comical, its industry-grade, and can stand on its own, it should be set free. MySQL, SSO, ESB, JEE, even NetBeans could sustain a whole new company, and these are redundant assets within the parent company's offering, they are not investment worthy, so why not let someone else do something with it. Cannibalization is possible, but considering the pay-back on green environments it could get to and turn-back in to maintenance revenue with a simple agreement from parent and spin-off, there is very little logic that just letting them wither on the vine in the argument that Sun was bought for hardware alone, and it is in keeping with the long-term principles of holding off Great Plains in medium-sized accounts. I have said this all before with some degree of implementation plan, like my earlier logic on a fork on Google Code, i dont need to see that exactly happen, but it needs room to breathe, and right now the oxygen on Glassfish, in particular, is being cut-off from ExaLogic sales push. This is not the only value of Sun, more can be done, and the only way I can see anything getting near its true value is for a spin-off.
This reminds me a lot of iPlanet. Back then, when the Sun-Netscape Alliance was in its first year, there was a lot of hype for the Sun investment in Netscape products. I was a kid, on my first job out of grad school, and actually advocated for an IPO, i was naive, but eventually fell in to line that it would work better as a vertical solution. And it did, it served Sun well, even though it caused us to work over-time to clean up the iAS 6.0 mess, it served Sun well. That didn't show up in the acquisition price, but Sun would have been virtually a worthless chip designer had it not been for the middleware assets. Oracle is doing its best to revive Sparc, and i applaud them for that, I think they should continue doing it, its great for the Valley, great to overcome Google's black-hole of data center design support, other companies need non-Google cloud data centers, and Oracle with Sun hardware fits the bill. Good job whoever worked on that, even Solaris seems to be safe for existing accounts. But the other side of Sun is breath-takingly innovative. All the middleware assets are better than JBoss and Spring Source, and by not addressing their value, Oracle is giving legit competitors a little more breathing room. Just keep 51%, split up 49% with investors who are savvy on enterprise software, and let some employees have a period of time where they could be employees of Oracle, still, while working on the start-up of acquired Sun software assets. Its really straight-forward, and is custom-made for an aggressive company like Oracle. It would appease the Sun employees who are not fortunate enough to work on Fusion, and give a little energy to the growing international monstrosity that is Oracle. It would simplify things for everyone.
Customers would know that they have the support of Oracle, if they invest in this new iPlanet-like company. Call it the Oracle-Sun Alliance, or whatever, just get some value out of it. Its like Oracle executives would rather keep WebLogic as the only option to punish customers, they are eventually going to get something better in IIS, .Net, and Great PLains, when it is all rolled-in to one environment on VS, only Glassfish stands in the way of this happening. Dont let it die out of fear of the unknown, like WebLogic will be dead if there is some innovation, WebLogic is not going anywhere, it is the development environment for BPM on the ERP apps, that is huge, like really huge, but it cant be expected to also fend off more nimble cloud purveyors as well, that is not logical. Oracle needs both, but that is not what is happening now, customers see the messaging about departmental apps, so no matter what Glassfish people tell Oracle sales reps, there is no way to get in the customer conversations, it is as an after-thought in Oracle strategic direction. There is no reason this should be the status quo, there is room to move forward, but it takes fresh thinking, and see the challengers as real, dont get caught flat-footed on your flank-side.
a primer on Glassfish
Its predecessors in Netscape Application Server and iPlanet Application Server did not work, and so it took the re-write of the Reference Implementation of the Sun ONE Application Server to provide the roadmap that would lead to a stable app server platform, that could be open sourced and turned in to Glassfish. Now, it is being systemically dismantled in the hands of Oracle as all the real money is in the big-ticket product lines of WebLogic, Oracle DB, and PeopleSoft ERP, and no one seems to notice. This leaves a market where only JBoss is sticking to the Enterprise Java specification, and competing platforms such as Spring Source turn their nose at Oracle, and build cloud environments. This is a shame, after all the effort to get a viable app server platform from Sun, it is being killed from within, with no real sales strategy, and little in the way of marketing support. Something should be done, but the Oracle employees charged with the success of Glassfish, as they were at Sun have not come out with anything more than technical analysis, and do not understand the marketplace's changing tide toward the cloud, waiting instead for Java EE 7, while everyone else shuns Oracle's customer-hosted-only model.
What can be done? Forking with unlimited resources would be fun, the ESB is top-notch, the EJB container is fast, and MySQL is well regarded to give customers a complete deployment platform for the cloud, and it would be taking on a long-time nuisance in the throes of developer interests. Does anyone anywhere have positive experiences with Oracle developer support, they simply dont do it, their site is fractured and useless with case examples of successful deployments, or easy-to-use documentation, like how the Glassfish team initially set its sights on, and still we get no word from anyone at Oracle that they plan to sell Glassfish to their enterprise base. Put simply Glassfish is more potentially disruptive than anything that WebLogic will do with Fusion. And still no action, Oracle is well positioned to dominate enterprise computing, both hardware and software after getting Sun for a negligible amount, so maybe it is time to take them on, and put Glassfish back in the running for leading enterprise cloud environment.
All of this is well documented but what could be hugely different than anything that a previous fork has done, is actually put a company behind it, and pay the developers that work on it, not allow all of the benefits go to a single entity, though i would propose a company to organize all of the efforts, whats to stop getting paid on commission and equity. I have proposed this before, but i wanted to signal the charge again, as Oracle pays little attention to anything other than Fusion, the DB, and the Google lawsuit. What if Fusion never delivers, and Glassfish is forked, could not Oracle's huge customer base be primed for a move off old WebLogic and convert them to cloud purveyors on Glassfish? I dont know what you guys are working on currently, absent an Android app, the most lucrative field in IT is in the enterprise, and Glassfish is ripe for the taking, so consider your options well when investing your coding talents in to community efforts, and do not waste your time on Oracle's Glassfish, go for a forked version, just like they did with Linux off of Red Hat. It is doable, and the time is right to take Oracle to task for its opposition to the developer community. Join us, and begin the cloud revolution via Glassfish.
will Glassfish survive?
i am just trying to reconcile how the better product receives 1/10th the resources, i mean WebLogic was dying before the acquisition, JBoss had it beat, and then Oracle picks it up for a song, somewhat cheaper than they got Sun, in relative terms, and turns it in to the base of Fusion, and ERP, and invests all this money in to it to become the enterprise platform, all while Glassfish was getting good, and ready to take-down JBoss, or at least take on Spring Source, and then the acquisition, and all funding dried up, all OSS community participation went away, and now its just a small division in an over-grown company, that has not innovated in a decade, but instead relies on its monopoly of the core piece of enterprise computing, and few hostile actions against erstwhile allies in the struggle with Microsoft, and it comes undone, Glassfish must be set free in order for Enterprise Java to survive, it will be irrelevant if it just goes the way of the Reference Implementation, it is too valuable for that, and so this is what i propose:
- Glassfish and MySQL spun off, with SSO, in to a separate company with 49% control by Oracle, and 51% control by all of us who will sign-up to the project, evenly divided among new and tiered for subsequent employees, but the company will always retain a bigger share of the control than Oracle, so as to not withhold innovations for the sake of the larger mother company.
- This will give Oracle a competitive wedge to go in to Red Hat, IBM, VMWare, and Microsoft accounts leading with Glassfish, to be ported to WebLogic when the time is right, for enterprise features, but build out Glassfish to be a cloud purveyor, so as to lead the market with Oracle benefiting without losing out on the focus of the internal sales force.
- Glassfish will in turn focus on becoming an intranet cloud provider, complete with hardware reference implementations, and core software builds on top of Linux, as ordered and copied and forked and implemented and enhanced by Oracle, so all Glassfish deployments will run on Oracle Enterprise Linux and Sun hardware, every last one of them.
- Oracle will provide the funding and make the determination when a VC should be brought in for help, if desired, the employees of the Glassfish/MySQL/SSO company will focus on delivering product and let the expert financial team at Oracle chart the future for its investment, with a solid understanding of the long-term picture, and the standing of Java if the company were to succeed.
- McNealy, Schwartz, Polese, Dooley, and Safa Catz on the Board with broad oversight of the direction of the company and an eye toward further integration with Oracle, further development of the Enterprise Java specification, and further build-out of clouds for Oracle's customer base that would like to look in to the opportunity available with the economics of hosted infrastructure.
- headquarters in GRand Rapids, Michigan with costs of office building, relocation of employees, and subsidization of international employees to work on the OSS projects, need to pay developers well, as this is a long-term view with no initial exit strategy available through stocks, as this company will not go public for an extended period of time.
all of this is accomplished with the introduction of a little risk-reward analysis by Oracle, that needs a jump-start and prove why it has been the biggest financial supporter of Java, and why it has earned the repsect of those who thought it could not innovate out of the dot-com bomb, and the resulting recession, they have proven to be the best bet in enterprise computing, and they have earned their chance at going for the biggest de-thronement in the take-down of Microsoft across the enterprise cloud infrastructure, with Linux, Java, Glassfish, and MySQL, it is all within reach, just $10M to start, open communication channels, and a little trust in the process, and it will be all there for the taking, its time to kick-start Java again, and nothing would do that better than GLassfish...,
glassfish as cloud platform
The really impressive thing about the Glassfish 3.1 release is the position it puts the product-line in to deliver on a whole new open platform for Oracle to pursue over-time non-established customer bases, in all target verticals, customers or in many cases, enterprises, that have not committed their entire infrastructure to Oracle or SAP, or IBM for that matter. What it does, in a short-term sense, is provide the Oracle sales force with something that can be sold in to 'green' environments, where there is no established leader among the mis-matched product acquisitions that said businesses have made, on a plethora of software companies' product-lines. It reinforces Oracle as a provider of leading-edge Enterprise Java features, that seem to only be getting better for both developers and administrators, alike, as Glassfish 3.1 offers the scalability offerings that will get customers interested beyond departmental applications, that are just looking for something cheap and easy. What Oracle can now say to the thousands of customers that are looking at JBoss for standardization or even SpringSource, is that there is now something better with Oracle's support plan. It will continue to be a process of differentiating the comparative features of WebLogic with Glassfish, but by turning to the cloud for full featured deployable component-ized apps, Glassfish 3.1 will carve out a sizeable and growing niche for developers to understand and for administrators to test, while maintaining a share of budget for advanced, next-stage deployments.
The cloud has been a moving target, transforming from on-line storage to app customization in order to take the features of scalable deployment to the next generation of mixing and matching applications, and parcels of applications to run different features of a web platform. Glassfish 3.1 delivers all of the functionality to look at what could come next, in the development of the cloud, as usability is delivered in clusters, and integration with development environments, that are standard to JEE, for cost-effective testing in environments that are beginning to move to the cloud for deployments. It would not be initially beneficial to Oracle to run a cloud based on Glassfish, though it is conceivable that customers of Oracle could do just that, and by maintaining increased cross-platform support, but only with the core, Glassfish remains a stellar alternative to the other open source offerings in Enterprise Java, including some of Oracle's biggest competitors to emerging markets. Oracle is well positioned to offer a feature-complete cloud offering, that would rather than cannibalize sales of WebLogic could actually open doors, in to new business environments, particularly those that are not somewhat invested in Enterprise Java, as of yet.
The next stage is taking the product-line to the positioning stage, and really offer an alternative off of JBoss and Spring Source, which continue to dominate the standard and non-standard environments, respectively. Oracle would be well-served to open up about Glassfish's potential as a deployment platform for next-stage applications in the cloud, and as Enterprise Java continues to lead the standardization process, as Java continues to maintain its role in the enterprise, there is a need to spell-out how customers should view the two-tiered application server offering, but not to detail, that is still being worked out. Instead, Glassfish 3.1 marks a point where Oracle can actually support two deployment platforms, alongside WebLogic, though it needs to be aggressive with both platforms, the Glassfish opportunity is to gather enough momentum with developers, that has continued to build since v. 1, and move to marketing the feature-set as being ideal for the cloud, and get some named customers on-board that will use Glassfish for reasons that can be duplicated in the cloud. Things that enterprises don't typically do, but considering the economics of an OSS-model, would actually benefit certain customers with knowledge on deployment architectures.
This will take reference architectures on Sun hardware, it will take more-detailed deployment guides on various types of applications, also more competitive analysis on how it stacks up with other OSS offerings, and sales guides for when a customer states something about looking at next-generation development and/or cloud deployment. Oracle's customers are, for the majority, savvy enough to understand when one product-line is tailored for their needs, and Glassfish 3.1 meets the requirements of those forward looking businesses and organizations that need something fast and now, while giving them a deployment guide for when certain aspects of their development match a broader roll-out with scalability requirements. It is not too soon to spell out the differentiating value of Glassfish 3.1 as soon as possible to gather more coverage from the customers and media on why the product-line yields what has been missing from Enterprise Java in the last few years: a distinct leader on new features and advanced deployment capabilities. The cloud is but a term to use in conversation, the real work is only accomplished when detailed documentation provides additional language and materials to realistically put the features of Glassfish 3.1 in perspective. This is the call for Oracle to do, and the time is right to transcend the standard marketing, to take the product-line of Glassfish to new levels, appearing to carve out a respectable niche among paying customers.
