Chapter 3: Apache and Geronimo

This chapter takes a mini-break from hands-on working with Geronimo to take a look at something that is very important to many Geronimo users. This chapter traces the origin of the Geronimo project. It focuses on the people who are behind the versatile server and the organizations that are backing these people. For readers who may not be interested in this background and history, feel free to skip forward a chapter, because this chapter contains no technical content.

The discussion in this chapter helps to answer the age-old question of how Open Source software works. The chapter also looks at the various widely adopted Open Source licenses, examines their terms, and explains how they may affect you as a user.

More and more organizations are adopting Open Source software for their production projects. This is certainly true if you are already exploring the use of Geronimo in your enterprise. The chapter shows some of the real benefits that Open Source software can bring to the table, and it also points out some pitfalls.

By the end of this chapter, you will have an appreciation for the history of Geronimo. You will become familiar with the developer community that created Geronimo, as well as the organization that is hosting the project. You will also be able to discern the differences between the different Open Source software licenses available and understand why the Apache 2.0 license is most appropriate for the Geronimo project. Last, but certainly not least, you will understand how adopting Open Source software (such as Geronimo) can provide tangible long-term benefits for your development project, and maybe even your company.

The Organization behind Geronimo

Geronimo is a very large Open Source software project, with developers from all over the world. They share the development and maintenance of the server code by working on a common source code repository. Work proceeds around the clock, since contributors are located in different time zones and have differing availability throughout the day. This shared repository is located on servers hosted by the Apache Software Foundation.

The Apache Software Foundation (ASF) is a nonprofit organization created to foster the growth and prosperity of Open Source software communities, leading to the creation of world-class Open Source software projects. The ASF has a rather interesting history dating back to the mid-1990s. It originated around one of the world’s most successful Open Source products.

Founded on World’s Most Popular Web Server

The spirit of the Apache Software Foundation, as its name implies, has its origin in a collaboration and administration model that evolved from the development of a very well known Web server - the Apache Web server. Indisputably the world’s most popular Web server, the Apache Web server had a very humble beginning.

The code that forms today’s Apache Web server originated from early public domain source code from National Center for Supercomputing Applications (NCSA) at the University of Illinois, Urbana-Champaign. The core code was well written for the time, but once the author, Rob McCool, left the NCSA in 1994, there was no official support for the public domain code.

Meanwhile, a group of Web masters from all over the world used the NCSA code and gathered together to collaborate on fixing defects and providing enhancements to the code base. Using emailed code patches as the main mechanism, the group shared user information and administrative tips, as well as code changes and enhancement. The Apache Group was formed in February 1995. The name Apache springs from the fact that the vulnerable server code is similar to a big patch-”A ‘Patch’y.” (For an interesting exploration, see the FAQ at http://httpd.apache.org/docs/1.3/misc/FAQ.html#name.)

The group continued to expand and pick up new contributors throughout the year, leading to the release 1.0 of the Apache Web server in December of 1995. Because of the strong community of Web masters (users of the Web server) behind the project, the Apache Web server adoption exceeded its NCSA parent within a year of release 1.0. The rest is history.

Based on a survey by Netcraft (http://news.netcraft.com/archives/web_server_survey.html, which is an industry-accepted statistics source, as of August 2006, the Apache Web server commanded the lion’s share of users on the Internet - a whopping 62 percent of the market share (representing more than 57 million servers. The next closest competitor is Microsoft Internet Information Server (IIS), weighing in at a distant 30 percent market share.

This installed user base proves that an online user and developer community centered around Open Source code can provide the support and development resources required to make a world-class project. The Apache Group (the name the team took on) is the first Open Source group in history to demonstrate this viability and to take the majority market share in a highly competitive market.

Apache Software Foundation

The Apache Group reorganized to form the Apache Software Foundation (ASF) in 1999. This was necessary because, as the membership in the original group grew, the formal administration, legal, and financial issues needed to be dealt with effectively.

At the same time, the ASF has created a reusable cyber-infrastructure for the bootstrapping, launching, promoting, and sustaining of Open Source projects. With time, this value is realized by the greater Open Source community - resulting in a large spread of projects being managed under the ASF.

Today, a very large number of successful Open Source projects have flourished under the ASF’s auspices. You can get a feel for the breadth of the projects by visiting the ASF official site, at www.apache.org. Figure 3-1 shows a recent front page from the ASF site.

Figure 3-1: Homepage of the Apache Software Foundation

In Figure 3-1, you can see the large number of projects on the left panel. These are called top-level Apache projects and are explained later in this chapter.

Also interesting is how the ASF is funded. Other than private donations, the Web site in Figure 3-1 shows some innovative ways that you can contribute to the foundation. It is important to point out that, while the ASF brings together developers and users around software projects by providing the computing resources needed for collaborative development and communications, it does not fund the software projects itself. In fact, most Open Source software developers donate their time and effort on the project. Like the Web masters who started the original Apache Web server project, these individual developers and contributors stand to gain from the high-quality final products that the collaborative process generates. They typically are also long-term users of the products.

Geronimo Has Inherited the Apache Spirit

Completely consistent with the founding spirit, the Geronimo project feeds off a thriving community. It is a global community of Java 2 Enterprise Edition (J2EE) users and developers. The community members interact via the ASF-hosted Web site, together with a wide variety of alternate supporting communications channels - including mailing lists, issue-tracking systems, wiki, and direct email.

The Geronimo server’s code base is the focus of the community. Any member of the community is welcomed and encouraged to do the following:

• Use the software

• Ask for help on any of the community communication channels

• Report defects

• Make suggestions for future enhancement

• Participate in technical design discussions

• Provide assistance to other new users

• Submit code patches to fix defects and/or add features

• Contribute existing code (possibly from commercial products) that would be useful for the project, which must be approved by the overseeing Project Management Council (PMC)

While the project management committee has the final vote and say on administrative and technical decisions, the consensus-based decision-making process is formally documented by the ASF and followed religiously. The wider community’s input is also regularly solicited through the communication channels and considered heavily when making decisions.

Without the initial group of enthusiastic Web masters, the Apache Web server would have never reach its de facto status today. Without a large group of enthusiastic J2EE server users and developers, Geronimo cannot reach its fullest potential. The PMC and the committers both realize this and do their best to ensure the growth and prosperity of the community.

Geronimo As a Top-Level ASF Project

Figure 3-2 shows the organization of software projects on the ASF.

Figure 3-2: Organization of projects at the Apache Software Foundation

The projects at the ASF are organized into two levels, as shown in Figure 3-2. Top-level projects are either of the following:

• Major, matured, well-known projects in their own right

• A grouping of second-level projects or subprojects

For example, the Jakarta project consists of many Java-based technology projects (not all projects in the ASF are written in the Java programming language). This includes the Velocity project among others. The Web services top-level project in Figure 3-2 houses many subprojects, including Axis, and Scout, to name just two.

When there is enough support and demand for a particular second-level project, it may be promoted to the top level. For example, Ant was formerly a subproject. Geronimo started life as a project under the Incubator. The Incubator is where projects and communities new to the ASF are bootstrapped. The next section provides a cradle-to-present timeline of the Geronimo project.

The Geronimo Project Timeline

Started in August 2003, the Geronimo team completed a J2EE 1.4–compatible server from scratch in about two-and-a-half years. Figure 3-3 shows a historical timeline of the Geronimo project that notes some interesting events.

Figure 3-3: Historical timeline of major events associated with the Geronimo project

The significant events, from its conception to the time of this book’s publishing, are shown in Table 3-1. You can cross-reference the rows in Table 3-1 with the timeline in Figure 3-3.

Table 3-1: Significant Events on the Geronimo Project Timeline
Open table as spreadsheet

Date	Description
June 2003	A group of developers walked out of their involvement in the JBoss project and formed their own business. The resulting company was called Core Developers Network, and the idea was to obtain Open Source consulting, training, and support work to fund and sustain the group’s Open Source work. They strived to create a J2EE container from scratch, leveraging their accumulated experience and expertise. These developers, and others that followed, were to become the founding members of the Geronimo project.
August 2003	Accepted as a participant in Sun’s certification efforts, the ASF announced their intention to create a new software project around a community of J2EE users and developers. This was a perfect project for the members of the Core Developers Network. The Geronimo project began in the Apache Incubator. The Incubator is an isolation chamber for startup projects. It is a place within the Apache organization where beginning projects and the developers behind them can benefit from the resources provided by the ASF while learning the ropes of the Apache Way. Some incubated projects, unfortunately, never make the cut. The Geronimo project started in the Incubator in August 2003. In this particular case, the incubation was mainly for the training and establishment of a PMC to govern the large Geronimo project.
November 2003	A demonstration at ApacheCon 2003 showed Geronimo running the de facto server benchmark of the time - Java Pet Store - for the first time. The Geronimo developers spent weeks of sleepless nights to prepare this operational demo, delivered during the conference from the Las Vegas conference hotel bar.
February 2004	By February of 2004, the Geronimo project and its new PMC graduated to a top-level project status at the ASF. Work continued in earnest throughout the year of 2004 to build the J2EE server.
April 2004	Geronimo 1.0 Milestone 1 debuts, providing a base set of functionality in an effort to gather initial feedback to continue forward.
September 2004	In September 2004, Geronimo 1.0 Milestone 2 was released. This was largely a demonstration-of-capabilities release, featuring partial support for Web applications and Enterprise JavaBean (EJB) deployments (for example, EJB CMP was not fully implemented).
November 2004	The Milestone 2 release was followed by a more full-featured Milestone 3 release in November 2004. Unfortunately, the configuration and deployment mechanism for EJB was broken in this release. Most evaluation users who needed to work with EJBs had no other choice but to download the latest unstable code from the code repository and build it themselves.
January 2005	In late 2004 and early 2005, a company named Gluecode Software, which was formally recognized for donating the Business Process Management (BPM) engine for Apache Agila, started to recruit key Geronimo developers, many from Core Developers Network. While commercial enterprise recruitment of developers from Open Source projects is certainly not new news, in almost all cases the new employment does not involve continual paid involvement in the Open Source project. Gluecode hired the Open Source developers, and all the developers continued their commitment to the Open Source Geronimo project. In fact, Gluecode built its flagship product on top of Geronimo to make the business case. The Gluecode product was a rebundling of the pieces that composed the Geronimo project. This bundling was less ambitious in that it did not include the EJB container component of Geronimo. In addition, Gluecode added to the mix its own GUI-based Web console for configuration and management (this was later donated to the project) and the integration of the Apache Pluto portlet engine. This allowed Gluecode to build on top of the Geronimo infrastructure to catapult the development of its commercial product. This marked one of the first publicly visible hiring and continued support of Open Source developers. It was a sign of the times. High-quality, robust Open Source software often involves world-class software engineering that is on par with (or superior to) any creations originating from any proprietary software vendor. Yet, the Open Source developers are often required to work at night and on their own time - skirting around the mundane (but bill-paying) activity they grudgingly called the day-job.
May 2005	IBM announced its acquisition of Gluecode. This meant that several key Geronimo developers immediately became IBM employees. While the community was skeptical in the beginning, it soon became clear that IBM intended for Gluecode to continue its intense contribution to Geronimo. IBM also started to market support services for users of the Geronimo server. IBM also continued to market the Gluecode product - a product built on top of Geronimo. Later in the year, IBM announced its Community Edition of the Websphere Application Server, based entirely on Geronimo.
August 2005	It was a long wait for many early adopters, but Milestone 4 finally arrived in August 2005. Milestone 4 is often described as the full-featured release prior to certification. This milestone release fully supported the deployment of Web-tier components, EJBs, enterprise applications, and Message Driven Beans (MDBs). For users evaluating Geronimo, this was the release that they had been waiting for - since almost all of the planned features were in place and functional. Jetty is the primary Web-tier container in this release. While Tomcat is integrated, it requires some major surgery on the configuration files and a rebuild to activate it.
October 2005	In early 2005, with most of the planned features in place, the team focused its work on getting the details right and on J2EE certification. The certification effort was both tedious and time-consuming. The work cumulated in the very first milestone release that was officially J2EE 1.4–compatible -Milestone 5 in October 2005. Milestone 5 also included the capability to easily switch between Jetty and Tomcat as the Web container, without rebuilding.
January 2006	With release 1.0, the future was met with a certified version of Geronimo. The announcement of Geronimo 1.0 at ApacheCon 2005 in San Diego (December 2005) was the moment that the entire Geronimo team had been working toward. The actual server code was not ready until early January of 2006, leading to a few weeks of anxiety among excited new users.
June 2006	Release 1.1, a robust bug fix release of Geronimo, is announced around the time of the JavaOne annual Java developer conference - May 2006. This release contains major bug fixes, a new syntax for specifying component modules, as well as new features such as support for hot deployment, support for Geronimo plug-ins, and a GUI-based installer. The actual distribution of Geronimo 1.1 was made available late June 2006.

At release 1.1, Geronimo gathered a significant community of J2EE users and developers. Moving forward, this community is likely to continue its growth. If the original Apache Web server is any guide, the ultimate community size and user base can be quite significant.

It is certainly an opportune time for users of proprietary J2EE servers to consider migration to Open Source. Often, however, a user coming from a commercial J2EE environment is full of doubt and questions about Open Source in general. The next section addresses these concerns.

Benefits of Open Source Software

There are many known and proven benefits in adopting Open Source software. Some of these benefits are quite tangible, while others are more abstract. Among the concrete benefits are:

• The software itself is typically free of charge, even when deployed for commercial purposes.

• Since the source code is available, you can always modify it if you need to adapt it to specific needs (of course, this is subject to the software license).

• Since the source code is available, you can fix the defects yourself and do not have to depend on a vendor’s schedule.

• Information, documentation (such as books and articles), and training are typically widely available from multiple sources, often internationally.

• The number of consultants or developers with expertise on an Open Source software code base can be sizable, and, therefore, skilled labor on the code base is often more widely available than for proprietary software.

• Wide availability of the source code typically means that support services from third parties are multisourced and competitive.

• If you are working in a multinational company, you are not restricted by the countries in which the software vendor decides to do business. There are no geographic boundaries with freely distributed Open Source software.

• You are protected from the risk associated with a proprietary software vendor going out of business, or a decision from the vendor to discontinue the product.

Some of the less tangible benefits include:

• You benefit from the experience of other users like yourself. The contribution of ideas and fixes for defects from a large user community helps refine the definition and evolution of the software in a manner that is not possible to achieve within a proprietary vendor’s limited market.

• Designers and developers on the job are fully qualified (in the case of the ASF, this status is achieved through a meritocracy - see the sidebar About the Geronimo Meritocracy) and typically highly experienced in the specific area. They typically work in collaboration to create the software. In many cases, you are getting the global-cream-of-the-crop developers working for you on an Open Source project.

• Open Source projects tend to leverage and build upon other Open Source projects. This often means significant features and flexibility that often are not available in a proprietary vendor solution.

With all of these (very significant) benefits in mind, it is hard to see why someone would shy away from adopting Open Source software.

Important-About the Geronimo Meritocracy

Developers of projects at the ASF follow the rule of a meritocracy, inherited from the group that developed the Apache Web server. As an official developer for an ASF project (say, Geronimo), you will be granted the ultimate commit karma to the source repository. Everyone can read the source code in the repository, but only official committers can modify or add to the code. There is no way to sign up or enroll to become a committer. To become a committer, you must be voted in by other committers. To earn the trust and approval of other committers, you must first prove your worth. This typically means spending time in the community, helping others, and contributing to the project in the form of a code patches, defect reports, mailing list involvement, and so on. If you are dedicated and capable, the existing committers community will eventually notice your merit and invite you to officially join the project as a committer.

Some of the most common scenarios preventing the use of Open Source software include the following:

• You cannot find an Open Source project that satisfies your needs.

• The maturity and reputation of some Open Source projects are questionable.

• You need dependable support, but no company is offering such a service for the Open Source project you are considering.

• The expertise for the specific Open Source project that you are considering is not available locally.

• You cannot abide by the specific licensing terms of an Open Source project (a variety of Open Source licenses are discussed in the next section).

Obviously, some of these issues cannot be readily overcome, and proprietary software may be your only choice. But when it comes to the selection of a robust, scalable, and compatible, J2EE 1.4 container, there is little reason why you would not investigate the possibility of adopting the Open Source Geronimo server.

Not all Open Source software is the same. For one thing, it may be distributed under different Open Source software licenses. This may have implications for how you may or may not use, modify, or redistribute the software. The next section will help you understand some of the most common Open Source licenses available today.