TomcatExpert

Apache Tomcat Support Options: Part Three-Understanding Community Support

posted by avanabs on April 15, 2010 10:23 AM

In prior entries, we’ve discussed Commercial JEE Application Server Support, the reasons this support is so costly, and began discussions focusing on the support differences between Tomcat and commercial JEE Application Servers. Now we’ll explore the three general types of Tomcat support that are available and dig into the most common choice, Community Support.

Tomcat Server Support Options

Tomcat users have three options available for support:

  • Community Support—The Apache Tomcat distribution is “supported” by the Tomcat community, on a volunteer basis. Repairs/enhancements are made (or accepted) by the Project Management Committee and committers (see below for details) on a best efforts basis, with no guarantees of either resolution or timeliness. Community support depends on the user doing some of the work, with the community providing expert advice.
  • Self Support—IT organizations can also support Tomcat themselves, by taking the source distribution, becoming sufficiently expert, and repairing/enhancing their copy of Tomcat. They may provide these back to the community if desired, and the community may accept the submissions if they decide that they meet broad customer needs and community technical standards. Self supporting organizations also can take advantage of the Tomcat community, although with the same limitations faced by the Community Support strategy. Self support does create the possibility of generating a branch in the Tomcat code, which may matter to some IT organizations.
  • Vendor Support—IT organizations can also purchase support from one of the Tomcat vendors, who already have the expertise and may already be active in the Apache community. In this case, the IT organization is outsourcing the Tomcat internals expertise, learning curve, community relationship activities, maintenance, test, and platform integration.

    Vendor support for Tomcat is similar to commercial JEE application server support in several ways, including outsourcing much of the detailed expertise and depending on the vendor to meet responsiveness guarantees. The huge difference is choice, leading to far more cost effective solutions in a competitive marketplace.

Each of these options has distinct benefits and costs. It is important to understand these while making the business decisions associated with deploying Tomcat, particularly for mission critical enterprise scale applications. The line between these three options is not always very clear, and the IT organization has to invest in some in-house expertise (just as with proprietary commercial products) no matter which option is selected.

How Does the Apache Tomcat Community Work

In order to evaluate the various Tomcat support options, it is very important to understand how the Apache process, and in particular the Tomcat Community, actually works. Tomcat is “Open Source”, and developed by a “community”, but that definitely does not mean that just anyone can change the official code. The Apache process is designed to strictly control how changes are made, and by whom, to protect the integrity of the technology.

The Apache process is based on the concept of a “meritocracy”, where participation at various levels is nominated and elected by current active project members (“committers”). Those who exhibit sufficient expertise and show substantial levels of contribution become trusted to interact more directly with the project code base. Experience has shown that the system works very well.

Apache Participant Definitions

The Apache process defines a number of roles for participation in community projects. We will focus on those relevant to the issue of supporting Tomcat, but the complete list of Apache roles can be found at http://www.apache.org/foundation/how-it-works.html.

  • End User—Anyone who uses the software. Users submit defect reports and feature suggestions, but not code. Apache Tomcat community users a the equivalent of commercial product customers, although they don’t pay for the privilege. Users require no permissions to participate.
  • Developer/Contributor— Users who contribute code and/or documentation to the project. Traditionally, developer users also actively participate in discussions, provide suggestions, and offer criticism. It is important to note that developers do not have write access to the project code repository and require no permissions to participate.
  • Committer—Committers are the key element in an Apache project. They are Tomcat code developers who are responsible for the architecture, planning, and code. Only committers are given write access to the code repository and they have signed the Apache Contributor License Agreement (CLA). Committers are elected by nomination and vote of the other committers. They can make changes directly and they are the way that developer code actually gets approved and into the project. There are very few committers in any project, even for a highly active community like Tomcat, which has 18 at last count.

    It is also important to note that even committers can’t unilaterally change the code base. The Apache Tomcat project has adopted two of the approved peer review processes, one for the stable production code and a second for the new release under development. “Review and commit” is used for the stable production branches, to insure that these remain as stable as possible. “Commit and review” is used for development branches and allows committers to rapidly submit changes to the code base, where it is then reviewed by community members.
  • Project management Committee (PMC)—The PMC is headed by an Apache officer. The main role of the PMC is not code and not coding - but to ensure that all legal issues are addressed, that procedure is followed, and that each and every release is the product of the community as a whole.

The Reality of Community Participation

From the above, we can see that only a selected group of community members can determine project technical direction, decide on what changes get made, and make changes to the project code base. In practice, this also means that fully supporting Tomcat involves individual participation at a very high level if you expect that your changes will ever make it into the mainline code base.

All three Tomcat support options need to be evaluated with the Apache process firmly in mind. For example, while a developer in an IT organization may be able to add a specific feature to Tomcat that their project requires, it is fairly unlikely that a proprietary feature will ever make it into the code base. If the IT developer does alter Tomcat to add their desired feature, they have effectively created a permanent proprietary branch. Even if the feature does get accepted, both the timing and the final function are up to the Committer community, not the submitting developer. This means that the “do-it-ourselves” option can be more of a hope than a reality.

At the other extreme, commercial Tomcat support vendors may have one or more Tomcat Committers on staff, which allows them to more readily introduce bug fixes and, to some extent, enhancements. While these submissions are always subject to community approval, committer status significantly enhances the ability to propose and implement changes as well as providing “insider” access to the community guru’s.

Tomcat Community Support

The Apache distribution does not include any guaranteed support, but the Apache community is both committed and active, with responses to queries and concerns typically coming somewhat more rapidly than the commercial JEE vendors provide for their products, and without the typical “is the server plugged in” escalation process.. As one financial services CIO noted, “I frequently get issues resolved by the Tomcat community quicker than my JEE vendor will even admit that I have a problem”.

The other side of this situation is that no response may be forthcoming and other than asking again, there is little/nothing that the user can do. This situation is more frequent for feature requests than for bug reports, but does happen in both cases. It is important to remember that all Tomcat community support is strictly on a volunteer “best efforts” basis and it is provided if/when convenient. The primary focus of every Apache community is to develop their project. Customer support necessarily is a background activity, no matter how committed the community may be.

Other Costs of Community Support

Equally important to remember is that the solution, if provided at all, will be in the form of a source code patch. It is highly unlikely that any regression testing has been done, that platform dependencies have been delt with, or that there is any associated documentation. Finally, the responsibility for manually applying the patch to the Tomcat distribution and rolling it out thru the IT infrastructure is the User’s responsibility. Because all of these are the responsibility of the user, this can require significant expertise and effort.

So, when choosing to adopt Tomcat Community Support, it is very important to remember that the User is a key participant and is expected to provide the bulk of the total effort.

Pros of Community Support

  • Very low fixed outside costs
  • Generally responsive
  • Direct access to Tomcat developer community

Cons of Community Support

  • Requires significant internal expertise to interact with community
  • Variable and unpredictable internal costs
  • Community support does NOT include regression testing, platform integration, etc
  • No guarantees on response time…or even if it ever happens
  • Community provides support on volunteer basis, if and when they get a chance to do it
  • Significant danger of forking code

In the last (and final) blog in this series, we'll discuss the other two Tomcat Support options...Self Support and Vendor Support.

Andy has recently decided to make the jump from individual consulting to join the Spring Source team. He will continue to be working with major clients to assist them with IT architecture evolution, now as a member of a large and growing organization. His first project will be leveraging Tomcat, Spring, and a Tomcat based data grid/cache called GemFire. He’s looking forward to sharing the lessons learned with the tomcatexpert community. Andy has been architecting, designing, and building enterprise infrastructure and applications software for most of his career. He’s been responsible for BEA’s “Blended Source” initiative, combining the best of Open Source (including both Tomcat and Spring) with WebLogic, BEA’s WebLogic Enterprise Security product family, MEI Software’s financial systems, Netegrity’s SiteMinder security product, Camex’s electronic publishing systems, mainframe applications for Bell Telephone, and many others. During that time his hands on technology experience has ranged from octal coding into neon lighted switches all the way through JAVA and beyond, including many generations of “the best and final thing we will ever need”, and he looks forward to working on the even better things coming in the future. He was involved in the early days of Open Source software as a contributor to EMACS and refocused on Open Source during his tenure as Director of Product Management with BEA Systems, combined with a fascination for the rapidly evolving application deployment architectures and technologies driving today’s development. Andy has provided architecture and technology guidance for both vendors and IT organizations and he shares what he is learning through consulting services and through his web site, Enterprise Software Trends (www.estrends.com).

Comments

Post new comment

CAPTCHA
This question is for testing whether you are a human visitor and to prevent automated spam submissions.