Nota: La opinión vertida es este post es personal y no necesariamente es la de la institución en la que trabajo.
Algunas Observaciones sobre el BRM
En este post voy a expresar mis opiniones personales sobre lo que pasó en el BRM y las razones por las que creo que el Ecuador debe mantener su voto como NO.
En el BRM hubo un malestar general de los miembros participantes porque había muy poco tiempo para discutir tantos temas. Países como India, Brasil, Malasia, Irlanda, Canadá, Grecia, inclusive los mismos EEUU estuvieron molestos con el proceso como incluso han denunciado públicamente varios significativos representantes de sus delegaciones.
El jefe de la delegación Hindú dijo que si el BRM era para llenar una hoja con un voto general, entonces no era necesario viajar a Ginebra y que este trabajo se lo pudo haber hecho desde el país de origen con mayor tiempo para la discusión.
Públicamente el jefe de la delegación de los Estados Unidos dijo “no veo como algo racional que se pueda discutir un estándar de 6000 páginas y 3500 comentarios en una semana. Es como correr una milla en 2 minutos” Brasil estuvo muy molesto con el hecho de que su propuesta sobre el anexo de mapeo de documento de legados nunca fuera discutida. En su blog personal Jomar Silva, miembro de la delegación Brasileña, declara: “No permitieron a Brasil presentar su propuesta sobre mapeo”
En este orden de cosas, el organismo de estandarización de Malasia ( STANDARDS MALAYSIA ) emitión un comunicado de prensa donde expresó “La delegación de Malasia en la reunión de ISO en Ginebra ( 25 – 29 Feb ’08) considera que los problemas técnicos en el borrador de estandar OOXML no han sido satisfactoriamente resueltos” Sin contar el incidente de Brasil, dio la impresión de que el BRM hizo el mejor trabajo posible pero simplemente era una misión imposible. Definitivamente el documento de OOXML no esta listo para un proceso de Fast-track, ya que en un BRM solo se debería discutir los últimos detalles de un estándar maduro. Como podemos ver, este estándar tuvo cambios profundos como el del alcance y la reestructuración del mismo.
Algunas Razones para Votar NO
Tras del proceso realizado el Ecuador deberá mantener su voto de desaprobación a la propuesta de estándar DIS29500 (OOXML) por las siguientes razones:
- No existe soporte nativo para OOXML en OpenOffice4, Koffice ni la mayoría de los principales competidores de MS-Office. Es más, no existirá hasta septiembre del 20085 en el caso de OpenOffice, por ejemplo. Existe un plugin hecho por Novell que todavía esta en su etapa temprana de desarrollo. Así que aceptar OOXML como estándar internacional puede perjudicar el proceso de migración a software libre del Estado.
- Existe un estándar que ya hace lo que OOXML hace (e incluso más) y tiene soporte nativo en OpenOffice.org, en KOffice y en la mayoría de las aplicaciones libres de ofimática. El formato ISO 26300 fue aprobado en el 2006 y está en proceso de implementación en países como Francia, Corea, Sudáfrica y Holanda, así como importantes regiones autónomas como Andalucía y Extremadura en España (unos 10 millones de habitantes entre ambas). Brasil también esta en un proceso de implementación de ODF como norma nacional brasileña (información recibida en Ginebra por Jomar Silva miembro de la delegación de Brasil y uno de los responsables de la implementación de ODF en Brasil).
- Es un estándar hecho con su principal funcionalidad (y la única diferencia con ODF) de poder migrar documentos antiguos de Microsoft Office 1997 hasta 2008. Es decir que es un estándar hecho para soportar archivos antiguos generados con software de una sola empresa. ¿No debería también dar soporte a los formatos antiguos de aplicaciones como Word Perfect o las hojas de cálculo de Lotus o de cualquier otro proveedor? Un estándar internacional debe ser pensado en todos y no solo en una empresa particular.
- El estándar DIS 29500 ha seguido un proceso absolutamente fuera de lo normal para un estándar de su tamaño. Nunca antes ISO había tramitado un estándar de tal tamaño mediante el procedimiento fast-track, y mucho menos uno que además hubiera tenido tan corta experiencia de estandarización previa (alrededor de 6 meses en el caso de OOXML, pero sólo internamente en la privada ECMA).
- Un estándar se debe hacer con discusión y retroalimentación de las partes, siendo las partes todas aquellas interesadas (cosa que no ha ocurrido en este caso, ). De esta manera todos participamos en tener un mejor estándar que beneficie a todos. Se debe buscar el consenso de las partes y tratar de evitar en lo posible las votaciones y la elección por mayoría. La votación que hubo sobre las 900 respuestas no permitió tener la discusión del caso y mucho menos el consenso. Al final se aprobaron las 900 respuestas con tan solo 6 países, de los 30 votando presentes, a favor de los mismos.
- Se tienen 28 días después del BRM para votar por un documento que no estará listo para esa fecha. Esto quiere decir que se nos está pidiendo aprobar un estándar de más de 6000 páginas antes de que la versión final de su especificación este lista. Es decir tenemos que votar por un Estándar que no sabemos como va terminar.
Esta bien claro el panorama y a donde se quiere llegar. Ecuador se debe mantener en el NO.
Acabo de ver la lista de integrantes del comité, veo bastante Microsoft y Partners. Como bien dices no debe haber un concenso solo por el simple hecho de mayoría. (veo como comento bastante pro-microsoft en el comite)