[python-madrid] Dominio es.python.org concedido!

[J. Javier Maestro]

2012/6/29 Jesus Cea <jcea at jcea.es>:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 29/06/12 04:46, J. Javier Maestro wrote:
>> Al final, veo que el correo me ha quedado un poco largo... pero
>> bueno. Los que estéis interesados, leedlo :) Los que no, esperad a
>> las conclusiones después de las reuniones :D
>
> Javier, tu correo es muy interesante y argumenta perfectamente tu
> posición. Te agradezco el esfuerzo de ponerlo por escrito.

Lo mismo digo :)

> Coincido contigo en que el objetivo de la asociación debe ser promover
> Python. Pero en mi mente enferma e idealista el objetivo puede
> lograrse de múltiples formas.

Sin duda, pero para mi, gana claramente el pragmatismo y el anteponer
la sostenibilidad de la Asociación a cualquier otro principio.

> A nivel personal estoy interesado en promover tecnologías abiertas y
> descentralizadas, huir de los "silos" donde se entra pero ya no se
> puede salir, de la dependencia tecnológica innecesaria, de terceros
> que te ofrecen un caramelo a cambio de tu alma (comodidad y
> conveniencia a cambio de tu privacidad), donde tú eres el producto a
> vender, no el cliente.

Aún no estando muy de acuerdo con que tu opinión aplique en el caso de
lo que yo propongo en mis correos, sinceramente yo no veo cómo esto
podría afectar a una Asociación que es, por definición, totalmente
abierta. Además, no creo que ninguna de las propuestas entre las que
podemos elegir en servicios externos tenga lock-in de ningún tipo,
puesto que todos ellos tienen vias de migración y exportación de datos
muy claras.

Para muestra, un botón: Google (seguramente muchos piensen que es el
arquetipo de servicio como el que describes, con gran lock-in y que te
ofrece un caramelo a cambio de tu alma), que te explica cómo salir de
su servicio Apps:
http://support.google.com/a/bin/answer.py?hl=en&answer=100458

> Y Python juega un papel importante ahí, porque la rapidez de
> desarrollo posibilita cubrir mucho campo en poco tiempo, con unos
> recursos escasos. Y cubriendo esos nichos con Python... se promueve
> Python. Se convierte en el lenguaje de referencia en areas críticas
> del "core" de como pienso que debe ser Internet.

Ya, y podría hasta estar de acuerdo con esto. Pero incluso estando
100% de acuerdo, te diría que me parece empezar la casa por el tejado.
Aún cuando quisiésemos llegar a tener un core 100% made in-house con
Python y/o un stack de soluciones OSS pythonistas o lo que sea, creo
que empezar con un servicio externo es lo más realista. Tendríamos
algo 100% funcional desde el día cero y sin la problemática añadida
del in-house. Luego, se puede ir migrando todo y sustituyendo lo que
se considere factible o necesario. Pero hacerlo al reves es, desde mi
punto de vista, receta de fracaso (además de una locura muy grande :).
No llegaríamos a tiempo a tener nada usable en poco tiempo.

Además, por muy ágil que sea Python (o cualquier otro lenguaje), a día
de hoy me parecería contraproducente abordar las infraestructuras de
una Asociación, una startup o un proyecto pensando en que debemos
hacer todo lo más desde cero posible. Creo que no es nada realista.

> Así que sí, entiendo tu propuesta de externalizar todo lo que sea
> posible. Pero como una asociación que quiere promover python, dar
> ejemplo (eat your own food) es también una decisión estratégica que
> debemos considerar.

Yo sinceramente pienso como Alejandro, que contesta en otro mail a
esto: tener una web con un producto o páginas PHP sí que caería en lo
de "eat your own dog food". Temas de infraestructuras core... creo que
no, y ni de lejos. Porque si no, el editor con el que programas
debería estar escrito en Python y el OS donde programas también y así
sucesivamente....

Creo que la linea está clara entre las acciones que la Asociación hace
hacia fuera, donde claramente el fin fundacional importa, frente a las
herramientas que use para llevarlo a cabo (sobre todo, a nivel de
infraestructuras de servicios). No creo que nadie quiera medir cómo de
Pythonistas somos en la Asociación en base a las infraestructuras de
servicios que elijamos. Por tanto, yo considero este tema totalmente
fuera de la ecuación de elegir infraestructuras de servicios core.

> Otro detalle adicional es que cualquier cosa que queramos hacer, si la
> externalizamos, está a expensas de que alguien ajeno piense que sea
> económicamente rentable, independientemente del valor que tenga para
> nosotros. Seríamos reactivos, en vez de proactivos.

Yo creo que la mejor regla (en esto y en general en cualquier
estructura organizativa) es empezar siendo reactivos para aprender qué
es necesario y poder pasar a ser proactivos sobre los temas que
importan.

Además, en el caso que nos atañe, sinceramente... seguiríamos teniendo
la misma problemática (o incluso más grave) si tenemos montados los
servicios en trozos de servidores personales (o en servidores
personales completos de cada uno). Por ejemplo, se me ocurre que
seguiríamos dependiendo de lo que un socio piensa que debe instalar en
su servidor (cosa que está en pleno derecho de hacer). O lo que un
socio cree que debe/puede pagar por el servicio. Todo esto
repercutiría en la calidad de servicio de los servicios (valga la
redundancia) de la Asociación.

> Supongo que la clave es decidir si la presencia online de la
> asociación es un escaparate de actividades que se realizan "offline"
> (conferencias, congresos) y por tanto nos conformamos con lo que nos
> den "otros", o nuestra presencia "online" forma parte de la estrategia
> de promover Python.

Hombre, creo que como he dicho antes, aquí no tiene sentido mezclar
infraestructuras con actividad de la Asociación. Creo que hay lineas
claras que no se deben pasar, pero llevar al extremo de que todos los
servicios que use la Asociación tengan que ser loquesea-en-Python...
me parece muy peligroso e inoperativo. Yo no creo que haya que decidir
esto, creo que hay que darse cuenta de lo que es core
(infraestructura, pura y dura) de lo que no.

> El tema de depender de una persona sí es importante. Hay formas de
> evitarlo. El tema de la calidad de servicio es importante. Hay formas
> de garantizarla.

Todo tiene formas y soluciones. Lo importante es a qué coste. Sobre
todo, coste humano. Y sinceramente, no creo que ninguna solución de
las que vamos a intentar ofrecer tenga una calidad de servicio más
alto que los servicios existentes a día de hoy. Por no hablar de la
dificultad (o más bien, de las soluciones ad-hoc) que habrá que montar
para poder no depender de una sola persona en la gestión de
infraestructuras.


Yo sinceramente creo que como esto no se puede decidir hasta que no
esté constituída la Asociación, deberíamos montar una solución que no
dependa de nada ni de nadie y que luego la Asociación vote qué hacer
con el tema de infraestructuras core.


Yo propongo que el DNS se monte en un servicio externo, con coste cero
para la Asociación (yo lo pago). Luego, colgamos una web estática de
una sola página en blanco que ponga "Asociación Python España (en
constitución)" o la web estática que sea en Amazon. Tenemos el tramo
gratuito para hacerlo. Y cuando la Asociación esté constituida y se
decida qué hacer, que se cambie o se quede.


Saludos,


-- 
J. Javier Maestro <jjmaestro at ieee.org>

-- 
Grupo de usuarios de python ubicados en Madrid
http://groups.google.es/group/python-madrid
http://python-madrid.es
http://twitter.com/#!/python_madrid
Para darte de baja del grupo envía un mensaje a python-madrid+unsubscribe at googlegroups.com