Making software projects successful, Part I of III

Get a better understanding of the ideal steps for creating successful software projects.

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.

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

Visibility

Appropriateness of the solution

Popularity

Community concerns

Size

Quality

Cults of personality

Support vectors

Project specifics

Ease of use

Source language

License

Cost

Age

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.

Start the conversation

0 comments

Register

I agree to TechTarget’s Terms of Use, Privacy Policy, and the transfer of my information to the United States for processing to provide me with relevant information as described in our Privacy Policy.

Please check the box if you want to proceed.

I agree to my information being processed by TechTarget and its Partners to contact me via phone, email, or other means regarding information relevant to my professional interests. I may unsubscribe at any time.