I've been reading the excellent Framework Design Guidelines. One of the sections that stood out is the tips they offer to make your framework easy for other developers to experiment with. As most developers are experimental in nature, any framework must be "cooperative" in this manner in order to be popular.
- "Allow a developer to use it immediately, whether or not it does what the developer ultimately wants it to do or not" (23).
- "Types used in advanced scenarios should be places in subnamespaces" (23).
- "Provide simple overloads of constructors and methods" (24). A type that is hard to instantiate is hard to experiment with.
- Give common scenarios recognizable names. For example, "MyClass.CreateFile" sounds more friendly than "MyClass.OpenInputOutputSteam", so more developers would naturally experiment with the former.
- "...a default should never result in a security hole or horribly performing code." (26)
- "Do ensure that APIs are intuitive and can be successfully used in basic scenarios without reference documentation (27). I notice their emphasis - instead of writing tons of tutorials (which most devs won't even read), make the framework itself easy to use.
- Make things strongly typed.
- And the classic - A good framework makes it easy to do the right things, and hard to do the wrong things.
They offer ADO.Net as an example of what is confusing (juggling all the different types just to hit the database).
These are good points, and easy to overlook, but make sense when someone points them out to you.