Novedades en la categoría Desarollo

Novedades Radicales

| 4 comentarios | Sin trackbacks

Hay mucha gente a la que le encanta establecer analogías (o isomorfismos como los llama Pepe Flores), para explicar nuevos conceptos, o ideas. Pero en realidad esa manera de pensar siempre falla cuando nos enfrentamos con conceptos que son "novedades radicales".

Al respecto quiero compartir este texto de Dijsktra donde explica mucho mejor esto:


La manera usual en la cual hoy planificamos para el mañana es en el vocabulario de ayer. Lo hacemos porque tratamos de avanzar con los conceptos que nos son familiares, los cuales han adquirido un significado en nuestra experiencia pasada. Por supuesto, las palabras y los conceptos no encajan precisamente porque nuestro futuro difiere de nuestro pasado, pero las estiramos un poco. Los lingüistas están bastante familiarizados con el fenómeno en el cual los significados de las palabras evolucionan a través del tiempo, pero también saben que este es un proceso lento y gradual.

Es el método más común cuando se trata de lidiar con la novedad: utilizando metáforas y analogías tratamos de vincular lo nuevo con lo viejo, lo novedoso con lo familiar. Bajo un cambio suficientemente lento y gradual, esto funciona razonablemente bien; en el caso de una discontinuidad aguda, sin embargo, el método colapsa: aunque podemos glorificarlo con el nombre "sentido común", nuestra experiencia pasada ya no es más relevante, las analogías se tornan muy superficiales, y las metáforas se hacen engañosas en vez de reveladoras. Esta es la situación que caracteriza a la novedad "radical".

Lidiar con una novedad radical requiere un método ortogonal. Uno debe considerar su propio pasado, las experiencias recogidas, y los hábitos formados en él como un desafortunado accidente de la historia, y debe acercarse a la novedad radical con la mente en blanco, rechazando conscientemente el intento de vincularla con lo que ya es familiar, debido a que lo familiar es desesperanzadamente inadecuado. Uno debe, con una especie de personalidad dividida, tomar una novedad radical como algo desasociado por propio derecho. Comprender una novedad radical implica crear y aprender un lenguaje extraño, el cual no puede ser traducido a nuestra lengua materna. (Cualquiera que haya aprendido mecánica cuántica sabe a lo que me refiero.) No hace falta decirlo, ajustarse a las novedades radicales no es una actividad muy popular, ya que requiere mucho trabajo. Por la misma razón, las novedad radicales no son por sí mismas bienvenidas.

A esta altura, bien se pueden preguntar por qué he prestado tanta atención y he gastado tanta elocuencia en una noción tan simple y obvia como una novedad radical. Mi razón es muy simple: las novedades radicales son tan perturbantes que tienden a ser suprimidas o ignoradas, al punto que la mera posibilidad de su existencia es generalmente negada antes que admitida.

Voy a ser breve en cuanto a la evidencia histórica. Carl Friedrich Gauss, el Príncipe de los Matemáticos pero algo cobarde, sin duda estaba al tanto del destino de Galileo -y probablemente podría haber predicho las acusaciones a Einstein- cuando decidió suprimir su descubrimiento de la geometría no Euclidiana, dejando que Bolyai y Lobatchewsky recibieran las críticas. Es probablemente más revelador ir un poco más atrás, a la Edad Media. Una de sus características era que "razonar mediante analogías" era descontrolado; otra característica era el total estancamiento intelectual, y ahora vemos porque ambas características van juntas. Una razón para mencionar esto es resaltar que, desarrollando un oído entrenado para las analogías no garantizadas, uno puede detectar una gran cantidad de pensamiento medieval hoy en día.

...

El concepto de novedades radicales es de importancia contemporánea ya que, mientras estamos mal preparados para lidiar con ellas, la ciencia y la tecnología no se han mostrado expertas en influirlas sobre nosotros. Ejemplos científicos antiguos son la teoría de la relatividad y la mecánica cuántica; ejemplos tecnológicos modernos son la bomba atómica y la píldora. Durante décadas, los primeros dos ejemplos dieron lugar a un torrente de corrientes religiosas, científicas o de otra manera cuasi-científicas. Día a día podemos observar el profundo error de enfoque con el cuál los últimos dos ejemplos han sido abordados, ya sea por nuestros políticos y líderes religiosos o por el público en general. Demasiado para el daño hecho a nuestra paz mental por las novedades radicales.


Fuente: http://www.smaldone.com.ar/documentos/ewd/sobre_la_crueldad.html

¿Y por que es tan importante esto?

Porque la naturaleza del software es una novedad radical, dejemos al mismo Dijsktra explicarlo:


Traje esto a colación debido a mi convencimiento de que las computadoras automáticas representan una novedad radical y de que sólo identificándolas como tal podemos identificar todo lo irrelevante, los conceptos errados y la mitología que las rodea. ...

La primera novedad radical es una consecuencia directa del poder bruto de las computadoras actuales. Todos sabemos como lidiar con algo tan grande y complejo; divide y vencerás, por ejemplo vemos el todo como una composición de partes y tratamos con las partes por separado. Y si una parte es muy grande, repetimos el procedimiento. La ciudad está compuesto por barrios, que están a su vez estructurados por calles, que contienen edificios, que están hechos de paredes y pisos, que están construidas de ladrillos, etc. eventualmente llegando a las partículas elementales. Y tenemos a todos nuestros especialistas sobre el tema, desde el ingeniero civil, pasando por el arquitecto hasta el físico de estado sólido y consiguientes. Ya que, en cierto sentido, el todo es "mas grande" que sus partes, la profundidad de una descomposición jerárquica es algún tipo de logaritmo del cociente entre los "tamaños" del todo y las partes más pequeñas. Desde un bit a cien mega bytes, desde un microsegundo a media hora de cómputos nos confronta con un cociente completamente abrumador de 10^9! 

El programador está en la posición inigualada en la cual la suya es la única disciplina y profesión donde un cociente tan gigante, lo cual completamente sobrepasa nuestra imaginación, debe ser consolidado por una sola tecnología. Debe poder pensar en términos de jerarquías conceptuales que son mucho más profundas que todas aquellas que debió enfrentar una sola mente alguna vez. Comparado con ese número de niveles semánticos, la teoría matemática promedio es casi plana. Evocando la necesidad de profundas jerarquías conceptuales, la computadora automática nos confronta con un radical desafío intelectual que no tiene precedente histórico.

Como estamos ante una novedad radical, no podemos seguir pensando en el desarrollo de software de la manera analógica (en el sentido de hacer analogías) como se ha hecho hasta ahora.


Las metáforas del constructor, o del arquitecto, o del ingeniero no funcionan con el desarrollo de software. Hay que pensar de una forma distinta, hay que aceptar la novedad radical y aceptar que la nuestra es una profesión radicalmente distinta a todas las que han habido antes.


Por cierto, estas novedades radicales se dan en muchos campos del saber, no solo en la informática. Es tiempo de dejar de estar atado a formas graduales de pensamiento, y empezar a asumir las novedades radicales en nuestros campos.

Pienso que uno de los mejores argumentos en contra de la noción de crisis de software fue dada indirectamente por Edsger W. Dijkstra, en su charla de 1988 "ON THE CRUELTY OF REALLY TEACHING COMPUTIN SCIENCE"

Cierta cantidad de estos fenómenos han sido agrupados bajo el nombre de "Ingeniería de Software". Así como la economía es conocida como "La Ciencia Miserable", la ingeniería de software debería ser conocida como "La Disciplina Condenada", condenada porque ni siquiera puede acercarse a su meta, dado que la misma es en sí misma contradictoria. La ingeniería de software, por supuesto, se presenta a sí misma como otra causa valiosa, pero es un colirio: si lee cuidadosamente su literatura y analiza lo que realmente hacen quienes se avocan a ella, descubrirá que la ingeniería de software ha adoptado como su estatuto "Cómo programar si usted no puede".

...

dijkstra.jpg
La práctica está impregnada de la confortable ilusión de que los programas son simplemente dispositivos como cualquier otro, la única diferencia que se admite es que su fabricación pueden requerir un nuevo tipo de expertos, a saber: programadores. Desde allí hay sólo un pequeño paso hasta medir la "productividad del programador" en términos de la "cantidad de líneas producidas por mes". Esta es una unidad de medida muy costosa, porque anima a escribir código insípido, pero hoy estoy menos interesado en qué tan tonta es una unidad, aún desde un punto de vista puramente empresarial. Mi punto hoy es que, si deseamos contar líneas de código, no deberíamos verlas como "líneas producidas", sino como "líneas gastadas": el sentido común actual es tan tonto como contabilizar esa cuenta del lado erróneo del balance.

Además de la noción de productividad, también el control de calidad sigue estando distorsionado por la confortable ilusión de que funciona con otros aparatos como lo hace con los programas. Han pasado ya dos décadas desde que se señaló que el testing de programas puede convincentemente demostrar la presencia de errores, pero nunca puede demostrar su ausencia. Después de citar devotamente este comentario bien publicitado, el ingeniero de software vuelve al orden del día y continúa refinando sus estrategias de testing, tal como el alquimista de antaño, quien continuaba refinando sus purificaciones crisocósmicas.

Un profundo malentendido es luego revelado por el término "mantenimiento de software", como resultado del cual muchas personas siguen creyendo que los programas -e inclusive los mismísimos lenguajes de programación- están sujetos a desgaste y ruptura. Su auto también necesita mantenimiento, ¿no es así? Es famosa la historia de la empresa petrolera que creía que sus programas PASCAL no durarían tanto como sus programas FORTRAN "porque PASCAL no estaba mantenido".


En el mismo sentido debo llamar la atención sobre la sorprendente facilidad con que se ha aceptado la sugerencia de que los males de la producción de software de deben, en gran medida, a la falta de "herramientas de programación" apropiadas. (Pronto aparecería la frase "banco de trabajo del programador".) Nuevamente, la chatura de la analogía subyacente se debe a la Edad Media. Las confrontaciones con las insípidas "herramientas" del tipo de "animación de algoritmos" no ha suavizado mi juicio; por el contrario, ha confirmado mi sospecha inicial de que estamos tratando principalmente con otra dimensión del negocio del aceite de serpientes.

Texto completo en castellano disponible en el sitio de Javier Smaldone.

Lo que no se entiende aún es que el desarrollo de software no es como la construcción de objetos, y esta naturaleza fundamentalmente distinta es la que lleva a errores al tratar de definir el éxito o fracaso de un proyecto de desarrollo de software.

DoomedDiscipline.jpg


¿Se imaginan tener que agregarle un nuevo dormitorio, y un jacuzzi al baño,  a cada departamento de un edificio de 24 pisos, todo durante un fin de semana, y con los inquilinos dentro?


Hace unos meses atrás hablé con ex profesor auxiliar de ingeniería de software, en una universidad tradicional. En esa ocasión me mostró un examen, donde se les pedía a los alumnos comentar la afirmación del Chaos Report sobre la alta tasa de fracaso de los proyectos de software. ¿Qué leseras les enseñabas a tus alumnos?! fue mi comentario sarcástico. 

Me acordé de esa discusión por un post reciente de Alejandro Barros, que parte provocándonos con la frase:

¿Se imaginan que sólo el 32% de los proyectos inmobiliarios o de infraestructura fueran exitosos?

Y lo titula: Comportamiento de proyectos TI: Están en deuda!


¡En Deuda! por supuesto no estoy de acuerdo, y tengo varios argumentos, y voy a exponerlos en este y varios post más.


El post de Alejandro parte mencionando el famoso Chaos Report, del que algo hemos hablado en el pasado, pero va más allá, porque aporta otras interesantes cifras, como esta encuesta artículo en Dr Dobbs Journal. Vamos a ir por parte, a ver si le encontramos sentido y si debemos reconocer esta deuda o no (ya tengo muchas deudas para tener que asumir una más).

El tema es polémico, por cierto, porque da para todo tipo de cifras, y abusos. Por ejemplo, Oracle dice que el 90% de sus proyectos son exitosos (toma!). Bueno, ya saben lo que dice House, todos mienten! 

En este post nos preocuparemos del Chaos Report, y dejaremos para otros artículos el seguir analizando las otras fuentes interesantes que aporta Alejandro, para terminar con una reflexión sobre la naturaleza del software, y porque creo que no es aplicable esta supuesta deuda.

El Reporte del Caos


Desde 1994 el reporte del Standish Group, el famoso Chaos Report,  se ha vuelto en el patrón dorado sobre la calidad de los proyecto TI, la conclusión lapidaria es: sólo el 15% de los proyectos TI tienen éxito. y nos muestra este bonito gráfico:

exito_2.png

¡Pero que desastre! Por qué no me dedico a otra cosa mejor...


Hay varias cosas que decir sobre este reporte: ¿cuál es la definición de éxito o fracaso? ¿qué tipos de proyectos se analizan? ¿de que envergadura? 

Robert Glass se hace las mismas preguntas que me hago yo con respecto a este reporte, en su artículo de agosto de 2006 de la Communications of ACM: "The Standish Report: Does It. Really Describe a Software Crisis?"

"Ha habido mucha discusión en las últimas décadas sobre algo llamado  "la crisis del software". Aquellos que hablan de tal crisis alegan que los proyectos de software están siempre sobre el presupuesto, con retraso, y son poco fiables.

Esta manera de pensar sobre una crisis del software representa una condena de la práctica del software. La imagen que se pinta es la de un campo del cual no se pueden esperar productos válidos.
...

Pero es importante retroceder y hacer algunas preguntas sobre este pensamiento de crisis:

        • ¿Representa a la realidad?
        • ¿Está soportado por los resultados de la investigación?
[...] La realidad es, puedo afirmar, que estamos en medio de lo que los sociólogos llaman la era de la información, una era que sería simplemente imposible sin una plenitud de proyectos de software exitosos. ¿Acaso esto sugiere que el campo del software está realmente en crisis? No de acuerdo a mi manera de pensar.

,,, A primera vista, hay una gran cantidad de publicaciones que concluyen que realmente existe esta crisis.Muchos estudios académicos aseguran  que la crisis del software es la razón detrás del estudio particular sobre el que están abogando, un concepto cuya intención es hacer frente y quizás solucionar esta supuesta crisis.
Los gurús del software a menudo se enfrascan en esta misma defensa, y con esta enmarcan su tópico favorito como solución a la crisis.

Pero hay un problema subyacente aquí. Muchos de estos artículos académicos y reportes de gurú citan la misma fuente para esta preocupación por la crisis, un estudio  publicado por el Standish Group más de una década atrás, un estudio que reporta altas tasas de falla, del 70% o más, y minúsculas tasas de éxito, un estudio que condenaba la práctica del software por el título que emplearon para la versión publicada de su estudio: El Reporte del Caos.

Así que el reporte de Standish podría ser considerado fundamental para muchas de las reclamaciones sobre la crisis. ¿Qué sabemos realmente de este estudio?

Esa pregunta es de una creciente preocupación en el campo. Varios investigadores, interesados en encontrar los orígenes de esta información clave, han contactado a Standish y les han pedido una descripción de su proceso de investigación, un resumen de sus últimos descubrimientos, y en general una discusión erudita de la validez de sus descubrimientos. Ellos han planteado estas cuestiones porque muchos estudios de investigación conducidos por académicos e investigadores de la industria llegan a datos largamente inconsistentes con los resultados de Standish.

Dejenme decirlo de nuevo. Los resultados de estudios objetivos no soportan, en general, las conclusiones de Standish.

Repetidamente estos investigadores que han preguntado a Standish han sido rechazados. Es aparente que Standish no ha intentado, al menos en el pasado, compartir mucho sobre de donde vienen los datos usados para el Reporte del Caos.
Y esto, por supuesto, plantea un cuestionamiento a la validez de sus conclusiones.

Pero ahora hay una nueva noción acerca de estos resultados de Standish. Un par de investigadores, peinando cuidadosamente el reporte original de Standish, descubrieron una descripción clave de donde podrían venir estos resultados. El reporte dice, en palabras propias de Standish, "Nosotros entonces llamamos y enviamos por correo un número confidencial de encuestas a una muestra aleatoria de altos ejecutivos IT, preguntándoles que compartieran historias de fracasos."

Noten las palabras al final de la oración: "..compartieran histoias de fracasos." Si esta es, de hecho, la base de contactos que Standish hizo con sus participantes en las encuestas, entonces los resultados del estudio están obviamente sesgados hacia los reportes de fracasos. ¿Y que importancia tiene si el 70% de los proyectos que son sujetos de historias de fracasos eventualmente fallan? No mucha.

Hay un dramático caso de deja vu acá. En los 1980s era popular citar la noción de la crisis del software citando el Estudio GAO, un reporte de la Accounting Office del gobierno norteamericano que reportaba una terrible tasa de de fracasos entre los proyectos de software estudiados. Pero en este caso, después de haber ido demasiado lejos, un investigador alerta re leyó el Estudio GAO y encontró que  este admitía, bastante abiertamente, que este era un estudio de proyectos conocidos por estar fracasando en el momento en que los datos eran recolectados. Una vez que este problema fue identificado el Estudio GAO fue rápidamente desechado como cita para soporta la noción de crisis del software. Es interesante que el primer estudio de Standish apareció no mucho después.

Glass termina preguntándose si será cierto que el estudio de Standish adolece del mismo problema que el Estudio GAO, y la verdad es que no sabemos. A pesar de que le han solicitado muchas veces la información al grupo Standish no ha sido posible obtenerla.

Hay una entrevista en InfoQ a Jim Johnson, de Standish, donde se le pregunta directamente sobre las críticas de Glass a su trabajo, les dejo el enlace,  para que juzguen por si mismos, personalmente creo que elude el tema.

En lo personal creo que el Chaos Report debe dejar de ser considerado serio hasta que las legitimas dudas de Glass y otros hayan sido resueltas.

Deuda Técnica

| Sin comentarios | Sin trackbacks

Me encuentro en mi trabajo ante una gran carga de trabajo debido a los siguientes factores:

  1. Un proyecto de desarrollo de larga duración (casi 2 años).
  2. un mini proyecto para re escribir un pequeño sistema, bajo presiones de cumplir con plazos normativos estrechos.
  3. modificaciones a un sistema fundamental que es la base para nuestras operaciones.
  4. la re escritura total de un sistema.

El caso 1 tiene su equipo, que es externo, y a pesar de ser grande y muy importante, está controlado. El segundo es un cambio inesperado, e impuesto por una autoridad externa, debemos hacerlo, sí o sí. Los casos 3 y 4 son productos de la deuda técnica.

Deuda Técnica

El concepto de deuda técnica se lo debemos a Ward Cunningham (*)

La deuda técnica es una metáfora que nos ayuda a pensar en este problema. En esta metáfora hacer las cosas de una manera rápida nos genera deuda técnica, de una forma similar a la deuda financiera. Al igual que las deudad financieras, la deuda técnica incurre en pagos por concepto de interés, en la forma de esfuerzo extra que tenemos que hacer en los desarrollos futuros debido a las decisiones de diseño rápidas y descuidadas que tomamos. Podemos elegir en seguir pagando intereses, o podemos pagar el capital mediante la refactorización del diseño en algo mejor pensado. Aunque hay un costo al pagar este capital, ganamos porque los intereses a pagar en el futuro se reducen.

Esta metáfora también explica por qué puede ser sensible tomar una aproximación rápida y sucia. Del mismo modo que un negocio incurre en deudas para tomar ventajas de las oportunidades del mercado, los desarrolladores deben incurrir en deuda técnica para poder lograr un plazo importante. El problema común es que las organizaciones en desarrollo dejan que su deuda siga fuera de controls y gastan mucho de sus desarrollos futuros pagando grandes intereses.

Las presiones de los clientes, y de los usuarios por tener un sistema funcionando dentro del tiempo que ellos requieren puede ser una fuente habitual de deuda técnica. Ante esto muchas veces tomamos la decisión de salir al mercado con un diseño no acabado, o incompleto, o no totalmente probado. Esas decisiones deben tomarse, y no es que esa decisión sea incorrecta, o mala (lo perfecto es enemigo de lo bueno). Lo importante es ser conscientes de esa deuda, y transmitir las consecuencias a los afectados. Por que al final, todas las deudas se pagan.


En este video Ward Cunnigham explica el concepto.

(*) Ward Cunningham es el creador del concepto de Wiki, entre otras cosas. 

Motivación Personal

| Sin comentarios | Sin trackbacks

Un caminante encontró a tres hombres, trabjando en na cantera, picando piedras.
Se acercó al primero y preguntó:

- Disculpe, buen hombre, ¿qué está haciendo?
- ¿No lo ve? Pico piedra. Debo ganarme el jornal.
Entonces, se acercó al segundo hombre y preguntó:
- Disculpe, ¿qué está haciendo?
- Fácil. Labro la piedra para construir un bello y sólido muro.
Y, finalmente, se acercó al tercer hombre y preguntó:
- Oiga, disculpe la pregunta pero, ¿qué está haciendo?
- ¿Yo? Yo construyo catedrales.

notre_dame_at_night.jpg

Las Técnicas de Dreystadt

| Sin comentarios | Sin trackbacks

La Segunda Guerra Mundial esta llena de historias de mujeres que trabajaron tomando el rol de los hombres, que se encontraban combatiendo. Esta es una de esas.

Imagen Thumbnail para Norden.jpg

En 1940 Alemania era el país lider en óptica, con fábricas como la de Carl Zeiss en Jena and of Ernst Leitz en Wetzlar. No había nada mejor fuera de Alemania, y esto era crucial para desarrollar instrumentos ópticos usados, por ejemplo, en los bombardeos de precisión. Es por esto que el ejercito alemán consideraba a la óptica como uno de sus recursos estratégicos.

En 1940 los militares alemanes consideraban que a los aliados les tomaría una generación preparar "artesanos ópticos" capaces de producir los visores de bombardeo de alta calidad como los de elos.

A principios de 1940 Estados Unidos contaba con un prototipo de visor de bombardeo de calidad, el "Norden", desarrollado por el ingeniero holandés Carl Norden. Lo malo es que no contaban con una industria óptica que pemitiera producir los miles de visores necesarios para las necesidades de la guerra.

De acuerdo a Peter Drucker, en esa época el jefe de la divisón Cadillac de General Motors, Nicholas Dreystadt aceptó el contrato de defensa para la producción en serie del visor de bombardeo Norden. Todo el mundo sabía que esta labor requería de mecánicos con un alto grado de habilidad. Durante la guerra no había gente para emplear, menos mecánicos de alto nivel.

Este es el relato en las palabras de  Drucker:

Imagen Thumbnail para bwwii.png

La única mano de obra que se encontraba disponible en Detroit eran viejas prostitutas negras. Ante el horror de todos Nick Dreystadt contrató a 2.000 de ellas. "Pero contraten a sus cabronas también", dijo. "Ellas saben como administrar a las mujeres". Muy pocas de estas mujeres podían leer y el trabajo requería seguir largas instrucciones. "No tenemos tiempo para enseñarles a leer", dijo Nick, "y pocas aprenderán de todas maneras." Así que fue al mesón de trabajo y por si mismo construyó una docena de visores. Cuando supo como hacerlo, tomó una cámara y filmó el proceso. Montó los cuadros de la película separadamente en un proyector y los sincronizó con un diagrama de flujo. en el cual una luz roja se encendía para mostrarle a la operadora lo que ya había hecho, una luz verde para indicarle lo que tenía que hacer a continuación, y una amarilla para mostrarle lo que tenía que revisar antes de tomar el siguiente paso. Este es el procedimiento estándar actual para un proceso masivo de ensamblado; fue Dreystady quien lo inventó. En pocas semanas estas operarias analfabetas y no calificadas fueron produciendo un mejor trabajo que los mecánicos altamante calificados habían hecho antes.


Lamentablemente esta historia no tuvo un final feliz, al finalizar la guerra, Dreystadt tuvo que enfrentarse al poder de los sindicatos, y tuvo que despedir a todas las mujeres que trabajaron en la planta de construcción de visores Norden.


Norden2.jpg

Eolas ataca de nuevo

| Sin comentarios | Sin trackbacks

En 2005 les contaba sobre el Caso Eolas:

Eolas significa "Embedded Objects Linked Across Systems" (objetos incrustados enlazados a lo largo de sistemas +/-). Pero en gaelico significa Sabiduría.

Los muchachos de Eolas tienen una patente desde 1994 que cubre la incrustación de objetos en browsers internet.

De acuerdo a la página de tecnología de Eolas la patente cubre, "los browsers para la web que soporten tecnologías populares como componentes ActiveX, applets Java y plug-ins para navegadores".

Por supuesto una vez obtenida la patente fueron contra el pez mas grande, y las emprendieron primero contra Microsoft, ganando unos 500 millones de dolares...

Cuatro años se tomaron en Eolas para ir detrás de las otras empresas:

Es más o menos obvio que Eolas tiene en la mira a Macromedia (ahora Adobe) y a Sun. Incluso Firefox puede ser afectado. Esto es tan dañino que hasta el W3C habia decidido combatir a Eolas, solicitando la búsqueda masivas de pruebas de "prior art", todo esto con el fin de que la oficina de patentes de Estados Unidos reconsiderara la patente entregada. Pero, aunque no sabemos en que va la cosa, Microsoft decidió que definitivamente los plugins deberán ser activados explícitamente por el usuario.

No sabemos el acuerdo al que llegaron Microsoft y Eolas, pero ahora la empresa anuncia  que la demanda incluye a dos patentes de Eolas: la U.S. Patent No. 5,838,906 ('906 Patent) y la U.S. Patent No. 7,599,985 ('985 Patent).

La patente '906 fue el objeto de litigio contra Microsoft en 2004 y que terminó con el resultado de 565 millones de dolares a favor de Eolas. De acuerdo a Eolas la oficina de PAtentes de Estados Unidos ha confirmado la validez de la patente '906 en tres procesos distintos, incluyendo dos  nuevos exámenes, el más reciente de los cuales concluyó en febrero de 2009.

De acuerdo a Eolas, la patente '985 es una continuación de la patente '906, y permite a los sitios webs agregar aplicaciones incrustadas totalemente interactivas a su oferta en linea a través del uso de los plug-ins y AJAX (asynchronous JavaScript and XML) como técnica de desarrollo web. La patente '985 fue otorgada en octubre de 2009.

Esta vez Eolas está demandando, entre otros a: Adobe, Amazon,   Go Daddy, Google, Sun Microsystems Inc. (por lo tanto a Oracle), Yahoo, y Youtube.

El diagrama de abajo corresponde a un esquema de como opera la patente '985 de octubre de 2009:

Eolas_985_patent_diagram.png
















Como pueden apreciar practicamente toda la dinámica de la Web 2.0 y de Ajax está cubierta por esta patente.

Un resumen de la patente la describe así:

Un sistema que permite al usuario de un programa navegador en un computador conectado a un hipermedio abierto y distribuido, acceder y ejecutar un programa objeto incrustado. El programa objeto es incrustado en un documento hipermedia de la misma forma que los objetos de datos.

El usuario puede selecciona el programa objeto desde la pantalla. Una vez seleccionado el programa se ejecuta en el computador del usuario (cliente) o puede ejecutar en un servidor remoto o computadores remotos adicionales organizados como procesadores distribuidos.

Después de lanzar el programa objeto, el usuario es capaz de interactuar con el objeto dado que la invención provee de la comunicación entre procesos necesaria entre la aplicación el programa objeto y el programa navegador.

Esta patente fue solicitada en 2002.

Esto de las patentes de software tiene muchos paralelos con la guerra fría, y la amenaza de las armas nucleares, las potencias se armaron con patentes de modo de asegurar la destrucción mutua (ya saben, yo tengo esta patente, pero no te demando si tu no me demandas por esa otra patente que tu tienes). En general las empresas grandes tienen las patentes en su arsenal pero tienen miedo de usarlas para no desatar una apocalipsis de las patentes.

Pero no contaban con que un chico se hiciera con una patente también, es como el caso de Irán, o Corea del Norte desarrollando armas nucleares. Solo que en el caso de las patentes el chico ya ha lanzado las bombas.

software-patent-graph.png


BloGalaxia website stats

Sobre este archivo

Esta página es un archivo de las últimas entradas en la categoría Desarollo.

CyberEntomología es la categoría anterior.

Educación es la siguiente categoría.

Encontrará los contenidos recientes en la página principal. Consulte los archivos para ver todos los contenidos.

Recibe La Naturaleza del Software por Correo Electrónico

Ingresa tu dirección de email:

Despachado por FeedBurner

Technorati

Búsqueda en Technorati

» Blogs que enlazan aquí

Páginas

Subscribirse