If it's just a 'toy' project, that's kind of DE-motivating. It should be useful, because then he can see the impact of a finished tool in a work environment providing real benefits to his co-workers.
Hrm.. Offhand, I'd guess that you've never had a side-project metastasize into something officially useful. Trust me, if you want de-motivating influences, the 'uselessness' of a toy project doesn't begin to compete with the exasperation of having a personal project declared 'valuable'.
It all goes back to the core issue of freedom to fail. You don't crash a program that all your associates are using. You don't rip out a bunch of working procedural logic and replace it with admittedly bad OO code, just to see what will happen. You don't stretch. You don't explore. You don't try anything new. You don't do anything that will damage the code, because the code isn't private to you. It's a service you provide to the community, and you don't want to degrade that service.
There are social hassles: Any time you release a piece of software to the public, you take on the burden of supporting that software. Nobody will take the time to learn your conceptual model, and everyone will want you to adopt theirs. Everyone will come up with their own wish-list of features they think you should add, regardless of whether those features are interesting to you, or even technically possible. And everyone will bitch at you, because they feel (with some justification) that using the code gives them a stake in the project.
There are organizational hassles: If management decides something is useful to the company, it no longer belongs to you -- it belongs to the company. Intellectual property issues aside, when a company annexes your work, you no longer control that work. Your bug-ridden, pre-beta code goes into deployment whether you want it to or not, because management expects it to work. You don't get time to fix bugs, because management has its own wish-list of features it expects you to add, and won't give you enough time to do any of them properly.
I've been pushed down that particular flight of stairs a few times. Often enough, in fact, to have adopted the rule, "never show a manager a working beta." Every time I've broken that rule, I've regretted it to the tune of at least a hundred hours.
Your definition of 'useful' translates to 'production code', albeit informally, and the production environment is just a lousy place to try and learn something new. Learning something new is hard enough as it is, without adding the hassles of customer support, or the risks of managerial intervention.
What a toy project should be is interesting. It should generate enough of a conceptual itch that the person doing the project will go after it like a terrier chasing a rat. Interesting is what drags you into the unknown. Useful is what happens once the unknown has been mapped, and is no longer quite so interesting.
