Los desarrolladores de gvSIG siempre habían tenido permiso de escritura en cualquier proyecto del repositorio estuvieran trabajando en él o no. Esta situación provocó una seríe de problemas. Entre otros se podrían citar:

• Modificación del núcleo de gvSIG por parcheado orientando las modificaciones al problema puntual del desarrollador de una funcionalidad.
• Muchas manos modificando el núcleo lo volvían menos estable.
• Las modificaciones que mejoraban unos desarrollos afectaban negativamente a otros.
• Desorden en la arquitectura por falta de visión del conjunto.

Como solución al problema se aplicó por el “articulo nº 13” la medida de restringir a todos los desarrolladores de gvSIG la escritura en los proyectos. A medida que estos necesitaban escribir debían justificar la necesidad de ello y se les permitía, si la organización del proyecto lo consideraba razonable. Los proyectos considerados como núcleo solo podían ser accedidos en modo escritura por pocas personas que se supone tenían criterio para validar las modificaciones propuestas por los desarrolladores. Para ello se propuso un protocolo de propuesta de cambios. Este protocolo está definido en:

https://gvsig.org/web/production/docs/procedures/procedimientos/changesInCoreOfgvSIG/changesInCoreOfgvSIG_0

Este método aportó soluciones a los problemas ininciales pero trajo otros distintos a los anteriores

• Debido al alto nivel de acoplamiento de algunos proyectos en gvSIG, la definición de núcleo no está muy clara (parte común a todos los desarrollos). La dependencia entre algunas extensiones y núcleo es tan estrecha que hace imposible desarrollar o mantener estas extensiones sin modificar constantemente el núcleo. Al mismo tiempo es difícil hacer algunas nuevas partes sin modificaciones constantes de esa parte común.
• Se solicita un análisis de la solución y no del problema. Esto produce que todos los desarrolladores deben conocer perfectamente los proyectos que forman el núcleo para aportar la solución con lo que es bastante costoso.
• Las solicitudes de cambio llevan un ritmo distinto a los proyectos. No se tiene en cuenta el tipo de prioridad que puedan tener y no hay nadie que le preocupe suficientemente porque no es responsabilidad de nadie que eso se aborde en un tiempo razonable. Algunas solicitudes pueden bloquearse y es responsabilidad del que lo solicita insistir sobre ello, es decir, no hay un método ágil para la resolución de este tipo de incidencias.
• El paso de la solución ha de realizarse a través de parches de eclipse. Este método no funciona bien cuando hay muchos cambios y da problemas en la carga.
• Los desarrolladores no hacen propuestas porque supone cargarse de trabajo que no siempre tienen tiempo de asumir con lo que los defectos persisten más tiempo del deseado.

El responsable del Grupo de Trabajo es Nacho Brodin (IVER)