MARKUP
Whitelist of markup is a must; I can’t see a way you’d avoid having to parse and validate input anyway. You’d need to consider how to Tidy ( http://www.w3.org/People/Raggett/tidy/ ) the markup, keep the site look and feel consistent and support fixing markup when the page DOCTYPE and user agent behaviours inevitably change. This is perhaps a small risk, but something you want to be able to fix in one place rather than in every back post in the site’s history.
SOURCE CODE
This is a programmer’s site; making code legible is important; that includes indentation and (most likely) colorization support. You can allow users to carry this burden with tools like jEdit’s Code2HTML plugin if you go with HTML markup. You take on a maintenance task if this support goes onto the server - updating the parser/encoder for every syntax change in every programming language.
[As a side note: I’ve noticed that automatically converting carriage return/linefeed into HTML elements can be result in interesting battles with the software when it comes to source code, depending on the approach chosen.]
Whatever markup you choose, I would create a minimal list of key must-have elements rather than supporting things just because you can. To me, that means supporting source code, links and the ability to paragraph text - pretty much anything else can be omitted to begin with and added as needs are identified.