

Ask HN: I'm a front-end dev. How do I get started contributing to open-source? - nicksergeant

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?
======
stevelosh
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/>

The code for the site is on BitBucket: <http://bitbucket.org/segv/hg-website>

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 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): <http://www.selenic.com/repo/hg/file/tip/mercurial/templates>

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.

Good luck!

~~~
nicksergeant
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).

------
jacobroufa
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.

<http://www.topnotchthemes.com/team/jobs>

------
honza
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.

~~~
nicksergeant
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.

~~~
kineticac
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.

~~~
nicksergeant
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.

