Hani, and in follow-up Toby Hede have both had a go at the tendency for projects, especially open-source projects to reinvent the wheel, with the implicit assumption that wheel-reinvention is prima facie a bad thing.

Before you go on, I'd suggest reading Joel Spolsky's characteristically brilliant essay: In Defense of Not-Invented-Here Syndrome:

"Find the dependencies -- and eliminate them." When you're working on a really, really good team with great programmers, everybody else's code, frankly, is bug-infested garbage, and nobody else knows how to ship on time. When you're a cordon bleu chef and you need fresh lavender, you grow it yourself instead of buying it in the farmers' market, because sometimes they don't have fresh lavender or they have old lavender which they pass off as fresh.

Here are some situations in which you will want to reinvent the wheel.

1. You want to avoid an external dependency. Every dependency you add makes your project just that little bit more complex, and that little bit harder for an end-user to get up and running. There is also an unavoidable mismatch between what you want external code to do and what it actually does that will have to be bridged over (and the bridge maintained across revisions of both codebases). Sometimes, you will decide that the effort to write something yourself is actually less than the effort of tracking and packaging someone else's code.
2. You want your product to be better than what's available elsewhere. This is what Joel was getting at: sometimes you want to re-invent the wheel because your wheel has to stand out from the competition. Take WebWork for example. Why didn't they just use Struts?
3. Self-improvement. You learn a great deal starting something from scratch. This is the most common reason for Open-Source wheel-reinvention. If you come in on an established project, you miss some of the most valuable experience. Is it a bad thing that these people aren't contributing to an existing project instead? No. Open Source is about scratching itches, after all, it's not about making the most efficient use of resources.
4. You are following the Extreme Programming doctrine of You Aren't Gonna Need It. This is similar to the pattern that Toby describes in the above-linked article. Early on, a reused framework is too heavy-weight for what you need to do, and integrating it would slow down your release so you write something yourself instead. Over subsequent releases you find yourself refactoring towards something similar to the framework you originally rejected, but that doesn't make the original decision to avoid the framework a bad idea. After all, meeting those early deadlines is important. Think of it like the Concurrent Garbage Collector in Java. Overall it takes longer, but you consider that a worthwhile trade-off against the big block of delay that the alternative would cause.

Now I'm not saying you should always build your own. Reuse has its place as well. I'm just saying that reuse is not an absolute good. In some circumstances, you're just better off with your own wheels.