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 users have three options available for support:
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.
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.
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.
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.
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.
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.
In the last (and final) blog in this series, we'll discuss the other two Tomcat Support options...Self Support and Vendor Support.