Don't use third party tools
That is, unless you plan on owning them and supporting them.
Allow me to explain. There are some tools, like the Linux Kernel or the Python Interpreter that you’ll be able to use (for the most part…) without a second thought. (Though, there are definitely imaginable, and in fact scenarios I’ve run into, where tweaking and investigation of these tools is required).
No, for the most part I want you to be wary of niche tools. Things like the Django framework, the Zenoss monitoring suite, random python libraries, system maintenance tools etc. Don’t get me wrong, these are fantastic pieces of software which are each excellent in their own right. But if you chose to use them in your business or in a project consider whether or not you’re willing to maintain the tool as well; could you get away with something inhouse that is much smaller, with many fewer features, but is tailored to exactly your needs?
Why? Well these tools each have use cases in mind. I bet dollars to donuts your specific use case will align with the use case of the tool, but not quiet perfectly. You’ll eventually do somethng ever so slightly out of scope. The tool will seem like it’ll work fine, but soon you’ll find that it is not perfect and you’ll have to hack it in some way, change a few lines of code here and there, add some extra script to support an ancillary function, run a cron job to periodically clean logs etc.
And that is fine. It is expected that you’ll need to do some tool sharpening.
But you probably won’t realize how much time you’ll sink into these tools. Some examples in my recent history: The Zenoss Monitoring Suite. A fantastic tool for monitoring cloud infrastructure. But what happens when you’re scaling your busienss at 200% or more per quarter? Zenoss worked fine with 20 machines, but how does it handle 200, or 2000? Ordinarily sure Zenoss can do 2000 machines, but we started adding custom templates to the nodes to collect extra data tailored to our application. Pretty quickly we found Zenoss either running out of system resources (we’ve moved it to larger boxes several times), or falling behind entirely or flat our having bugs which cause a certain use case to not work (Maintenance windows don’t quiet work as well as one would hope…). We’ve spent all in all hundreds of developer hours just working out ways to make Zenoss work for us. At the end of the day we’re finding that many of our original use cases can actually be handled perfectly fine with independent monitoring scripts entirely separate and outside of Zenoss; avoiding a lot of headache overhead. I can come up with at least a dozen other examples for other tools I’ve used including but not limited to the Linux Kernel itself, the python interpreter (who hasn’t had GIL or memory problems?), Django, Django-Piston, the Hudson Continuous Integration Environment, the Graphite graphing/monitoring tool, puppet, iclassify, nfs, nis, etc.
So, support your tools. Contribute your changes back upstream to help out the next person who happens to run into your use case. Just don’t try and support more than you can.
I’ll end this rant on one final point. Obviously you can only really make use of tools you can support, and you can only support tools you have the source and capability to build. Another great reason to never use proprietary software!