Si eres un dios del C++, probablemente esto no te interese. Podría ir más lejos diciendo que hackear el código del front-end no es un buen lugar para ti, pero siempre podemos utilizar la experiencia para compilar la plataforma. Hackear la interfaz no sólo precisa de habilidades de programación sino de instintos de diseño de interfaz y tener que aguantar de todo. Sin embargo, es relativamente fácil rebuscar por el front-end. Conocer suficientemente bien la base de C++/JavaScript/XML para empezar a familiarizarte es un buen punto de partida, sin ni siquiera indagar en XPCOM ni derivados. Primero lo primero, ante todo.
Empezar por lo básico
Antes de empezar a cacharrear, necesitarás aprender a moverte por Bugzilla. Clasificar/QA/buscar fallos un par de semanas o más es un requisito mínimo y recomendable antes de pensar "oye, que lo que quiero es hackear Firefox". Descubrir cómo funcionan los proyectos, aprender a indagar qué es lo importante y aplicar las lecciones aprendidas al proceso de clasificación inicial te llevará bastante tiempo leyendo y releyendo antes de poder familiarizarte. Coger algo al azar no es por lo general lo mejor que puedes hacer para empezar. Ver qué cosas son estables y cuáles necesitan atención especial es un buen punto de partida para empezar a hackear.
Compilar el panda
Podría desaconsejar lo qué ha sido mejor escrito por otros, pero me niego. Empieza con las instrucciones genéricas aquí, asegúrate de que usas una versión trunk del CVS y consigue un compilado bestial. Necesitarás ser capaz de hacer esto antes de intentar dar el siguiente paso. Sí, no es trivial compilar nada desde el servidor CVS de Mozilla. Pero si no te haces una idea incluso con ayuda, probablemente aun no estés listo. Ir desde "nunca he compilado nada" hasta "compilar en Win32" te podría llevar alrededor de una hora o más.
Organización del código fuente
El siguiente problema es "¿dónde está el código de la aplicación/interfaz?" El código específico de Firefox se encuentra aquí y el del toolkit aquí (En tu árbol del CVS sería <tt>mozilla/browser</tt> y <tt>mozilla/toolkit</tt>, respectivamente).
Trabajar con fallos
Por suerte, los votos cuentan. A veces es una cuestión simple hacer que los fallos ocurran y si tienes eso al alcance, utilízalo. Otras veces, los fallos del panel de estado con el indicador de "primer buen fallo" son buenos lugares para empezar a trabajar. Y por supuesto todo lo que te desconcierte también. Aquí es de donde sacarás las mayores satisfacciones personales.
Saber dónde pedir ayuda
El canal #developers del servidor IRC de Mozilla es un buen lugar para empezar si no comprendes algo por ti mismo. Pero primero agota otras opciones, como lxr/bonsai/Google (y este wiki) antes de molestar a nadie. Si es una pregunta del tipo "¿qué aspecto debería tener la interfaz?", la mejor opción sería preguntar a Mike Connor o a otro del grupo Firefox, a menos que estés listo para mostrar tu trabajo.
Cambiar la experiencia del usuario
Si estás pensando en implementar una característica solicitada o cambiar el comportamiento de algo que afectará a la experiencia del usuario, lo mejor para todos será que escuches otras opiniones antes de empezar. Habla con Ben Goodger, Mike Connor o alguno de los del grupo Firefox y acepta sus críticas y consejos. Si contestan con un "no", te habrás ahorrado un montón de estrés y resentimiento (basándonos en cómo la gente que no siguió esta premisa reaccionó con un review- en el pasado).