Sometimes when you rely on a software project, it disappears. For example, when Apple bought FoundationDB last month, some projects found themselves on a suddenly shaky foundation. [ed. note – I have fired myself from this blog] Open source projects are not the only ones that can suddenly disappear; commercial software rarely gets further updates when the company that produces it goes under. Sometimes it’s an inconvenience, sometimes it’s a disaster.

Unless you intend to write everything in-house, at some point you’re going to be relying on third parties. It’s not a reason to panic, but it’s a risk to be mitigated. Sometimes, it’s worth choosing an older-but-widely-used technology instead of the new hotness. (There are additional benefits to that choice as well.) Evaluating the risk here is no different than evaluating any other risk: what’s the likelihood of this project going poof and what’s the impact if it does? Consider, too, what you’re willing to do to mitigate the risk. Will you hire (if you’re a company who has things like money) the lead developer to keep the project going? Will you task your own developers with maintaining a fork after the source is closed? Will you throw up your hands and walk away?