Mark Dixon, desarrollador de Enerjy, ha escrito una interesante entrada en el blog de la empresa donde anuncia que esta herramienta para el análisis de código será a partir de ahora gratuita. En palabras de Mark, "hemos decidido que vender herramientas de desarrollo Java no es un modelo de negocio viable para nosotros". Esta decisión fue influenciada por tres sucesos:
1. En la pasada Java One, los productos gratuitos dominaron la escena. A pesar de que la gente se acercó al stand de Enerjy por los regalos, prácticamente no hubo interés por comprar la herramienta.
2. Agitar, la empresa que desarrolla herramientas para realizar pruebas a código Java, al final ha empezado a cerrar operaciones después de cambiar varias veces de modelo de negocio sin conseguir obtener ganancias razonables.
3. Las ventas de Enerjy han sido más lentas de lo previsto.
Al parecer se dieron cuenta que no era viable seguir cobrando por un producto si los desarrolladores prefieren no pagar por este tipo de herramientas. Por ello, el plugin para Eclipse de Enerjy es gratuito a partir de ahora y se comprometen a seguir desarrollándolo. Incluso para aquellos que lo han comprado después del 1 de abril de este año, se podrá negociar un retorno del dinero.
En el mundo Java existen empresas que han podido construir un modelo de negocio alrededor de la venta de sus productos, como el caso de Jira o IntelliJ; sin embargo ante la proliferación de productos gratuitos, este es un modelo de negocio cada vez más complicado para seguir. ¿Es más difícil hacer dinero ahora con el software que en el pasado o es simple cuestión de un cambio en los modelos de negocio ?
Por lo mientras, nosotros los desarrolladores tenemos disponible sin cargo alguno una magnífica herramienta para el análisis de nuestro códgio: Enerjy.
Yo si creo que es más dificil hacer dinero con el software, sobre todo como producto. El panorama ha cambiado y para que el desarrollo de productos de software comercial se va quedando relegado a nichos, por otro lado se potencia la adaptación, personalizacion, integración y "paquetizacion" de software ya hecho.
Lo que cambia un poco la perspectiva es que ahora el desarrollo de nuevos productos nace más de la "buena voluntad" o de las necesidades propias, mas que del deseo de hacer negocio. Como modelo de negocio tambien tiene sus perversiones, como una empresa grande comprando un producto de nicho y haciendolo OS solo para hundir el negocio de un posible competidor que esta creciendo demasiado...
El tiempo, como en todo, nos dirá que tal. Lo que está claro es que hoy en día no se puede ignorar.
"¿Es más difícil hacer dinero ahora con el software que en el pasado o es simple cuestión de un cambio en los modelos de negocio ?"
Yo creo que la respuesta está en la primera frase del link de anuncio:
"After much thought, we have decided that selling Java development tools is not a viable business model for us..."
En este caso, no me parece que se puede generalizar a todo el software en general, ni mucho menos. Simplemente (y sin conocer Enerjy hasta que se ha publicado esta noticia) me parece que han sido demasiado optimistas, y lo digo pensando en mis desarrollos:
Es por lo que creo que de este caso concreto no se pueda extrapolar al software en general...
Salu2
Hace unos días atras Jonathan Schwartz hablando de los resultados del tercer trimestre de SUN en su blog, defendía la misma idea de que las empresas no compran licencias para desarrollar, las ganacias etán en otro lado (por ejemplo el brindar servicio con/para el software). Cito textual:
"... ¿Por qué no abandonan la estrategia de distribuir el software gratuitamente? Porque nuestra prioridad es la adopción por parte de los desarrolladores..."
Acá la entrada completa: http://blogs.sun.com/jonathan_es/entry/el_tercer_trimestre
Realmente los que se adapten y entiendan este nuevo modelo (salvo excepciones) les costará mucho crecer y ganar.
"Ironically, I was putting together my own budget for next year and realized that there just aren’t any software purchases on there. We’ve bought a few specialized pieces of software - Mathematica for the index work; JProfiler for performance tuning and Atlassian’s Jira and Bamboo - but we’ve moved to free tools for everything else. Atlassian has insane maintenance prices, so if anything happened to Jira or Bamboo, we’d almost certainly replace them with Trac and something like Hudson."
Sigue el tio, confirmándome ;-) Si cambian a trac y hudson desde luego estarán tan contentos como yo ;-) No se ya si empiezo a estar harto de tanto "entrepreneur" con la cabeza metida en el propio culo (vender algo que ni tu mismo compras), que luego le echa la culpa al mundo de sus males...
Salu2
greeneyed: Lo que cambia un poco la perspectiva es que ahora el desarrollo de nuevos productos nace más de la "buena voluntad" o de las necesidades propias, mas que del deseo de hacer negocio.
Considera que alguien de una empresa farmacéutica o un fabricante de automóviles o una constructora, vamos prácticamente cualquiera excepto alguien obviamente del mundo del software. Yo creo que diría "joder esta gente está muy pirada".
Me resulta difícil pensar en una constructora que fabrique sus propios materiales y maquinaria de construcción de acuerdo a "sus necesidades propias". Me resulta difícil pensar también que alguien con "buena voluntad" diseñe el motor de un automóvil y lo entregue al resto de la industria "by the face". O un hospital que fabrique sus propios medicamentos hechos por su personal en sus ratos libres para satisfacer sus necesidades internas.
Ponte en el lugar de una empresa grande o pequeña, qué más da, en donde sus sistemas de información fueran absolutamente críticos, pensaría "joder por lo que se dice por ahí a saber lo que nos están poniendo en nuestros servidores la empresa X que hemos contratado para desarrollar y mantener en nuestros sistemas, programas hechos a ratos libres con buena voluntad o productos diseñados para resolver las necesidades internas de otros que a lo mejor no encajan ni con cera en nuestro ámbito, parece que esto es lo propio del mundo Java, deberíamos cambiarnos úrgentemente a un proveedor de Microsoft, pues Microsoft NO HACE ESO".
Lo que quiero decir en resumen es que si es verdad lo que dice greeneyed lo mejor es que nuestros clientes finales no se enteren.
Pues yo creo que lo que está ocurriendo es al revés y lo estamos viendo todos los días, que productos de "buena voluntad" (Linux, JBoss, Ext-JS, los primeros que se me vienen a la mente) o surgidos de necesidades internas propias (GWT hecho para satisfaces las necesidades de Google, SWT en el caso de IBM) se están convirtiendo en motor de negocio. Ciertamente el modelo de negocio está cambiando.
Yo creo que se llegará a un equilibrio, en mi opinión el doble licenciamiento en el caso de software de código abierto o el modelo versión community/enterprise serán el futuro.
Si esto no funciona yo creo que tendremos un futuro muy oscuro en la industria del software donde habrá montones de programas y herramientas hechos a base de ratos libres con calidad muy variable y de altísima incertidumbre y sólo unos pocos productos de alta calidad hechos por muy grandes empresas sin embargo usando presupuestos marginales a fondo perdido pero con el fin de satisfacer algún tipo de necesidad interna o motivación monopolística, es decir productos orientados a la satisfación de necesidades indirectas de las empresa que los fabrica y no tanto para satisfacer las necesidades de los usuarios finales de los mismos.
Por ejemplo Google ¿alguien cree que Google hace software claramente orientado a qué tú lo uses para tus clientes sin dependencias con Google?, NO. Google tiende cada vez más a que su software sea la puerta de entrada al mundo de servicios que ofrece, el software de Google conduce cada vez más a sus servidores, lo cual no digo que sea malo en sí mismo, es simplemente un hecho, el Google App Engine es un paso importante en esa dirección.
Lo que quiero decir en resumen es que si es verdad lo que dice greeneyed lo mejor es que nuestros clientes finales no se enteren.
Pues yo creo que lo que está ocurriendo es al revés y lo estamos viendo todos los días, que productos de "buena voluntad"... o surgidos de necesidades internas propias...se están convirtiendo en motor de negocio.
¿Que parte exactamente de lo que has dicho es "al reves" de lo que he dicho yo? Por que yo he dicho exactamente lo mismo. Que los productos ahora nacen de la "buena voluntad" y de las necesidades propias... si en vez de "nacer" lo quieres llamar "ser motor de negocio"... :).
Despues de tanto ejemplo de empresa etc. y luego dices lo mismo. Por si se me ha malinterpretado, no era en tono peyorativo. Lo unico que queria decir es que a estas alturas de la pelicula plantearse que vas a hacer un software relativamente comun y vas a poder venderlo como producto, no parece muy comun.
Por cierto, en cuanto a lo de buena voluntad... no quisiera entrar en polemicas pasadas pero no incluiria ExtJS ni tampoco JBoss a partir de un periodo :). El modelo version community/enterprise lo veo mas viable, el de doble licenciamiento lo veo mas problematico en algunos casos, lease Ext, pero como tu lo usas esta claro que no compartes mi opinion ;).
Y perdon que se me habia olvidado:
Considera que alguien de una empresa farmacéutica o un fabricante de automóviles o una constructora, vamos prácticamente cualquiera excepto alguien obviamente del mundo del software. Yo creo que diría "joder esta gente está muy pirada".
Si no ves la diferencia com producto entre el software y la maquinaria o los materiales usados en construccion... pues ahi no voy a entrar. Si hubiera disqueteras lo suficientemente grandes como para meter una casa y hacer copias baratas, por ejemplo, lo de la crisis hipotecaria iba a ser un cumpleaños para niños :).
greeneyed: ¿Que parte exactamente de lo que has dicho es "al reves" de lo que he dicho yo?
Quería decir que cada vez más la "buena voluntad" tiende a convertirse en negocio e incluso los productos que nacen como necesidades internas de una empresa también tienden a convertise en negocio, es el caso de Google, productos internos los "liberan" pero al mismo tiempo con la intención de atraer otros hacia el mundo Google, es decir como motor de negocio. NetBeans (Sun) y Eclipse (IBM) no están lejos de este análisis, ambos sirven para el mundo de servicios que ellos mismos (Sun e IBM) dan y también por supuesto para atraer a terceros.
greeneyed: Si no ves la diferencia com producto entre el software y la maquinaria o los materiales usados en construccion...
Acepto la ironía :)
El ejemplo de la industria farmacéutica no es malo, una pastilla por sí misma puede ser fácilmente clonable, "el valor" de la pastilla no es que dicha pastilla no pueda ser reproducible por otros (la "diskettera" existe) sino más bien el valor de la molécula, resultado de años de investigación, la molécula una vez creada y comprobada su eficacia puede ser "fácilmente" reproducible. Sin embargo la industria farmaceútica funciona porque la molécula está patentada y por tanto protegida. Yo NO estoy a favor de las patentes en el software pero SÍ a favor de la propiedad intelectual.
Un CD con el código fuente de Linux tiene un valor inmenso ¿por qué? porque si alguna empresa fuera capaz de comprar la propiedad intelectual de Linux pasaría a controlar millones de ordenadores especialmente servidores.
Tenemos que llegar a un modelo en donde la propiedad intelectual de valor al software independientemente de que el código sea abierto o cerrado y que el uso de dicha propiedad intelectual no sea siempre gratis, al igual que cuando una empresa de servicios cobra a su cliente final no le cobra el valor de un CD fácilmente copiable. De otra manera estaremos asumiendo que nuestro software NO tiene valor alguno.
Lo que quería decir es que tu frase de "buena voluntad" y "producto surgido de la solución a las necesidades internas de una empresa concreta" es el vivo retrato de un industria claramente amateur.
El primer caso no admite más explicación, en el segundo hablo de "amateur" en el sentido de que salvo que exista un esfuerzo de "universalización", soporte, adaptación, continuidad etc suena a "no nos importa hacer público nuestro producto interno que nos sirve a nosotros por si te sirve porque somos así de simpáticos".
Te pongo un ejemplo: SWT, SWT ha tenido su función, dar lugar a Eclipse en los tiempos en los que Swing no daba la talla, quizás SWT no tenga hoy futuro desde un punto de vista puramente técnico. El problema es que posiblemente el único futuro asociado a SWT sea el de seguir haciendo funcionar Eclipse y no el de satisfacer las necesidades de los muchos desarrolladores que basaron su software en SWT. Podemos llegar a la paradoja de que el viejo COBOL tenga más garantías de soporte y de futuro que algunas herramientas actuales supermodernas.
greeneyed: el de doble licenciamiento lo veo mas problematico en algunos casos, lease Ext
El doble licenciamiento no lo inventó Ext, MySQL tiene ese modelo desde hace mucho tiempo. El SpringSource Application Server es GPL y tiene toda toda toda la pinta de que usará doble licenciamiento para las aplicaciones que lo usen y las críticas han sido mínimas.
A Ext le han llovido las críticas no tanto por tener doble licencia sino por la evolución de sus licencias, básicamente un producto que no era de pago se vuelve de pago. Yo podía haber hecho lo mismo con ItsNat para parecer más abierto, más guay, más free, más community, pero sencillamente me pareció inmoral, desde el principio las cosas claras.
El ejemplo de la industria farmacéutica no es malo, una pastilla por sí misma puede ser fácilmente clonable, "el valor" de la pastilla no es que dicha pastilla no pueda ser reproducible por otros...
No estoy de acuerdo. Sinceramente, si "clonar" un medicamento fuera tan sencillo como copiar software, otro gallo les cantaria a los enfermos en Africa. Para tener una disquetera en este caso has de ser una empresa y como tal, eres blanco "facil" de abogados. En el caso del software, la diferencia en facilidad de creacion y copia es abismal. O al menos yo no creo que cualquiera con cuatro cursos y el quimicefa pueda hacerse sus propios medicamentos, ofrecerlos por Internet etc.
No entiendo la interpretacion que haces de que suene a amateur, cuando por necesidades propias y "buena voluntad" se pueden hacer cosas igual de profesionales, aunque bueno, si es cierto que me he dejado un caso y es el de "segundas intenciones", que es donde entraria tanto la parte de liquidar un competidor como el de atraer mercado a un producto/servicio relacionado.
En cuanto a lo de la propiedad intelectual, estoy de acuerdo en que deberia tener un valor y ese es un problema que no esta resuelto actualmente y sí es un problema. Por que no sola hay que llegar a una solucion justa sino ademas aplicable al mundo en el que vivimos, donde copiar esa propiedad intelectual es muy sencillo e intentar impedirlo es ponerle puertas al campo.
¿Quien ha dicho que el doble licenciamiento lo invento Ext? ¿Quien ha dicho que el problema por la doble licencia de Ext sean las criticas? ¿Quien ha dicho que la doble licencia sea siempre un problema? No se de donde has sacado eso, pero no es lo que yo he dicho.
Y la mitad de las criticas hacia Ext son por la evolución, ciertamente curioso ademas teniendo en cuenta sus origenes, pero la otra mitad es por la licencia libre escogida en el modelo dual. Y antes de que volvamos a MySQL y SpringSource Application Server, sería bueno hacer notar que en ambos casos estamos hablando de servidores y no librerias. Como ejemplo de librerias, el driver JDBC de MySQL es GPL sin problemas por que se puede usar normalmente a través de un API independiente (JDBC), y las librerias de Spring no usan GPL sino la licencia Apache. ¿Casualidad? Yo no lo creo.
greeneyed: No estoy de acuerdo. Sinceramente, si "clonar" un medicamento fuera tan sencillo como copiar software, otro gallo les cantaria a los enfermos en Africa.
Es "sencillo" por eso Brasil e India están clonando "ilegalmente" ciertos medicamentos (es ilegal en un sentido legalista, no necesariamente inmoral, pero este un tema que se sale de javahispano) y por eso cuando una patente caduca surgen los genéricos como setas. De todas formas estoy de acuerdo con lo de África.
greeneyed: estamos hablando de servidores y no librerias
Hombre Daniel tu sabes que un servidor de aplicaciones es una librería que abre sockets (por SpringSource) y que MySQL se accede a través de una librería, el driver JDBC.
greeneyed: Como ejemplo de librerias, el driver JDBC de MySQL es GPL sin problemas por que se puede usar normalmente a través de un API independiente (JDBC)
Umm, NO, cualquier "binding cercano" a una librería GPL convierte todo en GPL, la capa JDBC es un mero wrapper de interfaces a los objetos del driver GPL de MySQL, si ese "truco" fuera válido para sortear la GPL la GPL no valdría para nada y la LGPL no tendría ningún sentido.
La inmensa mayoría de aplicaciones Java accediendo a MySQL son aplicaciones que en teoría son GPL (seguro que la gran mayoría de los propietarios esas aplicaicones ni lo saben), como son aplicaciones internas no pasa nada, pero si se rascara sería otra cosa. Sun con la compra de MySQL ha comprado un buen caramelo desde el punto de vista legal.
Es "sencillo" por eso Brasil e India están clonando...
Hombre, sencillo, sencillo... no creo que para copiar un programa haga falta ser un pais. Y con patentes o sin, yo sigo sin clonarme los genericos en casa, de hecho conozco poca gente que lo haga, incluidos medicos y farmaceuticos.
Hombre Daniel tu sabes que un servidor de aplicaciones es una librería que abre sockets
Esa es una vision muy simplista. La diferencia es que libreria la usas para hacer tu programa, la has de distribuir con el, etc. Un servidor no lo sueles distribuir, ya que se suele tener que instalar in-situ, y sobre el ejecutas tus programas, no estan "vinculados". Y ya he dicho que la libreria JDBC de MySQL es posible gracias al API estandar JDBC. Supongo que sabras que precisamente por el binding y la GPL, el driver JDBC de MySQL fue durante un tiempo licenciado por separado como LGPL. Aunque tu creas que no, hay diferencia entre un servidor y una libreria y por eso suelen usarse licencias diferentes.
Umm, NO, cualquier "binding cercano" a una librería GPL convierte todo en GPL, la capa JDBC es un mero wrapper de interfaces a los objetos del driver GPL de MySQL, si ese "truco" fuera válido para sortear la GPL la GPL no valdría para nada y la LGPL no tendría ningún sentido.
Ahi te equivocas. Si haces tu software de forma que pueda funcionar sin usar la pieza GPL, no dependa de ella, tu software no tiene por que ser GPL. Y eso es lo que se usa precisamente. Si n, ahora mismo cualquier programa del mundo con el API JDBC deberia ser GPL, ya que podria usarse con el driver MySQL que es GPL y por tanto, zas. Para eso estan los wrappers y los APIs estandar.
La inmensa mayoría de aplicaciones Java accediendo a MySQL son aplicaciones que en teoría son GPL (seguro que la gran mayoría de los propietarios esas aplicaicones ni lo saben), como son aplicaciones internas no pasa nada, pero si se rascara sería otra cosa.
No. Si tu aplicacion puede funcionar en diferentes BDD, legalmente no esta vinculada a MySQL y por tanto no tiene que ser GPL. Por supuesto no puedes incluir MySQL en el producto, antes podias incluir el driver JDBC pero ahora ya no. Cuando se distribuye este software, no esta ligado para nada a MySQL, ni incluye librerias suyas, asi que desde el punto de vista de licencia, no hay nada que decir. Si un usuario se instala MySQL y ejecuta el programa contra esa BDD, no es el propietario del software y ademas no esta distribuyendo, asi que tampoco se aplica.
Si ni siquiera a través de wrappers se pudiera usar software MySQL, aun menos empresas lo usarian. Si es cierto en el caso en que estas aplicaciones esten hechas especificamente para funcionar con MySQL, accedan a APIs propietarias del driver o incluyan la BDD o el driver.
Por otro lado, no se a que refieres a que "como son aplicaciones internas no pasa nada, pero si se rascara sería otra cosa". Si no hay distribución de la aplicacion, la GPL no actua, punto. Así que usar productos GPL en una empresa internamente sin distribuirlos es totalmente legal, e incluso modificarlos y combinarlos con lo que te de la gana. Mientras no distribuyas el producto.
Yo creo que no me has entendido lo fundamental de la analogía de la industria farmacéutica. Quería poner con ese ejemplo que una empresa farmacéutica es una empresa:
1) Volcada totalmente en hacer un producto para terceros "no para consumo interno" e invirtiendo mucho dinero.
2) El producto está protegido por patentes porque la complejidad de la fabricación de la molécula no protege en absoluto el producto. El "coste" del fármaco no está en la fabricación sino en los muchos años de investigación en encontrar/diseñar la molécula que sirva para tal enfermedad no tanto para fabricarla. Si cualquier empresa tuviera el derecho de fabricar y vender la molécula del Viagra no tendríamos Viagra porque Pfizer no hubiera gastado un céntimo en su investigación. Esto no quita que existan grandes abusos y que deba trasladarse este modelo "literalmente" al mundo del software como quieren algunos.
3) La complejidad de las enfermedades que se quieren tratar y los recursos a emplear están lejos de la buena voluntad y no están al alcance ni siquiera de "usuarios corporativos" tal y como hospitales, los hospitales raramente desarrollan fármacos.
Si lo comparamos con cierto modelo de industria del software tendríamos:
1) No hay desarrollo de productos para terceros, como mucho productos internos corporativos que se liberan por si a otro les sirve pero sin vocación de producto ni de servicio a esos terceros. O productos para terceros hechos de forma totalmente voluntarista pero con futuro totalmente incierto.
2) El desarrollo de productos para terceros no tiene ninguna forma de remuneración *directa* por tanto no hay incentivos, recurso a la "buena voluntad" o a productos cuya remuneración es "indirecta". Dicho modelo de remuneración indirecta puede "pervertir" el producto en sí mismo, por ejemplo tener que usar los servidores del que hace el producto supuestamente gratuito, o bien la "obligación" de contratar los servicios de desarrollo de la empresa que lo produce porque "a propósito" existen barreras (uso de marcas, no disponibilidad de binarios, know how oculto, complejidad innecesaria etc) que dificultan dicho uso independiente.
3) Problemas/necesidades complejas o con enorme esfuerzo fuera del alcance de casi todos. Ejemplo: ¿alguien conoce un programa a la altura del AutoCad que sea gratuito?
Respecto a la GPL:
Yo no hablo de un producto que usa JDBC y que no distribuye el driver MySQL como bien dices, yo hablo de que cualquier *instalación* que *usa* el driver JDBC de MySQL. *Si se distribuye* ha de hacerse como GPL, por eso digo que no pasa nada, porque ningún producto se distribuye con el driver del MySQL, se usa siempre en instalaciones. Un wrapper que cambia la API de acceso de una librería GPL por debajo no anula la GPL, obviamente la GPL actúa cuando verdaderamente se usa dicha librería, está claro que JDBC puede no usar el driver JDBC de MySQL pero si en una *instalación concreta* se usa entonces sí, es GPL en el caso de instalar en otro sitio lo mismo a un tercero. Si no ¿como te explicas que la gente de MySQL (ahora Sun) licencie su driver como GPL? ¿para fastidiar? no (o sí según se mire), como una posibilidad de vender licencias por ejemplo para productos que incluyen MySQL (por ejemplo embebido) y no quieren ser de código abierto. Si en este tema los dos más o menos coincidimos.
Todo servidor de aplicaciones expone una API para acceder al mismo a sus aplicaciones por tanto es también una librería. No estoy hablando de un acceso por sockets que es otra cosa (es un binding "lejano" en donde tiene algo que decir la AGPL pero no la GPL).
No acabo de entender si lo que dices del modelo de industria del software lo dices como algo que no ocurre o ocurrirá, como algo que si ocurre, como algo que no es viable a largo plazo... Lo explicas pero no se si pones como ejemplo, contraejemplo, como futuro si no hacemos algo...
Respecto a la GPL, totalmente de acuerdo en lo que dices sobre la licencia,que es lo mismo que yo digo, lo que tu habias dicho que la inmensa mayoria que aplicaciones en Java que usan MySQL deberian ser GPL y eso es donde no estoy de acuerdo. La mayoria usan MySQL a traves de un API independiente y no se distribuyen, asi que no son ni tienen que ser GPL. Si se distribuyen, por supuesto que si.
Y no, no creo que cambiaran la licencia de MySQL a GPL para eso. Y menos para la gente que incluye MySQL embebido puesto que al incluir/requerir MySQL, ya tendria que ser GPL antes, no necesitaban que el driver fuera GLP para eso.
Cambiarle la licencia al driver JDBC no afecta a practicamente nadie, ya que los que no se veian afectados por no requerir/distribuir MySQL, siguen sin verse afectados, y los que usaban APIs nativos de MySQL o su driver JDBC ya hacian que su producto dependiera de MySQL asi que ya tenian que ser GPL antes...
Y podemos sacarle punta sematica a un lapiz y decir que un avion tambien es un cacho de metal que vuela ¿pero por que nadie dice que usa la libreria JBoss o Glassfish o que publica sus paginas web con la libreria Apache? Digo yo que será por que hay alguna diferencia. Y para este caso en concreto las diferencias remarcables es que las aplicaciones suelen requerir e incluir las librerias en sus distribucion ya que sin ellas no funcionan: las distribuyen. En cambio muchas aplicaciones utilizan un servidor pero no lo requieren, podria ser otro que diera el mismo servicio, y no se incluye con la aplicación: no se distribuyen. Y por eso habitualmente las licencias que se usan, o desde un punto de vista de negocio parecen mas recomensables, son diferentes. Por supuesto hay contra-ejemplos en ambos casos, pero mirando las licencias que se usan etc. y el modelo de distribucion etc. se suele explicar por que.
Si hasta la misma GNU tiene escrito en su FAQ que la GPL no es recomendable en todos los casos... y por eso mismo crearon la LGPL.
we’ve moved to free tools for everything else. Atlassian has insane maintenance prices, so if anything happened to Jira or Bamboo, we’d almost certainly replace them with Trac and something like Hudson.
Un apunte para ver las cosas en perspectiva. Mi empresa solo compra productos con mantenimiento, entre ellas alguno de atlassian. La semana pasada hubo una interrupción de 4 horas en una de las aplicaciones. De haber durado exactamente 1/2 hora más habriamos perdido 240.000€ por transacciones no realizadas antes del cierre. Un año de soporte para Bamboo en versión unlimited son 2000€. En este contexto tiene sentido comprar soporte, cosa que muchas grandes empresas hacen.
Respecto a SWT y eclipse, IBM tiene una posición ventajosa gracias a sus aportaciones y continua trabajando en productos basados en esta tecnología. Trabajar con un pie en el futuro significa que los demas pueden copiar lo que tú ya has hecho, pero no lo que vas a hacer.
"La semana pasada hubo una interrupción de 4 horas en una de las aplicaciones. De haber durado exactamente 1/2 hora más habriamos perdido 240.000€ por transacciones no realizadas antes del cierre. Un año de soporte para Bamboo en versión unlimited son 2000€"
Perdon pero es que no he entendido muy bien el ejemplo: "hubo una interrupción de 4 horas en una de las aplicaciones"... Supongo que hablas de alguna de las aplicaciones que hacéis, porque no puedo entender que si se para el Jira o el Bamboo, perdáis "240.000€ por transacciones".
Pero si estás hablando de una de vuestras aplicaciones, lo que no entiendo es porque pagar el mantenimiento de Bamboo os ha servido para recuperaros en 4 horas y no en 4 horas y media. Quiero decir que puedo entender que un mantenimiento de una base de datos 24X7 o de hardware o de ancho de banda, salve la situación, pero no llego a entender tu ejemplo, en el que pagar el mantenimiento de un servidor de build continuo haya solucionado un problema en vuestra aplicación.
Y si el problema de vuestra aplicación es que Bamboo lo desplegaba mal, pues no sé, igual el problema esta en usar Bamboo para desplegarlo, no en si existe mantenimiento o no del servidor de builds.
Salu2
Perdón, ambos hechos no están relacionados. Y sí, puedo entrar en una sala de servidores, pegar un par de tiros en cualquier dirección y continuaría funcionando todo. Solo queria decir que en ciertos entornos tiene sentido usar unicamente aplicaciones con soporte. También supongo que tu comentario sobre los "entrepeneurs" no tiene relación con trac&hudson vs jira&bamboo.
@Anonimo: Si pero en algunos "CPDs", si te peta un encufe se cae todo (Barajas?)
@sida y Africa: (Lei por ahi) Las variantes africanas no remiten tan bien con el cócktel actual (y no son el TARGET de la investigación farmaceútica) ...
La industria farmacológica está fuertemente regulada (talidomida ...): plazos, controles, pruebas, ensayos, certificaciones, permisos. La del sw es casi un cachondeo
Muchas empresan no pagan gran cosa por infraestructura para el desarrollo. La mayoría del sw ni tiene garantias, ni control de calidad, ni suficiente tiempo en el "campo de batalla": todo lo "nuevo" es beta. No hay tiempo (ni presupuesto). Esto, que se llamó crisis del sw, es su estado natural. Muchos vendieron la idea de que ya todo el sw era "infraestructura": costes fijos sin ninguna ventaja competitiva (lo que puede ser cierto para algunos usos). Otros vendieron que las máquinas se programarían solas, o que la IA sería realidad hace años ...
"Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning". - Rich Cook
Lo que antes era lo último hoy es infraestructura (por la que nadie quiere pagar). La infraestructura suele estar financiada por TODOS en muchos sectores (carreteras, redes de comunicacion). El sw se apoya y soporta innumerables layers (capas?) de "infraestructura"/estandares. Quien controla una capa puede dirigir (coaccionar?) lo que se pone por encima y (casi) abstraer lo de debajo (hasta que te pongan otra capa).
Las empresas tratar de "controlar" sus riesgos asociados a la infraestructura mediante contratos de servicio, pero muy poco sw como servicio existe aun. ¿Quién calcula y mide esos rieagos? Y si no se cumplen ¿QUÉ? ¿Nos vamos todos a la calle (cliente destruido y proveedor con rpducto desprestigiado)? El palo ha demostrado ser pedagógicamente inutil, aunque no por eso a dejado de usarse (tendrá su utilidad "psicológica").
JB
PD: Es my fácil, a posteriori, decir que un modelo de negocio/proyecto no es rentable. ¿Quién hubiera dicho hace 10 años que un IDE Java o un servidor de aplicaciones no era un negocio con mucho futuro?¿Quién hubiera dicho hace 30 años que vender el sw a usuarios finales de ordenadores personales era un gigantesco negocio (parece que solo MS lo vio claro desde el principio)?
Personalmente, cuando alguien que trabaja para hacer mejor, más agradable o eficiente mi trabajo fracasa (ya sea por su modelo o por flautas), eso no me alegra.
Si, ya se que esto lo debería poner en mi blog (y dejar solo la postdata) ...
Lo irónico de la tecnología es que si quieres lo "último", vas a pagar mucho y va a funcionar mal (aunque te dará probabilísticamente muchas más prestaciones). Y, si no lo quieres, el precio máximo que estas dispuesto a pagar se acerca a 0 (lo quiero gratis) y, "curiosamente" es mucho más fiablemente. ¿Qué modelo existente explica bien la natureza del sw (sus costes, sus actores, quienes son sus verdaderos autores ...)?
Lo único que tengo claro es que el tiempo de las "cajitas con sw en soporte físico" ya pasó.
JB
"Solo queria decir que en ciertos entornos tiene sentido usar unicamente aplicaciones con soporte."
Pues has puesto el peor ejemplo que se podía poner para justificar un contrato de mantenimiento con Bamboo.
"Personalmente, cuando alguien que trabaja para hacer mejor, más agradable o eficiente mi trabajo fracasa (ya sea por su modelo o por flautas), eso no me alegra. "
1º No me he alegrado de nada.
2º El negocio de Enerjy sigue, no han cerrado. Sólo han cambiado el modelo de negocio.
3º Personalmente, estoy seguro, por experiencia propia, que quien monta una empresa DEBE montarla para ganar dinero. Y eso te lo dirán en la primera media hora de cualquier master de empresas que hagas.
Que luego facilitas la vida a los demás, sanas a los enfermos y acabas con el hambre y las guerras... pues muy bien. Pero una empresa DEBE tener beneficios. Y si me pongo a vender congeladores en el ártico, y me va mal:
a. No merezco compasión.
b. No tengo derecho a quejarme del frío que hace en el ártico como motivo de mi fracaso.
Asi que permitidme que critique que alguien diga que el modelo de negocio está acabado y por eso ha fracasado. Digo yo que la existencia de FindBugs, PMD, CheckStyle, DoctorJ, Hammurapi... (http://pmd.sourceforge.net/similar-projects.html) desde hace BASTANTE tiempo, habrá tenido algo que ver. Para justificarse ante sus accionistas vale, pero estos tios han estado vendiendo neveras en el ártico.
Salu2
anónimo-bamboo dice:
Como ya dije arriba no he vinculado ambos hechos, solo mostrado un ejemplo donde el valor del negocio es muy superior a la licencia de soporte de al menos este producto, que da un servicio mejor que el de su equivalente gratuito. En ese contexto, sea Bamboo, que media en el trabajo de un centenar de personas, u otro, vale la pena contratar soporte.
Cuando el producto es propietario, es fácil adelantar a su equivalente gratuito en funcionalidad. O simplemente, ofrecer soporte a algo ya existente. El problema para la viabilidad de estos negocio es que solo empresas grandes contratan soporte, y estás no son muy numerosas.
En la línea de PMD hay otras herramientas propietarias como devKing. Si tienes el dinero, solucionar una incidencia con devKing es una llamada telefónica, frente a contratar un consultor (que igualmente vale dinero) para trabajar con PMD e intentar solucionar los posibles problemas que le surjan. PMD es estable, tiene una comunidad detras etc, pero no es digamos tan estable como el servidor Apache, y pagando sabes que cq. error se arreglará antes en la herramienta propietaria. Esto no es venta de neveras, aunque su mercado es presumiblemente muy pequeño.
Hola Bamboo (te llamo por tu diminutivo ;-)),
Si te fijas, yo no he dicho que todo sea tirar dinero, ni que Bamboo sea vender neveras. Lo que digo es que a partir de este caso concreto (ANALIZADOR DE CODIGO JAVA) no se puede inferir que todo el negocio del software vaya mal.
De la misma forma, tampoco se puede inferir lo contrario, que por ser deseable pagar el mantenimiento de un servidor de build continuo que media en el trabajo de cien personas, sea deseable pagar el mantenimiento de un analizador de código Java. Simplemente: si el Bamboo se os cae un día, puede dejar a 100 personas de brazos cruzados. Si devKing se cae un día, que pasa? que ese día la gente puede usar System.Out en lugar de log?
Por supuesto que a la hora de contratar un mantenimiento hay que ver el perjuicio que tendría que algo deje de funcionar: en vuestro caso puede ser totalmente razonable pagar por bamboo (en el mío, no). Pero es que no me viene a la cabeza ningún caso en el que una herramienta de análisis de código sea IMPRESCINDIBLE (como indique allá por mi primer post), o que no pueda ser sustituido por una gratuíta, o por el saber hacer de los programadores contratados. Y pagar por pagar tampoco creo que sea la cuestión.
Y sigo creyendo que ESTE caso tiene bastante de vender neveras. A los de Atlassian les va estupendamente, no he dicho yo que vendan neveras, es más, desde mi primer post vengo diciendo que SI hay negocio en vender determinadas herramientas, pero que un analizador de código está más que trillado (razones en mi primer post).
Salu2
Mmm, yo creo que lo único que tengo que decir para editorializar la noticia y los comentarios es que volvemos a la eterna pregunta: ¿El software debe ser considerado como un producto o como un servicio? helppppppppppppppppppppppp!!!
Hola a todos,
Quisiera saber si la herrmienta enerjy me serviria tambien para incorporarla en el Jdeveloper11, de ser posible, alguien podria pasarme un tutorial que explique el uso y manejo de analisis de codigo, ya que tengo un poryecto muy grande para analizar q esta desarrollado con JSF y JPA, por favor alguien pudiera ayudarme!!!
Escribe tu comentario