What are your criteria for choosing a framework or library?

Question

In general, how do you choose a framework or library to use in your application? Does it have to be open source? Does it have to be commercial? Does it have to be actively developed, well-documented, or have a pretty home page? If your language has native support for some functionality, what would make you choose a third-party framework or library?

What are your criteria?

Answer 1

whichever makes most sense for the project your working on. There are no hard and fast rules. It's like decided which language to code in.

Answer 2

1. It has to work.
2. It has to be viable -- commercial support, actively developed, or so complete that updates aren't necessary except for ports.
3. It has to have reasonable support - examples, full source code, developer forum, feedback/bug reporting.
4. It has to be stable.

Answer 3

Being stable is the most important. If it does what you need to do and if you can figure it out, then the only thing left is if it's stable.

If it has a clear interface documentation is not as important - and if it has a poor interface documentation is more important. If it is a massive project which many things can be done with it and your intended use may change in the future (TineMCE for example) then an active support forum is required.

Opensource really helps but is not required. If it is not open-source a demo is required so that you can write all of the code you need to interface with it first before you purchase it.

So far, the coolest liscence scheme in a library i've seen is Js-Ext. It is open source if your application is; but you need a license if you want to make money with your project.

Answer 4

If there is an open source option that works I will always choose that, there is no better support then having the source code and being able to make changes to suit your needs. If there is no api documentation I don't waste my time with it.

Edit: @Josh Brown comment

Yes I have actually had to make changes to open source libraries I have used. I used a library for th first version of a project, then the requirements for the next version required me to add a new feature. It was easier to modify the library myself then to find a new that supported the new feature and then modify my code to work with the new library.

Answer 5

1. Simple easy to learn design
2. Customizable
3. If it is not free it should be at a very reasonable price with no royalties to distribute or integrate
4. Large community

Answer 6

I would choose a framework based on :

• it should be open source ( in most of the cases , this will ensure it's quality )

• it's documentation should be existent , updated and easily accesible

• it should have a good learning curve

• it should be fun to use

Answer 7

• It must have no run-time license fee: my employers (ISVs) can pay a per-developer license, but usually not a per-customer or per-end-user license.

• I must be able to support it (which means my having source code): in case the vendor goes out of business, won't fix a bug, or won't add new functionality which we want in our next release.

Answer 8

For C/C++, non-tools development:

• Can I configure how it allocates memory?
• Can I control how it performs I/O?
• Can I control its concurrency?

For tools development: - Does this code make me feel like a bad person?

Answer 9

1. Well documented
2. Reasonably intuitive API (if ConvertToInt() exists, ConvertToDouble() should be there too!)
3. Consistent conventions (see PHP for how NOT to do it!)
4. Example code (THAT COMPILES AND RUNS!)
5. Source code (so you can fix bugs, learn, etc)
6. Stable

As to when to go for a new component instead of using what you have

1. The component has more functionality/features than the native one (the .NET datagrid for instance is wanting in many areas like grouping)
2. It would take you too long to do what the component does, or you don't have the know how (for instance security/encryption components)

Answer 10

1. Stable API
2. Compatible license
3. Fits your tech stack nicely
4. A lot of users (applications relying on it), actively developed/maintained
5. Open Source is better (if its license is OK for you)
6. Developers eager to use it :)
7. Performance and features

Answer 11

In order of importance:

1. It is easy to understand and/or well documented (tutorials are the best).
2. I can use it the same at work and at home (so open-source is helpful, but copyleft not)
3. It has recent activity.
4. It is stable. Some indications for it are a version >= 1.0.
5. The project tries to keep compatibility to earlier version. Nothing is more annoying than getting the new version of the framework for the new feature that would be handy for your app - and then recognizing that your app no longer works with the framework.

Some projects that match these criteria:

• Java
• The Apache Commons libraries I used so far (IO, Logging, Math)
• JTS Topology Suite

Answer 12

Required criteria:

• Must fit the project requirements, not the other way around (avoid "When you have a hammer, every problem looks like a nail")
• Works without needing kludges or hacks
• Stability

Important, but probably not a deal-breaker:

• Good documentation (in terms of Java, this means at a minimum a complete set of Javadocs on the API)
• Active community of users
• Consistent, predictable idioms
• Compatibility in future releases

Optional, nice to have:

• Open-source
• Tutorials and examples available
• Optimized for performance

Answer 13

I want something that:

• works (you really can't over-emphasize this)
• is well written (it probably needs to be OSS so I can look at this)
• is well maintained - I want to see updates on a regular basis
• has a clean interface
• I can fix if it breaks (again, OSS is a win)
• doesn't lock me into a single vendor

Answer 14

I like tvanfosson's answer above.

Having poor documentation or a bad looking home page is a turn off but doesn't push me away as fast a buggy code or a poor API.

As for using third party libs where the language already has support, I use the jodatime library rather than Java's built in date handling (which I think most people agree sux.) I was thrilled to hear that they are redoing date handling more like Joda's implementation.