miércoles, 24 de octubre de 2007

Charla de Carrera Profesional

Versión descargable aquí (PDF, 1.86 Mb.)

Ayer Martes di una charla a los Estudiantes de la Carrera de Ingeniería Civil Industrial de la Universidad de Valparaíso. La invitación fue cursada por los alumnos del Centro de Estudiantes de Ingeniería Civil Industrial, a quienes agradezco su gentileza y atenciones.

Fue un muy grato momento y tuve la oportunidad de poder compartir algunas ideas sobre desarrollo de carrera profesional. En lo personal, es muy gratificante poder compartir con alumnos universitarios, porque me "refrescan" de mis actividades del día a día y aprendo siempre un nuevo concepto o clarifico alguna nueva idea al compartir con ellos.

Parte de la presentación fue una conferencia que di hace un tiempo sobre un modelo de Emprendimiento y Empresa y que ya comenté en otro artículo previo. Pero la novedad en este caso, fue una presentación que preparé con base en el artículo Lecciones de Surfing y Tecnología que había escrito a principios de este año (y que es uno de mis artículos "preferidos").

Los invito a revisar la presentación, donde pongo en forma "gráfica" los conceptos que desarrollé en ese artículo.



Gracias nuevamente por la invitación, y mantenemos el contacto.

Stay Tuned!

Leer artículo completo ...

jueves, 18 de octubre de 2007

Comentarios preliminares sobre la Estrategia Digital

Versión descargable aquí (PDF, 55 Kb.)

Hace unos días, Alejandro Barros, en su rol de Secretario Ejecutivo del Comité de Ministros para el Desarrollo Digital, invitó a la Comunidad a comentar el primer borrador de la Estrategia Digital 2007-2012 para Chile.

Indudablemente, dicho gesto marca un cambio en la forma y en el fondo del cómo definir las políticas públicas en Chile. En un artículo que escribí hace unos días en SushiKnights, identifiqué una serie de signos que indican que hay una tendencia irrevocable, en términos del cómo serán definidos ciertos procesos de decisión futura, por la vía de las herramientas de participación comunitaria.

Desde dónde surgen estos comentarios

Estos comentarios surgen del trabajo y análisis que desarrollamos con Cristian Ocaña, Presidente del Consejo de Especialidad de Computación e Informática del Colegio de Ingenieros, especialidad de la cual soy Consejero. Y corresponde a un draft de ideas, que impulsaremos desde los espacios institucionales en los cuales participamos, para que sean incorporadas en el proceso de discusión.

Por lo pronto, representa opiniones de fondo de Cristian y quien suscribe, pero la redacción final y de los juicios críticos, soy 100% responsable :-)

Sí creo relevante hacer una declaración, indicando la óptica desde la cual hago estos comentarios.

Indudablemente es una visión sesgada, ya que no cubre en profundidad y extensión las múltiples dimensiones del documento. Por una deformación profesional, mis comentarios los realizo desde mi visión particular como Ingeniero (es decir, como un profesional que desempeña su labor íntimamente ligado a estos temas) y como Empresario Tecnológico (es decir, como un agente productivo que tiene un interés económico en algunas de estas definiciones y una mirada global de desarrollo país). Esto se complementa con mi visión como Ciudadano, en términos de la opinión que tengo respecto a ciertas políticas de desarrollo y oportunidades para los ciudadanos de mi país.

Hago esta declaración, porque a algunos llamará la atención que no toque por ejemplo en este artículo, aspectos relacionados con la Educación o a los procesos de Participación Social en un modelo de Sociedad Digital, siendo temas en los cuales tengo una opinión, pero no me considero un experto que pueda emitir públicamente opiniones fundamentadas al respecto.

Por ello, agradeceré ponderar en los comentarios siguientes estas consideraciones, motivo por el cual quienes tengan observaciones sobre la Estrategia Digital desde otras miradas, podrán considerar que algunas de mis opiniones son rebatibles o contradictorias con sus posiciones propias.

Los procesos de consenso son complejos, especialmente en temas que tienen múltiples miradas en relación con visiones de sociedad y futuro.

Paso ahora a detallar los comentarios y proposiciones.

Sobre la forma del proceso

Hay quienes propugnamos que estos procesos deben ser de mucho más largo plazo, con una participación más profunda y de muchos otros actores.

La preparación de un documento emitido desde la Secretaría Ejecutiva, solicitando la opinión de la Comunidad para que proponga indicaciones que serán evaluadas para su posible incorporación al documento, es un avance importante pero no suficiente.

En el futuro, creo que se requieren modificaciones fundamentales tanto de forma como de fondo, no sólo en el proceso de elaboración, sino que también de mantención, actualización y control, por parte de todos los actores de la Comunidad Nacional. Deberemos tener siempre presente que son estrategias nacionales que involucran a muchos actores. Y en consecuencia, los diversos actores deben comprometer tanto su participación en la elaboración como el cumplimiento de los compromisos, en lo que les toque.

También es necesario considerar el contexto en el cual esta proposición surge. Y emitiré algunos juicios duros, aprovechándome quizás de ciertos privilegios al conocer algunos detalles internos y participar en forma tangencial en algunos de estos procesos de discusión.

Un Gobierno que durante su primer período simplemente no había contemplado el tema del desarrollo tecnológico y la sociedad digital como tema relevante, en 6 meses se encuentra desarrollando una serie de iniciativas que significan cambios institucionales, proposiciones a la sociedad en su conjunto y diseño y elaboración de estrategias. Bien por ese cambio.

La labor que el equipo de Alejandro se encuentra desarrollando es compleja, incluyendo no sólo la relación con entes externos al Gobierno, sino que también, significa complejos procesos de convencimiento y alineamiento de las diversas instituciones y personas, que al interior del Gobierno poseen responsabilidades, cuotas de poder importantes y diferencias de visión. Este equipo debe lidiar entre otras barreras, con múltiples funcionarios y altos ejecutivos del aparato público, quienes aún consideran que estas discusiones no son de alto impacto para los procesos de desarrollo futuro de nuestro país. Y por ello, la participación de múltiples actores es fundamental, ya que de esta forma los resultados de estos procesos no sólo serán una visión consensuada (y en algunos casos negociada) al interior del aparato público, con todas las complejidades y sesgos que dichos procesos de discusión al interior de los Gobiernos en forma inherente poseen.

Y por último, un antecedente no menor: estas definiciones preliminares son urgentes, por un sentido práctico, considerando que el 2008 y por una característica propia de nuestro país, la contingente discusión electoral, llevará a un segundo plano las conversaciones importantes, como a la que nos ha convocado Alejandro.

En consecuencia, considero que este primer avance es interesante y un aporte preliminar, pero en el futuro, el proceso deberá contemplar modificaciones profundas a la génesis y modelo de participación en la construcción de estas iniciativas. Y en cuanto a los plazos, si bien muchos nos sentimos incómodos con los plazos relativamente cortos para estas discusiones fundamentales, también consideramos que es un avance que debe darse en algún momento y que como cualquier obra humana, es perfectible en el tiempo.

Comentarios sobre el fondo

No pretendo en este documento desarrollar in extenso los puntos planteados, más allá de enunciar las ideas de consenso con Cristian y realizar una pequeña proposición. Simplemente, son observaciones que invitan a profundizar en algunos aspectos del documento.

Sin perjuicio de lo anterior, sí quiero establecer que creemos con Cristian que cada uno de los puntos en este documento, tienen mérito propio en sí para ser considerados en forma independiente, ya que creemos que son definiciones importantes y que deben ser consideradas en el producto final.

La falta de una Visión

El documento establece un "estadio de desarrollo deseado" pero no define una visión que de cuenta de ese estadio (pág. 13, Párrafo 1, el Objetivo de la Estrategia).

No se establece en ninguna parte "a dónde queremos llegar como país", siendo indicados algunos objetivos, difícilmente medibles y que indudablemente son buenas intenciones, pero no se define una "Visión País" para el 2012.

Desde un punto de vista formal, el desarrollo de una estrategia parte por la definición de una visión, y por ello, recomendamos como primera acción consensuar y definir "Cuál es el Chile que queremos el 2012", a través del Soporte de las Tecnologías de la Información y las Comunicaciones, en un modelo de Sociedad o Economía Digital.

Sobre la base de una visión clara del país que queremos al 2012, tiene sentido hacer las siguientes preguntas:

  • ¿Queremos un país en el cual cada escolar tenga acceso a su propio computador?
  • ¿Queremos un país el 2012 en que cada hogar esté conectado a Internet?
  • ¿Queremos un país con un 60% de sus ciudadanos "alfabetizados digitalmente"?
  • ¿Queremos un país en el que cada empresa y cada ciudadano resuelva el 98% de sus trámites con el Gobierno sobre Internet?
  • ¿Queremos un país en el cual el 50% de las operaciones de negocios se desarrollen mediante servicios de e-business?
  • ¿Queremos un país en el cual el 5% de las exportaciones sea por servicios de "conocimiento empaquetado", con capacidades competitivas internacionales?
Esas son preguntas de visión que creo nos debemos hacer, y más aún, debemos convencernos de que es posible. Incluso estos días se abren discusiones en torno a temas de acceso y conexión. ¿Sobre qué visión? ¿Para qué? Por deformación, la visión que planteo contempla métricas específicas. No necesariamente debería ser así. Pero indudablemente una apuesta de futuro que efectivamente quiera ser implementada, debería incorporar dichas métricas.

Desde un punto de vista TI formal, queremos conocer el "Caso de Uso País Chile - 2012".

El alcance del documento actual

El documento está exclusivamente centrado en el Aparato Público y sus acciones y condiciones. Es una estrategia de Gobierno, no es un proyecto de Estrategia Digital País, ya que define acciones y condiciones exclusivamente para el Sector Público, pero no define aportes y responsabilidad del Sector Privado, el Sector Productivo, la Industria Tecnológica, el mundo de la Educación y de los Ciudadanos.

Una estrategia país debe contemplar a todos los actores. Indudablemente, en el caso chileno, el Estado es el motor del modelo de desarrollo tecnológico y de industria, pero dicho esfuerzo no es suficiente. Y creemos conveniente que contemple opiniones y compromisos de otros sectores de la Sociedad, no sólo declaraciones de buenas intenciones.

El documento, a partir de su lectura, define objetivos y líneas de acción exclusivamente para el Sector Público, y que están centradas más en lo que el Gobierno puede hacer que en la visión de un "Proyecto País".

Por ello, creemos que el documento no se hace cargo de la experiencia internacional de estrategias de desarrollo digital exitosas, que surgen del consenso de todos los sectores de un país, en un modelo de ecosistema, donde todos los actores colaboran entre sí y con roles claramente definidos.

Eso provoca que la propuesta que surge del actual documento, estando basada exclusivamente en las acciones gubernamentales, sea altamente riesgosa, ya que no define las condiciones, los supuestos y las responsabilidades que los otros actores deben cumplir para lograr el éxito de los objetivos nacionales.

En resumen, falta que muchos otros opinen y "se pongan" con el documento: Qué piden, qué ofrecen.

Sobre la Convergencia

El Documento debería incorporar una mirada de Convergencia, entendiendo que los temas TIC consideran múltiples sectores complementarios y procesos de encadenamiento productivo mayores, incluyendo la Infraestructura de Telecomunicaciones, la Industria del Contenido, la Industria Tecnológica y la Industria de Servicios, en forma no exclusiva.

Si incorporara esa nueva mirada, la Estrategia contemplaría un conjunto de acciones colaborativas y ordenadas detrás de un objetivo, en reemplazo de estrategias y objetivos parciales y de un segmento en particular.

Por ejemplo, no se contempla en la estrategia, a diferencia de otros modelos de estrategia nacional como la de Nueva Zelandia, la industria de producción audiovisual. Para el caso de la Educación soportada por tecnología, son un aporte fundamental para el desarrollo de contenidos locales, o para el caso de fomento de la Industria Tecnológica, complementan los procesos de producción de soluciones para industrias de e-learning, control a distancia o marketing multimedial.

Por ello, creemos que para cada "proceso", deberían identificarse los diversos roles y responsabilidades, en esa mirada de encadenamiento, bajo una óptica de "Convergencia".

Innovación, Investigación y Desarrollo

Siendo discusiones amplias, indudablemente polémicas y no zanjadas, creemos que el documento debe definir una posición clara respecto de la forma y la profundidad en que estos conceptos impactan los diversos espacios de la Economía Digital.

Por ejemplo, no se menciona ni compromete una visión política y económica respecto al compromiso concreto que se realizará en la generación de incentivos específicos para la Innovación y la Investigación+Desarrollo en los temas TIC, como ejes específicos de desarrollo.

En el ámbito de la Innovación y la Investigación y Desarrollo, creemos fundamental profundizar estrategias de acción que contemplen alternativas de operación complementarias en tres frentes, basadas en:
  • Foco específico en la Innovación
  • Foco específico en la Investigación+Desarrollo
  • En un continuo de Innovación+Investigación+Desarrollo+Innovación
La estrategia chilena hasta el momento se ha centrado principalmente en este último modelo, buscando en los proyectos a financiar o fortalecer, componentes científicas que generen factores diferenciadores insertos en una oferta tecnológica. Creemos que esa visión es sesgada, no completa y no responde a dinámicas propias de la industria. Además de que su impacto real hasta el momento y siendo francos ... ha sido bastante bajo.

La propuesta que profundizaré en los próximos días, como miembro de las mesas de trabajo para la Estrategia Digital y siendo consenso ya en varios espacios colaborativos en los cuales participo, al menos en cuanto a la declaración, pretende profundizar los acentos específicos para cada ámbito, generando incluso modelos de competencia y colaboración entre sí, pero desde estas tres miradas en forma complementaria.

Por ejemplo, la innovación no tiene por qué estar exclusivamente basada en conocimiento científico desarrollado en Chile o basarse en nuevos resultados producto de la investigación. Y de igual forma, la Investigación+Desarrollo no debe orientarse exclusivamente a aquellos sectores en los cuales existan capacidades locales de innovación industrial o competencia internacional.

Todos los modelos pueden ser complementarios.

¿Y por qué esta separación? Muy simple.

Porque al separar los focos, deberán implementarse institucionalidades y proyectos diferentes, con objetivos diferentes, con actores diferentes, con instrumentos diferentes, con métricas de evaluación e impacto diferentes.

Ya es consenso a nivel nacional que los modelos de fomento al desarrollo de industria y procesos de fortalecimiento no han sido efectivos. No es accidental que en este momento, una porción mínima de los fondos para innovación disponibles (producto de los nuevos gravámenes al sector minero), estén siendo "poco ejecutados". Podremos decir que es consecuencia de una oferta pobre, por una demanda incompleta, con un proceso inadecuado. Da lo mismo. El impacto es ... mínimo.

Algo hay que hacer, con urgencia. Y eso pasa por un cambio de mirada.

Es tiempo de realmente "innovar en el proceso de innovación", y es en este documento de la Estrategia Digital, que define las políticas y los consensos públicos y privados, donde se debe reflejar. No basta con las definiciones específicas de un sector del aparato público. Deben ser consensos nacionales.

Esta introducción al tema la complementaré con una visión de "industria tecnológica", que indudablemente es uno de los principales actores de este proceso.

Chile como competidor internacional en ámbitos específicos de tecnología

Nos parece que el documento debe realizar algunas declaraciones reales y concretas, que reflejen un convencimiento de la capacidad de competencia mundial de Chile en el ámbito tecnológico.

Nuestra experiencia local indica que la Industria Tecnológica Local puede generar capacidades competitivas a escala internacional, más allá de exclusivamente fomentar una oferta de externalización de procesos de negocios (BPO) o servicios offshoring.

No estamos diciendo que las actuales estrategias estén equivocadas. Nuestra opinión es que no son suficientes y que las "pocas fichas" que tenemos, las apostemos bien.

Y un ejemplo muy práctico. El que Chile sea uno de los centros de desarrollo e investigación de Yahoo a nivel mundial, nos muestra que somos capaces de "crear conocimiento de alto valor empaquetado" en el ámbito TI, con una capacidad de competencia mundial en las primeras líneas de trabajo científico y tecnológico. Agradezco que ese grupo de ingenieros y científicos liderados por Ricardo Baeza, no hayan terminando desarrollando módulos administrativo-contables para empresas Top500 en sus ERP internos, aún cuando probablemente y en muchos casos, sus ingresos institucionales y personales serían mucho mayores si se dedicaran a eso.

Y esos son los ejemplos a buscar, profundizar, estimular. Pero pasa primero por un convencimiento real: de que "Chile SI puede".

Eso es indudablemente un compromiso con el futuro de nuestro país, siendo una apuesta riesgosa y que muchos están (estamos) dispuestos a asumir.

Más aún, las estrategias de desarrollo focalizadas en offshoring, basadas principalmente en "maquila" de servicios profesionales para crear una oferta internacional (indudablemente con recursos humanos de alta preparación y competencia), en la práctica no difiere en cuanto a la "forma del modelo de negocios", respecto de otras industrias cuyos modelos de crecimiento son lineales, sobre la base de la explotación de recursos naturales.

Los servicios de BPO u offshoring indexan modelos de ingreso lineal, basados en la capacidad de prestación de servicios en la medida de las capacidades y recursos humanos disponibles (más allá del posicionamiento propio que como país requerimos como actores en esta industria). A la larga, la única diferenciación o ventaja competitiva de largo plazo, con una industria mundial altamente flexible y que tiende a ser un commodity mundial (altamente especializado, pero un commodity al fin del día) será el precio. E incluso en ese ámbito, los estudios internacionales nos mencionan que tenemos una debilidad potencial en el largo plazo, en la medida que los ingresos per cápita nacionales sigan creciendo.

Pero una mirada estratégica global también debe incluir otros factores. Es consenso al interior de la industria de software chilena, que en el largo plazo, esa estrategia nos "empobrecerá intelectualmente", ya que por un simple tema económico, la industria local no podrá competir con la oferta laboral de servicios internacionales, hipotecando en el largo plazo el desarrollo de una industria tecnológica fuerte, cuya viabilidad se basa en un recurso escaso: las personas innovadoras, emprendedoras y altamente capacitadas.

Proponemos que en forma complementaria a la estrategia actualmente en curso, se diseñen estrategias e instrumentos que fomenten la creación de productos de conocimiento empaquetado, y que permitan insertar dichos conocimientos en cadenas de valor mundiales, con modelos de ingreso exponencial.

Y también, proponemos dejar de una vez por todas de ser "política y económicamente correctos", en un contexto internacional de competencia directa entre países en la industria del conocimiento.

Se requieren modelos de subsidio directo, como lo tienen otros países (incluso latinoamericanos y que hoy día nos dan "cancha, tiro y lado" en temas tecnológicos y de software, como por ejemplo Uruguay, Argentina y Costa Rica), y que subsidian directa y abiertamente la contratación de personal calificado en empresas locales que crean tecnología, que financian en 100% el desarrollo de nuevas empresas aunque sean "riesgosas y con experiencias de negocios no probadas", que crean espacios reales de incubación de ideas y empresas, a precios claramente subsidiados y que atraen incluso empresas extranjeras (por ejemplo, el parque tecnológico de Panamá con un valor mensual full equipado de US$ 17 por metro cuadrado es simplemente ... una ganga).

Y son países en los cuales sus Gobiernos están dispuestos a actuar realmente como "capital semilla" y "fondo de capital de riesgo" en su totalidad, no como una tímida declaración de "contraparte del 1+1 o el 1+2, en el mejor caso".

Es una realidad. Capital de riesgo privado en Chile no existe para el tema tecnológico. No tenemos la cultura, el tamaño, la experiencia. Y los que queremos crear "industria tecnológica", lo reconocemos hidalgamente ... no tenemos idea de cómo presentar un Business Plan a escala internacional para conseguir financiamientos internacionales ... y es verdad, nos interesa, pero tenemos que además estar vendiendo las entradas, acomodando los espectadores y haciendo malabarismo. No podemos.

OK. Lo dije. ¿So what? ¿Dejamos de tener capacidades reales de competencia mundial porque no sabemos, no queremos o no nos interesa llenar "los formularios y las planillas"? No. Muy por el contrario.

Por lo tanto, basta. No queremos que nos sigan tratando de enseñar a los tecnólogos como diablos hacer un Business Plan de calidad. Son otras nuestras competencias. Propongo armar un ejército de planilleros a los cuales podamos transmitirles una visión, una idea de negocios, un mercado y nosotros nos dedicamos a hacer productos, a atender a nuestros clientes, a "crear valor". Nosotros sabemos de tecnología, y mucho. Pero no nos sigan tratando de enseñar a llenar instrumentos en los cuales perdemos valioso tiempo y recursos de competencia internacional. Más aún. No financien más "evaluadores" para evaluar nuestras "deficientes planillas". Sigan pagando lo mismo para que "ellos" nos hagan las planillas. Y tengan por cierto que como país seremos más eficientes. Nosotros no gastaremos más plata en "contratar asesores de planillas" y el Gobierno "no gastará más plata en corregir y enseñarnos por qué las planillas están malas". Se acortan los plazos, el país gasta la mitad de los recursos, hacemos la pega de una sola vez y la hacemos bien. Y si finalmente, la planilla da en rojo ... "Game Over". Nos cambiamos de juego.

Por lo tanto, si creen que tenemos las competencias para crear una industria tecnológica nacional fuerte, la única opción pasa por el fomento real con una visión país para "crear" una nueva industria, no sólo "estimularla" y seguirla pasando por "la moledora de carne" de las evaluaciones. Varios empresarios tecnológicos me comentan que al postular a los fondos públicos, vuelven a a tener la misma sensación de estómago de nuestros exámenes de fin de semestre de Microeconomía en la Universidad.

En un contexto de competencia internacional, la innovación y la capacidad de competencia de nuestra incipiente industria tecnológica nacional es muy difícil de realizar, cuando los empresarios locales (y ejemplos sobran) deben competir en escala internacional con ofertas subsidiadas, respaldadas o incluso 100% garantizadas por sus gobiernos.

En cambio en Chile, con el modelo del "1+1", los recursos son escasos y además pasan por convencer a un aparato público que no está convencido de que "es posible".

Hoy día, con los modelos de subsidio directo a la industria del conocimiento que implementan muchos países (siendo una inversión mínima para los presupuestos nacionales), se desarrolla, se crea industria. Contra ellos competimos en escala internacional. Después del "impulso inicial", créannos que posteriormente los empresarios tecnológicos "haremos la pega". Y con creces.

Un ejemplo hipotético de análisis de escenarios, que al leer este documento muchos reconocerán como parte del día a día. Y teniendo como sustrato el mismo capital humano y conocimiento del equipo de Ricardo Baeza, chilenos con capacidades intelectuales, académicas y tecnológicas en un nivel similar.

Supongamos que Larry Page y Sergei Brin (los fundadores de Google) hubieran decidido desarrollar su emprendimiento en Chile: "Un nuevo buscador en Internet para el planeta". OK. Let's rock and roll.

Sobre la actual base del actual modelo de instrumentos, subsidios y "respaldo al desarrollo de la industria" (tema que muchos vemos con preocupación no sólo se "modifica" con las nuevas propuestas, sino que más aún, se "institucionaliza con mayor fuerza"), los escenarios que probablemente Page y Brin habrían enfrentado en Chile son:
  • No habría existido el "instrumento" adecuado al cual postular para financiar su proyecto ("Game Over").
  • No habrían tenido los recursos para contratar un consultor que les ayudara a "preparar los formularios" en forma adecuada, para el instrumento adecuado ("Game Over").
  • Habrían tenido que desarrollar sus propios "evaluaciones de mercado" y "diseño de Business Plan", haciéndolo en las noches y durante los fines de semana, con la esperanza de ganarse "un capital semilla de prospección", obteniendo los recursos 3 meses después de haber terminado el draft de Business Plan, para recuperar recursos que ya se gastaron y con una alta cuota de riesgo. Es un ejemplo interesante: para postular a la obtención de recursos para desarrollar el Business Plan Inicial, debes presentar como base un Business Plan inicial (Proceso que en otros espacios he llamado la "política recursiva de fomento").
  • Habrían fracasado por no tener las garantías necesarias para "asegurar" las contrapartes en caso de inversiones de montos mayores y alto riesgo ("Game Over").
  • Habrían tenido que conseguir el "respaldo institucional" de alguna institución universitaria o algún organismo intermedio, que con el correspondiente "peaje económico" y la obvia carga burocrática, para finalmente y después de al menos un año, lograr consensuar, presentar, negociar y acordar un proyecto "viable", con el respaldo "institucional" necesario, para la canalización y operación de los fondos. (Si no consiguen el respaldo, "Game Over")
  • Por un tema de "prioridades internas", el instrumento estaría "temporalmente en proceso de redefinición, por lo cual vuelva en 6 meses, pero por si acaso haga toda la pega y déjenos el formulario listo, para cuando la línea se abra de nuevo. Nosotros le avisamos" ("Game Over").
  • Algún evaluador o incluso el Comité de Aprobación habría dicho "no es una innovación efectiva, ya que el desarrollo de algoritmos de búsqueda y text retrieval están un dominio del conocimiento ampliamente desarrollado en el mundo TI, y además existen actores dominantes como AltaVista y Yahoo que ya dominan el mercado de buscadores, por lo cual no existe opción de crear espacios para nuevos competidores" ("Game Over").
  • Y si todas esas barreras Page y Brin, después de mucho esfuerzo y concentración en el "proceso" más que en su "emprendimiento" las hubieran franqueado, los fondos con suerte les habrían llegado ... después de un año (cuasi "Game Over").
¿Es ese un modelo real que permita la capacidad de innovación tecnológica y creación de industria en Chile? Claramente, no.

Por ello, hay conceptos de innovación y sus procesos asociados que en Chile no están consensuados, y aunque no guste lo que digo, los conceptos de Innovación, Investigación y Desarrollo que se manejan en la industria, no coinciden con las actuales definiciones públicas ni con los "tiempos" en los cuales se implementan.

Y por eso una pregunta "quemante". ¿Qué preferimos? ¿Destinar 20 Ingenieros de Software de primer nivel, que los tenemos en Chile, para prestar servicios de soporte especializado de plataformas Unix, donde el Revenue Per Employee anual que se puede obtener, en el mejor de los casos, es de US$ 140.000 por empleado, en un modelo de servicios offshoring, o bien destinar esos 20 Ingenieros a la creación de una empresa Top1000 mundial de software o tecnología, independiente de que sea innovadora desde un punto de vista científico o no, lo cual DA LO MISMO, pero donde el Revenue Per Employee promedio sea de US$ 300.000 por empleado y que dichos ingresos permanezcan en Chile, y no sean exclusivamente ingresos que pueda recuperar el país por la vía tributaria, además con condiciones preferenciales para la atracción de empresas extranjeras?

Insisto. No digo que las actuales sean estrategias equivocadas. Digo que son "insuficientes".

Desde un punto de vista estratégico y económico, creo que hay muchas visiones país que consensuar. Quienes estamos en la industria ... seguiremos porfiando.

Política Tecnológica

Por último, proponemos modificar el modelo de Areas de Trabajo, por un modelo de "Arquitectura de País IP".

Esta idea surge de un trabajo que hicimos con Pepe Flores en 1998 para el sector privado, diseñando un modelo de organización en el cual se identifican capas de servicio y áreas de trabajo, en un modelo colaborativo. El modelo no lo presentaré en este documento por extensión y será motivo de otro artículo que presentaré en los próximos días.

Pero como resumen ejecutivo, la idea es plantear un modelo (basado en capas de servicio y conceptos de protocolo), que permitan diseñar proyectos específicos pero relacionados con las diversas iniciativas, en un esquema matricial.

En dicho modelo, la idea es que se defina en cada capa:
  • Los objetivos y funciones de la capa.
  • Los actores en cada capa.
  • Los servicios que requiere de la capa inferior.
  • Los servicios que ofrece a las capas superiores.
Quienes tengan conceptos de arquitectura tecnológica, comprenderán rápidamente el modelo.

Es una propuesta arriesgada y ambiciosa, pero es simplemente una "proposición innovadora", que pretende definir como complemento a una "Estrategia Digital", una "Arquitectura Digital " de implementación.

Esta es una primera aproximación de análisis al documento planteado y que esperamos sean proposiciones que se incluyan en su forma final.

Es tiempo de seguir trabajando, diseñando, modelando, consensuando.

Pero seguimos convencidos ... vienen tiempos interesantes.

Saludos.

Cristian Ocaña - Marco Antonio Zúñiga

Leer artículo completo ...

El impacto del FLOSS en el concepto de "valor"

En los artículos previos de esta serie sobre FLOSS, he analizado las diferencias de licenciamiento y distribución entre el Free/Libre Open Source Software (FLOSS) y el software propietario, así como algunos ejemplos del impacto del FLOSS en la interoperabilidad y los estándares. También identificamos algunos modelos que dan origen a los proyectos y sus formas de financiamiento.

En este artículo analizaré algunos de los impactos comerciales que ha provocado el FLOSS en la industria del software y mi opinión sobre algunos cambios que provoca en ciertos ámbitos particulares.

El impacto en el concepto de "valor"


Tal como analizamos en el artículo anterior, el enfoque FLOSS (en forma independiente de las consideraciones filosóficas) tiende a asegurar la interoperabilidad, permitiendo la interconexión entre sistemas disímiles, mediante protocolos abiertos y definidos por la Comunidad. Eso en sí, indudablemente es un gran beneficio desde un punto de vista técnico.

Pero otro impacto del FLOSS, tan "visible" e importante como el anterior, es la modificación del concepto de "valor" de las diversas aplicaciones de software. Y aquí no estoy hablando de precio, sino de qué tan importante para el usuario es una aplicación.

Esta distinción es crítica, ya que el "valor" incidirá en otro aspecto fundamental para el desarrollo de la industria del software: cuánto está dispuesto a pagar el usuario por ese valor.

La continua destrucción del valor agregado
(O cómo los clientes cada vez exigen más)

Una característica del mundo tecnológico y en particular en la industria del software, es la continua modificación del concepto de "valor", en forma mucho más profunda que la evolución del "valor agregado" aplicado en otras industrias.

Un ejemplo básico es cuando junto con un pack de latas de bebida de Coca Cola y como forma de promoción, se incorpora como "valor agregado", un vaso con la imagen conmemorativa del último mundial de fútbol. En ciertos casos será un regalo, y en otros el cliente estará dispuesto a pagar un pequeño sobreprecio. Pero el hecho es que dicho "valor agregado" temporal, no modifica la esencia del "producto": La Coca Cola per se sigue siendo un producto de buena calidad. Y para el cliente, el "valor" de la Coca Cola seguirá siendo alto, en forma independiente de cuantos vasos, chapitas u otros promocionales se incorporen para aumentar la fidelidad.

Pero en el caso de la tecnología y particularmente el software, es muy distinto.

Por ejemplo, el "control remoto" de un televisor era un elemento de "alto valor", incorporado como una gran innovación a un televisor tradicional. El "cliente/consumidor" reconocía en esta nueva funcionalidad un gran avance, y estaba dispuesto a pagar "mucho" para tener la opción del control remoto, en los televisores que lo incorporaban inicialmente.

Pero en un mercado con múltiples competidores y consecuencia del continuo desarrollo tecnológico, el "control remoto" pasó a ser un elemento inherente al "producto televisor", pasando a formar parte de la "oferta básica". El "valor" de dicha funcionalidad dejó de ser un diferenciador. Un televisor que hoy no incorpore un "control remoto" como parte de sus prestaciones básicas es un mal producto, y al perder dicha capacidad diferenciadora su "valor", indudablemente el cliente no estará dispuesto a pagar por eso.

En el caso de la industria financiera, a mediados de la década del '90, un cliente estaba dispuesto a "pagar más" en un banco que ofreciera sistemas de consulta remota por vía telefónica o vía Internet. Hoy, un banco que no ofrezca dichos servicios, simplemente no tiene opción de competir. Ni tampoco puede cobrar por ellos.

Por ello, las ventajas competitivas generadas en cualquier industria sobre la base de "desarrollos tecnológicos", son temporales y empatables, con el tiempo suficiente y los recursos adecuados.

Y en el mediano plazo, esas ventajas competitivas tienden a ser un "commodity", es decir, dejan de generar un factor diferenciador de "valor", desde el punto de vista del cliente.

Un producto que cae a la categoría de "commodity" es la pesadilla de un Gerente de Marketing. Y por ello, en particular en la industria tecnológica y de servicios, los responsables de la estrategia de diseño de productos, viven con las zapatillas de correr puestas, tratando de liderar los procesos de "destrucción de valor" en forma continua.

Como último antecedente, es relevante considerar que al existir múltiples ofertas que responden al mismo "valor" para el cliente, siendo algunas de esas opciones de "precio cero" (ahora sí que podemos decir "gratis"), por un razonamiento y un comportamiento económico "racional", la demanda optará por las soluciones "gratuitas" (siempre y cuando respondan al mismo nivel de exigencias que requiere el "negocio" del cliente).

El FLOSS sin lugar a dudas ha modificado los parámetros tradicionales sobre los cuales se ha creado la industria de software. La inmensa oferta de aplicaciones basadas en la colaboración y el enfoque FLOSS, con millones de programadores distribuidos en el planeta colaborando en la construcción de "commodities" de software, ha hecho que la industria de los "constructores de productos propietarios" se vea afectada.

Pero no en forma total. Y solamente en algunos nichos específicos.

Es en esas áreas donde focalizaré ahora mi análisis.

Cuando lo que antes era de "alto valor" se transforma en un commodity

Muchas aplicaciones que en los "antiguos tiempos" eran de "alto valor" para un cliente (por ejemplo, un editor de texto, un compilador, una calculadora o una base de datos sencilla), con el paso del tiempo y con una gran base de "conocimiento empaquetado de libre disposición", han ido perdiendo su valor.

De una u otra forma, las "prestaciones básicas" de software (y por las cuales antes se podía "cobrar bien") se han transformado gradualmente en un "commodity" y con múltiples alternativas para elegir.

Pero ese fenómeno no es exclusivo por causa del FLOSS.

Mi opinión es que la "commoditización" surge en primer lugar producto de la alta competencia de la propia industria tecnológica.

La natural competencia entre los proveedores de plataformas básicas, las cuales fueron incorporando diversas herramientas como parte de la oferta básica y sin exigir al cliente que tuviera que "pagar adicionalmente" por ello, genera en forma continua productos más complejos, modificando la esencia de la oferta inicial, haciendo que los antiguos diferenciadores pasen a formar parte esencial de los nuevos productos.

Por ejemplo, la aparición del Macintosh a mediados de los '80 (y previamente Lisa), nos sorprendió a muchos, ya que Apple incorporaba como parte del suite básico del sistema operativo MacOS, una serie de herramientas que históricamente en otras plataformas, eran productos "caros" y (en esos tiempos) de "alto valor".

Por ejemplo, aplicaciones de diseño gráfico como MacPaint y procesadores de texto como MacWrite, incluidas como parte del suite de herramientas básicas con MacOS y el Macintosh, ofrecían prestaciones básicas de diseño, formateo e impresión muy avanzadas para ese tiempo, como parte del bundle del equipo. Esas prestaciones eran más que suficientes para resolver las necesidades del mercado SOHO (Small Office, Home Office), iniciando la revolución del "desktop publishing". A través de la plataforma básica del Macintosh, cualquier usuario podía hacer una carta simple o diseñar una invitación de cumpleaños.

La respuesta del proveedor dominante de sistemas operativos de escritorio, en ese momento Microsoft, no se dejó esperar. Y la versión inicial de Windows incorporó una serie de prestaciones mínimas para "tratar de empatar" esa oferta básica, sin llegar a incorporar las funcionalidades de los suites de ofimática de avanzada, pero ya marcaba el inicio de la "commoditización" de los productos de ofimática, tema que analizaremos en detalle más adelante en este artículo.

FLOSS en la infraestructura básica

Hoy día vivimos un fenómeno similar al que ocurrió en los viejos tiempos del '80, como explicamos en el artículo anterior, cuando los dominantes de la industria del hardware y el software de sistemas "rechazaban" esta amenaza llamada TCP/IP (porque en el mediano plazo les hacía perder sus "ventajas comparativas" obtenidas gracias al lock-in tecnológico).

Lo mismo ocurre hoy con la industria del software de aplicaciones, en aquellos ámbitos donde la aparición del FLOSS "transforma" productos que antiguamente eran de "alto valor agregado" en commodities. Y en muchos casos, gratuitos.

Hay ejemplos claros de este proceso de competencia creciente entre productos propietarios y soluciones FLOSS, en el ámbito de la "infraestructura".

Por ejemplo, Linux y Apache (o en general lo que se conoce como el stack LAMP) aumentan gradualmente su participación de mercado para el desarrollo e implementación de soluciones WEB, en reemplazo de otras "arquitecturas propietarias". ¿Hasta dónde? No lo podemos predecir, porque depende de muchos otros factores adicionales, como por ejemplo, la estabilización de las participaciones de mercado a nivel de sistemas operativos, la disponibilidad de recursos humanos calificados, consideraciones políticas, disponibilidad de aplicaciones especializadas, etc.

Hasta ahí, todo iba más o menos bien, estando hasta hace un par de años la competencia en la infraestructura básica, restringida a los proveedores de hardware y de sistemas operativos.

Pero una situación que era fácil de predecir y tarde o temprano iba a llegar, es la creciente oferta FLOSS que empieza a "invadir" el mundo de las "aplicaciones de usuario final", donde hay mucho dinero en juego y de muchos actores relevantes.

Y eso provoca otro impacto importante en la industria, particularmente en el segmento de la ofimática, que en mi opinión es otro segmento de commoditización creciente.

FLOSS en las aplicaciones de usuario final

La creciente penetración (con una notable y sorprendente evolución) de soluciones de ofimática como OpenOffice, ha provocado que en este tiempo, empresas como IBM liberen en forma gratuita su plataforma de ofimática Lotus Symphony, con la esperanza de obtener "valor" por la vía de otros productos complementarios o servicios por los cuales cobrar.

Por otro lado, Microsoft ha impulsado en forma fallida su formato propietario OOXML hacia un estándar internacional, con el claro fin de proteger su plataforma de productos Office, que representa un importante segmento de sus ingresos.

Personalmente, y a diferencia de algunos analistas, no creo que la reacción de IBM sea una estrategia "contra" Microsoft.

Simplemente, creo que es una continuidad de la estrategia de BigBlue para acercarse al mundo FLOSS y moverse junto con las tendencias de la industria, generando alianzas temporales para privilegiar y defender sus soluciones de hardware, sus servicios de consultoría y sus aplicaciones propietarias de "alto valor agregado" ... y de "alto precio".

IBM, a pesar de la constante sátira que se hace, no es un dinosaurio decadente. En absoluto.

Personalmente pienso que IBM es una empresa muy inteligente en la definición de sus estrategias de largo plazo y que la mantiene como un actor relevante y vigente, a pesar de todos los vaivenes de la industria, que ven aparecer y desaparecer actores en forma continua.

IBM es un enorme elefante astuto, pero que se mueve ágilmente en patines y si es necesario aprende a subirse a un skate, que reconoce tendencias irrevocables, algunas veces con mucha anticipación y otras en la cúspide de un fracaso rotundo. A su pesar, enterró en algún momento OS/2 con todo el costo económico y de imagen asociado, reconociendo la tendencia en el desktop con un actor dominante como Microsoft. Enterró su modelo de red SNA abrazando la causa de TCP/IP. Y desechó sus arquitecturas de microcanal moviendo sus arquitecturas hacia ISA. Y así, podríamos continuar. IBM es un ejemplo de adaptación en los modelos competitivos de "destrucción de valor", moviéndose a segmentos más altos en la cadena de "valor", adaptándose a las tendencias y estándares naturales de la industria, a pesar de asumir altos costos.

Y se adapta a las tendencias irrevocables que tarde o temprano llegarán, pero con una ventaja fundamental ... aprende de sus errores y sale fortalecido.

Al igual que como TCP/IP y las plataformas LAMP, las soluciones FLOSS de ofimática (en mi opinión en un horizonte máximo de 3 años), terminarán siendo commodities integrados o disponibles como parte de los sistemas operativos subyacentes.

Y no me extrañaría que en algunos años, IBM decida seguir declinando en algunos casos o liberando soluciones propietarias en otros, en la medida que las tendencias de la industria las definan como un commodity, manteniendo su posición dominante en los segmentos de "alto valor" de la industria ... y por consecuencia, de los bolsillos de los clientes.

Así como el básico editor de archivos de texto y una calculadora fueron "integradas" como parte de las componentes mínimas en cualquier sistema operativo de usuario, sobre la base de aplicaciones portables, las plataformas de ofimática formarán parte del "paquete estándar", ya sea en un notebook, un PDA o un computador de escritorio, más temprano que tarde.

Necesidades comunitarias

Había terminado de redactar este artículo, pero no me habría quedado tranquilo sin dejar de identificar otro escenario en el cual el FLOSS genera también modificaciones a la industria del software. Y es en aquellos escenarios donde se pueden identificar modelos en los cuales la competencia y la colaboración coexisten, fusionados en el neologismo de la "coopetición". En dicho caso, los modelos FLOSS pueden surgir como una consecuencia natural de la "agregación de demanda" de una industria específica.

Un ejemplo es el anuncio hace un tiempo de un proyecto colaborativo en la industria automovilística japonesa, quienes crearon la Japan Automotive Software Platform Architecture (JasPar), con el fin de definir una única arquitectura de software para el control interno de los vehículos, y que sea común a diversos fabricantes de autos de Japón.

No sé si el modelo final será Open Source o no. Y la apertura podría generar impactos importantes y oportunidades interesantes para incluso nosotros como desarrolladores de tecnología en Latinoamérica.

Pero el razonamiento detrás de esta iniciativa es bastante simple. No es un problema filosófico ni político. Es simplemente una muy adecuada decisión estratégica de negocios.

Al momento de la redacción de este artículo, las compañías que forman este consorcio son Toyota, Nissan, Honda y Denso. Estas compañías llegaron a la conclusión de que "competir" en el sistema operativo básico y la interacción de componentes internas en un vehículo no es un modelo eficiente. La competencia entre dichas compañías estará dada por el precio, las prestaciones en la cabina, la cadena de dealers, los servicios de pre y post venta, el "luxury" y la imagen, etc.

Los modelos de programación dinámica que definen el nivel de carburante y control de inyectores, son modelos físicoquímicos públicos y que mal que mal, son de amplio conocimiento y pueden ser configurados caso a caso, por lo cual para las plataformas de software básico, no hay "valor agregado" en que cada compañía diseñe, construya, mantenga y soporte arquitecturas propietarias de software básico para la inyección de carburantes. Y así, suma y sigue.

Por lo tanto, es mucho más eficiente definir un proyecto colaborativo, que asegure un uso eficiente de los recursos, seguridad y estabilidad. Y principalmente, un modelo de interoperabilidad, que integre a todos los proveedores de partes y piezas de la industria, en una cadena de valor integrada y que permita una alta flexibilidad en la oferta. Este modelo de negocios está claramente descrito en la estrategia global del proyecto, en competencia al modelo estadounidense y europeo, que optan por la competencia e integración vertical, a partir de una oferta quizás más robusta pero menos flexible.

Así como el caso de JasPar, podemos encontrar múltiples otros ejemplos y en diversas industrias y dominios del conocimiento, en los cuales es posible diseñar modelos tecnológicos de coopetición, que permitan el desarrollo de plataformas tecnológicas colaborativas, manteniendo el "valor agregado" como parte de la diferenciación de cada actor.

Este modelo en particular, fue enunciado por Verónica Achá (querida amiga y otra SushiKnight ;-), representante de Innova-Corfo en la mesa FLOSS del Ministerio de Economía hace un par de semanas.

Verónica planteó una iniciativa incipiente para generar oportunidades de desarrollo tecnológico en industrias productivas en Chile, aplicando modelos FLOSS para las plataformas tecnológicas base, permitiendo modelos de competencia en las aplicaciones de "alto valor" generadas por la industria. Este modelo muchos lo consideramos muy interesante, ya que toma lo "mejor de los mundos", aportando capacidades de competencia internacional para la industria tecnológica y de software nacional, y capacidades competitivas importantes para segmentos productivos de nuestro país.

En términos más simples, un modelo tipo JasPar (el de los fabricantes de automóviles japoneses) pero aplicado a la industria del salmón, el vino, la minería, etc.

¿Y qué queda para los que vivimos en esta industria?

Finalmente, en este escenario de tendencias dado por la continua "destrucción de valor" y "commoditización" permanente del software ... ¿qué queda en el largo plazo para los que vivimos de esta industria?

¿Deberemos transformarnos en lemmings suicidas para asegurar la supervivencia de algunos pocos afortunados que logren vivir a partir de servicios altamente especializados, o peor aún, dejar de trabajar en los temas que nos apasionan y dedicarnos a la agricultura básica o la alfarería?

No creo que sea así. Muy por el contrario. Y tampoco es necesario presentar un bonito Curriculum Vitae en el sitio WEB de IBM y posteriormente comprarse un par de trajes, lindas camisas blancas y sobrias corbatas. :-)

En el próximo artículo de esta serie, discutiré el por qué en mi opinión los modelos de desarrollo de software futuro, serán un permanente complemento entre soluciones FLOSS para los "commodities" de aplicación, soluciones propietarias para "requerimientos específicos de negocio" y plataformas de "servicio" basadas en estándares de interoperabilidad.

Por ahora, para mis colegas de la industria de software (y sólo para mantener el suspenso) hay "buenas noticias", pero deberán esperar algunos días hasta el próximo artículo. :-)

Stay tuned!

Leer artículo completo ...

domingo, 14 de octubre de 2007

Marketing y Usabilidad aplicados a mi Blog

¡¡¡ Tenemos nuevo dominio !!!

Mis lectores habituales verán en la barra del browser que el antiguo "muchomaz.blogspot.com" se transformó en un flamante ¡¡¡Cha Chaaaan!!!: "blog.maz.cl". En términos técnicos, el cambio fue relativamente simple, pero tendrá varios efectos y resultados que espero sean positivos.

Aprovecharé para analizar algunos aspectos de marketing y usabilidad en la Web, a partir de mi propia experiencia como "prestador de servicios de contenido", siendo fiel a mis recomendaciones para diseñar e implementar una idea de negocio tecnológico: tener una visión y escuchar a los "clientes".

Ya había enunciado el modelo de negocios de mi blog (el cual hasta el momento según mis expectativas ha sido exitoso), pasando de un tímido emprendimiento a una cosa ya bastante más armada. Así que veremos ahora la táctica de implementación de la estrategia y lo que he aprendido en el camino.

También debo reconocer un punto ... me he puesto "fashion" para mi presencia en la "blogocosa", a pesar de ser un amateur de la Web 2.0. Y si eres usuario de Blogger, este artículo te puede servir para aprender un par de trucos nuevos.

Estaremos en modo "Beta" por un tiempo. Pero es un cambio de identidad con continuidad operacional 100%, criterio fundamental para que el negocio "camine". Incluso, si ingresan la antigua dirección, el browser porfiadamente te llevará al nuevo dominio (Magia! Je Je Je). Y si encuentran algo que no funcione o tienen algún comentario, como siempre es muy bienvenido y desde ya se los agradezco.

Por fin el nombre indica lo que este espacio pretende ser: "El Blog de Maz" :-)

Aquí va la historia.

El inicio

Partí con este blog en Julio del año pasado, pensando en dejar por escrito y en forma relativamente ordenada ideas desperdigados por múltiples lados, siendo para mí, un repositorio de artículos más que una bitácora personal.

Esa definición es importante desde el punto de vista de "marketing", porque define las expectativas y una línea editorial, analizando conceptos que caigan en el ámbito de la "E-Arquitectura" (según la definición en el header de mi blog).

Todas mis otras divagaciones sobre temas más disímiles, las comparto en forma colaborativa en otro espacio como miembro de SushiKnights.

El primer cambio: de Blogger a New Blogger

El primer cambio importante fue tecnológico. En Enero del 2007 decidí migrar a la nueva versión de Blogger después de 6 meses de estar "en el aire" con la antigua versión. En el viejo esquema con macrovariables, era poca la lógica que podía incorporar a las plantillas. Y además, Blogger me "recomendaba encarecidamente" cambiar a la nueva versión.

El cambio tampoco fue tan difícil (era poco el contenido y mis conocimientos de CSS/XML/HTML eran bastante más básicos), por lo cual me demoré más en entender el nuevo esquema que en hacer la migración.

Siendo un programador viejo, si tu proveedor de plataforma "te recomienda en forma continua e imperiosa" un upgrade a la nueva versión, en la medida que yo fuera aprendiendo más, sabía que tarde o temprano tendría que moverme a la "nueva plataforma".

BloggerA todo esto ... ¿por qué Blogger? Porque era lo que conocía cuando partí y fácilmente me permitía entrar a la Web 2.0. Tuve suerte, porque creo que al final fue una muy buena decisión (aunque poco informada).

Pero el cambio de Enero fue bueno, porque sirvió para ponerme al día en algunos estándares de la Web y aprovechar de sacar un poco de óxido de los dedos, después de varios años sin programar (labor que añoro con nostalgia :-(

Haciendo tunning a mi blog

De a poco fui incorporando varios widgets: algunos propios de Blogger, technorati, contadores, analytics, feedburner, adsense y varios otros artefactos que han entrado y salido del blog.

Por una de esas extrañas coincidencias que ocurren en la vida, gané una suma no despreciable de dinero en poco tiempo con AdSense, cosa que me motivó intensamente, pero fue una "golondrina de invierno" (por si acaso, si no has incorporado AdSense en tu sitio, contarás con mi eterna gratitud si pinchas el botón en la barra lateral y te inscribes :-)

Mientras tanto, los artículos seguían apareciendo, agregaba detalles, implementé la nube de tags y la opción de "Leer Más" para los artículos.

Hasta que ocurrieron dos "eventos" importantes en Septiembre.

La primera catástrofe: Perdimos todo

A principios de Septiembre del 2007 tuve un "accidente" (elegante justificación para una torpeza mayúscula que cometí) que me obligó a reconstruir totalmente la plantilla del blog.

Después de un par de días de trabajo intenso, logré reconstruir el "look & feel" previo de mi blog, cosa que fue más fácil, porque ya estaba más "experimentado" con Blogger y sus "trucos".


Así que aproveché de incorporar algunos nuevos "features" al template y quedé bastante satisfecho, aún cuando en la práctica "se veía igual que antes".

La segunda catástrofe: Es bueno pero "feíto"

A los tres días de la "resurrección" del blog, vino la siguiente catástrofe: un comentario de mi amigo Chubasco, que en resumen decía "es bueno el contenido, pero con un diseño gráfico de parvularios" (en realidad, el comentario que publicó fue muy generoso y lo que Mauricio me dijo en privado fue incluso más gentil, pero el mensaje final era bastante claro :-)

Reconozco que me "piqué" y el comentario caló hondo, especialmente después de todo lo que había trabajado los días previos. Pero en el fondo, lo que Mauricio me decía era una gran verdad (Gracias!), claro que sin llegar al extremo de McLuhan, en cuanto a definir que "el medio es el mensaje".

Mauricio tenía mucha razón. Pero tampoco es necesario tener un template gráfico de primer nivel (como el que tienen otros blogs, de personas dedicadas profesionalmente al tema u otros que han pagado buena plata para que se los diseñen). Me interesa que lleguen clientes por el "contenido", no por el "envase". (Típica declaración de hombre en los "early forties" :-)

El punto es que si en el contenido invierto bastante tiempo para generar material de divulgación tecnológica de calidad y que sirva a otros, debería también invertir tiempo en que la presentación sea de mejor calidad.

Podría hablar con varios diseñadores amigos para que me ayudaran. Pero considero que decir "Hazme un favor ... ayúdame con el diseño de mi blog" es lo mismo que si alguien viniera y me dijera "Hazme un favor ... diséñame una estrategia de e-business para mi compañía". Hay una distancia importante entre un "favor" y ... ustedes entienden.

No estoy dispuesto a invertir dinero en mi Blog, mientras estén los recursos disponibles en la Red o pueda hacerlo yo, además de que me divierto muchísimo y aprendo bastante, lo cual indudablemente para mí es bueno.

El nuevo template

Así que durante Septiembre busqué ejemplos de templates en muchas partes, dado que el diseño gráfico y la estética no son mi fuerte, y tampoco sé lo suficiente como para crear una buena plantilla desde cero.

Si bien la "oferta" de templates gratuitos para Blogger es bastante amplia (gracias a múltiples y generosos diseñadores y programadores repartidos por todo el planeta) no fue una búsqueda fácil, ya que deseaba algo que cumpliera con varias exigencias:

  • que fuera de 3 columnas
  • que permitiera resizing de ancho y se adaptara al tamaño de la ventana del usuario, manteniendo una cierta armonía mínima (ya explicaré por qué)
  • que se desplegara correctamente por lo menos en Firefox, Explorer y Opera
  • que además fuera relativamente bonito, pero sin mucha recarga gráfica
El segundo punto sobre el resizing, lo considero muy importante para un blog de artículos, aprendido de Jakob Nielsen.

Cuando el template es de "dimensiones fijas", para los posts largos (como mis artículos) se provocan dos efectos indeseables, que incluso empeora cuando son templates de dos columnas:
  • para los lectores con alta resolución en el ancho (1024 o más), el blog se ve como una "larga y angosta franja" centrada, ocupando en muchos casos sólo la mitad del espacio útil de la pantalla (o sea, como Chile: largo y flaco pero rodeado de mucho mar y montañas)



  • para los lectores de baja resolución (800x600, un 20% de mis lectores), para leer correctamente deben dejar un área visual grande fuera de la pantalla o peor aún, ir haciendo scrolling horizontal en forma continua para poder leer.

Por lo tanto, mi blog debía incorporar resizing de columnas, por una razón muy simple: es un blog de artículos y por lo tanto debo facilitar la lectura a mis "clientes", en forma adecuada para "su" dispositivo, no como a mí me guste.



Después de mucho buscar, finalmente me decidí por el template actual, que tiene varias características "bonitas" desde el punto de vista gráfico y que funcionalmente cumple con las cosas básicas que requiero (en todo caso, a quienes tengan más de 1024 pixeles de ancho, al template le incorporé dimensiones máximas para que no perdiera armonía y tampoco sean "largas líneas kilométricas" que cansan al lector).

Hice varias modificaciones estructurales internas, para definir "proporciones relativas" en reemplazo de "medidas absolutas", uno que otro tag CSS adicional para los casos extremos, algunos condicionales en el XML, nuevos widgets y Voilá! ... tenemos la cara actual.

No es precioso, pero sí bonito y "funcional al objetivo de negocios"


Todo marchaba sobre ruedas.

Mi nuevo Blog me tenía satisfecho. Tengo un buen ranking en Google para los conceptos que me interesan y recibo muchos visitantes que se quedan un buen rato leyendo mi blog, y muchas visitas de "fieles" lectores recurrentes. Con el cambio de template, aumentó el promedio de páginas leídas en una visita y el tiempo de permanencia en mi sitio.

¿Y cómo ayuda al negocio?

Y tal como había definido en el modelo de negocios para mi blog midiendo el PxQxT, se mantiene la tasa de crecimiento del Q (cantidad de visitantes y pageviews). Pero con el cambio, mejoró notablemente el P (el "precio" que los lectores pagan, medido por promedio de páginas visitadas y tiempo de la visita) y el T (la recurrencia, o sea, mejoró la fidelidad).

En definitiva, fue una muy buena inversión. Mauricio tenía mucha razón. El cambio fue bueno.

Y me quedé tranquilo ... hasta hace unos días.

Bueno y bonito tu Blog, pero es ... de newbie

Lo que ocurrió hace una semana fue una crisis mayor y que no había "leído" bien, a pesar de haber recibido algunos comentarios de algunos "clientes" en el tiempo.

El PxQxT iba bien (factor fundamental para medir el éxito de mi negocio) pero había descuidado un factor fundamental: la imagen de marca.

Y como broche de oro, hace un par de días, un comentario de un importante blogger nacional fue lapidario: "¿Y por qué no usas WordPress? Es lo que "se usa" y es bien visto. Blogger es demasiado básico. Además te permite tener tu dominio personal y no andar arrastrando un dominio para newbies como blogspot".

Ugh! Eso sí que fue un golpe duro. Y lo peor ... no tenía respuesta.

En realidad, lo de usar Blogger como tecnología me da lo mismo, porque es una plataforma bastante potente, si uno aprende a sacarle el jugo y al fin del día la tecnología básica es una ventaja competitiva, pero no fundamental. Pero el tema del dominio personal era importante.

Hay un tema de identidad y el "muchomaz" nunca me gustó mucho (era el nick que logré encontrar en Blogger y al principio no le di mucha importancia, pero con el tiempo, como ya me había lanzado, tenía que continuar).

El tema además era muy complicado desde el punto de vista técnico, porque ya había generado "identidad en la Red" a través de múltiples vínculos. El dominio de mi blog está en muchas partes, incluyendo el pie de firma de mis correos, y además hay muchos vínculos directos hacia mis artículos.

Un cambio absoluto habría significado perder, entre otras muchas cosas, el posicionamiento en los buscadores. Y un factor no menor, perder toda la inversión realizada en Blogger y su plataforma era una pérdida importante (estoy capturado por un lock-in tecnológico).

Una solución parcial, pero de muy bajo impacto, habría sido moverme a otro dominio, colocando en las páginas de "muchomaz.blogspot.com" un JavaScript de redirección, con un mensaje avisando la dirección de la "nueva casa". Pero eso era una solución demasiado parcial y que para muchos "clientes", especialmente los "nuevos", habría sido una gran molestia.

Pero el problema más importante continuaba siendo quedar "desconectado" de múltiples índices automáticos y las referencias directas. Eso significaba comenzar casi desde cero la generación de identidad en la red.

Y ahí estaba yo, dándole vueltas al tema, tratando de tomar una decisión que no quería tomar, pero necesaria para asegurar la viabilidad de largo plazo de mi "negocio".

Incluso, abrí una cuenta en Wordpress, pero con los años uno se pone mañoso y por mucho que uno lo diga y lo enseñe, el cuerpo se resiste a los cambios radicales.

Y entre tanta "duda existencial digital", recordé algo interesante.

Hay que aprender de los que saben

Un blog que leo en forma permanente es usando.info de Juan Carlos Camus, uno de los buenos Arquitectos de la Información en Chile. Hace un tiempo me llamó la atención un botón "I power Blogger" en su sitio, pero no le di mucha importancia.

Hasta que lo recordé hace un par de días.

Y entonces dije ... ¿Cómo? ¿Un sitio tan bueno como el de Juan Carlos, que es una persona que sabe mucho de estos temas y con un dominio totalmente personalizado, pero alojado en Blogger?

Había que investigar. Y vi la luz.

La solución: el DNS

Blogger tiene un feature utilizado por pocas personas, mediante el cual uno puede definir en forma externa un registro tipo CNAME en el DNS propio, apuntándolo hacia un servidor de nombres de Google (ghs.google.com).

Con ese servicio, uno puede dejar la lógica completa alojada en un servidor externo y el repositorio de datos en Blogger (como lo hace Juan Carlos), o bien, en forma mucho más simple (como ahora lo hago yo) asociar ese nuevo nombre de dominio con el "nombre propio" en Blogger.

En términos sencillos, mi nuevo registro "blog.maz.cl" lo hice equivalente al viejo y querido "muchomaz.blogspot.com", con un par de operaciones simples.

Pero lo más interesante es que Blogger (a través de la magia del DNS), hace automáticamente toda la traducción, siendo además el nuevo dominio el dominante (que utilizarán por default todas las URLs). Pero con una ventaja fundamental: todo lo anterior, continúa funcionando y en forma transparente.

Es una mejora notable a un requerimiento fundamental del negocio, con un 100% de continuidad operacional. El sueño de todo marquitecto.

Desde un punto de vista técnico, significó un par de modificaciones en las tablas de DNS de mi dominio personal (maz.cl) para incorporar los nuevos registros, un cambio de configuración en mi cuenta blogger y ... voilá! Todo funcionó impecable y a la primera.

Puedo seguir haciendo todo lo que hacía antes, pero con una "imagen de marca" que deja de ser newbie y aprovechando el 100% de toda mi "inversión". Y si la plataforma es Blogger o cualquier otra, da lo mismo. Ahora es un dominio bajo "maz.cl" (o sea, yo. :-)

Y ahora ... ¿terminamos?

Así que ahora puedo dedicarme a seguir escribiendo nuevos artículos (o sea, continuar aumentando el PxQxT con una imagen de marca definitiva), sin preocuparme de la plataforma base y claro, cambiar de vez en cuando la gráfica y algunas terminaciones menores. Pero basta de jugar con la tecnología.

Claro que .... mmhhh.

Escribiendo este post recuerdo un comentario de un "cliente" que me dijo el otro día: "Oye Maz .. tus artículos son buenos pero no siempre tengo tiempo para leerlos, así que prefiero imprimirlos para cuando tengo tiempo. ¿Pero sabes? Se imprimen con gráficos y las columnas laterales molestan". MMmmhh ... interesante problema. Mi blog, pero "offline". Me gustó.

Y partimos de nuevo. Si los clientes lo piden, habrá que hacerlo. Claro que eso será para divertirme ... mal que mal, ya se me ocurrió el cómo: si juego un poco con la API de Blogger para la interfaz de query de los RSS, una pequeña aplicación JavaScript y un programa chico en un host externo para sacar el contenido y ... en fin. Ya partimos de nuevo.

De a poco y gracias a mi blog, estoy volviendo a ser lo que realmente me gusta: ser un programador. :-)

Stay tuned!

Leer artículo completo ...

miércoles, 10 de octubre de 2007

El aporte del FLOSS a la interoperabilidad y por qué surge

En el artículo anterior presentamos una breve introducción a las diferencias de licenciamiento y distribución entre el Free/Libre Open Source Software (FLOSS) y el software propietario.

En este artículo, analizaremos la relación del FLOSS con algunos temas que están en la discusión mundial y particularmente en Chile, en el contexto de la Estrategia Digital 2.0: la Interoperabilidad y los Estándares.

También presentaremos algunos ejemplos de cómo han surgido algunas comunidades de desarrollo para proyectos FLOSS, indicando las diferencias respecto de su "financiamiento".

Partamos con un poco de "pre-historia", contada por un viejo dinosaurio tratando de sobrevivir en un universo dominado por los mamíferos tecnológicos. :-)

Una breve (y antigua) historia para ejemplificar

Partí mi relación personal con la tecnología en los inicios de la década del '80 del siglo XX (Uf! qué viejo estoy :-) y conocí un mundo basado en tecnologías totalmente propietarias.

El mundo se dividía entre los que utilizaban Burroughs, IBM, DEC o algún otro proveedor tecnológico, y la decisión de "con quién casarse" era muy compleja. Eran matrimonios indisolubles, donde la selección de un proveedor tecnológico significaba "todo": Protocolos de comunicaciones, hardware, terminales, bases de datos, aplicaciones, software, capacitación, procedimientos. Todo. Cuentas totalmente "cautivas". Lo que hoy se llama "lock-in tecnológico".

Quienes partimos con un microcomputador personal en el hogar en los '80, teníamos (y mantenemos hasta el día de hoy :-) diferencias irreconciliables sobre cuál micro era mejor: Atari, Sinclair, Commodore, etc. Compartir juegos entre microcomputadores de diversos fabricantes era imposible, y jugar en red en tiempo real entre plataformas diversas, ni siquiera lo imaginábamos posible.

El hecho es que ... nadie conversaba con nadie.

En la Escuela de Ingeniería de la Universidad de Chile, transferir un simple archivo de texto entre el mainframe IBM y nuestro sobrecargado equipo Tower con Unix, era un proceso heróico, que con suerte completábamos después de días de trabajo, coordinaciones y favores personales.

Y gradualmente, la llegada de TCP/IP (un protocolo abierto de interconexión entre sistemas, sigla hoy conocida por todo el planeta), permitió un gran avance: la Interoperabilidad.

Un "simple" protocolo abierto, público y conocido, construido por la comunidad y que todos los proveedores tecnológicos se vieron obligados a implementar (muchas a veces a regañadientes), permitió el sueño dorado: e-mail, FTP, Telnet, gopher, archie, aplicaciones disponibles en las más diversas plataformas y que permitían la "conversación" entre sistemas muy disímiles. Comunicación inmediata entre las "distantes galaxias informáticas".

Y la caja de Pandora con secretos exclusivamente reservados para los expertos, finalmente se abrió. HTML/http (el WEB) llegó a principios de los '90, con unas aplicaciones extrañas llamadas "browsers", para transferir "texto e imágenes" y componer "páginas" armónicas y gráficamente atractivas, en una pantalla remota.

El impacto en nuestro planeta ... ya es historia conocida.

TCP/IP y los estándares

Desde TCP/IP, el modelo de desarrollo e implantación de estándares tecnológicos a escala global cambió radicalmente:

los "estándares de jure" (es decir, estándares protegidos y definidos entre cuatro paredes por "expertos" del área, con el "respaldo de marca" de connotadas instituciones) debieron ceder el paso a los "estándares de facto" (construidos sobre la base de modelos colaborativos de toda la comunidad en forma abierta).
El sólido edificio de los estándares de comunicación del modelo OSI, debió rendirse después de largas peleas en el "campo de batalla" de las implementaciones, frente a un ágil competidor denominado stack IP, que no tenía ningún dueño (o en forma equivalente, muchos dueños), construido además sobre múltiples procesos de prueba y error, en continuos refinamientos sucesivos.

El enfoque FLOSS aplicado en TCP/IP y sus aplicaciones (basado en colaboración, interfaces y definiciones públicas), modificó el paradigma del diseño, desarrollo y provisión tecnológica, especialmente en cuanto al manejo de los datos y la interconexión entre sistemas.

Y TCP/IP modificó radicalmente la industria, incluyendo un reordenamiento de los roles y los actores. Pero esos cambios recién comenzaban.

Haciendo un "salto en el tiempo", la experiencia y la conclusión que todos aprendimos (que en el contexto de la Estrategia Digital veremos reflejada de diversas formas), es que hay dos principios fundamentales que cautelar bajo cualquier circunstancia, ya sea al interior de una organización, en un país o en escala global:
  • La preservación futura del dato
  • La interoperabilidad entre soluciones tecnológicas diversas
Las causas del surgimiento del FLOSS

Las causas por las cuales surgen las "comunidades de desarrollo" en torno de proyectos FLOSS son múltiples y variadas, y es relevante entender su origen, porque permite proyectar modelos económicos y tecnológicamente viables en el futuro, más allá de la visión filosófica, política o tecnológica que cada individuo pueda tener (y por favor, hago este análisis con pleno y profundo respeto a dichas visiones).

El primer caso, emblemático porque además define las bases filosóficas originales del FLOSS (y que con el tiempo también ha tenido diversas derivaciones), surge por la visión de un brillante programador llamado Richard Stallman, quien declara su deseo de "liberar"a los usuarios de restricciones en el uso del software y el conocimiento, dando origen al suite de productos GNU y posteriormente a la conformación de la Free Software Foundation.

En otro caso, surge el esfuerzo de un brillante programador llamado Linus Torvald, quien decide "construir" su propio sistema operativo, que le entregue la flexibilidad tecnológica de Unix pero sin las restricciones de pago de licencia, liberando posteriormente su creación e invitando a la Comunidad en la construcción colaborativa de esa impresionante plataforma llamada Linux.

Hay casos de productos de software propietario, para los cuales por diversas razones, su modelo de negocios original ha fracasado. En la disyuntiva de no poder continuar soportando las aplicaciones por inviabilidad comercial, y respondiendo a la necesidad de continuar manteniendo a los usuarios (y eventualmente, crear nuevas oportunidades de negocios colaterales), las empresas propietarias del código optan por liberar dichos productos a la comunidad, en un modelo Open Source.

En algunos de esos casos, se han creado importantes comunidades de desarrolladores que mantienen y potencian esos productos, siendo un caso emblemático el de Netscape, que dio origen a Mozilla y sus derivados (entre otros, Firefox). Otro caso emblemático es el de Borland y sus productos InterDev (incorporado en modalidad OpenSource dentro de Eclipse) y su base de datos Interbase.

Por último, podemos encontrar productos FLOSS en los cuales grandes empresas tecnológicas invierten y soportan, para lograr otros beneficios por la vía de negocios colaterales, hardware, servicios, consultoría u otros productos de alto valor agregado (y precio).

Un ejemplo de esto es la plataforma Apache, que hoy soporta el 50% de los sitios WEB del planeta. Si revisamos la declaración de impuestos del período 2005-2006 de la Apache Foundation, observaremos que su financiamiento por la vía de donaciones y venta de algunos servicios, es levemente inferior a los US$ 150.000 (?!), cifra ínfima en cualquier lugar del planeta para cualquier iniciativa similar. Pero nadie puede negar los millones de dólares que empresas como IBM, Redhat, Sun y otros aportan por la vía de Horas Hombre dedicadas exclusivamente a Apache, además del propio soporte de la comunidad, recursos que dan sustento permanente al proyecto y sus derivados.

¿Y por qué estas distinciones?

Porque en mi opinión, todas las experiencias de proyectos FLOSS son distintas. Es muy difícil identificar a priori las condiciones que determinan que un proyecto FLOSS sea exitoso.

En consecuencia, tampoco podemos afirmar taxativamente que "el FLOSS es la mejor vía para el desarrollo de un proyecto país" o "FLOSS es la única vía éxito para el desarrollo económico y las libertades" o incluso que "el FLOSS es una tendencia irrevocable y todas las empresas tecnológicas tenderán hacia él". No es así, y en los próximos artículos iré desarrollando ideas al respecto.

No obstante, algunos de nuestros políticos en Chile consideran sumamente "fashion" realizar esas afirmaciones, sin tener la más remota idea de lo que significan. Muchas veces son declaraciones erradas y que tienden precisamente a ir en contra del uso del FLOSS, en vez de colaborar en su implantación adecuada. Y por ello es que considero una responsabilidad de quienes conocemos un poco más de estos temas, ayudar a establecer consensos que aseguren proyectos viables de desarrollo y no simplemente "declaraciones para la galería". (Me reservo en esta oportunidad el derecho a no incluir links externos en este párrafo, pero es sumamente fácil encontrar esas declaraciones ... :-)

Lo que sí tengo muy claro es que la viabilidad de un proyecto FLOSS depende de la disponibilidad de recursos que lo sustenten: en algunos casos, será el desinteresado aporte de miles de voluntarios en el planeta quienes aportarán sus horas de trabajo para el mejoramiento continuo de las soluciones. En otro, serán corporaciones u organizaciones que darán sustento financiero para la continuidad del proyecto. En algunos, serán comunidades o individuos que se financian por otras vías (grants, donaciones, tiempo dedicado). Y en otros casos, simplemente personas que donan recursos o tiempo en forma desinteresada, como un aporte a la sociedad.

Pero en todos los casos, "alguien financia". Es decir, los recursos de alguna parte surgen.

Y ese es el desafío: identificar la mayor cantidad de variables y condiciones, que permitan modelar un proyecto basado en tecnología, considerando la mejor combinación de elementos que permitan el desarrollo sustentable del proyecto, más allá de las simples declaraciones de voluntad. Esto es válido para los usuarios (personas, gobiernos, empresas, etc.), para los emprendimientos o empresas tecnológicas, para el desarrollo de una industria basada en conocimiento y en una escala mayor, para el diseño de una estrategia de desarrollo tecnológico para un país.

Con estos antecedentes, en el próximo artículo que liberaré el 14 de Octubre, realizaré un análisis sobre el impacto que el FLOSS ha tenido en la industria del software en su conjunto, modificando los paradigmas tradicionales y cómo se relaciona con la industria del "software propietario".

Stay tuned!

Leer artículo completo ...

domingo, 7 de octubre de 2007

Diferencias entre Software Propietario y Software Libre (FLOSS)

Con este post iniciaré una serie de artículos de análisis sobre las diferencias comerciales y de modelo de negocios entre el "software propietario" y el "Free/Libre Open Source Software (FLOSS)".

Aprovecharé también de plantear mi posición personal en estos temas. Lo considero adecuado, ya que participo en diversas instancias profesionales y gremiales, y en particular, soy miembro de la mesa FLOSS convocada por el Ministerio de Economía, en el contexto de la discusión de la Estrategia Digital para Chile.

Desde ya, declaro que tengo el "alma dividida": por una parte, adscribo varios de los principios filosóficos y reconozco muchas de las ventajas técnicas del FLOSS. Pero también considero importantes algunos aspectos del software propietario, especialmente en temas comerciales y de modelo de negocios.

En mi rol como profesional y empresario, para mi realidad personal debo considerar modelos económicos sustentables que me permitan pagar las cuentas de fin de mes. Y para mi país, tengo la responsabilidad de colaborar en conciencia con criterios adecuados para el diseño de un modelo de desarrollo nacional basado en conocimiento y tecnología.

So my friends, let's rock and roll.

Las denominaciones

Generalmente se utiliza el concepto de "software licenciado" como sinónimo de "software propietario", pero en estricto rigor, plantear que son equivalentes es un error.

Como toda obra intelectual, toda aplicación de software es "licenciada" (es decir, tiene una licencia de uso) y se reconocen derechos de "propiedad intelectual", dependiendo de la decisión del "autor" o "creador" del software. Cuando hay cesión de derechos, aplica lo que defina el "dueño de los derechos".

Por lo tanto, las aplicaciones de software de cualquier tipo, sea "propietario" o "libre/FLOSS", tienen todas una licencia de uso.

La distribución del FLOSS

Hay muchas diferencias entre el software "propietario" y el software FLOSS, e incluso dentro del propio ámbito del FLOSS.

Una distinción filosófica del Free Software respecto del software propietario, es la apertura "total" del conocimiento incluido en el software.

Una distinción técnica entre el software "propietario" y el FLOSS, es la apertura del código fuente de las aplicaciones junto con la distribución "binaria".

En el FLOSS, se permite la distribución y modificación del software, pero manteniendo el espíritu original de las condiciones definidas por el autor, en términos de uso y distribución "libres" (sin restricción).

Para que una aplicación cumpla con la denominación de "Open Source Software", debe incluir la distribución del código fuente del software y cumplir con las 10 definiciones entregadas por la Open Source Initiative (OSI).

Por su parte, el "Free Software" (seremos insistentes en que NO debe confundirse con "gratuito") es mucho más restrictivo y la definición está dada por la Free Software Foundation (FSF).

La distribución del "software propietario"

En el caso del "software propietario", la distribución se restringe a quienes adquieren una "licencia de uso" (generalmente por la vía de un pago), para un "paquete de aplicación" o "producto". Pero la distribución se restringe al código "binario" (los programas ejecutables de las aplicaciones), quedando el código fuente en propiedad de los creadores del software. Y dependiendo de las condiciones de la licencia, existirán diversos "usos" permitidos a los "usuarios".

En algunos casos muy particulares para "productos" o "paquetes", y dependiendo de las condiciones del acuerdo entre el desarrollador de software y el cliente, se realiza una transferencia del "código fuente" de la aplicación. Una tendencia creciente es el "aseguramiento", implementado a través de un procedimiento de "software escrow", donde bajo ciertas condiciones (típicamente bancarrota o falta de mantención y soporte), el cliente puede acceder y modificar el código para usos futuros.

Pero en cualquiera de las condiciones anteriores, no se transfiere los derechos de propiedad ni se da una libertad total al cliente que recibe dicho código.

Por último, no todo "software propietario" es pagado. Existen muchos desarrolladores que por razones estratégicas y comerciales, transfieren licencias de uso a "precio cero" (o sea, son gratis). Pero eso NO significa que sean aplicaciones FLOSS. Son simplemente aplicaciones propietarias, pero gratuitas.

Los desarrollos "a medida"

Un último caso es una situación en la cual un cliente financia servicios profesionales (Horas Hombre) para que un desarrollador de software le "programe" una aplicación de software específica, financiando totalmente el desarrollo.

En dicho caso, se aplica el principio de "el que financia es el dueño de los derechos de propiedad". Pero cuidado. Siempre y cuando las componentes básicas que se utilizan en el desarrollo no sean de tipo FLOSS. De ser así, el desarrollo debería automáticamente ser de uso y propiedad pública, o al menos, deberían aplicarse las licencias de las componentes básicas y sus restricciones. Una forma interesante de verlo es considerar la "falta de restricciones", principio generalmente conocido como copyleft.

En este tema, es importante que los CIOs de las compañías comprendan bien los aspectos de licenciamiento al solicitar un desarrollo de software, en forma independiente de si los desarrollos son sobre software propietario o con plataformas FLOSS. Me ha tocado ver situaciones en las cuales por desconocimiento de las partes, se cometen ilegalidades o no se respetan ciertos principios. Mi opinión es que en el tema de los derechos de propiedad del software, la demanda y la oferta en Latinoamérica todavía están muy inmaduras. Es un tema que al menos en la Agenda Digital 2.0, quiero proponer como una acción específica de divulgación masiva.

Algunos desarrolladores de software tienen la percepción errada de que los "desarrollos a medida" son propiedad del desarrollador, independiente de que el cliente lo financie. No es así. Una regla sencilla es aplicar el viejo principio de que "el que pone la plata, pone la música". Esto incluye el caso de desarrolladores de software contratados por una empresa. Las creaciones intelectuales creadas durante la jornada laboral y pagadas (financiadas) mediante un sueldo, son propiedad de la empresa contratante.

Este último aspecto en cuanto al financiamiento es muy relevante, especialmente para el análisis de los aspectos comerciales: Quien financia, es el dueño de los derechos (al igual que muchas otras situaciones de la vida).

Esta distinción puede no ser compartida por algunos, pero la consideraremos como un criterio fundamental de análisis.

Mi resumen sobre la propiedad del software

En resumen, y siendo consistente con los criterios y definiciones anteriores, la guía que aplico en el modelamiento de procesos de negocios de software, distingue las siguientes situaciones:

  • En el caso de "productos FLOSS", el dueño es "la comunidad", dado que la inversión para el diseño, construcción, testing y mantención, la realizan múltiples programadores en modelos colaborativos. No existe un único dueño, ya que los dueños son "muchos". La "inversión" es principalmente tiempo (horas de trabajo) aportado por la Comunidad en diversas formas. El código fuente es público y distribuido.
  • En el caso de "software propietario", el dueño es el "desarrollador de software", quien realiza la inversión completa para el desarrollo del producto. El desarrollador transfiere a sus clientes algunos "derechos de uso" según las condiciones incluidas en el acuerdo comercial. El código fuente es propiedad de la empresa desarrolladora.
  • En el caso de los "desarrollos a medida", el dueño del producto de software es el cliente que financia los "servicios profesionales", en forma independiente de que pueda contratar más servicios profesionales para la mantención y soporte futuros. El código fuente es propiedad del cliente que contrata.
Indudablemente, para todos los casos anteriores, deben aplicarse las restricciones de las licencias de los productos básicos con los cuales se construyan las aplicaciones de software.

Las condiciones de uso y distribución NO pueden ser contradictorias (o peor aún obviadas o modificadas) por la vía de un "acuerdo comercial" específico.

La colaboración y cooperación en el mundo tecnológico

Personalmente creo que, al menos en la industria tecnológica, la colaboración y la cooperación pueden desarrollarse en diversas modalidades y múltiples ámbitos, en forma independiente de las estrategias comerciales y de desarrollo que cada individuo u organización decida, sobre la base de criterios consensuados.

Indudablemente existen matices, ya que estos temas son controversiales y de continuo debate.

Mantengo una prudente distancia de los que sostienen que el mundo debería ser totalmente "free" en al ámbito tecnológico y que quienes lucran (lucramos) de la tecnología son (somos) unos inmisericordes explotadores capitalistas. Y por otro lado, me molesta profundamente la actitud de quienes sostienen que los propensores del FLOSS en sus diversas corrientes, son grupos de "hippies hackers" que no tienen preocupaciones económicas y sostienen un sueño irreal. Los fundamentalistas de ambos bandos no aportan.

En este espacio y como presentaré más adelante, mi posición ecléctica y pragmática es "tratar de tomar lo mejor de todas las visiones".

En mi próximo artículo analizo el aporte del FLOSS a la interoperabilidad.

Stay tuned!

Leer artículo completo ...

Seguidores

  © Blogger templates Newspaper III by Ourblogtemplates.com 2008
      Header Image: Modification of Technology Curve by Wonderlane

Back to TOP