If it's a core business function -- do it yourself, no matter what.
ref: Joel Spolsky - In Defense of Not-Invented-Here Syndrome
Many answers here are good, but there's another aspect to consider with Libraries: Built-in vs 3rd Party
Built-in:
By all means, use the built-in libraries until you come to a point they are not adding value. Then, add your own library (i.e. reusable code) that sits on top of them. The less code you write, the less code you maintain.
If using a good library, you'll end up learning anyways. Only consider writing your own library when you've hit the wall of usefulness of the built-in libraries and you find yourself writing more awkward code to get around those deficiencies.
Also, by using a built-in library, you're more likely to have code that's understood by your fellow developers. (They'll otherwise wonder why you needed to re-implement string splitting, sorting, searching, etc)
3rd party:
The bar to using a 3rd party library should be much higher. Ideally you want to minimize the number of external dependencies in a project. Also, 3rd party libraries vary greatly in quality that's not immediately apparent, and you need to invest time to evaluate them. They usually have an added purchase cost (sometimes per-developer), deployment costs (i.e. per server), and cost more in terms of increased regression testing you must perform when they come out with a new version, or fix a bug, or just change things around. A built-in library has a large percentage of this regression testing done for you and breaking changes are less common with built-in libraries.
Anecdotally, after evaluation, I've found that many 3rd party libraries don't appear to do much more than I can do myself, and they're useless unless their design focus matches my needs 100%. Sometimes all they do is lock you into their proprietary ways, especially if you only need the 1 or 2 bits of functionality.
When using a 3rd party library, it's often a good approach to utilize an adapter pattern if possible to reduce the amount of coupling from 3rd party code to your own code.
On the one hand, Not-Invented-Here syndrome causes many bugs to be introduced (arrogant programmers figure they can do it better, only to realize later they've essentially reproduced the same that the library offers, but with fewer features, more bugs, and this isn't even taking into account the development cost of unnecessary code).
On the other hand, using libraries can speed your delivery and time to market.
The trick is to recognize what your core competencies are and choose accordingly.
Don't forget to check the web for how well a particular library performs or what other people think. e.g. jQuery (3rd party, javascript, free) and Linq (built-in, .net) are libraries that are invaluable when one looks at the huge productivity gains made when utilizing them.