Archivo de la categoría: Software libre

Entradas sobre software libre

Coste del sofware: modos de venta, ¿cómo afectan al precio?

Ya hemos visto cómo saber cuanto cuesta una aplicación informática, desde un punto de vista práctico. No se va a entrar en detalles de cómo valorar el precio a priori (con COCOMO o con los Puntos de Función) ya que no es algo que se me de especialmene bien y porque el propósito no es valorar el desarrollo, sino una instalación que hagamos nosotros.

Normalmente, nunca vamos a ser quienes realicemos el software, sino que compraremos uno hecho. La razón de comprar el software tiene como motivación la adquisición de derechos de mantenimiento. Esto es especialmente importante si somos una empresa ya que, ante cualquier problema, necesitaremos que alguien nos ayude a arreglarlo.

En esta situación, el encargado de elegir la solución informática que más le interese, tendrá el deber de elegir entre las diferenes soluciones de que disponga. En general se resumen en dos:

  • Compra una licencia de un paquete ya hecho
  • Contratar a una empresa para que desarrolle la aplicación a medida

Con la primera opción se obtiene mejor precio, ya que la compañía que desarrolla la aplicación divide el coste en muchas partes con la esperanza de obtener beneficio a largo plazo. Este mecanismo permite también, que las compañías puedan enriquecerse por aplicaciones que venden mucho.

La segunda opción supone un desembolso mayor. La razón es que tenemos que pagar todo el desarrollo (los programadores, el desgaste de las máquinas, etc.), pero como contrapartida, la aplicación será nuestra, no solo una copia. Este caso es el más sencillo de entender: el coste está directamente relacionado con el coste del desarrollo más el beneficio de la empresa que lo haga.

Cuando se compran licencias, lo que se compran son derechos de uso. Existen muchas aplicaciones empresariales cuyas licencias son temporales. Aunque sale más barato, puede que a largo plazo sea mucho más caro.

El modo de calcular el precio de un software que se vende por licencia es sencillo. Este software a costado X. Si se vende por Y, entonces con la venta de X/Y copias ya está amortizado su desarrollo. Cualquier copia extra de más que se venda es beneficio. Lo lógico es invertir este benefico en el propio software para mejorarlo. También es lógico pensar que si el software ya está produciendo beneficios, su coste puede reducirse.

La realidad es que estas empresas no reducen el precio de la licencia y, en muchas ocasiones, no reinvierten el beneficio en mejoras. Lo que suelen hacer es una nueva versión y la venden, empezando de nuevo el ciclo. Esto supone que a largo plazo, las licencias que pagamos están sobrevaloradas, costando realmete mucho menos de lo que pagamos.

Para poder entender esto mejor, primero hay que darse cuenta de que hacer copias de una aplicació n software no cuesta dinero, podemos hacer infinitas por un coste casi nulo. Esto supone que no se pagan las copias, sino sólo una parte del desarrollo.

Con lo explicado hasta ahora, ya deberíasmos ser capaces de empezar a valorar un software (lo que ha costado y por cuanto nos lo venden) y también debemos ser capaces de darnos cuenta de que en muchas ocasiones puede que nos estén estafando con el precio. En los siguiente artículos que va a seguir viendo un poco de esto, sobre todo el apartado de las licencias. También vamos a empezar a ver los costes reales para una empresa de utilizar varios modelos de venta software para su funcionamiento interno (desde el punto de vista de que es la empresa que compra el software).

Por último me gustaría pedir disculpas por haber realizado un artículo un pelín extenso, pero creo que era un poco difícil dividirlo.

Coste del sofware: Cómo medirlo II

Vimos en el artículo anterior como medir lo que nos cuesta realizar una aplicación informática. Esta medición es desde el punto de vista del empresario (lo que me cuesta realmente hacerlo). Pero dejé algunas cosas en el tintero.

La razón de que no las contase tiene que ver con el hecho de que ya no estamos en el ámbito del fabricante de software, sino en el del mercado. Esto es, ya no mido el coste únicamente por lo que me cuesta hacerlo, sino que también interviene la situación del mercado. Esto es lo podríamos denominar como valoración especulativa.

La razón de llamarlo especulativo se debe a que se basa a hecho que no son valorables económicamente, sino que especulamos en cuánto puede repercutir sobre el precio alguna condición. Las principales condiciones que pueden repercutir sobre el precio del software son las siguientes:

  • Imagen de la empresa
  • Calidad del software
  • Demanda en el mercado
  • Novedad (cómo de novedoso es)

Como vemos, estas condiciones no se dan únicamente en el software, sino que repercuten a la mayoría de los productos (coches, ropa, etc.). No voy a entrar en más detalles, ya que no me parece algo sencillo de valorar (no me dedico temas de economía).

Esta vez no me he excedido mucho. Siento haber tardado en publicar este segundo artículo, pero estoy muy escaso de tiempo gracias al PFC.

Proximo capítulo: modos de venta, ¿cómo afectan al precio?

Debian y kde 3.4.2

Ayer decidí arriesgarme. Actualicé de kde 3.4.1 a 3.4.2 aún a sabiendas de que perdería bastantes aplicaciones. Pero ahora lo tengo es castellano.

Las aplicaciones ya las iré poniendo poco a poco, conforme salgan de nuevo.

La cosa no pinta mal, todo funciona perfectamente, así no me quejaré, pero espero que repongan superkaramba, baghira y kxdocker pronto.

Coste del sofware: Cómo medirlo

Para conocer cuanto nos va a costar algo, tendremos que saber cómo medir dicho coste. En el caso de hacer la comida, será el coste de los ingredientes más el del gas (si usamos fuego) o electricidad (para los que usen microhondas/vitrocerámica/etc.). La pregunta es, ¿cómo medir el coste de un producto software?

Que yo conozca, para medir el precio de un producto software se viene utilizando COCOMO y COCOMO II, que miden el precio a partir de líneas de código fuente escritas y los Puntos de Función de Albrecht, que utiliza su propio mecanismo: el punto función. Este se puede convertir a pernonas-mes, a líneas de código, etc.

Personalmente, creo que estos mecanismos tienen un problema: sólo sirven para hacer estimaciones. El precio real vendrá dado a la finalización del desarrollo del producto software. Es en este momento cuando sabremos realmente su precio.

El precio del producto software, en el momento de su terminación viene dado por (principalmente) el coste de la mano de obra. Esto es, si tenemos un trabajador que cobra 1000€ mensuales programando durante 3 meses, el coste será de 3000€ más el beneficio. En concreto, los principales costes del desarrollo del un producto software son:

  • El personal involucrado
  • El material utilizado (principalmente papel, lápices, bolígrafos).
  • Desgaste de los equipos(impresoras, computadoras, etc.)
  • Otros gastos: teléfono, gasolina (cuando se hacen visitas al clientes), etc.

Como podemos apreciar, el coste de un producto software se ve influido por muchos elementos, pero existen más elementos que pueden influir en este coste (los iremos viendo en los próximos artículos). Pero esto nos permite saber una cosa: el precio que nos cuesta hacerlo es lo que gastamos para hacerlo. El precio que nos cuesta comprarlo es lo que le cuesta a otro hacerlo más un beneficio (no tiene porqué ser así, como ya veremos).

Ya sabemos como medir el coste (con algo objetivo). En los próximos artículos veremos que puede hacer variar este coste y su precio final. También veremos cómo valorar el coste de una instalación (hardware+software).

Hasta el próximo artículo.

Coste del software: Introducción

Mucho se habla sobre si es más barato implantar software libre frente a software propietario (o viceversa). Hemos visto gran cantidad de informes diciendo que si es más barato GNU/Linux, que es más barato MS Windows, pero en ningún caso estos informes tienen en cuenta según que detalles (por ejemplo, si la aplicación a utilizar existe en uno y en el otro no).

Con este panorama, creo que es necesario explicar cómo saber cuando es más barata una solución y cuando otra, teniendo en cuenta todos los elementos posibles. Para ello estoy preparando unos artículos que nos permitan entender mejor cómo valorar este tipo de productos.

Espero que esto sea de utilidad. La mayor parte de las cosas que explicaré serán obvias, pero no viene mal comentarlas. También se tratarán detalles sobre los modelos de venta que actualmente se utilizan.

Para terminar, pediros que no seáis impacientes, ya que puede que me lo tome con algo de calma.

Sobre la licencia GPL y LGPL (II)

Antes que nada, darle las gracias a David por su reconocimiento, pero… ¡No me las merezco! No he hecho más que copiar (espero que la licencia GPL sea GPL :P). Las partes en inglés son copiadas y las traducciones también (me voy yo a poner a traducir… ¡Anda ya!).

Lo de las licencias tiene su tema. Es complejo (sobre todo si no eres un chupasang… abogado). La verdad es que haría falta un estudio que comparase estos casos concretos (MySQL, QT y el resto que tengan dobles licencias). Por ejemplo, en las librerías QT (en el código) pone lo siguiente:

/****************************************************************************
**
** Copyright (C) 1992-2005 Trolltech AS. All rights reserved.
**
** This file is part of the core module of the Qt Toolkit.
**
** This file may be distributed under the terms of the Q Public License
** as defined by Trolltech AS of Norway and appearing in the file
** LICENSE.QPL included in the packaging of this file.
**
** This file may be distributed and/or modified under the terms of the
** GNU General Public License version 2 as published by the Free Software
** Foundation and appearing in the file LICENSE.GPL included in the
** packaging of this file.
**
** See http://www.trolltech.com/pricing.html or email sales@trolltech.com for
**   information about Qt Commercial License Agreements.
** See http://www.trolltech.com/qpl/ for QPL licensing information.
** See http://www.trolltech.com/gpl/ for GPL licensing information.
**
** Contact info@trolltech.com if any conditions of this licensing are
** not clear to you.
**
** This file is provided AS IS with NO WARRANTY OF ANY KIND, INCLUDING THE
** WARRANTY OF DESIGN, MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.
**
****************************************************************************/

Que viene a decir que puedes elegir o QTL o GPL, pero no pone que si usas código cerrado debas utilizar QTL (y pagar). Aquí el problema es de interpretación de la licencia GPL (ver el artículo anterior).

La verdad es que se puede proponer a GUL-doc realizar el estudio.

Por ahora prefiero no tratar más este tema, al ser problema de interpretación, podríamos pasarnos toda la vida discutiendo.

Sobre la licencia GPL y LGPL

Para hacer un final contundente sobre lo de las dobles licencias y la posibilidad de hacer software propietario con la GPL, expongo a continuación un fragmento de la licencia GPL, para ser más exacto, el punto 2.b:

You must cause any work that you distribute or publish,
that in whole or in part contains or is derived from the Program
or any part thereof, to be licensed as a whole at no charge to all
third parties under the terms of this License.

Que traducido dice:

Debe hacer que cualquier trabajo que distribuya o publique y
que en todo o en parte contenga o sea derivado del Programa
o de cualquier parte de él sea licenciada como un todo, sin carga
alguna, a todas las terceras partes y bajo los términos de esta Licencia.

Como Programa se entiende (ver punto 0 de la licencia):

This License applies to any program or other work which contains
a notice placed by the copyright holder saying it may be distributed
under the terms of this General Public License. The "Program",
below, refers to any such program or work, and a "work based on the
Program" means either the Program or any derivative work under
copyright law: that is to say, a work containing the Program or a
portion of it, either verbatim or with modifications and/or
translated into another language. (Hereinafter, translation is
included without limitation in the term "modification".) Each licensee
is addressed as "you".

O dicho de otro modo, en la licencia GPL, Programa es toda aquella aplicación bajo los términos de la licencia.

Con esta información, se entiende que si se enlaza un programa propietario a una librería bajo los términos de la licencia GPL, este debe ser también GPL ya que utilizará partes con GPL.

Para salvar esta situación, se incluye en la licencia lo siguiente:

These requirements apply to the modified work as a whole.
If identifiable sections of that work are not derived from the
Program, and can be reasonably considered independent and
separate works in themselves, then this License, and its terms,
do not apply to those sections when you distribute them as
separate works. But when you distribute the same sections as
part of a whole which is a work based on the Program, the
distribution of the whole must be on the terms of this License,
whose permissions for other licensees extend to the entire
whole, and thus to each and every part regardless of who wrote it. 

Que traducido queda como:

Estos requisitos se aplican al trabajo modificado como un
todo. Si partes identificables de ese trabajo no son derivadas
del Programa, y pueden, razonablemente, ser consideradas
trabajos independientes y separados por ellos mismos,
entonces esta Licencia y sus términos no se aplican a esas
partes cuando sean distribuidas como trabajos separados.
Pero cuando distribuya esas mismas secciones como partes
de un todo que es un trabajo basado en el Programa, la
distribución del todo debe ser según los términos de esta
licencia, cuyos permisos para otros licenciatarios se
extienden al todo completo, y por lo tanto a todas y cada una
de sus partes, con independencia de quién la escribió.

De este modo, si enlazo con la librería, no hace falta convertir a GPL el programa, porque no es un todo… ¿O sí? Supongo que eso dependerá de varios fatores:

  • Si se enlaza estáticamente, si sería un todo, por lo que debe convertirse en GPL
  • Si se enlaza dinámicamente y si siempre distribuyes tu aplicación con dichas librerías, ¿sería un todo o solo la suma de las partes?

Este segundo punto queda un poco oscuro y supongo que dependerá de la interpretación de cada cual.

La licencia LGPL surgió como mecanismo para evitar problemas de este tipo. Con ella, se puede enlazar (siempre que sea dinámicamente) con librerías y nunca habrá problemas de licencia. Está pensada precisamente para ello.

Volviendo al punto que empezó esto, las QT: si la licencia es GPL (sin modificaciones), me da igual que mi aplicación sea o no propietaria, puedo enlazarla sin que tenga que pagar a trolltech. Igualmente pasa con MySQL. La única razón que estas (MySQL y Trolltech) tendrían para obligarte a pagar sería la interpretación del segundo punto anterior, ya que de otro modo, la licencia GPL te eximiría del cambio de licencia de tu aplicación.

De todos modos, esto creo que es mejor que nos lo explique un abogado o estudiante de derecho (Sergio, ¿te apuntas?).

Enlaces:

Sobre KDE y QT

No es por empezar un flame (nooooooooo :P), pero como no soy capaz de poner comentarios en las entradas de voiser, pues lo pongo como entrada en mi bitácora.

Lo primero es sobre la licencia de QT: es libre, tanto para MS Windows como para Linux, bajo los términos de la licencia pública GNU GPL). Por tanto, no es necesario pagar si tu aplicación es comercial. Esto pasaba con la antigua licencia. Entonces… ¿cuál es el problema? Que si quieres hacer una aplicación y no quieres publicar su código fuente, no la puedes enlazar a librerías con licencia GPL (en este caso deberás utilizar librerías cerradas o con licencia LGPL). Por tanto, no te queda más remedio que pagar por una licencia de QT comercial.

Probablemente el problema con la licencia QT sea más bien que se entiende que una aplicación comercial debe ser de código cerrado cuando esto no tiene porqué ser así.

Sobre el modelo de desarrollo de KDE-gnome hay poco que decir: si haces mal las cosas desde el principio, te tocará empezar de nuevo cada vez (¡pero qué malo que soy! :P). El mayor problema con el proyecto gnome es su total desintegración. Con esto me refiero a que no hay casi nada integrado, todo es diferente. Puede que a la mayoría de nosotros (programadores, administradores) no nos importe mucho, pero para el usuario final sí que es importante. De poco sirve añadir tecnología si eres incapaz de que nadie lo use. Esto ya lo decía hace unos meses el desarrollador principal de firefox (desgraciadamente no encuentro el enlace).

Sobre el desarrollo de KDE decir que se basa en QT, que lo desarrolla Trolltech. No puedo decir mucho más, ya que no tengo ni la más mínima idea de qué hacen estos.

De momento nada más, si se me ocurre algo ya lo pondré.