In parts one and two of this series, we've discussed the terminology around what makes a project successful, because without a common understanding of what success is, we cannot cooperatively achieve it. We've also covered two primary aspects that affect project success: the project's problem space (what it's trying to do) and the project's community (who uses what it's trying to do).
However, the problem space and the community are not the software project. One can discuss classification as a problem domain for weeks on end, but the problem of classification is not the same as a library to actually perform the classification. The problem space is "how to get from point A to point B." The project is "a Honda Accord."
The project itself
It's time to stop talking about the problem of transportation and who might need it, and start talking about what provides the transportation. Most of these aspects are fairly trivial (and obvious) but they still affect project success, and a project that makes deliberate decisions will be likely to be more successful than one that does not.
First off, how easy is the project to actually use? It might be entirely appropriate for the problem, perfectly accurate in its results, and have dedicated and talented maintainers, but if the user base can't figure out how to use the project appropriately, it's not going to be very successful. A successful software project will work hard to lower the barrier to entry for new and existing users.
Classification, as a computational problem, has been mentioned already. One difficulty with classification is that while it's something that's understood in a general sense, every actual application that needs classification has a unique requirement for a classification library. As a result, classification libraries tend to be either too general -- and therefore impenetrable for newcomers -- or far too specific for reuse. This is an example where the barrier to entry is rather high.
On the other hand, you have a library like Spring -- which makes dependency injection trivial to use in an application. This is an example of a low barrier to entry. There are good reasons Spring is so well-known -- and this is one of them.
One of the things that help lower the barrier to entry is obvious: documentation. Documentation has to be written clearly and well, with the right balance of readability and detail, to push project success along.
Clear documentation is difficult to produce; many projects offer little detail, with the maintainers feeling that usage is obvious, while others offer far too much information, obscuring the forest with trees. While there are very successful projects that serve as examples of both concerns with documentation, projects that strike a good balance here will have a greater chance of success.
Source language (and artifact language) also factors in, in most cases, if only because it brings an association with the language's community and imports the language's mindset, the zeitgeist.
It also affects who thinks they can use a given project. A developer whose application is written in C isn't going to look to a Java library first; a Java coder won't normally look at a C library, or a Scheme library, early in the development process, even if a project written in a different language happens to be done perfectly for the problem at hand.
That doesn't mean the source or artifact language can't be worked around, by any means; there are certainly bridges between languages, available as plugins -- or even architectural possibilities like messaging systems or HATEOAS.
However, workarounds aren't usually a positive aspect; if users are expected to use extras in order to take advantage of a given project, it has to be made worth the effort despite competition from other projects.
Licensing is, of course, also a factor. An open source license tends to carry with it a low cost for procurement -- making it easy to download and try. Some licenses affect project success by adding restrictions; the GPL, for example, is a viral license and some users avoid it, whether by choice or by necessity.
If the project costs money, then the value proposition becomes very important; a $2,000 project that offers a $100 return isn't going to be very successful by most measurements.
This also affects the community around a project. A freely available project represents a burden of gratification for its maintainers -- and gratification might include real money, especially if the project is actively maintained. How do the maintainers get compensated for their effort? If it's not worth it to the maintainers, then the project will become less and less maintained; this is a consumptive model and is typically not effective for a long-lived project.
Therefore, the gratification of the maintainers is a major factor. If the maintainers need money (and who doesn't?), then how do they get rewarded? Often, this is through support contracts, where the maintainers offer customers problem support, architectural support, or priority in some other way.
However, there's a community cost to monetizing projects as well; many consumers resent the idea that there's a debt to be paid in any form to someone who provides something "for free."
Some of the other measures of success are project age and the number of project releases, often called "project churn." A project that's been maintained for years is typically more successful than one that is very new or has been unmaintained; this might be obvious, but also should factor into measurements.
Note that churn is not a good sole indicator of success. A project that has had few recent releases might simply be well-done. TeX, for example, had its last major release in 1991 (although opinions will vary on the definition of "major") -- yet TeX is a popular and well-known standard for typesetting.
What you've seen is a cursory overview of some aspects of project success, along with some thoughts about what success might actually mean.
You've read some suggestions about things to consider in terms of project structure. There are some workable recommendations. Success is a worthwhile goal, providing esteem for those who experience it. While there's no simple guide for creating generically excellent projects, one can at least hedge bets by considering the attributes of successful endeavors, and addressing them as best as can be done.