Unlike many enterprise software engineers, I have the good luck to work for a company that not only permits, but actively encourages its developers to use open source in their projects. However, as Uncle Ben told Peter Parker, "With great power, comes great responsibility." 1
There are a huge number of open source projects in the world. It can be difficult to find ones that meet your project's needs, and don't come with too many potential pitfalls of their own.
Working with FOSS (Free Open Source Software) over the years, I've developed a mental checklist to use when evaluating what's out there and deciding whether or not to use what I find. Here are some points I consider when searching for that perfect FOSS component for my project.
Avoid the Kitchen Sink
All software can be subject to feature creep, and FOSS projects are no exception. If you're looking for a solution to a specific problem, you'll often find an open source solution that, in marketing parlance, not only solves your problem, but also does so much more! (Sorry, I tend to use exclamations when I try to pretend to know anything about marketing.) However, unless there is a clear, measurable benefit to the project, stick with a simpler solution.
Occasionally, "more" is a good thing. There may be other parts of your project that would benefit from the FOSS project's many other wonderful features (order now and you’ll also receive a deluxe Left-Handed Cheese Straightener™!). While all in one, sweeping projects can look great at first glance, these sorts of projects often make assumptions that do not apply to your work. This can lead to spending more time rewriting that great all-in-one solution than working on your own code.
Plus, one of the great strengths of the FOSS world is that there is almost always more than one solution to a given problem. Choosing the simplest, most maintainable project that does only what you need will save your team time and effort. Keep in mind the aphorism: "A solution should be as simple as possible, but no simpler." 2
Check the License!
There is a tendency among developers—and among most FOSS users—to think of "free" and "open" as synonymous with "completely unencumbered." We see a cool FOSS project that does something we need and just grab it and start coding. This is a really bad idea, particularly at an enterprise level. Almost every commercial or FOSS component comes with some sort of stated license or licenses and those little legalisms can be the difference between a successful project that ships, and a project that founders in the murky seas of copyright law and unmet obligations.
Broadly speaking, a software license is a set of conditions agreed to in order to use a project's copyrighted code, which is to say, all of its code. Licenses can range from relatively permissive requirements such as including the license and copyright statement, to wide-ranging requirements that you provide a copy of the source code or (and this is one of my favorites) that you buy the author a beer if you're in her hometown. 3
Always, always, always read the licensing terms to discover what you are committing to by using each project's code. To play it really safe, have a lawyer read the license and let you know what you're getting into or use a license analysis tool to get an idea of what you will be obligated to do. By purest coincidence <grin>, my company, OpenLogic, happens to make a pretty decent license analysis tool.
Regardless, whenever you use a FOSS project, know what your legal obligations are. Nothing feels worse than pulling and rewriting a project because of a licensing restriction you can't meet, except, possibly, having your company face a lawsuit because your project didn't comply with a license.
Don't Play with Zombies
When you are comparing FOSS solutions for a problem, you may discover a promising project that looks great, except the code hasn't been updated in three years. This is a "Danger, Will Robinson" 4 sign.
In the best-case scenario, you've stumbled across the project's old repo and you just need to head to another site to find the current living, breathing project. Less commonly, the project might have been so successful that the project managers decided to take the project commercial. This is another case where there will generally be an actively maintained product, but you will have to pay for it.
In the not-best-case scenario, you'll poke around the project's site a little longer and discover that no one has posted on their blog since the dawn of time, their mailing list hasn't seen any mail since the first release announcement, and their wiki is still on the "How to create a page" page. In other words, you've stumbled across a zombie project, still available but abandoned by its creators and users.
Think long and hard about using a zombie project. Unless you are willing to update and maintain the code internally or to fork and resurrect the project, look for an alternative. While code should be self-documenting, trying to peer into old code and decipher the developer's assumptions, find bugs, or even create builds, can be difficult and time consuming.
On the other hand, a project with active commits, recent releases, up-to-date documentation, and a thriving user community is a gem without price. Being able to communicate with a developer about how or why he made a particular decision, or whether a particular behavior is by design or a bug, can make your life easier and your project's code more maintainable.
Short version: as in the zombie apocalypse, avoid undead FOSS projects and try to stick with the ones that aren't trying to eat all of your team's brainpower.