Netscape Communications hizo dos anuncios importantes el 23 de enero de 1998:
El 31 de marzo, estuvo disponible la primera versión del código fuente de Communicator.
¿Y ahora qué? Para que el producto crezca, madure y continúe siendo de ayuda e innovación, los cambios hechos por los distintos desarrolladores de todo Internet deben ser compaginados, organizados y reunidos como si fueran uno solo.
Mozilla
fue el nombre del código original que vino del
anterior Netscape Navigator, y posteriormente llamado, Netscape
Communicator.
Después, fue el nombre de la mascota-dinosaurio de Netscape Communications Corporation.
Ahora, queremos usar el nombre Mozilla como el término genérico para referirnos al software cliente de Internet desarrollado a partir de nuestro proyecto de código abierto.
Netscape Communications Corporation matiene los derechos de las marcas registrada Netscape, Navigator, y Communicator; todavía no se han decidido, si las hubiere, restricciones que Netscape mantendría sobre el uso de estos nombres. De todas formas, todavía se necesita un nombre genérico para el navegador, y ''Mozilla'' es tan bueno como cualquier otro.
Así, Mozilla es un conjunto de tecnologías, pero ninguna en especial (en términos biológicos, Mozilla es un género; un producto particular es una especie). Y mozilla.org (pronunciado Mozilla Punto Org o The Mozilla Organization) es el grupo de personas que coordinan el proyecto.
Existe un grupo encargado de actuar como un lugar de virtual para el código de Mozilla. Este grupo es mozilla.org. Mantendremos un punto central de contacto y comunidad para los interesados en usar y mejorar el código:
Somos integradores de código. Y, a través de nuestros foros, intentaremos ayudar a la gente para alcanzar consensos, y, de ese modo, proveer dirección y coordinación para futuras mejoras.
Es fácil observar que todos los proyectos de software libre que han tenido éxito siguen este modelo de desarrollo distribuido e integración centralizada. Uno de los temores que a menudo expresan los neófitos en el software libre es que la disponibilidad del código llevará a la fragmentación, lo que podría ocasionar eventualmente miles de versiones distintas descendientes de un mismo código , lo que llevaría al caos y la confusión. Pero, en la realidad esto no ocurre; organizaciones como mozilla.org velan por ello. Eric Raymond intenta explicar porque en su excelente documento, La Catedral y el Bazar. Esperamos actuar con el estilo del ''Bazar'' , y ser para el público el código de Netscape como Linus Torvalds lo es para Linux.
Como se dijo anteriormente, los que estamos en mozilla.org no somos los programadores principales del navegador Mozilla. Funcionamos como un cuadro de distribución, facilitando la cooperación de los miles de participantes que están en la red. Y juntamos el fruto de esta labor en un lugar.
El verdadero trabajo es hecho por gente como usted.
¿Cómo puede participar? ¡Simplemente
haciéndolo! Creemos en hechos, no en palabras
. Operamos
como una meritocracia, así es que cuanto mejor sea el
código con el que contribuya, más se le dejará
contribuir: es decir, cuanto mejor desarrollador pruebe que es con sus
acciones, se le dará más responsabilidad Esto no es un Consorcio
.
No existe ningún número de socio. Si aporta código,
entonces es un miembro. Es así de simple.
Ahora, en nuestro rol de integradores del trabajo hecho por incontables desarrolladores de Internet, debemos tener algunas reglas. Si aceptáramos ciegamente cualquier parche que se nos enviara, muy pronto tendríamos un caos total, y un árbol de código que no trabajaría, y esto no es bueno para nadie.
El modelo básico sobre el cual queremos funcionar es que cada módulo principal tendrá un propietario designado por mozilla.org. Esta persona será alguien que conozca bien el código; que de hecho este desarrollando el código, que trabaje bien en el entorno del código abierto, y que se sienta preparado para ser arbitro de qué debería ir en ese módulo, y qué no. Esta persona será también el programador primario, esto último no es necesario. El propietario del módulo acepta mejoras y correcciones de errores de otras personas.
Los cambios de un módulo los hace el dueño del mismo, y entonces se envian a mozilla.org para su inclusión en el código de nuestras distribuciones. Si el dueño de un módulo es nuevo en el trabajo, vamos a trabajar cerca de él para asegurarnos de que nos estamos ayudando los unos a los otros: que nos están dando el nivel de calidad deseado, y que les estamos dando la información y asistencia que necesitan. No hay reglas duras y rápidas aquí, pero lo que es seguro es que el dueño del módulo será juzgado, por nosotros y por el público, centrándonos en las tareas que han llevado a cabo.
La lista actual de dueños de módulos puede encontrarla aquí.
De esta manera, tenemos un sistema autoregulado: si el propietario de un módulo es visto por el público como que no hace un buen trabajo (quizá sus versiones suelen contener errores, o no son portables; o quizás; no son correspondientes con los errores reparados o las sugerencias) lo que ocurrirá entonces es que, alguien de la red se dira a sí mismo (y a nosotros), ``eh, yo puedo hacer mejor este trabajo.'' Y nosotros le diremos, ``Pues adelante.''
Si el usurpador y el antiguo dueño del módulo no pueden resolver sus diferencias, por omisión, la decisión final la tienen los que estamos en mozilla.org: estaremos en una situación donde hay dos personas preguntándonos si vamos a tomar su versión de un módulo determinado, y vamos a tomar la mejor para incluirla en nuestra versión del código.
Aunque esperamos no llegar a este punto. En la mayor$iacute;a de los casos, no tendremos que tomar estas difíciles decisiones, porque la gente intentará solucionarlo por sí misma, y cooperar, y aceptar la ayuda cuando le sea ofrecida. Hay años que evidencian que en la comunidad del software libre se intentan solucionar estas cosas sin mucho alboroto.
Pero, los que estamos en mozilla.org decidimos que ponemos en la distribución de código que hacemos. Así es que nosotros tenemos la palabra final sobre que va en nuestras distribuciones.
Por supuesto, cualquier persona de cualquier lugar del mundo puede hacer su propia distribución de código: no somos únicos al respecto. Y esta es otra forma de autoregulación que tiene el sistema: si el público cree que estamos tomando malas decisiones sobre que incluir y que excluir, sobre el trabajo de quien usamos o no usamos, o cualquier cosa así, entonces el público opinará con su pie colectivo: cogerán sus distribuciones de código de otro que no sea mozilla.org, y seremos irrelevantes.
Esta es la forma aproximada de trabajar de todos los proyectos de
código libre que han tenido éxito, y es por eso que los
estamos emulando. Llamamos a esto el modelo del Dictador Benevolente
.Dictador
porque hay una persona (u organización) que eventualmente toma la
decisión final en caso de que hayan disputas; y Benevolente
porque el dictador siempre intenta hacer lo que está bien.
Porque si el dictador deja de hacer bien las cosas, el dictador es
ignorado, y , por lo tanto, deja de ser un dictador.
Para aquellos de mentalidad más democrática, otra forma de verlo es que el arbitro final es en realidad un tipo de oficial electo: la votación consiste en si alguien lo escucha.
¿Así que quiere ayudar? ¡Genial!
Lea nuestro documento Getting Involved si
quiere saber qué trabajo debe hacerse. Lea el documento Hacking Mozilla para saber
cómo enviar el código.