El futuro de Google App Engine: un marketplace de aplicaciones

Voy a sacar mi bola de cristal y voy a hacer una reflexión sobre lo que creo que será el modelo de negocio principapl de Google App Engine.

Google App Engine es un servicio gratuito hasta unas cuotas bastante interesantes. Es gratis hasta aproximadamente 5 millones de páginas vistas al mes. A partir de ese límite el coste es no obstante bastante asequible. ¿Es este el modelo de negocio principal de Google App Engine? Yo lo dudo. La inmensa mayoría de las aplicaciones no creo que superen esas cuotas, y las que la superen no creo que le den muchos beneficios a Google.

Hay una de las características de Google App Engine de la cual creo que poca gente se ha percatado. Esta característica es que podemos instalar una aplicación de Google App Engine en nuestro dominio si tenemos Google Apps. La autenticación de usuarios en tal caso no se hace contra las cuentas de GMail, sino con nuestras cuentas de nuestro dominio de Google Apps. Por ejemplo ahora Google ha liberado Jaiku, por lo que es sencillo tener un Jaiku que funcione con las cuentas de nuestro dominio. Entonces... podemos tener un Jaiku para nuestra empresa, un Jaiku privado. Y del mismo modo que podemos tener Jaiku, también podemos tener cualquier aplicación hecha para App Engine integrada en nuestro dominio. Y por tanto también integrada con Google Docs, GMail, Spreadsheets, Calendar... pero bajo nuestro dominio.

Es por ello que creo que lo que Google pretende es crear un marketplace de aplicaciones empresariales. En un futuro cuando la plataforma esté más madura podremos acceder a nuestro dashboard de Google Apps e instalar aplicaciones a la carta. Como ya hace la App Store de Apple para el iPhone/iPod Touch, o como el marketplace de Zoho Creator. Por lo tanto habrá personas o empresas que desarrollarán aplicaciones para App Engine y las empresas con cuentas en Google Apps podrán comprarlas e instalarlas a golpe de click. El negocio para Google podría ser quedarse con una comisión de la transacción o suscripción.

Aplicaciones para... la gestión de las vacaciones de los empleados, para facturación, nóminas, seguros sociales, herraminetas de comunicación internas, de gestión documental,...

¿Qué opiniáis? ¿Creéis que Google pretende algo así?

#11   

Más que con la appstore de apple lo compararía con marketplace del SO android del mismo google.

#12   

La idea es bastante buena y seductora, con algunos peros. Las aplicaciones para móviles estilo iPhone suelen ser cerradas y están destinadas a usuarios finales. Las aplicaciones web necesitan en la mayoría de las ocasiones modificaciones y son para servicios a terceros.

#13   

2Saludos y buenas noches casi madrugada :D

@vrruiz es cierto que hay algunos peros en esta premonicion , vision o prediccion de @gimenete pero pero como dics es una idea buena y seductora , tomando esos peros que mencionas no te quito la razon en la misma , una solucion seria la misma que se aplica en las aplicaciones reales , aquel cliente que pide una web normalmente le dejamos el codigo de la misma salvo que quiera que nosotros mantengamos dicho codigo ,sino simplemente el cliente ya con ese codigo obrara como estime conveniente y necesario

Y en este marketplace podria ser igual , tu desarrollas la aplicacion para un cliente y si este te lo solicita le dejas el codigo , se lo pasas por mail o cualquier otra via y que sea ya el entonces el que se encargue de mantenerlo a no ser claro que tu desees cerrar el codigo privando al cliente de las modificaciones que el desee hacer sobre su applicacion web y monopolizando la misma y esclavizandolo a ti y es donde yo si le veo el pero , no deberia permitirse tal cosa de cerrar el codigo de la aplicacion y si lo haces tiene que haber una garantia 100% de que podras darle mantenimiento a ese cliente que ya ha pagado por la aplicacion o que esta pagando una cuota y es en este forma de pago donde quizas se podria hacer la excepcion

si yo pago por una aplicacion para que la haga para mi ME QUEDO CON EL CODIGO aunque al final no lo toque pero tenerlo disponible por si mañana el programador desaparece no tener que tirar muros abajo y volverlos a construir

y la otra serian los clientes de pagos en cuotas mensuales , anuales o demas , ellos si es posible que no necesiten el codigo pero el equipo de desarrollo detras de esa aplicacion tendria que garantizar el mantenimiento de la misma y darle solucion y corregir los errores que aparezcan porque no puede ser que yo pague una cuota y despues no se me de servicio ni solucion a mis problemas

Por eso el pero que planteas espero que no sea uno en mayusculas y se permitan los modelos que uno estime , porque es cierto que haya codigos que a veces deseamos cerrar por x motivos y se nos deberia permitir , lo que no se deberia permitir es que todas sean cerradas y el cliente no tenga el codigo a su alcance para modifircarlo segun necesidades , tambien no debemos olvidar las licencias de software existentes actualmentes , se podria hacer uso de las mismas y ya estas dictarian las reglas a seguir o por el contrario desarrollar una nueva para este entorno pero contentaplando todas las variables

Pero bueno , cruzo los dedos @gimenete :D
porque estoy muy de acuerdo con @vrruiz es una idea bastante buena y seductora :D ya estoy atontao con tu prediccion :D a ver si se cumple :D

Sin mas , me despido señores
que duerman bien :D yo seguire viendo BASILISK :D

#14   

Por lo que sé, al "Java" App Engine se envía el bytecode, no hace falta el código fuente para ejecutar la aplicación, así que sería posible vender aplicaciones cerradas. Sean libres o no, las aplicaciones web que se vendieran tendrán que soportar cierto grado de personalización (logotipos, hojas de estilo, etc).

#15   

Hombre @vrruiz , siempre es posible cerrar un codigo incluso dando el codigo fuente dando un licencia super restrictiva con el mismo , asi como declarando una clausula para el uso de blackbox en tu codigo

Pero es como decia antes no se si es justo para el cliente que esta pagando , y ya no hablo del cliente normalillo que se conforma con lo que le des mientras le des asistencia tecnica cuando tenga algun problema , pero hay clientes que tendran la capacidad de contratar a otras personas para que le hagan otra parte y quizas no quieran depender del creador por x motivos

Es que hay de todo , por eso digo que lo que comentas y la idea que veo que sigues SERIA UN GRAN PERO y se deberia tener en cuenta todas las opciones , que quieres cerrar la aplicacion me parece bien , pero que este no sea el mecanismo por defecto , que sea flexible segun necesidad y requisitos del cliente , porque es como cuando trabajas para una empresa que te contrata cuando firmas el contrato hay una clausula de derecho donde normalmente es la empresa quien se queda con el derecho de lo que hayas desarrollado alli mientras duro el contrato , es lo mismo tu eras el desarrollador y la empresa el cliente , ellos pagaron y pusieron sus condiciones , que no las aceptas pues no hay problema existen muchos mas desarrolladores.

Y que conste que yo muchas cosas que tengo estan cerradas eh que no es que sea un puritano del open source ni nada , pero una cosas son las cosillas que hago para mi y que el algun momento comparto y otra es cuando ofrezco un servicio a un cliente

Una pregunta , donde fue que leistes que el GAE solo sube el byte code ? es como dices el codigo fuente no hace falta para ejecutar la aplicacion , pero donde leistes eso ? me gustaria saber

Es que con python antes tu como es logico subias el codigo pero alli se compilaba y es lo que se usaba pero el codigo estaba alli y segun como lo hicieras te lo podias descargar , pregunto porque estaba pensando en añadirle la misma funcionalidad a mi aplicacion o mi web alli pero si es como dices seria inutil dedicar esfuerzos en pasar el codigo de un lado a otro solo para una funcionalidad que no serviria

Sin mas
me despido

#16   

ostia @gimente se ve que me ha gustado tu entrada no veas la cantidad de entradas que he añadido :D

pd : algo extraño en mi :(

#17   

jejeje. Me ha sorprendido la acogida de mi post :)

Un detalle a tener en cuenta, y que creo que va en la vía que comento, es que sea la aplicación Java o Python, no es posible descargar de vuelta ningún fichero de App Engine. Es decir, si se despliega una aplicación en GAE, luego no hay forma de descargar lo que has subido. Por lo tanto es posible hacer aplicaciones cerradas en GAE y "venderlas" a terceros sin dar el código fuente sin problemas.

saludos!

#18   

Saludos @gimenete

La verdad es que el tema elejido esta acertado y nada descabellado y teniendo en cuenta el crecimiento que esta Teniendo GAE siempre es bueno escuchar ideas al respecto y la tuya me ha gustado mucho y la manera en que la reflejastes no esta mal , ya ves la polemica que esta levantando , a ver si se suman mas personas :D y creamos el culto a @gimenete el nostradamus del siglo XXI :D

Por otra parte disculpa que te corrija pero al menos las aplicaciones python si se pueden descargar desde appengine , los archivos staticos no, ya que los almacena en otra carpeta o servidor una vez que se despliega , pero todo lo que no sea statico ya sean imagenes , html , el codigo python todo se puede descargar de vuelta :D

Por eso es que le pregunte a @vrruiz donde habia leido que solo se subia el bytecode a google ya que quiero probar hacer lo mismo con java y demas , es decir poderme descargar el codigo

mira en este post tienes informacion sobre la que digo yo use este codigo y funciona sin problema para todo lo que este en la aplicacion y que no sea statico

http://www.manatlan.com/blog/zipme___download_sources_of_your_gae_website__as_a_zip_file

Solo espero que este equivocado sino mejoderia mucho :D

Sin mas me despido

ah @gimente gracias por agregarme ;)

#19   

Vaya con el markdown , este es el enlace que queria poner antes , con esto pueden montarlo de forma que se puedan descargar el codigo y todo lo que no sea estatico de vuestra applicacion en GAE

Link Text

Sin mas , solo por ahora
me despido :D

#20   

Descargar tu codigo de tu applicacion en google appengine