Do research. Are the solutions you found in step 1 suitable to the problem at hand? Consider the pros and cons of each item. Now, carefully evaluate how idiomatic the items are to your language and environment. If the item is open source, does the community seem active? If it doesn't fully map to your problem, does it look like you can modify it to do so?

Even if you end up developing a solution from scratch, you should at least now have some good references. Keep in mind, extending an existing project may be considerably less work. You might even be able to offload maintenance of that component. 3. Consider the license. This isn't just for the legal department. What kind of project you are working on will weigh in heavily. Commercial or open source? As a software professional, you need to be abreast with the various licenses in the wild. As an open source developer, you need to consider how licenses will affect your work being packaged by distributions. An open source library licensed under the GPL is not acceptable for static linking to commercial software. However, you can link to an operating system provided copy or bundle the dynamic library with your application. LGPL does not have this restriction. With both of these, you must supply your changes upon request from end users among other things.

BSD, MIT, and Apache style licenses allow you to make changes and redistribute under completely different licenses. Some just want credit in your documentation. These are very compelling even in commercial development.

Commercial components may have a per-copy fee associated which may dissuade their use by your organization. If you don't get the source, you won't be able to effectively change or maintain it so you will also be at mercy of that developer.