The top risks of this project, at first blush, look to be the following:
New Technology. For this developer, both Python and XML represent new technologies. While they seem stable, both are relative newcomers to the computing world, and both are technologies with which I have little experience. This should be easy to overcome given the amount of experience in the open-source community, but it initially represents a significant obstacle.
Fuzzy Requirements. The author has never used any defect- or issue-tracking system more complicated than a text based file with problems and dated notes accompanying the problems. As such, YakTrack represents a system which satisfies my needs. Unfortunately, even after studying existing applications, it's difficult to come up with requirements which will satisfy all customers. My response has been to design a system which is easily customizable, and trust the user community to come up with desirable "plug-in" modifications. While this doesn't entirely mitigate the problem of fuzzy requirements, it does mean that desired functionality should be easy to add in the future, particularly in the form of "wrappers" around the existing functionality (a GUI program "wraps" the submit command, adding gui functionality to replace the default text-based prompts; a security verification stub "wraps" the email gateway, only allowing certain request types to pass if associated with certain user names)
Distributed Development Team. The bazaar-style development of open-source projects seems to work best when a development effort starts with a core system and is incrementally grown by the user community. Developing the core, then, is the primary task of the initial YakTrack development team, which consists (at this point) of one person. While this may be enough to develop the core, the prospect of leading a distributed team, whose members have never met each other, to develop an initial product is pretty daunting. I'm trying to mitigate this by developing at least the very basic components (the immediate-mode commands for creating a repository, filing, querying, and editing reports) to a usable level before "staffing up" the core team.
A maze of twisty add-ons, all alike. We've stated earlier that one of the strengths of this design is that it can be easily extended to expand the capabilities of the existing tools and add tools which are not in the default distribution. This is in general a good thing, but there can be some problems with an easily extendible product. If too many third-party plug-ins exist to perform the same task, it could be difficult to decide which ones to use-- and poor-quality add-ons could degrade the percieved quality of the core product. A possible option might be an on-line catalog of "official" plug-ins which have been verified for quality, although this may put a damper on some desired proliferation.