Introduction
In this article, I'll try to figure out why some open source projects tend to become bloated or susceptible to feature-creep and end up displeasing a lot of users and some developers. I suspect this tendency is more common in popular open source projects. But why is feature creep a problem and how could it be avoided? In this essay, I'll try to deal with these two questions.
Defining the Problem
For the purpose of this article, I will define feature creep as a software developmental issue that occurs when a project starts becoming more and more complex as it tries to add features and enhance functionality beyond what was originally planned for.
Some Symptoms of Feature Creep
- The project starts adding features that its users consider optional or not necessary for its proper functioning.
- The code starts getting complicated and the code-base requires re-engineering to accommodate the extra functionality.
- The features sought to be incorporated do not dovetail into the existing code or were not part of the original vision.
- The project is monolithic in structure and new features are sought to be added to the "core" functionality without considering a modular design.
Why Is Feature Creep Bad?
Feature creep is bad because it tends to make code bloated and complicated, and harder to maintain. From an end user's point of view, it adds complexity to the functionality and tends to slow down the application, consuming more memory and processing power. Besides, free creep is inherently against the KISS philosophy and goes against the basic UNIX design philosophy of "do one thing and do it well."
Besides, feature creep is a sign of poor planning and application design. Feature creep is a sign that the project encourages monolithic design over modularization which allows additional features and functionality to be developed by third parties as modules or plugins.
The biggest problem with feature creep is the tendency to break compatibility with older versions of the application. Also because it is tempting to add new features, the core functionality of the application is ignored. Some popular open source software "evolve" so much that it is hard to recognize the original version from the latest.
Why Feature Creep Happens in Open Source
I am not really sure, but the reason for feature creep may stem from an inherent desire to keep coding, rather than a desire to please customers. Unlike proprietary commercial software, most open source projects are driven by motivations other than market share and commercial success. I think here are a few reasons why feature creep actually occurs in open source.
- A desire to show off. Not necessarily alway - but there is a tendency to showcase coding talent among open source developers (it may also be part of a developer's portfolio) and this leads to adding more features. Some of the features may be purely eye-candy or add nothing of value to the end user.
- Poor initial design. This happens when the original scope of the project was much less ambitious. Like trying to add additional storeys to a single-storeyed building without the proper foundation.
- Lack of focussed leadership. This happens in projects without a strong leader with a clear vision of the project. When there are too many developers and there is no single focus, there is clearly the danger of feature creep.
- Too much end-user feedback. End users tend to demand features, not always understanding the technical costs and repercussions. When developers start to listen too much to the users, feature creep becomes an issue.
- Desire to match proprietary software feature-by-feature. This happens as well. This is especially the case with desktop environments in *nix.
Can Feature Creep Really be Avoided?
I think it can be. But it requires a strong willed project manager who won't be pressurized into adding features just because users want them. A strong vision and a clear roadmap always helps.
I think all open source projects will benefit from a 'freeze' at a particular point of its life-cycle. This is when the project should start focussing on bug and security fixes rather than feature addition. A lot of successful open source projects are simply frozen this way and maintain a stable existence for years without being considered dead or dying.
Mostly it has to do with the original developer's (or active maintainer's) philosophy. A mature developer or project lead goes a long way to ensuring that the community around the project is vibrant and healthy and the project remains focussed and on track.
The Alternatives to Feature Creep
There are several alternatives to feature creeping when it comes to enhancing the functionality of an open source application:
- Modular design - allow third party developers from the community to add features via plugins or modules without touching the core of the project.
- Major version increment - freeze the older, mature version of the project, but start working on a major incremental developmental version that adds the enhanced features by re-engineering the code. This allows a greater degree of freedom to break existing code as there is no inherent desire to maintain code compatibility with the frozen mature version.
- Fork - should always be a last resort, but it can be a better way to start enhancing a project than a major version increment when the idea is that the new version is not meant to be backward compatible with the earlier version.
Conclusion
Feature creep is an issue that most large software projects face, but the challenges in open source are different from those faced by closed shops. While there is no explicit competition to attract users in the open source world, feature creep does become an issue with some of the more popular open source software. Avoiding feature creep is desirable as it reduces the maintenance costs of the project in the long run and also prevents the project from going off-track and evolve into something unrecognizable from the original, if left unchecked.