No hay mucho que decir acerca de los aspectos técnicos del sitio web del proyecto: montar un servidor web y crear las páginas web son tareas sencillas, y los aspectos más importantes acerca del diseño y contenido ya han sido tratados en capítulos anteriores. La principal función del sitio web es ofrecer una visión general clara y unir las otras herramientas (Sistema de control de versiones, gestión de fallos, etc.). Si no se tiene la experiencia suficiente para configurar un servidor web, no será difícil encontrar a alguien que pueda hacerlo y desee ayudar. Sin embargo, para ahorrar tiempo y esfuerzos, es preferible utilizar uno de los sitios web enlatados.
Existen dos ventajas importantes de utilizar sitios preparados. La primera es la capacidad y ancho de banda del servidor. Sin importar cuan exitoso pueda a llegar a ser el proyecto, el espacio en disco no se va a acabar y la conexión no se verá superada. La segunda ventaja es sencillez. Estos sitios ya han seleccionado un gestor de fallos, un sistema de control de versiones, un gestor de listas de correos, archivador y todo lo que sea necesario para llevar un sitio web. Ya han configurado las herramientas y se realizan los respaldos necesarios de los datos almacenados por estas. No es necesario tomar decisiones. Sólo es necesario rellenar un formulario, presionar un botón y se tiene un sitio web así de fácil.
Estos son beneficios muy significativos. La desventaja, por supuesto, es que se debe aceptar sus opciones y configuraciones, incluso si algo diferente sería mejor para el proyecto. Por lo general, estos sitios se pueden ajustar bajo ciertos parámetros pero nunca se obtendrá el control total que se tendría si se hubiera hecho en casa teniendo acceso de administrador al servidor.
Un ejemplo perfecto de esto es la gestión de los ficheros generados. Ciertas paginas web del proyecto puede que sean ficheros creados—por ejemplo, existen sistemas para mantener los datos del FAQ en un formato fácil de modificar, desde el cual se pueden generar ficheros HTML, PDF y otros formatos. Al igual como se explica en “Versiones de todo” anteriormente en este capítulo, no se desean diferentes versiones de los formatos generados, sólo del fichero maestro. Pero cuando el sitio web está hospedado en el servidor de otra persona, puede que sea imposible crear un hook personalizado que permita regenerar la versión HTML pública cada vez que el fichero maestro del FAQ sea modificado. La única solución es tener diferentes versiones de los ficheros generados de manera que aparezcan en el sitio web.
Pueden haber consecuencias más importantes también. Puede que no se tenga el control sobre la presentación deseado. Algunos sitios de hospedaje permiten editar las páginas web, pero el diseño original del sitio termina apareciendo en diversas formas. Por ejemplo, algunos proyectos hospedados en Sourceforge tienen páginas web totalmente personalizadas pero apuntan los enlaces a la página web de Sourceforge para más información. La página en Sourceforge sería la página principal del proyecto si no se hubiera utilizado una personalizada. La página de Sourceforge tiene enlaces al gestor de fallos, repositorio CVS, descargas, etc. Desafortunadamente, una página en Sourceforge también contiene una gran cantidad de ruido de fondo. La parte superior es un anuncio en banner, por lo general, una animación. El lado izquierdo es un arreglo vertical de enlaces con poca relevancia para alguien interesado en el proyecto. El lado derecho es por le general más publicidad. Sólo el centro de la página es dedicado a material específico del proyecto e incluso esto esta organizado de forma confusa lo cual hace que los visitantes no estén seguros de donde pulsar a continuación.
Detrás de cada aspecto individual del diseño de Sourceforge existe sin lugar a dudas una buena razón—buena desde el punto de vista de Sourceforge, como la publicidad. Pero desde el punto de vista individual del proyecto el resultado puede que sea una página web alejada de la ideal. No es mi deseo criticar a Sourceforge; estas mismas preocupaciones se aplican a muchos de estos sitios de hospedaje. El punto es que hay que hacer un sacrificio. Se obtiene el alivio de los aspectos técnicos de llevar el sitio del proyecto, pero con la condición de aceptar la forma de llevarlo de otra persona.
Sólo usted puede decidir acerca de cual sitio de hospedaje es el mejor para el proyecto. Si se decide utilizar un sitio de hospedaje, deje abierta la posibilidad de cambiar a un servidor propio más adelante utilizando nombres de dominio personalizados para la página principal del proyecto. Se puede remitir el URL al sitio hospedado o tener una página totalmente personalizada detrás de la URL pública y llevar a los usuarios al sitio hospedado para funcionalidades más sofisticadas. Sólo asegúrese de organizar las cosas de manera que si decide cambiar de solución para el hospedaje, la dirección del proyecto no deba ser modificada.
El sitio de hospedajes más grande y conocido es SourceForge. Otros dos sitios que proveen los mismos servicios sonsavannah.gnu.org y BerliOS.de. Algunas organizaciones, como Apache Software Foundation y Tigris.org[19], ofrecen hospedaje a proyectos open source que encajan su misión y su comunidad con proyectos ya existentes.
Haggen So ha hecho una evaluación exhaustiva de varios sitios de hospedaje como parte de su investigación para su tesis de doctorado titulada Construcción of an Evaluation Model for Free/Open Source Project Hosting (FOSPHost) sites. Los resultados se encuentran en http://www.ibiblio.org/fosphost/, y en http://www.ibiblio.org/fosphost/exhost.htm hay un gráfico comparativo.
Un problema que no está estrictamente limitado a los sitios de hospedaje pero que usualmente se encuentra en estos, es el abuso de sus funcionalidades de login. La funcionalidad es suficientemente sencilla en si misma: el sitio permite a cada visitante registrarse con un nombre de usuario y contraseña. A partir de ahí mantiene un perfil para este usuario de manera que los administradores del proyecto puedan asignar ciertos permisos a este usuario, por ejemplo, el derecho de enviar cambios al repositorio.
Esto puede ser extremadamente útil y de hecho es una de las principales ventajas de los sitios de hospedaje. El problema es que a veces, el login de los usuarios termina siendo requerido para tareas que deberían ser permitidas para visitantes anónimos, especialmente la habilidad de añadir bugs en el gestor de fallos o comentar en bugs ya existentes. Al requerir que sólo sean usuarios registrados quienes puedan llevar a cabo estas acciones, el proyecto eleva la vara de participación para lo que debería ser algo rápido y conveniente. Por supuesto, se desea poder contactar con alguien que ha introducido algún dato en un bug en el gestor de fallos, pero sólo con tener un campo donde introducir la dirección de correo electrónico (opcional) debería ser suficiente. Si un nuevo usuario encuentra un fallo y desea reportarlo, se verá molestado por tener que rellenar un formulario para crear una nueva cuenta antes de poder introducir el fallo. Puede que simplemente decida no hacerlo después de todo.
Las ventajas de la gestión de usuarios generalmente superan las desventajas. Pero si se pueden escoger cuales acciones pueden ser hechas anónimamente, asegúrese no sólo de que todas las acciones de sólo lectura sean permitidas a visitantes sin registro, pero también algunas acciones de introducción de datos, especialmente en el gestor de fallos y, si se tiene, en el wiki.