A long, long time ago, in a galaxy far, far away, a statement was issued (in a discussion around just-in-time compiling) that the success of a project was inversely proportional to the number of people who were part of the project. While the statement was issued partly in jest, it created a new topic, about what factors actually made a software project successful or not.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
Since few of us really want to be anything other than successful, it started a train of thought:
What makes software projects "good"? At first glance, the "I'll know it when I see it" definition applies; one can see a project and usually gauge how successful it is without objective data.
The problem is that "success," as a term, has no concrete meaning; to one person, a project might be a crowning achievement, and to another, that same project might be a miserable failure. It depends almost entirely on the perspective and goals of the observer.
However, if there's a general sense of "project success," it should be possible to enumerate qualities that make a project successful, and potentially measure how well a project provides those qualities.
Red Hat's Open Source and Standards group -- a set of brilliant people (including your humble author) whose focus is on helping the open source communities upon which Red Hat depends -- uses the open source mindset to help foster success across all projects, in part by documenting what contributors see as relevant for making a project run smoothly and well.
While there's no substitute for actually spending time reading and participating in The Open Source Way, here are a few things to think about to help define and understand project success.
One man's approach
In the discussion that started the topic of project success, one brave person suggested that there were three factors to success:
- The people working on it
- The amount of money being paid
- The debt the committers are in
At first glance, these look fairly flippant, but there's reason behind them, especially when the terms are better defined or rephrased.
The people working on a project need to have a specific disposition and intellect, enforced by a meritocracy of some sort. The project space -- what the project does -- might be interesting, well-defined, scoped and well-known, but without a strong and talented set of committers, the project's success is doubtful.
Gratification factors in, as well. Being phrased as "money" in this list is somewhat unfair; some projects are very successful, even though they don't necessarily involve the transfer of money. Therefore, "gratification" is a better term.
Some people are gratified purely by actual money, of course. Others, however, see reputation as a worthwhile compensation, while still others work for altruistic purposes -- a common theme in open source, as it turns out, even if financial reward might lie at the end of a tunnel of support contracts or other such services.
Debt refers to the level of need for gratification, and despite being put in financial terms, it's an appropriate reference. If John wants to buy a ring for his fiancée, John will be highly motivated to create something successful, with the measurement of success ultimately being whether he can or cannot afford the ring he wants to buy for her.
A more complete list of requirements for success might cover three general areas: the project's problem space, the project's community, and some details about the project itself. A cursory breakdown might look something like this:
- Problem space
- Mission statement
- Appropriateness of the solution
- Community concerns
- Cults of personality
- Support vectors
- Project specifics
- Ease of use
- Source language
- Number of releases
The Open Source Way identifies many, many more aspects, including how to monetize projects built with open source, and makes concrete recommendations for measurement and implementation. Most of the recommendations apply to closed source projects as well, although open source creates the most positive movement.
With that said, consider how each of these factors in with a software project with which you're associated; what do the terms mean to you? Given your own definition, how does the project address the subject, if at all? Has it been a deliberate consideration, or has the development "just happened"?
There's no right answer -- software projects have stumbled blindly into working and successful software models, and projects have failed despite careful planning. It's still worth thinking about.
More in this series
Part II: What makes a project successful?
Part III: Addressing the project in order to be successful