It's (relatively) easy for a programmer to get started contributing to an open-source project. Find a project you like, in a language you're good at, and start working. Not as easy for a front-end dev. I do HTML, CSS and JavaScript, passionately. How and where should I start looking for open-source projects that need my help?
Take a look at Drupal. Historically it's needed the most help in the front-end department. There are tons of opportunities within the Drupal sphere. Also, Top Notch Themes (developed Skinr and Fusion, some up and coming theme related Drupal contribs) is hiring. Maybe try to get your feet wet there? Link below.
The easy option is to create your own stand-alone project, like a jQuery plugin
or HTML reset.
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.
(Disclaimer for others: I'm Nick's coworker, so I know more about him and what
he can easily do.)
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: http://hg-scm.org/
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.).
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.
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.
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.
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.
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.
My advice is to do a few things, in order:
* 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.
* 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.
* Find a designer to work with so you can make something beautiful that is hard to
reject.
* If at all 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.
* 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.
Incredibly well thought-out response. I agree that writing something from scratch for a FE dev is significantly easier than working on someone else's code. Traditional programming either works or it doesn't (or not well). Front-end devs all have a unique style of coding, unfortunately. There are a number of areas (CSS class names, for example) that have no industry-standard technique.
I like the idea of possibly redesigning hg-scm.org's public site. Seems like it'd be an easy-in to possibly get into rewriting the built-in Mercurial web server (and build some personal cred in the hg community).
There are a lot of interesting Javascript frameworks to explore. Contributing to those is challenging, so I would start with writing plugins for those. Learn how to make a simple jQuery plugin. You must have worked with some in the past. Look it up on Github. They usually have their issues listed, pick an easy one, and try to fix it. Start with small fixes. Read a lot of code. Poke around.
Great idea. I've generally had a poor experience hacking on existing jQuery plugins, but mostly because of the situations I find myself in while using them. Most of the time I'm under a time crunch for a client and simply need to get something working. Unfortunate reality. I should take a plugin that I think needs work, and either rewrite or contribute back to the project.
If you ever modify libraries or extend them, you should spend just a little more time submitting those somehow. You learn a lot by taking a few small cycles in making it worthy of adding to open source projects. If the modifications are production ready, then they should definitely be good enough contribute.
You're right. What happens all too often is we make the change with the hopes of going back to clean some stuff up, document, etc, then never get around to it.
http://www.topnotchthemes.com/team/jobs