Inspired by some of the conversations we’ve been having, I’ve been thinking about how a program changes over time. If you look at spreadsheet programs as an example, they started out pretty simple. They were single-sheeted, with a limited number of cells, and a set of (mostly financial) operations you could perform on cells. Now they are multi-sheeted, explicitly extensible, graphics rich, and so on. What drove the addition of these specific features in later versions? What drove the order in which those features were added?
I have a pretty good handle on how those decisions are made in a closed source environment. Version 1 is usually a bare-bones implementation of the core vision for the product. For subsequent version, a product manager talks to customers and developers about what is needed beyond the base functionality. (Some have complex processes for doing customer and market surveys, while others use a less formal approach.) At some point, the product manager will release a Product Requirements Document, outlining desired changes and additions for the next version release. There is then a negotiation with the technical management staff to factor in cost, budget, and resources. Usually, some subset of the requested functionality is authorized for implementation.
I’ve always considered this a pretty good way to grow a product. As long as the product manager does due diligence on the gathering of customer intelligence, the product generally evolves in a way that is useful to a large majority of its users. This is creationism, a top-down methodology. Features and futures are mandated, and pressed down into the development team.
So how does an open source project change over time? Generally, it seems, in an evolutionary, bottom-up fashion. Developers propose a new feature, usually committing to be the implementer. The community, through its developer mailing list, discusses the pros and cons, along with other details. If people react favorably (or sometimes even if they don’t), the proposing developer will code something up and submit it to the mailing list. It gets examined and tested by anyone on the mailing list that is so inclined, and once it meets the coding and quality requirements for the project, it may or may not be committed to the source tree.
So, are these approaches to new features equivalent? Do they equally address the real needs of the users of the product? I don’t know.
With closed-source companies, there is usually a focus on “bang for the buck.” If they’re going to devote expensive development staff to a feature, they want to be confident that the feature is going to be both important and well-received by the majority of the user community. After all, the money on development is spent with an eye toward maximizing profits. Though a company might hire user advocates to help them form the vision for the product’s future, they are paid strategists with the same goal: maximize profits; write to the largest audience.
One side effect of this is that features that might be very valuable to a small piece of the user community might never be added to the product at all. Usage models on the edge are rarely addressed. In some cases software companies try to mitigate this by providing hooks for user extendibility, but even knowing how a user might want to extend a program is a challenge.
Open source proponents point to the “community,” and claim that products advance synergistically based on real, whole-community interaction, and that this covers the needs of everyone, not just the majority. If the users are developers, I have no problem believing that. If a developer wants a product to do something she needs, but which most users wouldn’t need, she can implement the addition and get it added. If it works well, and if it adheres to existing standards of quality, it will likely be committed to the main product.
The scenario where this might not work so well, however, is the one where the users of the product are not developers. I suspect that the edge-case users in that scenario might have as much difficulty influencing the upcoming feature set as those using closed source software. What is the mechanism that gives them a voice? What say you?
