Check out this link, I will admit that I haven't read the article, but there seems to  be a nice chart that summarize it at the bottom of the page. Basically, it lists 9 things that they think an OSS project should have in order to be successful. I had a some comments about each of those:

• A thriving community - yes, indeed, I would go further and say that you need a thriving developer community. Ref: NDoc for what happens when it is not so.
• A benevolent dictator - not the only way to go, check out the Apache's way: "consensus based development process".
• Disruptive goals - to scratch an itch or to make my life better, not really disruptive. Actually being good-enough + free is most of what people want. You don't have to be that much better, you just have to have less barriers along the way.
• Transparency - decisions in the open - very important, since the other option is an opque process, which means that a developer that is trying to work with it has no access to the reasoning behind decisions, which is not a good place to be in an OSS project. I actually believe that the Apache Foundation has a policy that mandate all decisions to be made on an archieved email list, for exactly this purpose.
• Civility - no personal attacks - yes, although that is basic for any online community:
  
  OSS Participant #1; Your code sucks, it doesn't adhere to our formatting standards and there aren't enough design patterns, I am reverting it!
  OSS Participant #2: Well, you had a buffer overrun three years ago, so what do you know?
  The above doesn't make a healthy community.
• Documentation - this is the traditional OSS weakest point, documentation is critical to make sure that users don't have to follow the code in order to find out what they are supposed to do. (Although I personally find that this is the best way).
• Employed developers - (dedicated to the OSS project) - this certainly help tremendously, but there are enough examples about sucessful OSS projects to show otherwise. (NHibernate until Sergey joined JBoss, Castle until Castle Stronghold, etc)
• A clear license - fully in agreement here. If I don't know what I can do with it, I will not touch it.
• Commercial support - that is actually the other way around, first you have a project getting successful enough that you need commercial support (suddenly it is not build the ToDo page, but a core system, which require the support), that creates the need for commercial support.