In the first part of this series, we addressed some terminology around project success and laid out a rough set of things that successful projects have addressed … somehow, even if "addressing" means "ignoring completely."
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
We finished by offering an open-ended chance for a thought experiment: How would you define these terms, and how have you seen them addressed by projects? What makes the projects successes or failures with respect to these qualities?
- 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
While everyone will have their own personal definitions of many of these, let's take a look at some general definitions, to offer some scope and perspective on how the terms factor into success.
The problem space
The problem space of a project is what it does.
A project's mission statement determines quite a bit about whether the project is going to be successful or not. Hibernate, for example, has a defined problem space of mapping an object model to data storage, most often relational databases.
A project without specific goals, or goals that are difficult to explain, will typically struggle to succeed, compared to a project with specific goals.
Visibility is another factor of success; a better mouse trap would be a wonderful invention, but if nobody is aware of it, it might as well not exist for most people's definitions of success. Sites like TheServerSide.com, DZone, InfoQ, Reddit and StackOverflow factor heavily into creating visibility for a project.
The project might be well-defined, and have the opportunity for being well-known, but if it doesn't actually do what its mission statement demands, it's not going to be successful. Imagine if Hibernate was unable to persist data to a database if the data contained the letter 'A' - that failure would be a massive barrier to success.
Lastly, the popularity of the project -- in terms of the number of installations relative to the number of potential uses -- factors heavily into the definition of success. This number is relative; if there are 400 applications that need a particular solution, and a given project is used in 390 of them, then that project is very successful in its domain. However, if there are four million projects that could use the solution, and it has only 390 installations, then the popularity isn't much of a positive factor for success.
That doesn't mean it's not successful. As stated in the introduction, perspective is everything -- if the project maintainers expected to have ten users, and ended up with 300 happy users, the maintainers might be thrilled beyond belief -- while MegaSellOutCorp might see 300 users as a critical failure.
Software project community
Another measure of a project's success can be seen in who maintains the project. In many ways, maintaining a solid and happy community of developers and users is the leading indicator of project success -- because if the community is satisfied, then there's a strong chance that the project concerns laid out previously have been addressed in a satisfactory manner.
There are two overlapping groups in a software project's community: users and maintainers. Many maintainers are also users -- which is often how they become maintainers in the first place.
Let's consider the maintenance community, first.
Is the set of maintainers a large community? How many maintainers could be said to be dedicated and invested in the project's success? Is it trivial to become a member of the set of maintainers? Do they accept maintainers who are unskilled? If so, in what roles?
A project with no barrier to entry, granting commit rights to people who don't understand the problem space or the project architecture, is likely to have a rockier road to success than a project with a tightly knit, focused group of maintainers who value merit.
Sometimes, of course, a project has an aspect of a cult of personality, which can be both a positive and a negative.
A cult of personality is a social structure in which a person's charisma or past reputation serves as a magnet, rather than the person's current contributions or skill level. Such a project member might attract users and other committers to a project, despite a lack of other contributions.
This can be a positive aspect, because it shows others that the personality believes in the project enough to have public association with it, and a functioning meritocracy might filter out any hangers-on such that the community has a larger base of users and committers from which to draw.
It can be a negative, however, if the personality attracts negative attention, or the meritocracy does not function well enough to endure the noise that extra attention brings.
Another factor here is how the community connects. Is it solely over IRC? StackOverflow? Web-based forums? Email? Telephone? All of these have strengths and weaknesses; a strong and successful project will probably have many of these available as communication channels, often funneling all communiques into a central, searchable repository.
There's a question, of course, about how to measure all of this. There are projects (EKG, for one) that examine mailing lists and other such channels to try to measure the health and activity of a community; one would watch for frequency, quality, intent and other such criteria to gauge how much activity there was, and how useful the activity became as well.
As usual, there's no actual full right and wrong answer as to what should be done, or could be done. The Open Source Way has tried to capture many thoughts regarding measuring the health of community connections, and as befits a site concerned with open source, everyone can contribute to the general pool of knowledge.
Next in this series
Part III: Addressing the project in order to be successful