The easy option is to create your own stand-alone project, like a jQuery plugin
or HTML reset.<p>The harder option is to contribute to an existing project. This is not an easy
question, but I'll try give you a concrete example.<p>(Disclaimer for others: I'm Nick's coworker, so I know more about him and what
he can easily do.)<p>I contribute to Mercurial. There are two parts of Mercurial that could use
some help from a frontend developer. The first is the Mercurial website
itself: <a href="http://hg-scm.org/" rel="nofollow">http://hg-scm.org/</a><p>The code for the site is on BitBucket: <a href="http://bitbucket.org/segv/hg-website" rel="nofollow">http://bitbucket.org/segv/hg-website</a><p>If you want to improve it, it's as simple as forking, making your changes and
sending David a pull request. The site uses Jinja templates, so you shouldn't
have much of a problem with them (Nick works with Django every day, for those
of you that don't know him. Django templates and Jinja templates are very
similar.).<p>Mercurial also has a built-in web server whose templates need some serious
love. The code for those is here (the gitweb, paper, monoblue, etc
directories): <a href="http://www.selenic.com/repo/hg/file/tip/mercurial/templates" rel="nofollow">http://www.selenic.com/repo/hg/file/tip/mercurial/templates</a><p>Mercurial's templating language is pretty much a huge clusterfuck for web
development. We've been talking about replacing it with something else but it
hasn't happened yet.<p>There are two big, huge, ugly problems with both of these options. The first
is that as a frontend developer you need a designer to tell you what to
implement, unless you've got some aesthetic sense yourself. I know Nick can
design fairly well, so that's not an insurmountable issue.<p>The other problem is that you'll inevitably encounter people with different
design tastes than your own, and your contributions might not ever be accepted
because they don't like them! Design-by-committee is a Sarlac pit of good
intentions, angry words and ugly results, but unfortunately that's the attitude
of many programmers toward the projects they contribute to.<p>Even though these programmers may have websites that look like they crawled out
of 1998, their opinions on frontend and design work hold a lot of sway because
they contribute to the guts of the project. I don't think that's a good thing,
but I'm trying to be realistic here.<p>With backend code it's much easier to justify your patches -- who's going to
argue when you send a patch and say "this improves performance by 20% according
to these benchmarks and passes the entire test suite"? Frontend code (and
design) is much more difficult, and the results (rejected patches) can be
disheartening.<p>My advice is to do a few things, in order:<p>* Talk to the project's community through IRC or mailing lists, and tell them
that you'd like to redesign and reimplement the frontend-related stuff in the
project. If they're not at all receptive, move on to another project.<p>* Find a contributor and talk to them. Make a friend. They'll be useful to bounce
ideas off of and can help you when you get stuck on something backend-related.<p>* Find a designer to work with so you can make something beautiful that is hard to
reject.<p>* If at <i>all</i> possible, make your contribution pluggable. For example, instead of
modifying one of the theme's in Mercurial's core, create your own theme. That
way people can try it out easily before it's merged into core.<p>* Submit your patches and be prepared to argue for your design against the guy that
thinks all websites should span the entire width of your browser window.<p>Good luck!