Feeds:
Entradas
Comentarios

Posts etiquetados ‘software’

Es evidente que esta reducción de costos a gran escala es lo que hace imparable a la revolución tecnológica.

Fuente: barrapunto

Antti Palosaari, desarrollador del Kernel de Linux, ha descubierto un modo no documentado en un sintonizadores de TV digital con chip Realtek RTL2832U, permitiendo sintonizar por software entre las frecuencias de 64 a 1700MHz (e.g. mapa de radiofrecuencias de España y EE.UU.), por un coste de sólo 11 USD (hay equipos dedicados para tal cosa mucho más caros, e.g. el USRP N200 cuesta 1500 USD). De esta manera, en principio, se podría acceder a comunicaciones de radionavegación aeronáutica, radio FM, canales de radio para aeronáutica, canales de cuerpos de seguridad, TV, telefonía GSM, señal del sistema de posicionamiento Galileo y GPS, etc. Visto en Slashdot.

Read Full Post »

Fuente: La Pastilla Roja

Suele ser la tónica habitual que los desarrollos de software realizados a medida se queden en propiedad del cliente. En realidad, da igual si se quedan o no, porque lo que se desarrolla suele estar hecho tan a medida que es imposible en la práctica reutilizarlo en otro sitio. Más aún, yo he visto muchos proyectos de software desarrollado internamente con la intención de venderlo también fuera después y casi siempre es un fracaso. Existen algunas excepciones, por ejemplo Stephen O’Grady menciona en un post cómo la base de datos IMS de IBM surgió del Programa Apolo de la NASA, a esto O’Grady lo denomina el modelo del software extraído.

El modelo del software extraído es extraordinariamente atractivo para el emprendedor ya que es una alternativa a la financiación de capital riesgo. Es por ello que repasaré a continuación en qué se basa.

1º) Un cliente no va a hacer un desarrollo a medida parecida a ningún software estándar que ya esté en el mercado. Entonces, mi primera idea es que no se puede “extraer software” de un nicho de mercado que ya esté “commoditizado”.

2º) Para que un proyecto a medida se apruebe internamente, debe proporcionar una ventaja competitiva muy clara, o, alternativamente solucionar un problema muy perentorio y preocupante. Ello suele conseguirse mediante el empleo de alguna novedosa tecnología o técnica procedimental. Segunda idea pues, no se puede extraer software empleando sólo tecnología madura. No quiero decir con ello en absoluto que lo contrario sea cierto, que sólo se deba emplear tecnología experimental. Nosotros mismos hemos extraído mucho software Java y .NET, es más, resulta más sencillo extraer Java o .NET que extraer Ruby o Python. Lo que sí sucedía es que dicho software además de estar escrito en un lenguaje maduro, contenía innovaciones técnicas y de proceso de negocio que sí eran claramente diferenciales.

3º) El proyecto debe empezar por algo pequeño por lo que sólo un puñado de gente apueste un céntimo y, si el piloto tiene éxito, entonces extenderlo rápidamente. Esto es porque si el software a extraer empieza con un megaproyecto de alcance corporativo entonces empezarán a implicarse demasiados departamentos cada uno arrimando el ascua a su sardina y al final lo que salga será un híbrido que hará todo pero no servirá para nada por ser el fruto de que en comercial querían un Ferrari y en producción querían una furgoneta. Además, si el proyecto es grande, se convertirá en objetivo de los tiburones de consultoría quienes argumentarán que es demasiado grande e importante como para que lo haga una startup.

4º) El cliente debe ganar más cediendo el software al proveedor que manteniéndolo él mismo en solitario. Hay varias formas de regular esto. Cliente y proveedor podrían pactar un acuerdo de reparto de beneficios por la venta. Pero yo creo que lo mejor es persuadir al cliente de que se quede con una parte y permita que el proveedor tome propiedad del resto con la condición de liberarlo como Open Source. Esto es porque a fin de cuentas el negocio del cliente no es vender software, ergo un acuerdo de reparto de royalties puede provocar que la agenda de desarrollo y comercialización de futuras versiones dependa de intereses del cliente contrarios a los del proveedor.

5º) Los competidores deben de poder adoptar el software sin que ello resulte lesivo para ninguna de las partes. Se suele tener mucho miedo de que la competencia copie mejores prácticas, y es una preocupación razonable. La mala noticia es que lo van a hacer de todas formas. Ninguna ventaja competitiva ganada invirtiendo en tecnología dura para siempre. La única oportunidad que tiene el primer cliente es la de llevarle entre 3 y 5 años de ventaja a la competencia en cuestiones de eficiencia tecnológica. Por otro lado, el ecosistema de clientes debe de ser de tal naturaleza que les permita compartir software. Compatir secretos técnicos siempre parece a priori del todo inviable, pero recordemos que hasta las armas más modernas están disponibles en el mercado para quien pueda pagar su alto precio.

6º) El software debe estar diseñado, desarrollado e implantado desde el principio para extraerlo. Ello implica que debe ser más modular de lo que sería un software a medida estrechamente acoplado a las necesidades del cliente. Y también que todos los interfaces entre los módulos deben de estar totalmente exentos de “dependencias raras”. Por último, hay que hace run esfuerzo mayor en generar documentación durante el proceso de desarrollo que sirva como guía para los implantadores que vendrán detrás.

Si se cumplen las condiciones anteriores, el software extraído puede ser una forma fantástica de lanzar una empresa porque cuando el primer proyecto termina, la startup tiene:

1º) Una estructura de costes que se autofinancia con los ingresos del cliente.
2º) Un producto terminado.
3º) Una referencia comercial importante.
4º) Cero deuda.

Sólo hay que tener cuidado con una cosa más, cuando termina el proyecto del primer cliente, hay que reducir los gastos al mínimo, siendo frecuentemente necesario reducir plantilla (a veces es posible hacerlo fácilmente traspasándo mano de obra al cliente). Esto es debido a que aunque la startup sepa cómo fabricar software y ponerlo a funcionar, corre el peligro de escalar demasiado pronto cuando aún desconoce otros aspectos clave por ejemplo sobre cómo contratar comerciales y hacer marketing para ganar prospectos. Tras el primer proyecto exitoso puede ser un buen momento para coger deuda, pero dicha deuda no debe utilizarse para mantener a un equipo sobredimensionado de programadores ociosos mientras esperan a que alguien cierre la siguiente venta.

Read Full Post »

Fuente: la pastilla roja

Leyendo el post de José Luis Mortadelo y yo y las cárnicas del software, iba a titular esta entrada de una forma más sensacionalista. Algo así como “Las ETTs del Software” o “Las Factorías de la Precariedad”. Pero sería injusto y erróneo generalizar de esa forma y meter a todas las software factories en el mismo saco.

El pasado 7 de noviembre Fernando Barciela publicaba en El Pais Negocios que la facturación de las factorías de software españolas ha pasado de 26,7 millones en 2004 a 376 millones en 2008 y sigue creciendo a un ritmo superior al 20% anual.

A principios de 2009 ya comentábamos en La Pastilla Roja que las TIC están siendo inmunes a esta crisis. Aunque es poco probable, en mi opinión, que España se convierta en una gran potencia relevante en near shore europeo de desarrollo de software y a continuación explicaré porqué.

Casi todos los colegas de Grupo Tibi me dicen que 2010 ha sido un buen año. Los empresarios tienen tendencia a ser optimistas crónicos, pero para KnowGate también ha sido un buen año, de modo que les creo. En general, todas las empresas de externalización de servicios van bien. Esto es debido a que se está desintegrando el mercado de trabajo y en la medida en la que las empresas contratan menos trabajadores propios se ven en la necesidad de subcontratar más por la vía mercantil para cubrir sus necesidades de tecnologías de la información. Como los salarios en las capitales de provincia son más bajos que en las grandes ciudades, las empresas encuentran en las factorías de software una buena fuente de mano de obra barata.

El trabajo de los informáticos es tanto el desarrollo de software como la atención diaria de sistemas (devops) y actualmente es perfectamente posible realizar dicha operación de sistemas desde lugares remotos a través de una línea segura.

Otro factor en juego es que es difícil encontrar buenos técnicos. Formar a un buen informático (como a cualquier otro buen ingeniero) cuesta largos años de inversión que luego los clientes no pueden o no quieren pagar porque el precio les parece una burrada. La solución adoptada es entonces la del McDonald’s: si no puedes encontrar un buen chef pues montas un restaurante de comida que a la gente le guste pero donde nadie sepa realmente cocinar. Este es el proceso de industrialización del software. Se trata de dividir el desarrollo en etapas compartimentalizadas y super especializadas en las cuales cada persona implicada sólo necesite unos conocimientos muy específicos y sea fácilmente substituible.

Ya hay desde hace tiempo programas que se desarrollan de esta manera, en el software bancario, por ejemplo, las empresas tratan de eliminar su dependencia de los programadores superhéroe, se invierte menos en salarios de los peones programadores y en lo que se gasta mucho es en pagar a quienes diseñan y controlan el proceso industrial.

Articulo completo

Read Full Post »

Software vs. Copyright

Fuente: Via Libre

Un noviazgo auspicioso

Por muy razonable que a mucha gente le parezca el hecho de que el software esté sometido2 al copyright 3 , se trata en realidad de una decisión arbitraria, adoptada como resultado de las negociaciones que, en los ‘70, se realizaron para encontrar un marco regulatorio para los programas de computadora.

En defensa de esta decisión, diré que subyace a ella una observación correcta de la naturaleza de los programas como construcciones culturales, no técnicas, como obras que se escriben y no productos que se manufacturan. Esta observación es crucial, en cuanto reconoce la capacidad expresiva de los programas de computadora, como el vehículo idóneo que permite a las personas comunicar algoritmos, de la misma manera que las partituras permiten comunicar música o las ecuaciones permiten comunicar ciertas verdades matemáticas.

Tratar al software como la obra expresiva que es tiene consecuencias importantes y beneficiosas para la sociedad. Implica, por ejemplo, que el derecho a la libertad de expresión se aplica tanto a quienes se expresan en código como a quienes se expresan en castellano o en notación musical, reconocer al software como parte de nuestra cultura, a la que los Derechos Humanos nos garantizan acceso, y que el régimen al que se lo someta debe tener como objetivo fomentar su difusión para ponerlo al alcance del público.

Otra implicación importante es que el objeto de la regulación es la obra (el programa) y no su función: si yo escribo un programa para que la computadora realice determinada tarea, otras personas pueden escribir otros, distintos, que resuelvan el mismo problema, sin que haya conflictos legales. La actual controversia en Estados Unidos sobre las patentes de software, muestra las consecuencias que hubiera tenido considerar al software, erróneamente, como producto y no como obra: en ese país, es posible obtener una patente sobre “utilizar un programa para resolver el problema *X*,”, y a partir de ese momento el titular de la patente es la única persona con derecho a escribir programas que resuelvan *X* 4.

Un matrimonio conflictivo

Si bien el reconocimiento de la naturaleza expresiva de la programación hace evidente que las patentes no son el marco regulatorio adecuado para el software, esto no quiere decir que el copyright necesariamente lo sea o, al menos, que sea razonable aplicar exactamente el mismo copyright, de exactamente la misma manera, a programas que a libros o canciones.

El elemento que más fácilmente se identifica en el derecho de autor como inadecuado para el software es el de la duración. El copyright es un monopolio limitado en el tiempo, con la idea de que, una vez expirado, la obra que pasa al dominio público sigue siendo útil. En el caso de la mayoría de las obras musicales y literarias, podemos asumir que seguirán siendo útiles durante un tiempo muy largo 5 , los programas tienen una vida útil muy limitada. La rápida evolución de los diseños de hardware y el surgimiento constante de nuevos entornos de aplicación hacen que ningún programa sea útil sin modificaciones a escasos cinco años de ser publicado. Un programa que entrara en el dominio público diez años luego de ser publicado ya sería inútil para fines prácticos.

Hay otro aspecto menos obvio en el cual la transacción social implícita en el copyright no se cumple para el software. Cuando un autor publica una obra bajo copyright, (un libro, una pintura, una composición musical), esta queda inmediatamente a la vista del público. El público puede estudiarla, analizarla, desmenuzarla y apreciar todos los aspectos que hacen a la construcción de la obra. Esto no ocurre necesariamente cuando la obra es un programa: los programadores tienen la posibilidad de ejercer el monopolio sobre la obra sin necesidad de revelarla.

Esto es posible gracias al hecho de que hay varias representaciones de un mismo programa, algunas de las cuales son prácticamente imposibles de comprender por el ser humano porque están diseñadas para ser interpretadas por una máquina. Por supuesto, las personas que programan no usan esas representaciones directamente, sino que usan lenguajes de programación, notaciones formales diseñadas para ser fácilmente comprensibles para quienes las conocen, aunque al ojo no entrenado aparezcan como una cruza entre el inglés y las matemáticas. Un programa para calcular la raíz cuadrada de un número, por ejemplo, podría escribirse así en el lenguaje “C“:

/* Esta función imprime la raíz cuadrada de su argumento */
static void printsqrt(float x) {
if (x < 0) /* la raíz de un numero negativo es imaginaria */
printf(“El numero es menor que cero!\n”);
else /* el numero es positivo, todo bien */
printf(“%f\n”, sqrt(x));
}

En este trozo de código puede apreciarse la intención comunicativa del programa, expresado en una notación “humana” que incluye notas aclaratorias de la intención del autor y las razones por las que toma ciertas decisiones, de modo que pueda ser entendido por otra persona. Esta representación del programa en forma comprensible a los humanos es lo que suele llamarse “código fuente” del programa6. Lo que la computadora ejecuta, sin embargo, no es el código fuente, sino el resultado de traducirlo, mediante un proceso automático, en *lenguaje de máquina*. Un programa en lenguaje de máquina consiste en una larga lista de instrucciones codificadas numéricamente, que listan en detalle las operaciones elementales que el procesador debe ejecutar. Cuando traducimos el programa de más arriba para que pueda ser ejecutado en máquinas de tipo “PC,” todos los elementos comunicativos desaparecen, y queda reducido a la siguiente lista de números::

2212858197 1171855596 3673086216 2665537513
250282615 1680082119 3892839557 4294967036
1171856363 605871368 4294901736 610065919
604292868 134514050 4294893544 1438894591

El problema consiste en que el derecho de autor no sólo se aplica a los programas en su forma legible sino también al software en lenguaje de máquina, aún cuando sólo se distribuye el segundo, y no el primero. Pero la transacción del copyright se basa en la idea de que el autor obtiene del público un monopolio sobre la obra a cambio de socializarla. Cuando un programa se distribuye sólo en lenguaje de máquina, esa socialización no se produce, y el público es estafado.

Los hijos reclaman el divorcio

Mucho ha escrito ya la `Free Software Foundation’7 acerca de los daños que los monopolios sobre la distribución de software causan en la sociedad como un todo, criminalizando actitudes valiosas como la solidaridad de compartir con nuestros semejantes. Pero más allá de eso, la manera en que aplicamos el copyright a los programas sin prestar atención a aquellas características que lo diferencian de otros medios de expresión cultural atenta contra su florecimiento como tal.

La práctica generalizada de la distribución de software sin código fuente (más parecido, estrictamente, al ejercicio de un secreto industrial que al de un derecho de autor) entorpece la capacidad de quienes ejercen la disciplina de aprender unos de otros, como ocurre en las demás artes. Dificulta, además, el ejercicio efectivo del derecho de autor sobre aquellas obras que sí han sido publicadas como código fuente: resulta muy difícil descubrir y demostrar que cierto programa contiene un plagio de otro cuando no contamos con el código fuente del primero, sino sólo con una lista de números dentro de la cual puede estar, o no, escondida una de muchas posibles traducciones del programa.

El resultado de esta distorsión es fácil de reconocer la práctica: un mercado de grandes corporaciones que privatizan para sí las obras de sus empleados, manteniendo el monopolio sobre su distribución sin enriquecer el acervo cultural común ni aportar obras útiles al dominio público, al tiempo que corren muy poco riesgo de ser descubiertas cuando incorporan en sus programas obras de terceros.

Queda por preguntarse cómo sería el paisaje de software actual si en aquellas negociaciones de los ‘70 hubiera prevalecido la idea de que el software requiere un régimen similar al copyright pero adaptado a su naturaleza específica, con duraciones drásticamente menores y exigiendo la publicación del código fuente.

En todo caso, la gran cantidad de desarrolladores de software libre, que deliberadamente renuncian a imponer condiciones restrictivas a la distribución, estudio y confección de obras derivadas de sus programas no sólo desmiente de plano que el copyright sea necesario para el desarrollo de la disciplina, sino que demuestra, por construcción, que un ambiente de cooperación y colaboración es mucho más fértil que uno de aislamiento y restricción.

  1. Este texto forma parte del próximo libro de Fundación Vía Libre para la Feria de Frankfurt []
  2. Es común leer que el software está “protegido” por derecho de autor. Lamentablemente, quienes usan esa imagen suelen olvidar decir *de cuáles riesgos* está siendo protegido, y por lo tanto resulta difícil decidir si la protección es tal. Decir que el software está sometido al derecho de autor refleja más fielmente lo que está ocurriendo: todo software está bajo derecho de autor, independientemente de los deseos de sus autores y usuarios. []
  3. En este texto hablaré de “copyright” en vez de “derechos de autor,” porque aquel resume al subconjunto de los derechos de autor que son reconocidos en la mayor parte del mundo. A los efectos de la discusión, el argumento no cambia. []
  4. Un detalle interesante es que tal patente se puede obtener *aún si quien la solicita no ha escrito todavía el programa, ni tiene intenciones de escribirlo*. []
  5. La exagerada duración actual del copyright hace que esa asunción aparezca como exageradamente optimista: es altamente probable que, setenta años luego de la muerte del autor, ya no haya ejemplares viables de la obra, ya sea por degradación del medio (papel, vinilo, celuloide) o porque la obsolescencia del formato hace que no haya dispositivos que permitan acceder a ellas. ¿Cómo escucharíamos hoy música grabada en un magazine de ocho pistas? []
  6. Una exposición más a fondo de la diferencia entre lenguaje de programación y lenguaje de ejecución puede leerse en `¿Qué es el código fuente? `_ []
  7. http://fsf.org []

Read Full Post »

Fuente: barrapunto

Jonathan Schwartz, ex-CEO de Sun, escribe en su blog Los buenos artistas copian, los grandes, roban (traducción): «Lo siento por Google, Steve Jobs también intentó demandarme. [...] En 2003, Steve llamó a mi oficina tras presentar un prototipo de escritorio para Linux llamado Looking Glass, para hacerme saber que los efectos gráficos estaban “robando la propiedad intelectual de Apple”. Si lo llegáramos a comercializar, “Te demandaré”. Mi respuesta fue sencilla: “Steve, estaba viendo tu última presentación, y Keynote parece idéntico a Concurrence, ¿esa propiedad intelectual es tuya?”. Concurrence era un programa de presentaciones creado por Lighthouse Design, una empresa que ayudé a fundar y que Sun compró en 1996. Lighthouse desarrolló aplicaciones para NeXTSTEP, el sistema operativo basado en Unix cuyo núcleo fue la base de todos los productos de Mac, tras la compra de NeXT por parte de Apple en 1996. Steve usó Concurrence muchos años, y cuando Apple hizo su propia herramienta de presentaciones, es obvio dónde encontraron la inspiración. “Y la última vez que miré, MacOS estaba basado en Unix. Creo que Sun también tiene unas cuentas patentes del sistema operativo”. Steve no dijo nada. Y esa fue la última vez que oí hablar del tema». En la entrada, Schwartz también cuenta cómo Bill Gates quiso sacar tajada de Sun por OpenOffice.

Read Full Post »

Seguir

Recibe cada nueva publicación en tu buzón de correo electrónico.

Únete a otros 96 seguidores