TWiki - it would be cool to translate to XML instead of HTML and use a style sheet to transform. That would make it easier to write stuff in Twiki and move it to DocBook XML.

Also, it would be cool to have a twiki plug-in that could automagically produce image galleries out of directories full of image files (i.e. thumbnails, etc). Sorta done, I wrote a small hack to build the thumbs one at a time.

Dia - UML shapes need a once-over. Add more attachment points, allow different colors, etc. Still true, but I use ArgoUML now.

Bonnie - add a make dist target to Makefile, generate GNU/Linux binaries for intel, sparc. Also output results one test at a time so you don't have to wait until the end. looks like bonnie++ has superceded bonnie.

sh-utils - figure out a way to jsonXML-enable these tools. This would preserve the flexibility of text I/O, pipes, etc while making it easier to do medium-complexity processing on the output. Also explore using a command-line shell that can display jsonxml in a nicely formatted way. http://xmlstar.sourceforge.net/ is a different approach but looks like a good start.

collaborative document preparation - a tool which starts out loose (like a wiki) but then can move documents into a more structured form (docbk?) when they gel, and manage the changes and comments made to them. http://www.conglomerate.org/ has some interesting ideas but is a dead project.

javancss - investigate how much get/set methods throw off the statistics that are generated. Hack the code so they don't count and see if how different the results are on some large programs.

XMMS - a McIntosh skin (i.e. a skin that looks like McIntosh hifi gear). Probably a copyright violation, but seems fun.

XML Schema Tools - I can think of two useful XSL stylesheets: one to generate a FOP image of a schema. It's often much easier to look at schemas as images (for example many commercial packages can show a schema in tree form) than code. Another useful stylesheet would generate code! It would need to use the proprietary extensions that allow multiple output files for one input file, but other than that it should be pretty straightforward.

Emacs JDE - when you try to build an application it moves point to the line where the first compile error happened, but not the column. Since many of my compile errors have to do with un-imported classes, having the cursor where I could C-c-v-z would be nice.

magit - "folded" log listing i.e. it looks like a one-line listing but when you tab on a commit line it unfolds to show the commit in more detail.

Rails Auditing - all of the plugins I've seen to date (paper_trail, vestal_versions, etc) are "weak" in that they're application-level code so they can be easily subverted by anyone that has access to the database. It might be interesting to have a "strong" auditing package that uses triggers instead of application code to manage the audit data. This would allow for much more rigorous enforcement of the audit rules. You might be able to, for example, make the audit tables writeable only by triggers so external apps couldn't corrupt the data (on purpose or by accident).

How would it work? I worked on a previous system where we wrote a tool to inspect the schema and generate a set of audit tables, one for each data table, that tracked the contents of the data tables along with some additional data such as timestamps. We wrote triggers to push data into the audit tables on insert, update and delete. I'm a little fuzzy on whether we wrote the "old" data or the "new" data to the audit tables but either approach should work.

There are 3 principal components: schema maintenance, trigger maintenance, and application code. Schema maintenance will probably be patches to Rails' migration code - essentially for each migration action you need to do that action to the audit tables as well as the regular tables. Triggers will be database vendor-specific, but hopefully will be able to be table-independent. It would be a drag to have to change the triggers for adding or removing columns, for example. Ideally we'd be able to create the trigger when the table is created and have the trigger be able to move the data from the regular table into the audit table without a priori knowledge of the table's schema. Might not be possible, in which case schema maintenance like adding or removing columns from tables would require re-doing the trigger. The application code would add on to AR models: it would read old versions and reify them. Paper_trail's API is a good example. Some sort of diff code and some display code would be nice, too.

Shared Music DB - it would be cool if beets and quod libet shared a common database.