Se ha descrito bastantes veces la singularidad del software Open Source frente al software propietario: seguridad, factores sociales, factores económicos, etc. En este post me gustaría mencionar otros factores diferenciales que no son tan frecuentemente citados.El software Open Source tiene una arquitectura más modular que el propietario
Una aparente debilidad del modelo de desarrollo de software Open Source como la dispersión y diversidad de los desarrolladores revierte en un beneficio: la dispersión obliga a construir el software Open Source en piezas que sean fáciles de interconectar. Esta conclusión es la que se desprende de un estudio del MIT (citado por Nicholas Carr y descargable aquí) tras un análisis comparativo de la arquitectura de Linux y la última versión de Netscape (origen de la primera versión de Mozilla).
Otra conclusión interesante del mismo estudio es que la arquitectura de un software propietario es un reflejo de la organización de los equipos que lo han desarrollado. Como son equipos muy cohesionados, las distintas partes del software tienden a estar muy interrelacionadas entre sí, por lo que cualquier cambio posterior de la aplicación tiene un gran impacto (los que tienen experiencia en desarrollo y mantenimiento de software lo entenderán muy bien).
Supongo que es por eso que cada vez que actualizas cualquier aplicación en entorno Windows te pide que reinicies la máquina.
El software Open Source no es viable para cualquier aplicación
Que se me entienda bien, no es que técnicamente sea inferior, es una limitación debida a la filosofía identitaria del software Open Source, ésto es: cualquier desarrollo sobre una aplicación Open Source debe ponerse a disposición del resto de la comunidad.
La primera vez que empecé a pensar en este factor diferencial fue a raíz de un comentario de Carmen Puras en un post que hice acerca de las aplicaciones de negocio que corren en Open Source.
Carmen dudaba que el modelo fuese válido en su entorno profesional (banca). Y tiene toda la razón: Si una empresa desarrolla una aplicación de gestión que no está disponible en el mercado y que supone una ventaja competitiva sobre su competencia (caso frecuente en el entorno bancario) lo lógico es que no quiera que la competencia se pueda beneficiar y por tanto es difícil que pueda utilizar como base un entorno basado en Open Source.
Lo que nos lleva a una interesante y creo que controvertida conclusión: El software Open Source sólo es viable cuando se construyen aplicaciones que no constituyen ventajas competitivas frente a la competencia. La historia de las aplicaciones Open Source parece corroborar esta conclusión: primero fue Linux, después aplicaciones básicas como Firefox y últimamente ERPs.
¿Está el software Open Source condenado a convertirse en una commodity?
19 comentarios:
Ese caso estaría dando la razón al R. Carr, el autor del famoso "Does IT matter?", al que muchos tecnólogos rebatieron sus argumentos, entre otros Enrique Dans.
Yo creo que es muy difícil que la ventaja competitiva esté en el software, sino en la capacidad de la empresa para obtener lo mejor de él y de que ese SW cubra sus procesos. No sé con quién me alinea esto.
Por decirlo academicamente, el SW no es la vantaja competitiva, ya que es imitable y no perdura en el tiempo. Pero la capacidad de la organización en aprovecharlo y en mejorar constantemente sus procesos de acuerdo a los mejores sistemas posibles perdura y no es facilmente imitable.
Y esto no estoy seguro de que dependa de como has costruido el software...
(Perdón por el rollo, pero no es fácil comentar esto en dos líneas)
De acuerdo Rafa, yo añadiría además la reflexión de que por tanto el hecho de que no haya diferencia entre que "poseas" o no el software, contribuye a la "comoditización" de las IT, o al menos elimina una barrera para ello.
¿La alternativa sería el desarrollo a medida como forma de proteger el conocimiento "depositado" en el sistema? - Que sorprendente ¿no?
Mi esquema "ideal" de sistemas en una compañia se acerca a lo que propones.
Los sistemas que no forman el núcleo de negocio, estándares (en general: contabilidad, RRHH, compras, etc.). El núcleo de negocio, a medida o con mucha personalización.
Lo difícil es saber cual es tu núcleo. Por ejemplo, para una gran superficie, ¿cual sería su núcleo? o ¿donde estaría más personalizada? Según el enfoque, podría ser la logística o el DWH de clientes.
Esto permitiría conocer el verdadero enfoque de las compañías viendo simplemente sus licencias de software.
Rafa... ¿y el negocio de un banco cuál sería, traducido a software? ¿Host? ¿ERP? ¿CRM? ¿DWH? ¿...Excel/Outlook? ;)
Yo estoy convencido de que el software sirve a las personas (como casi todo) y somos nosotros los que, dependiendo de para qué carajo queremos un determinado software y de cómo lo usamos, así nos irá.
Windows, Linux... ¿qué es más cómodo y productivo? Pues, dependiendo de cómo se integre en la organización pues así será.
Informático, etoy de acuerdo en que el software es una herramienta. De hecho, es lo que defendía en el primer comentario.
Como dices, un mismo SW puede una solución excelente para una compañía y un lastre para otra. Y me reafirmo en que la ventaja la obtendrá la compañía de la forma de aprovecharlo y de identificar procesos y herramientas, no de las herramientas en si mismas.
La discusión con tic616 era sobre la comoditización o no del software o de que parte del conocimiento puedes estar depositado en el software.
Lo que quería expresar en el segundo comentario es que, si el conocimiento (o parte de él) están en ese SW, podríamos saber a que parte del negocio da más importancia una empresa viendo donde tiene sus aplicaciones más personalizadas.
No conozco mucho los sistemas bancarios, pero me da la sensación de que Bankinter debe tener herramientas de análisis de clientes mucho mejores que Ing, cuando el primero es capaz de generar constantemente ofertas y mensajes muy personalizados, mientras que Ing opta por un "café para todos" basado en simplicidad. Y está parte está comentada desde el punto de vista de un cliente, recordando que no tengo ninguna experiencia en sistemas bancarios, aunque en cierta ocasión (hace mucho tiempo) me comentaron que de los 20 primeros bancos (cuando había 20 bancos), 18 tenían el mismo sistema "de base".
Rafa, coincido contigo en casi todo, pero lo que quería hacerte ver es que la respuesta a: "cuál es el negocio de un banco, traducido a software" es muy simple: cualquiera... que dé dinero o permita ahorrar gastos.
Así de simple. Las empresas no miran por qué software es mejor o peor, sobre todo las grandes. Lo que pretenden, en la mayoría de los casos, es encontrar "herramientas" (y si no las hay, las crean, como ejemplo Banesto) que les permitan trabajar en condiciones "más mejor" de modo que el rendimiento puro de negocio sea mayor. Así de simple.
Si en ese aspecto el OpenSource, Software Libre o como se llame tiene algo que pueda ser útil para la estrategia de negocio de un banco, pues bienvenido sea; pero si incrementa los gastos estructurales, pues puerta. No es cuestión de "qué" seas, sino de "lo que" hagas o permitas hacer. O al menos, eso me pareció a mí. ;^)
Llego un poco tarde a este debate, pero allá voy.
Por lo que veo, creo que un poco todos tenéis parte de razón.
Es cierto que en una empresa como un banco hay tantas áreas, y con tantas aplicaciones que hay cabida para todo:
- Nosotros usamos herramientas ofimáticas, y hay herramientas ofimáticas open source, y si quisiéramos podríamos optar por ellas.
El tema es que para que haya un software opensource debe haber básicamente una comunidad de desarrolladores que esté interesada en el desarrollo, o sea, que haya mucha gente que pueda usar este software.
Lo que yo hablaba con Luis en el post al que se refiere, es que por ejemplo, empresas a las que les interese un aplicación para generar la información legal para entregar a la Central de Información de Riesgos del Banco de España (que tenemos que entregar exhaustiva y puntualmente todos los meses), pues, francamente, quitando las entidades bancarias españolas, no veo a nadie más interesado en esto.
Y os puedo asegurar que la aplicación no es nada fácil de desarrollar.
Y no hay ningún comercial que te venda software para ello,ni me puedo imaginar a los bancos pasándose el software para que lo utilicen los demás.
¿Y qué me decís el software de apoyo a una nueva hipoteca? Si la entidad que ha ideado el producto ha hecho la inversión para su desarrollo ¿cómo va a compartirla? ¿también comparte la idea del nuevo producto?
Le pasé a Luis una presentación sobre una experiencia en software libre de una asociación informática de varias Cajas de Ahorro llamada ATCA, y lo que habían visto es que el software de base para infraestructuras, seguridad, ... que es más estándar con otros sectores sí habían apostado por él, pero el software de lo que llamamos "core" del negocio difícilmente habría una comunidad grande como para desarrollarlo y que tuviera una evolución.
Con aplicaciones "core" bancarias me refiero a (entre otras), para que veáis el mundo que es un banco:
- Cuentas personales
- Cuentas de crédito
- Préstamos
- Medios de pago (administración de tarjetas, centro autorizador)
- Avales
- Cartera de efectos
- Transferencias
- Truncamiento
- Domiciliaciones de recibos
- Factoring
- Confirming
- Préstamos sindicados
- Recaudación de tributos
- Control global de riesgos
- Control de impagados
- Prevención de blanqueo de capitales
- Comercialización de seguros
- Fondos de inversión
- Valores
- Comercio exterior: moneda extranjera, créditos documentarios, seguros de cambio, remesas al extranjero...
- Mesa de tesorería
(en fin, muchos millones de líneas de código)
y luego las típicas que pueden ser más comunes con otro tipo de empresa: clientes, contabilidad, compras, inmovilizado, presupuestos, RR.HH,...
por no hablar del DataWarehouse, con sus herramientas de análisis y reporting, data mining, Ficha de clientes, análisis de rentabilidad, simulaciones de situaciones,...
gestión documental (papel cero), el BPM,...
y luego en cuanto a gestión de conocimiento, la Intranet corporativa con todas sus aplicaciones.
Y seguro que alguna más se me escapa, porque a estas horas no estoy ya para mucha memoria.
Si yo tuviera que montar todo esto con software libre. ¿Qué podría hacer, sobre todo en cuanto a las aplicaciones `core`?
Pero es que voy más allá. Creo que no sólo en banca, sino en muchas otras empresas al final si el grado de mecanización es muy grande, no hay software libre para ello. Pienso en Telefónica y el software que tiene que tener para su control de redes de comunicaciones.
Bueno, hasta aquí llego, que ya está bien.
Carmen, muy buenos ejemplos de aplicaciones que tienen "embebido" el conocimiento de negocio y que según mi (nuestra) tesis difícilmente podrán ser desarrolladas bajo Open Source.
PD. No lo he hecho hasta ahora, pero aprovecho para "vender" un poco: aprovechando que lo menciona Carmen, si conocéis a alguien que necesite consultoría sobre herramientas BPM hacédmelo saber porque creo que tenemos un buen conocimiento (hemos visto-demo más de 30 y analizado sobre 10 en profundidad).
Pues nada, ya puestos...
Mi promo ;^)
Dí que sí, i2. Para eso estamos
Hola a todos,
leyendo el post y los comentarios he visto que todos concuerdan en que sistemas grandes de gestion no pueden ser desarrollados en un modelo OpenSource, ya sea por la cantidad de "lineas de codigo" necesarias para embeber la logica del negocio en un sistema, y eso es evidente, el desarrollo de software libre no se paga como un similar en software propietario por algunos esquemas economicos implicitos en cada modelo, pero, dado a que la propia naturaleza del software libre de ser generalmente mas modular, general y abstracto que el software propietario, podrian concebirse sistemas (herramienta) donde puedan hacerse abstracciones de la logica del negocio de forma que esta pueda ser definida particularmente por cada entidad que use el software y poder hacer uso de esta sin que esto signifique compartirla con la competencia y utilizar todos un software propietario.
A mas bajo nivel hay ejemplos de esto, como: Los gestores de bases de datos, servidores web, sistemas operativos (todos utilizan estos software, que pueden ser libres o no, con un fin determinado por el uso particular en cada caso)
Creo que a la esta polemica le falto acotar en un inicio el tipo de software del que se trata, refierendome a si es un sistema o una herramienta.
Saludos
No es que no se puedan, Licenciado (anda, como Yo! ;), es que no hay quien se atrava porque no ve rendimiento (en €uros). Así que son los usuarios quienes tienen que hacer de Juan Palomo ("Yo me lo guiso, Yo me lo como"). Por eso Carmen dice que el software bancario (con sus pros y sus contras) ha de ser desarrollado por el propio banco o coger algo que pueda adaptarse a "lo suyo" sin perder la "propiedad" sobre sus procesos de negocio.
Es por eso por lo que cuando no se encuentra el software apropiado, una de dos: o se decide hacer o compras Office, que el Excel es mu chulo pa estas cosas.
Justamente de eso hablaba, El punto es que las herramientas de software de gestion deberian darle la posibilidad a los usuarios de definir su logica de negocio sin necesidad de tener que caer en tareas de programacion. Asi todo lo que creen sera propiedad de ellos, pero el software motor de toda esta definicion podria ser sin dudas software libre, opensource.
saludos
i2 y Ernesto, el tema va por ahí:
Los desarrollos que contengan conocimiento estratégico del negocio y por tanto puedan ser una ventaja competitiva: a medida y propietario.
El resto: desde lo más básico (por ejemplo el sistema operativo) a lo más "avanzado" (un CRM) podrás ser propietario o Open Source
Perdoname, tic616, pero... ¿porqué tengo la extraña sensación de que en muchos casos el "conocimiento estratégico del negocio" se basa en algo en Excel / Word o similar o incluso en un mail?
Nada que perdonar i2. Abstrayéndonos de las herramientas concretas, me refiero a conocimiento de una organización que se plasma en una aplicación de negocio concreta (algoritmos específicos, ratios de cálculo basados en la experiencia, "best practices" propias, etc.) ... y que no querría que la competencia pudiera tener acceso.
Aciertas en que demasiadas veces ese conocimiento está en hojas Excel y por lo tanto no siendo aprovechado en su máxima potencialidad.
Bueno, aunque sea muy tarde (en la hora y en el debate) aporto mi opinión. Efectivamente, el core business es específico de cada empresa y debe tener desarrollos específicos (o parametrizaciones específicas de un software común).
Como dicen por ahí, hay grandes superficies más centradas en el DW y CRM (ECI) y otras en la logística (Carrefour, etc..). Estas dos empresas tendrás sistemas muy distintos y/o los usaran de forma muy diferente.
Pero, ¿porque no comparamos la misma aplicación en distintos sectores? Igual el CRM de Bankinter (y yo tampoco tengo ni idea de Banca), tiene mucha relación con el de ECI o cualquier otra empresa centrada en el cliente. Estas dos empresas sí podrían compartir una base Open Source, sobre la que desarrollar sus propias adaptaciones.
Al final, creo que todos estamos más o menos de acuerdo. Lo que pasa es que la situación de partida de Carmen es muy extrema. Bancos hay pocos, se trata de un negocio muy regulado y muy específico de cada país y, para colmo, son tan grandes que se pueden permitir el lujo de desarrollar a medida. Me parece que no es la situación más común de la empresa española.
Por cierto, I2, lo de que se trabaja mucho en Excel, lo confirmo. Pero además, debo decir que hay veces en que hasta resulta la mejor opción.
Bueno, lamento lo atropellado y convulso de mi comentario, pero creo que algo se entiende.
Preferiria Utilizar Access antes de Excel, pero claro yo no estoy en condiciones de decirlo porque tengo la capacidad de hacer mis propias herramientas y darle solucion a mis problemas puntuales, pero a gran escala que la estandarizacion ayudara mucho en ese sentido, propuestas como la de ebXML y otros son validas pero no llegan a prender entre los desarrolladores (quizas porque queremos siempre hacer la casa completa, desde abajo)
Para mi es una cuestion de estandarizacion y niveles de solucion, a mas bajos niveles tenemos definicion de datos concretos, validacion, comunicacion, y a mas altos niveles analisis, reporting, y cualquier otra "aberracion" que se les quiera ocurrir a los consultores y/o directivos/analistas. para todo (creo yo) ya hay herramientas libres, lo unico que falta es que esas herramientas libres no se disgreguen en su objetivo, que pienso que debe ser simple, unico y viniendo de un mundo tan grande y particionado como es el de las aplicaciones para linux, siguiendo el tema de unix "small is beautifull" que grandes cosas no se podrian lograr.
Saludos
El debate está muy interesante pero me parece que ha derivado un poco. La tesis es muy simple: no es un tema técnico, es un tema de estrategia empresarial. Nadie va a querer desarrollar una aplicación que incorpore su conocimiento de negocio sobre una herramienta que le obliga a compartir lo que desarrollo - es decir su conocimiento.
Publicar un comentario