Section 2.2. The Elements of Open Source Maturity


2.2. The Elements of Open Source Maturity

As mentioned previously, the elements of open source maturity are direct indicators of the potential difficulties you can encounter when using open source. The specific elements of open source maturity we will discuss are:

  • Leadership and culture

  • Vitality of community

  • Quality of end-user support

  • Extent and scope of documentation

  • Quality of packaging

  • Momentum

  • Quality of code and design

  • Quality of architecture

  • Testing practices

  • Integration with other products

  • Support for standards

  • Quality of project site

  • License type

  • Potential for commercial conflicts

  • Corporate commitment

Each of these strengths is directly related to the difficulty an IT department will encounter when using the software. These criteria are not absolute. Some are fuzzy, some are matters of taste and judgment, and many overlap in different ways.

As an IT department becomes more adept at using open source, the weaknesses that are difficult to overcome during an open source deployment will become easier to understand and identify.

2.2.1. Leadership and Culture

One of the most important factors in evaluating the maturity of an open source project is the quality of its leadership. Are they serious developers with a strong understanding of technology and the kinds of problems that you, with a business at risk, are facing? What previous successes do they have to show for their work?

Unlike a commercial software company, open source projects don't rely on CEOs or directorsindividuals, that is, whose reputations, associations with other companies and organizations, and previous executive positions are typically described on a web site for all to see. But that hardly means the official leaders of an open source project cannot, or should not, be assessed before one commits to that project's code and its community of fellow users and developers. Indeed, precisely because the open source movement is open, with most of its participants' activities and exchanges recorded on various Internet mailing lists and web forums, more valuable information might actually be available about those people than what is available about executives at private and public companies. Far more than its commercial counterparts, the open source community and process are self-documenting.

The first question to ask about a potential project is simply this: is the leadership identified? Unfortunately, a number of open source projects get started by individuals who hack together a piece of code that works, more or less, and then leave it there, unfinished, unpolished, and unworkable for any serious applications. What's worse in terms of evaluating leadership is that beyond an out-of-date "About Me" statement on the project's web page, there is no indication that anyone is in charge of moving the project forward. Clearly, no enterprise wants to start depending on what is essentially an abandoned project, no matter how good its founders' original intentions were or how hard they once might have worked to realize an initial vision. Like all software, open source evolves; it's more a process than a static, deliverable object. It is practically a living thing that needs ongoing nourishment, encouragement, and care. And without leadership of some kind, an open source program will wither and eventually die.

One good indicator of serious, devoted, and informed leadership specific to the open source realm is the degree to which a project leader or other team member participates in the many forums that have sprung up to facilitate the open source movement. Not every project leader will be as prolific and active a contributor to these forums as Gavin King of JBoss fame, for instance, or Scott Ferguson of Resin. They have distinguished themselves by speaking regularly at major open source conferences and participating in numerous online forums and mailing lists. All of this shows a level of personal, emotional, and perhaps even financial investment in not only leading their specific projects, but also furthering the progress of the open source concept as a whole.

But even individuals who don't demonstrate exemplary participation can be evaluated just the same. You can review their contributions to online forums and their appearances at important conferences. Most of the significant online forums get archived for a period of several years or more, which makes it possible to see how often an individual has contributed and how favorably his peers have responded to his comments. Is he articulate? Is he technologically savvy? Has he made a significant contribution to the public knowledge base for the product?

It should be noted, however, that sheer celebrity is not a perfect measure of leadership skills. Due diligence analysis is still required, even if a project has received a lot of press or is backed by a large company, such as Sun or IBM. Neither fame nor sponsorship is a guarantee of quality.

Besides personal ability to lead, another crucial measure of an open source project is its culture. What is the project's attitude? How does it respond to questions or suggestions for changes or new features? Are the people who represent the project publicly defensive? A prickly attitude, for instance, is not likely to help engender warm feelings among the users, developers, and respected industry analysts who might contribute to the project's long-term success. To a large extent, open source projects live or die by word-of-mouth, by the Net's myriad grapevines, where anyone can evaluate a developer's attitude and expertise. By the same token, an excessively fawning attitude can be detrimental, too. There is such a thing as using open source forums to draw too much attention to a particular body of work or using them as outlets for a tacit form of advertising.

Good leaders spend their time wisely, but with generosity. Highly knowledgeable individuals, such as Scott Ferguson, have made themselves available to the community and have demonstrated a remarkable responsiveness, without capitulating to the many naïve and downright lazy questions that his exposure inevitably invites. Ferguson doesn't bother to respond when he's asked, for the 50th time, "How do I configure security restraints?" But when a substantial issue arises, he's there with useful questions and answers that help the community. And those who have followed his activities over the years say Ferguson gives credit where credit is due.

In the end, a strong, professional, respectful culture leads to a healthy project. If people feel they are part of something good, if developers and users aren't put off by bad attitudes among a project's leaders, there is a better chance that they will remain committed to the projectand even throw themselves into it.

Superior culture also attracts superior people. It is a self-sustaining process.

A developer's time and energy are limited, and the best won't waste their resources contributing to projects that don't provide the kind of payback they are seeking, whether it is monetary gain or just the satisfaction of knowing they've made the world a better place.

2.2.2. Vitality of Community

There is a huge correlation between leadership and the vitality of the community. Leadership breeds a healthy culture that will spawn an active community. In such communities, everyone finds something useful to do, and one of the key indicators of this is a division of labor between the project's developers and users. Evidence of this can include separate lists for users and developers, and subprojects dedicated to productization activities such as creating easy-to-use installation packages or user documentation.

Healthy open source communities also tread a fine line between disciplining lazy behavior, such as using curt replies to direct people who have simple questions to locations where the answers can be easily found, and welcoming new people into the project.

The size of the community is also a good indicator of a project's viability. How active are forums? How many downloads happen, and how often? How frequently is the project referred to on Google? What is the project's rating on sites such as OSDIR (http://www.osdir.com/)?

2.2.3. Quality of End-User Support

End-user support is a key element of a project's maturity, and it's one of the most crucial elements in terms of saving time when using an open source project. Active forums, well-maintained FAQs, and documentation that are available through a search engine are generally the biggest time-saving feature of an open source project. Such mechanisms identify not only answers, but also members of the community who are fellow travelers, who are using the software in the same way you are. Contacting such community members directly can often be a huge timesaver if both sides of the conversation have something to offer to each other.

As discussed earlier in this chapter, one of the most compelling aspects of open source projects are the very public and free-ranging discussions that take place among the lead developers, far-flung contributors, and end users. These discussions serve a variety of purposes, not the least of which is providing general advice, tips, and specific answers to end users' problems. Most open source projects rely on these open forums as low-overhead substitutes for the kind of profitable annual support contracts for which commercial software companies typically charge a handsome price.

Not surprisingly, the most popular open source applications and programs tend to have the most active forumsand the most seasoned and helpful experts participating in those forums. Under the best of circumstances, answers to a technical question might show up within minutes or hours of the original post. Overnight is more typical. Usually, the answer is entirely satisfactory. But on some lists and boards, questions simply go unanswered.

Two extremely helpful features of the best online forums are a searchable archive of questions and answers, and well-maintained FAQs. Both arrangements make it easier for developers to find out if their particular problem has been addressed already. Ideally, an archive is organized according to topic, but a free-text search can be enormously helpful, too. Likewise, the best FAQs address the most recent issues that have been important to developers and users. This requires a certain amount of attention from someone on the project in question and is often neglected as other tasks get priority. But an up-to-date FAQ is usually a sign of a healthy, actively supported project.

2.2.4. Extent and Scope of Documentation

Another good clue about a project's work process and code quality is the quality of its documentation. Sloppy documentation can well reflect sloppy coding practices or, at the very least, an arrogance or even disrespect for the final user of the code. Perhaps it's too much to expect that every line of source code should have a comment attached to it, as some textbooks would prescribe. But it's not out of line to expect that the instructions for installing, running, and fine-tuning a piece of enterprise software be written in reasonably clear English. Moreover, the historical milestones in the code's development ought to be available for all to see. Transparency is a must.

Tomcat, an open source, Java-based servlet container, is a good example of how this documentation should be done. Better than most open source projects, documentation for the Tomcat site is organized by major version release, in reverse order: Release 5.x, Release 4.1, and so forth, back to the original Release 3.0. The original documentation for each release is kept available, just as they were when each release was current. This comprehensiveness is essential to using Tomcat, because many users are still using older releases of the program. Easy, direct access to older documentation, without the trouble of having to search for and unpack the relevant files, makes it much easier for consultants, say, to reconfigure, tweak, or debug any particular Tomcat installation they happen to stumble across.

Something else to look for in a project's documentation is a comprehensive user manual or reference guide. This manual should provide complete instructions for installing the software in question, and not just simplistic README files. Particularly important, and too often completely missing, is information about how to configure the software. Configuring a new program can be enormously time consuming, even with good documentation at hand. But working without a manual clearly outlining the common configuration scenarios can add significantly to the integration costs. Now, if you're working with a very well-known and widely used piece of open source, such as the Apache Web Server or its frequent companion, Tomcat, you might be in luck. These especially popular programs have spawned their own commercial books, written by expert users or by the developers themselves. Like all third-party computer and software manuals, the quality and comprehensiveness can vary. But the fact that such a book is available at all is a good indication of a program's usefulness and reputation in the marketplace. In most cases, a project's web site will offer pointers to such books, perhaps with commentary. Likewise, by scanning online forums you might find mention of relevant titles. Several technical publishers, including O'Reilly Media, have published manuals on open source programs and books concerning the movement in general.

2.2.5. Quality of Installation Packaging

It behooves prospective users to evaluate how an open source program is packaged. Some programs are available only as source code, thus requiring users to undertake the somewhat difficult task of compiling that code into binary, executable form. Other projects provide both source and binaries, and still others come complete with installers designed for specific operating systems.

Perhaps the highest state of evolution for an open source project is when someone has had time to write an installation package that can install the software easily on many different platforms and configurations. This usually is not fun work, and for a project to have attracted a community that is large enough for this to be accomplished is a sign of the project's maturity and strength. Sometimes, one of the senior developers will actually take the time to do this sort of work himself, and much earlier than it would have happened otherwise. This is not uncommon when the open source effort is fueled by a core team that is also interested in selling consulting services related to the project.

2.2.6. Momentum (or Frequency of Releases)

Like all software, open source tends to undergo constant updating. New features, new extensions, bug fixes, and other changes get worked into each new release. How often new releases of a program become available might help or hinder its effective use. Clearly, if updates are not released often enough, users will be forced to wait too long to use the latest code and won't be able to use the program as effectively as possible. And if an important bug is discovered, the fix for it ought to be made available as quickly as possible.

Veterans of the open source world know how frustrating it can be to discover in the archives of a project's mailing list that an important problem has been addressed with new code but that the code is not yet available in an official release of the program. Until the official release is available, the only option users have is to undertake a new build of the program on their own, using the prerelease version of the softwarea difficult undertaking that many developers wish to avoid.

On the other hand, there is such a thing as a too-frequent release schedule. Ideally, new releases should be put forth only when substantial additions and changes have been made to a program, and not simply with every sprinkling of not-so-important changes.

The right release schedule depends largely on how stable and mature a project is. Many programs reach a stage where they are not receiving many updates and the rate of new releases slows down to one or two a year, if that. On the other hand, a lack of updates can be an indication of abandonment or stalled development activity, so look carefully at other clues on the project's web site. In the past, stalled open source projects have been resurrected as business conditions and related technologies changed. A less mature product that is in high demand and wide use can be updated as often as once a month.

Check out the release history, though, to see if the new releases are mainly significant or more trivial. A well-managed release cycle indicates the presence of experienced technologists at work. Well managed can mean different things depending on the culture of the open source project. For example, Drupal and Tikiwiki, two excellent LAMP-based content management systems, have well-managed release cycles. But Drupal favors longer beta periods and multiple release candidates, because that project favors stability over new features.

2.2.7. Quality of Code and Design

Exceeding the importance of almost every other factor, of course, is the quality of the actual code that is produced for others to use. In contrast to commercial software, open source code is just that: open to direct inspection at the source-code level by anyone and everyone, including potential users, developers, competing development teams, and yes, even nefarious hackers. Few people have the knowledge or time, however, to evaluate the software's quality fully, by inspecting its source code line by line, module by module. But it is possible to glean some meaningful insight into the thinking that has shaped the codeinto the mind or minds that have produced what you see.

The clues are primarily visual. Take the code layout, for example. Have the authors organized the code in a way that invites understanding, and that reveals at least some organization? Is the code modularized? How are the modules grouped together? Has a naming convention been rigorously adhered to? Anyone with a modicum of experience in writing and working with enterprise-level software should be able to "read" this high-level structure and the labels being used and get at least a partial feel for the software's functions and the quality of its coding.

The deeper the inspection of a program, of course, the more fully its quality will be revealed. Many open source programs are the result of team efforts, with some modules, functions, and Java classes, for instance, of much higher quality than others.

2.2.8. Quality of Architecture

The quality of an open source program's architecture is difficult to assess, but for obvious reasons, it tends to be an important measure of the code's maturity. By architecture, we mean system components (such as classes in J2EE and PHP systems, modules in Perl), use of design patterns, OO techniques, and naming conventions. To evaluate this kind of architecture fully, it's necessary to understand the program's requirements to some degree. And even then, it can take a fair amount of investment and time to fully determine and understand a program's internal architecture.

Fortunately, a small industry of open source-focused support companiesessentially consultancies specializing in helping users to employ selected open source projectshas been spawned by open source's growing popularity. Maintaining a critical understanding of the architectures of open source programs is the bread-and-butter work of these firms. It can be extremely helpful in the early stages of evaluating an open source project to call on such firms for help in understanding the project and code, and how it stacks up against commercial alternatives.

2.2.9. Testing Practices

Some open source code comes with automated, built-in testing facilities as standard features. In particular, the developers of many mature Java projects have gotten the testing religion and have begun to make test routines a significant portion of the code they develop and make available for public use. As much as 70% of some code is devoted to this kind of testing, which can be especially important when building, say, a public web site whose servers will have to deal with high volumes of visitor traffic and transactions. The presence of unit tests is a key indicator of good design.

2.2.10. Integration with Other Products

All software in the enterprise operates as part of what developers often refer to as an ecology, meaning that a set of interdependencies cause programs to call on each other, vie for shared resources, and exchange transactions and information. As users evolve their computing setups, they might swap out one program for another or install a new system, and such changes can disrupt the ecological balance, as it were, by altering or ignoring certain dependencies between the previous set of applications and subsystems. Release 3.4 of Program A might work fine with Release 7.8 of Program B, but when the user upgrades A to 3.5, the long-existing compatibility between the two programs might break down. Much as what happens within a desktop PC, conflicts can arise as programs are added to and removed from a working system.

Frequently, open source projects are aware of such dependencies and new releases are proactively tested with other open source software. The Zope application server, for example, has been used frequently with the Squid reverse proxy cache. It is likely that when a new release of either comes out, it will be tested with the other. Pay attention to and take advantage of such nests of compatibility.

2.2.11. Support for Standards

Closely related to the question of dependencies is the need for programs to use standards-based APIs. For various reasons, open source projects sometimes trail the standardization being pushed forward by the still-dominant commercial marketplace. In other cases, two or more open source projects focused on the same area of technology might be competing to set the standard for a certain brand-new API. The situation can get particularly confusing and difficult for users to negotiate if a project that is pioneering a new category of software advertises itself as adhering to a standard API, but in fact ends up implementing an API that diverges from the standard.

The problem of dependencies and nonstandard APIs is sometimes addressed in open source projects by having a program download with a preselected set of other programsthe programs that make up its local ecology, that is. By predetermining this collection of applications, subsystems, and drivers, perhaps supplied by a number of different projects or authors, it is possible to make sure all the pieces work together correctly. In short, someone else is managing dependencies for the user.

2.2.12. Quality of Project Site

Open source project web sites are usually masterpieces of brevity and clarity when it comes to site design. That said, some are more concise and well organized than others, and this can matter a lot when a large team with different skills and relationships to the open source project are involved in a deployment. A great site can make it easy for everyone to educate himself and find what he needs.

2.2.13. License Type

Open source projects employ a variety of different licenses. In some cases, there might be no restriction on the use of the software for developing a new system that is based on a certain open source program. But when it comes time to distribute those applications and the underlying program in a commercial application, or to make the applications available through a public web site, users must pay a feeperhaps determined by how many servers are executing the software. Some licenses give the user freedom not only to work with the program to develop new applications, but also to distribute it at no charge. Still another level of license permits users to modify the software themselves, perhaps requiring that they contribute their improvements back to the open source project.

One of the great attractions of open source is that users get direct access to the program's source code. This can be of great comfort when problems arise. One of the worst disasters to hit a corporate IT environment is when a piece of commercial software breaks down and the code's supplier has gone out of business. When this happens, an enterprise's entire investment in a piece of software can be lost, and there is no way to save it. With an open source program, users can get at the source code and change it if need be. This is a vital form of insurance, with advantages that many corporations are now waking up to. Not every company will bother to modify open source code, but just knowing that it is an option can be a major comfort.

2.2.14. Potential for Commercial Conflicts

Unfortunately, software of all sorts, open source and commercial, sometimes has a dubious legal status. Code might infringeor simply appear to infringeon the intellectual property of a commercial company. This puts developers as well as users at risk of potential legal action by those commercial suppliers. A software company's decision about whether to sue to protect its product can depend more on how well the competing open source project is faring in the marketplace than on actual infringements. The Open AMF project, for example, implements a proprietary protocol created by Macromedia. While the Open AMF software does some very interesting things, if Macromedia frowns on the effort, it might have the power to shut down the project.

This sort of conflict is a rare occurrence, however, given that open source projects focus mostly on integration with other open source projects. It is also a risk that is inherent in the use of any software, open source or commercial.

2.2.15. Corporate Commitment

Several open source projects, such as the Linux operating system and Apache Web Server, have enjoyed tremendous support from large, established computer companies, including IBM, Sun, HP, and Dell. IBM, in particular, has helped the Apache server effort with people and valuable source code, not to mention its name and reputation.

Corporations also lend their support to open source projects by adopting them on a massive scale. Nothing brings an open source project to maturity like a deployment on 50,000 desktops by a highly professional IT organization.

2.2.16. Putting It All Together

The elements of open source maturity are stepping-stones on the path to realizing what you are getting yourself into. Understanding an open source project means being able to estimate how much work will be required, and how hard that work will be based on a department's assessment of its skills and how it intends to use the software. The result of a maturity analysis, then, should be a list of worries.

The next section of this chapter boils down the Open Source Maturity model into a concise set of factors that will be used later in the book to put the recommended open source projects on the same simplified scale. Readers might find in the model an easy way to organize the results of their research.



Open Source for the Enterprise
Open Source for the Enterprise
ISBN: 596101198
EAN: N/A
Year: 2003
Pages: 134

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net