Muchos de ustedes se habrán preguntado por qué no posteaba o me hacía cargo de la cantidad de barbaridades que se decían respecto a OOXML. La prudencia y la transparencia del proceso establecían que si habíamos optado por el camino del Comité Nacional de OOXML para expresar nuestros puntos de vista, fuera ahí donde hablara.
El proceso ha terminado, en el cual trabajamos 19 instituciones, asistimos a 13 reuniones, revisamos los 217 comentarios y TODOS aprobamos los 214 comentarios y solo tres fueron aprobados con votos de disenso. Una mayoría abísmate mostró consistentemente un trabajo profesional y a veces bien tedioso que llevó a coronar este proceso.
Con estupor he podido ver la carta "declaración" del DCC respecto a su rechazo a OOXML. No me produce estupor el voto sino que los argumentos que ahí se presentan los cuales no se condicen con la idoneidad y ética de profesores de la Casa de Bello.
Igualmente existe en el ambiente que la visión del DCC es la visón del comité. No sabía que el voto de la Universidad de Chile valía más que el de la Universidad Federico Santa María o que la Universidad de Ciencias de la Informática, o de al Acti, o el Gech o la ADI o 19 instituciones privadas y de gobierno que participaron y aprobaron los 217 comentarios. Estimados, las 19 instituciones que se dieron el trabajo de asistir representan todo el espectro del país y claramente, en un voto mayoritario no comparten los puntos de vista del DCC.
A continuación procedo a hacer un descargo de todos y cada uno de los puntos que ahí se mencionan y dejo a criterio del lector si esto este voto tiene alguna fundamentación y no es simple manejo dialéctico que se aprovecha del buen nombre de la Universidad por sobre el ciudadano bien intencionado.
Espero que con el mismo respeto que hemos aceptado estoicamente todas y cada una de las difamaciones y faltas de la verdad de, seamos correspondidos por aquellos que tienen una opinión diferente.
1. Sobre el proceso ISO/IEC DIS 29500.
a) El proceso que se ha seguido dista mucho de haber sido realizado con la profundidad técnica que una decisión de este tipo requiere. Es patente que ningún miembro del Comité estudió las más de 6.000 páginas que contiene la propuesta de estándar. Esta aparente desprolijidad es una consecuencia previsible de la decisión de los proponentes de apurar la discusión (Fasta Track), que fuerza a tomar una decisión en pocos meses.
La argumentación arriba mencionada muestra una absoluta desinformación de cómo son llevados a cabo los procesos de revisión de normas en el seno de la ISO. ISO toma resoluciones de una manera colegiada en la cual, la suma de las partes revisadas por todos sus miembros dan la garantía que la totalidad de la norma fue revisada. En el caso chileno, se levantaron 217 observaciones que fueron parte de las 3.500 que se levantaron nivel mundial. Nadie puede reclamar que estas 3.500 observaciones no corresponden a la más acuciosa revisión que jamás se le haya hecho a norma alguna. Tal como lo señaló el propio representante de la Free Software Foundation, Oscar Valenzuela, en el Comité Espejo, ellos contaban con un equipo de 50 profesionales dedicados full time a revisar a profundidad la norma y encontrarle los errores más pequeños que se pudiera decir. Baste con ver el comentario CL 126 donde se menciona un error a nivel de un pixel corrido en un Word Art!
El tiempo que ha existido es más que suficiente para hacer un análisis acucioso si uno se dedica a esto. Si la gente no tiene tiempo, ¿es culpa del proceso o de las personas? Un caso para tomar en cuenta. Chile, después de la votación del 2 de septiembre, se juntó 13 veces. Brasil solo 2. Principal argumento de Brasil, no hay tiempo. A ese ritmo, concuerdo 100% que no alcanza el tiempo.
Si la Universidad estimaba que no existía el tiempo suficiente para realizar una revisión acusiosa al nivel que ellos esperaban, debieron haberlo manifestado al momento de iniciarse las reuniones y en el peor de los cosas, haberse abstenido de participar. La ratificación por parte de la Universidad de Chile del reglamento de las sesiones del Comité Espejo el 16 de noviembre, es un reflejo de que el tiempo de análisis no era una objeción en ese momento.
b) La inconveniencia de apurar la estandarización de un producto a un inmaduro quedó en evidencia en la reunión BRM (Ballot Resolution Meeting) de Ginebra el pasado febrero. En ella sólo fue posible discutir técnicamente menos del 20% de las observaciones hechas por los distintos países.
Nuevamente, la aseveración anterior muestra un desconocimiento absoluto de lo que es el proceso de estandarización de ISO y en especial el BRM y lo que se estaba discutiendo en él. El proceso de ISO esta compuesto por una serie de normas a las cuales los participantes y proponentes se someten, independientemente de si gustan o no. En la misma reunión del BRM con 29 votos a favor y solo 2 abstenciones, se acordó qué se iba a votar y con qué modalidad: Lo que se iba a votar en bloque eran aquellos comentarios que cada Comité Espejo en su seno había aprobado. En el caso Chileno eran 214 de 217. Lo mismo con los demás países. Lo que se discutió fue justamente aquello que no había consenso en cada Comité Nacional y que una cantidad sustancialmente menor. Se discutió y votó quedando solo 16 observaciones rechazadas.
c) Los temas relativos al contexto nacional chileno fueron escasamente tratados en las reuniones del Comité chileno, sobre todo debido a la premura del tiempo por responder comentarios técnicos propios de la propuesta.
La Universidad de Chile se marginó de la primera etapa de este proceso que duró 6 meses. En ese período se encargó un estudio en derecho sobre la legalidad de la norma respecto a las normas chilenas que norman el uso del documento electrónico. Igualmente, la Cámara de Comercio de Santiago entregó un informe sobre la conveniencia de contar con un Estándar con OOXML en el concierto de la economía Chilena.
2. Las características técnicas de la propuesta OOXML
1. Interoperabilidad. Es la capacidad que permite a los sistemas heterogéneos comunicarse y operar entre sí.
a) Este es un tema crucial para ISO en la estandarización de datos. La propuesta presentada está lejos de satisfacer este requerimiento, debido a uso de múltiples funcionalidades que no son estándar (ej. fechas, fórmulas matemáticas, referencias).
No entendemos esta aseveración de la Universidad de Chile pues el 100% de los problemas que sí presentaba la norma fueron modificados a plena satisfacción de las mismas recomendaciones que la propia Universidad de Chile hizo en el proceso. De hecho, el Comité Espejo acogió y aprobó estas recomendaciones -según consta en las actas publicadas en el sitio de la Cámara de Comercio Electrónico- con la aprobación de la Universidad de Chile. La casa de estudio sólo voto en contra de 1 observación que no consideró apropiadamente respondida, pero finalmente participó en un voto de minoría.
Es más, estos temas fueron tratados a profundidad entre los profesores del Departamento de Ciencias de la Computación y una eminencia mundial en este campo como Jean Paoli, co-autor de XML y OpenXML en las dependencias de la misma casa de estudios.
b) No hay consenso, aun después del BRM de febrero, que la traducción del formato binario de Office a OOXML este documentado. Esto es esencial para que otros desarrolladores puedan recrear el formato original.
Definitivamente nunca va a ver consenso pues OOXML no mapea formatos Binarios por dos razones básicas:
c) La extensiva y compleja documentación (más de 6.000 páginas; comparar por ejemplo con las 40 páginas del estándar XML) hace muy difícil extender y desarrollar aplicaciones que interoperen con este formato.
Lo anterior, concordando con la apreciación de la Universidad, definitivamente el representante del DCC no leyó ni siquiera el índice de la especificación. Vamos por partes:
La especificación, como la de cualquier pieza de software profesional, está formada por seis secciones que más adelante detallamos. Como cualquier programador sabe, no es necesario leerse el 100% de una especificación para poder hacer uso de un software. Es más, podemos hacer cosas realmente espectaculares ocupando una porción ínfima de la documentación. Veamos las partes y después, solo "recordemos" cómo funciona el mundo real:
-
Introducción (Fundamentals, 178 páginas), simplemente describe la norma, las partes y piezas que la componen.
-
Empaquetamiento (Open Packaging Conventions, 131 páginas), donde se describe cómo se empaqueta un archivo OOXML
-
Manual de Consulta (Premier, 473 páginas), es el típico manual para comenzar a trabajar donde se explican los detalles básicos de cómo crear aplicaciones usando la norma. Es el manual normalmente llamado como "Getting Started"
-
Manual de referencia (5220 páginas). Es el detalle de todas y cada una de las funcionalidades de la norma. Está compuesta por 8 secciones independientes y 3 anexos
-
Extensibilidad (Markup Compability, 43 páginas) es el manual para saber cómo extender OOXML.
Cualquiera que haya programado en la vida sabe perfectamente que no es necesario y tal vez nunca lo haga, leer todo el manual. Es como decirle a alguien que si quiere usar OpenOffice (para no herir susceptibilidades) debe leerse el 100% del manual si quiere escribir una carta. O si quiero hacer un programa en C++ debo leerlo entero para hacer un programa. Si uno es relativamente prolijo, se lee la introducción y el Getting Started. Luego, a medida que me voy enfrentando a problemas, leo la sección del manual que habla sobre lo que estoy preocupado. La argumnetación del DCC cae en algo tan obvio o grotesco como lo siguiente: si estoy haciendo una aplicación para Word, para qué tengo que leerme lo que dice relación a Excel y PowerPoint. Y si estoy viendo cómo grabar un archivo, ¿para qué me tengo que meter en la incrustación de WordArts?
Claramente este comentario está absolutamente fuera de la realidad. Lo que sí es real, es que la norma es completísima y aquellas partes que no lo eran, ahora, por el mismo proceso de la ISO ser completaron. Ahora se van a agregar páginas, no quitar.
El argumento de comparar una especificación con XML, es llevar la argumentación al extremo de la falacia. XML es la sustancia con la cual se crean los vocablos o esquemas, donde OOXML es uno. Estos esquemas van a ser más extensos en tanto en cuanto mayores sean las funcionalidades que ellos deban representar en el subset definido por XML. ODF tiene más de 2.000 páginas. Por ejemplo, lo que dice relación solo a Excel tiene 1.095 páginas. ¿Cuántos libros de cómo usar Excel son de mucho más de 1.000 páginas? La especificación de PowerPoint es de 265 páginas.!!! Creo que ni un libro de PowerPoint for Dummies tiene tan pocas páginas.
d) Los temas legales de licenciamiento han sido objeto de muchas críticas debido a su falta de precisión. La insertes sobre si se ha cruzado una línea legal o no también desalienta las implementaciones alternativas.
Realmente no entendemos esta aseveración. Simplemente nos remitimos a lo que plateamos al principio. La ISO es una organización de estándares, cuyo prestigio y seriedad no está en duda, pues por la misma razón, todos hemos acudido a ella como ente para que regule y norme estos estándares. Pues bien, la propia ISO, en su proceso de aceptar la norma ECMA 376 para convertirse en un estándar ISO, descartó , previa revisión, que esta norma tuviera cualquier problema de propiedad intelectual que se le exige a cualquier otra norma ISO.
Si dudamos de la claridad y seriedad de ISO en este aspecto tan relevante, ¿porque no dudamos cuándo ODF o PDF entraron a la ISO?
e) Para nuestra comunidad local, el determinar cómo armoniza cualquier propuesta de formato de datos con el decreto de firma electrónica y el Decreto 81 sobre interoperabilidad documental en Chile, es un aspecto crucial, que no se alcanzó a discutir en el proceso.
Nuevamente, nuestra sorpresa es mayúscula. Tal como se mencionaba anteriormente, la Universidad de Chile se marginó de la primera etapa de este proceso que duró 6 meses. En ese período se encargó un estudio en derecho sobre la legalidad de la norma respecto a las normas chilenas que norman el uso del documento electrónico. Sin perjuicio de lo anterior, este informe estuvo disponible a todos los miembros del comité y fue sometido a escrutinio en el subcomité de propiedad intelectual, al cual por cierto, a pesar de estar invitados no se excusó de asistir el representante de la Universidad de Chile.
2. Modularidad. Es la capacidad de un software de ser tratado como un sistema coherente de varias partes independientes entre sí.
a) La propuesta carece absolutamente de modularidad. Esto es particularmente notorio en la dificultad para reemplazar formatos obsoletos por funcionalidades ISO estandarizados (por ejemplo fechas, formulas matemáticas, algoritmos de seguridad, algoritmos de cálculo, etc.). Los editores optaron por agregarlas junto a (no en vez de) las antiguas no recomendables.
Los problemas que se señalan fueron corregidos a completa satisfacción de lo solicitado por nuestro comité y la comunidad mundial de la ISO. No se logra entender porqué se insiste en quedarse con la primera versión de la norma como si todo el trabajo de corrección que hizo en estos últimos meses no hubiera existido. Todas las funcionalidades donde se pidió usar una norma ISO fueron acogidas y las partes obsoletas fueron sacadas de la especificación y colocada en un capítulo aparte para especificaciones Transitorias.
b) La experiencia demuestra que la alta complejidad de las especificaciones no modulares tiende a producir una sola implementación (la del autor de la propuesta). En consecuencia, la adopción de formatos con este tipo de deficiencia puede limitar seriamente el desarrollo de la industria de software en Chile.
Totalmente de acuerdo en la premisa y en la conclusión siempre que una norma carezca de modularidad, cosa que por cierto no es lo que hoy tenemos en OOXML luego de 1 año de trabajo en ISO sobre ella. Es verdad que en ese año muchos se dedicaron a reclamar que no tenían tiempo para trabajar, pero hubo un grupo no menor, encabezado por la FSF e IBM que revisaron al máximo nivel de acuciosidad la norma. Nosotros como Microsoft no podemos estar más agradecidos pues el producto que salió de este proceso es infinitamente mejor que la que habríamos pensado.
3. Aspectos rescatables. De estandarizarse correctamente una propuesta de este tipo, Microsoft debería hacer pública la documentación de los formatos usados en las suites Office. Esto debiera acompañarse de la apertura de licencias correspondientes. Estas acciones al menos en principio permitirían a otros productores de software que no sean MS desarrollar aplicaciones para intercambiar datos con esos formatos.
Adicionalmente, se conseguiría la existencia de un estándar para la documentación legada que está en esos formatos (MS Office).
Microsoft ya hace lo que señala la Universidad. Es más, esto ocurrió justamente a recomendación de ISO para poder entrar al proceso. La documentación está publicada en la página web de Microsoft y en la de la Biblioteca Nacional de Inglaterra (Miembro de ECMA). La publicación lleva consigo todos los temas de propiedad intelectual en las cuales, básicamente, los igualamos a los de OOXML. Nos causa una extrañeza profunda este comentario, pues esto fue profusamente analizado y discutido en las reuniones del comité y subcomités, además de ser expuesto a los profesores del DCC por Jean Paoli en forma particular y por Nick Tsilas en forma general a todos los miembros del comité. ¿No lo escucharon o no quieren escucharlo?
¿Qué busca el DCC? ¿Por qué quieren causar tanto daño? ¿Qué les hemos hecho para que nos traten de esta forma? Si tan mal piensan de nosotros, ¿por qué aceptan trabajar con nosotros en proyectos de mutuo beneficio?
Para aquellos que hoy están metidos en esta discusión, sin duda esta pregunta es tremendamente relevante. ¿Cómo es posible que un país como Alemania, cuna de OSS haya votado que si por Open XML así como ocurrió en Brasil que votó no con comentarios?
Sin embargo antes de tratar de esbozar una respuesta quiero fijar el marco sobre el cual me quiero referir.
Como ustedes saben, hoy la votación en Chile está en manos del INN en su calidad de miembro activo de la ISO. El INN estableció como regla para tomar una decisión al respecto, convocar a todas las instituciones relevantes del país a participar en una mesa de trabajo para discutir el tema. Esta decisión, la cual acatamos, implica que ninguna empresa persona natural podía participar sino que a través de sus representantes. Por lo anterior, debo ser respetuoso de esta institución y no entrar en el debate que ahí está ocurriendo a riesgo de ser imputado como que estamos haciendo presiones indebidas.
Por lo anterior y hasta que no se emita el voto no voy a entrar en la arena chica a discutir las diversas objeciones técnicas que se mencionan en la blogósfera. Una vez emitido el voto, voy al hueso.
Sin perjuicio de lo anterior, existen una serie de consideraciones de procedimientos y de arquitectura del estándar que, a ojos de un lector concienzudo, podrá inferir fácilmente las respuestas a las inquietudes técnicas que se manifiestan. Así que aquí voy:
¿Otro estándar más? Give me a break!
Es sumamente humano pensar que para qué queremos otro estándar si ya tenemos demasiados. Como muestra de esto, en solo XML existen más de 140 estándares de documentos. 141?...no way. Pero , no, ¿valdrá la pena entender porqué existen tantos estándares? Simplemente porque cada cual está inmerso en una realidad distinta y tienen un historia que no puede ser olvidada. Si vemos por ejemplo los estándares que existen en imágenes JPEG (es más, existen al menos tres tipos de JPEG – JPEG, LPEG-LS, y JPEG 2000), PNG, y CGM cada uno de los cuales es un estándar ISO, atienden diferentes necesidades en el mercado. Lo mismo sucede con los lenguajes de Esquema (Schema languages) – RELAX NG (ISO/IEC 19757-2:2003) versus DTDs como fue incluido en SGML (ISO/IEC 8879:1986). El correo electrónico es otro ejemplo – tenemos X.400, SMTP, POP3, IMAP . Porqué no nos ponemos de acuerdo y hacemos uno no más?. Simplemente por dos razones: cada cual tiene sus virtudes que se muestran en los diferentes ámbitos donde se desarrollan y, no menos importante que lo anterior, existe una inmensa base instalada de cada cual por lo que si adoptamos uno, ¿ que hacemos con lo que ya existe?
A la hora de diseñar un estándar tengo dos caminos que seguir: crear un perfecto de laboratorio que describe una realidad idílica pero que no existe. Hacer una pieza de arte, un estándar de laboratorio. Perfecto!. Otro camino sería crear uno que se haga cargo del pasado, del presente y a pesar de ello, pueda enmarcarse en las tendencias del futuro. A este lo llamaría un estándar de mercado pues está inmerso en una realidad de mercado.
OOXML fue diseñado inicialmente como uno de laboratorio pero al pasar por la ECMA, sus miembros exigieron que fuera uno de mercado. ¿Por qué? Pues la mitad de sus miembros son usuarios finales y dos de ellos en particular, son bibliotecas. Las bibliotecas no podían darse del lujo de ignorar la inmensa cantidad de documentos existentes por la sola promesa de tener la “última chupada del mate”. Entonces ahí comenzaron los desafíos. El acuerdo fue el siguiente: todo aquello que diga relación con compatibilidad reversa deberá ser opcional. Y así fue como un documento de unas 2.000 páginas se convirtió en 6.000 páginas: Backward compatibility. Al hacerse cargo de este problema, había que hacerse cargo de definir en las lista de posibles valores, formatos que definitivamente no tienen nada de estándar, como VLM o WMF. Pero nuevamente son opcionales y no son por defecto.
Nice, pero ¿de qué sirve todo esto si las especificaciones de esos binarios no están en el estándar?. Bueno dos cosas, si hoy nos “fríen” por que son 6.000 páginas,¿ qué dirían si este tuviera 20.000 o más? ¿ Cómo se soluciona esto? Igual como lo hacen otros estándares: hacen referencia a ellos y la especificación se busca en la documento del referenciado. OOXML hace lo mismo pero con una diferencia que pone de punta a los “puristas”: se referencia cosas que no son estándares. Algún suspicaz tendrá en la punta de su teclado la siguiente pregunta: “… buena oh!..ahora para poder usar OOXML finalmente tengo que pagarle a Microsoft para que me “suelte” las especificaciones de los binarios!!! …”
No mis amigos, eso ya no es así (lo fue pero no mas). Hoy cualquiera que quiera los estándares los puede pedir y obtiene una licencia indefinida , irrevocable de uso de los formatos para el propósito que desee.
Estimados, ¿ustedes creen, a pesar de lo que traten algunos cabezas calientes hacernos pensar, que la ECMA se habría prestado para eso? La ECMA es un ícono de soberanía intelectual de Europa y los europeos cuando se meten con americanos no andan jugando. Estas opciones incluyen la Promesa de Especificación Abierta de Microsoft (Microsoft’s Open Specification Promise), el Convenio de Microsoft (Microsoft’s Covenant) y una licencia Razonable y No Discriminatoria (Reasonable and Non-Discriminatory (RAND)) libre de regalías.
Ha habido muchos comentarios recientes de que Microsoft y otros miembros del Ecma TC45 deberían haberse unido al Comité Técnico OASIS que trabaja en ODF en lugar de crear otro estándar en Ecma. Pero Office Open XML y ODF tienen principios base de diseño diferentes: Ecma puso gran importancia en la fidelidad del legado existente de documentos Microsoft Office, mientras que OASIS se ha opuesto activamente a cualquier principio de diseño que haga relación a compatibilidad retroactiva con documentos Microsoft Office existentes. Los comentarios hechos por un miembro del TC de OASIS que desarrolló ODF (el Presidente actual de la Fundación ODF, Gary Edwards) son muy claros en que ni Microsoft ni su principio de diseño de compatibilidad retroactiva serían bienvenidos en OASIS en su blog:
“¡No hay manera posible en que ninguna persona pueda reclamar que el OASIS ODF TC de hoy le daría la bienvenida a Microsoft y haría cambios para acomodar la especificación! ¡De ninguna manera! Y la prueba de esta hostilidad puede ser vista en las discusiones actuales y en los rechazos de las propuestas específicas de interoperabilidad de Microsoft.”
Entonces ¿Por qué fue que Microsoft no trabajó simplemente con la gente original de ODF para que le ayudaran a construir su especificación? Bueno yo diría que hay al menos cuatro buenas razones para tomar esta decisión:
1. El alcance de la especificación ODF no incluyó nunca ni siquiera los requerimientos básicos que necesitaba para apoyar un formato completamente abierto – y el comité técnico de OASIS no quería incluir estos requerimientos. Estos incluyen:
a. Hojas de cálculo
b. Tablas en presentaciones
c. Características de accesibilidad para gente con discapacidad
d. Soporte de Esquema de Personalizados (Custom-defined schema support)
e. Personalización de Metadata (Custom metadata)
2. No fue sino hasta el 2005 que la especificación ODF se ofreció como formato de documento general office XML y fue en consecuencia rebautizado ODF.
3. ODF empezó y fue completado en su mayoría como un formato específico XML que soportaba Sun OpenOffice con un alcance cerrado en torno a ese producto.
4. No hubo oportunidad para Microsoft de participar en este proceso dado tanto el alcance original y los 6 meses transcurridos entre que fue rebautizada la especificación ODF y su consecuente aprobación por OASIS como un estándar.
Se debe recordar que el Capítulo del Comité Técnico de OASIS ODF específicamente dijo que los esquemas de Sun OpenOffice eran el punto de partida para todo el trabajo y esquemas, y no fue mucho después que el nombre del Comité Técnico (TC) cambió a “Open Document Format (Formato de Documento Abierto)” u “ODF”. El comité técnico mantuvo un foco muy claro y cerrado para presentar las funcionalidades del producto original Sun StarOffice.
Por más que lo traten los “chicos” de StarOffice, no son lo mismo de Office y menos que Office 2007 ( Works 95, maybe ) por lo que si nos metíamos debíamos volver atrás como 10 años!
Es más, esto fue lo que dijo Gary Edwards, editor de ISO 26300 ODF, cuando respondió a esta cuestión en su “blog ”:
“La membrecía del OASIS ODF TC está clara e inequívocamente en el record a diferencia de la interoperabilidad que el mercado está pidiendo. Los temas de "compatibilidad, interoperabilidad y convergencia", como se describen arriba, han sido llamados por miembros actuales del TC: "fuera de límites", "fuera de alcance", "no nuestro problema", "dejen que los convertidores y transformadores lidien con eso", y "hablen con Microsoft".
¡Si Microsoft quisiera unirse al OASIS ODF TC hoy en día, buscando adoptar ODF para satisfacer las necesidades documentos “legacy” -características propias de MSOffice-integración de línea de negocios de su base monopolística, el TC tendría que lidiar con los mismos problemas que en forma sumaria han rechazado en sus actuales discusiones de compatibilidad-interoperabilidad-convergencia!”
En definitiva, la pregunta si es un buen estándar no se refiere a sí que si es el mejor o que es superior a ODF. No, OOMXL es un estándar más: abierto, completo y libre que por cierto puede y va a ser mejorado que se hace cargo de los miles de millones de documentos que hoy existen en el mercado y los lleva a una plataforma 100% interoperable.
Recordemos que la interoperabilidad no solo dice relación con lo que pueda construir en el futuro sino que tengo que hacerlo con lo que hoy existe. Si no me creen, pregúntele a los de CORBA!
A raíz de los eventos de los últimos días, no es raro que alguien que desconoce el mercado (y otros que dicen conocerlo) piense en Microsoft y el Open Source como un antónimo, como algo que no puede coexistir en un ambiente y que en ciertas circunstancias sea hasta conveniente. Esto podría sonar hasta herejía.
En realidad está lejos de ser una herejía y esto se puede constatar desde las dos puntas del tema: Los usuarios y los desarrolladores. Los usuarios de sistemas de información buscan las mejores herramientas que a su parecer le proveen el mejor valor para el costo que están dispuestos a pagar por ella. Asumir que los usuarios no son racionales, tanto cuando pagan por una licencia o un servicio o que están obligados a pagar, es no entender la lógica del mercado. Nadie puede sostener hoy, ni hasta los más fundamentalistas del OSS que ambas plataformas tienen programas para solucionar problemas de los clientes. Si eso es así y los clientes elijen una u otra y a veces ambas es porque han encontrado el justo equilibrio en el valor que cada alternativa le provee.
El costo de una solución está dado por el valor de la licencia, el hardware y los servicios. Los modelos basados en código propietario, basan su modelo de negocio en obtener el retorno de su inversión fundamentalmente en el costo de la licencia siendo que los basados en código libre hacen su ganancia en los servicios que presta. El usuario final decide producto elije basado en una simple evaluación de costo sobre beneficio. Este principio económico es el que sustenta la política de neutralidad tecnológica adoptada precisamente por los países más avanzados en tecnologías de la información del mundo.
La realidad del modelo de negocio de código abierto es tan real que Microsoft, lejos de apartarse de él, trabaja de una forma armoniosa con aquellos desarrolladores del mundo que ven en nuestra plataforma una excelente oportunidad de negocios para crear nuevas aplicaciones de código abierto. Podrá parecer una contradicción lo que escribo en estas líneas pero basta ver que hoy en día, en solo dos sitios web SourceForge y www.CodePlex.com hay más de 79.000 aplicaciones de código abierto basados en nuestra plataforma. Igualmente trabajamos con las principales empresas de código abierto del mundo, como por ejemplo, SugarCRM, MySQL, Novell, JBoss, Zend, XenSource, SUN, Mozilla , Aras, SpikeSource, Xorp y otros. Es más, Microsoft provee a la comunidad de código libre de un sitio web, http://port25.technet.com orientado principalmente a dar soporte a esta comunidad en temas relacionados con interoperabilidad con nuestra plataforma. Respecto al código abierto, lo compartimos con los Estados, Las Universidades y nuestros socios de negocios. Incluso , hemos creado un programa de apoyo a empresas que trabajan en Código Libre para ayudarlos a crear un negocio de esta práctica (http://www.microsoft.com/opensource/economic.mspx)
Algunos de ustedes se preguntarán que gana Microsoft con tanta apertura. Algunos de ustedes verán esto con suspicacia pero la respuesta es clarísima: es lo que piden nuestros clientes. Ellos no quieren que las empresas de tecnología los obliguemos a decidir por una plataforma u otra. Ellos ya tomaron su decisión en base a los méritos de cada cual. Lo que nos exigen es que ambas sean interoperables y eso se logra adhiriendo a los estándares mundiales de interoperabilidad y trabajando codo a codo unos con otros.
Microsoft no compite con modelos de negocios. Microsoft compite con productos.
Los invito a revisar en mayor detalle todos estos puntos en nuestra página web www.microsoft.com/opensource
