<- Volver al listado
Un fracaso y un éxito en Plastic SCM: +1 liberando artistasCuando diseñamos Plastic, la primera versión, queríamos que fuera muy, muy bueno con ramas, y buenísimo haciendo merges. Ese ha sido nuestro foco durante años. Ramas cortas y frecuentes, muchísimas, y muchos merges. Con esto podías sacar versiones muy a menudo.
Nosotros mismos nos aplicábamos el cuento, y sacábamos varias versiones al mes. En 2007 esto no era lo habitual, y algunas empresas nos decían que por qué anunciábamos tantas versiones, que daba mala sensación, como que el producto estaba roto o algo. Incluso tuvimos vendedores con los que quedábamos en que nuestra versión era anual, y punto (luego seguíamos publicando versiones en la web… pero eso es otra historia).
También daba miedo el tema de las ramas. Una generación se educó con SVN, así que las ramas eran el infierno. Podemos gestionar miles de ramas, pero no las uses si no quieres, llegamos a decir :-)
Todo esto cambió, gran parte gracias a Git, y ahora no tenemos que ocultar ni nuestras múltiples versiones semanales ni que hacemos muy bien ramas y merges. Parece que acertamos adivinando hacia dónde iría el mercado.
Y también hicimos que Plastic fuera muy bueno con ficheros enormes, algo que nos abrió oportunidades en el sector de los videojuegos, donde Git se rompía con frecuencia.
Y entonces, cuando estábamos seguros de que lo teníamos todo, aprendimos una cosa curiosa:
¿Sabías que en los estudios de videojuegos el 95% de la gente vive sometida por las decisiones de un 5%?
Nosotros tampoco hasta que descubrimos que los artistas odian los controles de versiones que eligen los programadores. Son mayoría, pero viven sometidos.
No les importan ni las ramas, ni los merges, ni nada de eso. Pero sí que necesitaban lo de los grandes ficheros. Y nuestra interfaz gráfica, con nuestro Branch Explorer que es como nuestro ADN, tampoco les gustaba.
¿Qué podíamos hacer?
Esto pasó sobre 2013 y nos lo contaba gente de Telltale games. El 90% de su plantilla de más de 300 son artistas. Usan Maya, SolidWorks, y su entorno interno para crear episodios, animaciones, vídeos, etc. Tienen teras de historia, y una copia de trabajo suponía tantos gigas que ni cabía en sus máquinas (que son maquinones, por cierto, en videojuegos siempre tienen pantallas súper grandes por 2, y maquinones).
¿Qué hacíamos?
Pues creamos Plastic Gluon, una nueva interfaz de usuario más una forma diferente de trabajar, basada en el mismo núcleo que Plastic pero construida en torno a:
Como artista quiero decidir en qué ficheros quiero trabajar, hacer cambios y poder subirlos de forma fácil. No quiero ver jamás un merge. Es más, es muy posible que no quiera ver ni ramas jamás.
Como artista quiero poder bloquear ficheros para que nadie los pueda tocar mientras trabajo.
Como artista no puedo bajar el repositorio entero porque son miles y miles de ficheros enormes.
Esto iba en contra de algunos de nuestros principios, pero si evitábamos la guerra ideológica y nos centrábamos en hacerlo… era posible. Ya teníamos locking y grandes ficheros, era sólo cuestión de hacer una interfaz diferente y de permitir trabajar con “trozos sueltos”… Era posible.
Escuchamos al cliente, encontramos una nueva oportunidad y conseguimos que Telltale usase Plastic. Ahora un 40-50% de las descargas de Plastic son de la industria de videojuegos y de ellas la mayoría de equipos que usan Unity. Podemos decir que ha sido un éxito.
Hay muchos más, pero estos son dos casos curiosos… uno que escuece, y otro que ha salido muy bien.
Pero si quieres conocer más sobre cómo trabajamos, mientras esperas al próximo post, hemos escrito hace poco una serie de posts contándolo
Y si quieres conocer al equipo que hace posible Plastic SCM y SemanticMerge, puedes echar un vistazo aquí.
Finalmente, siempre estamos buscando gente nueva para el equipo así que si te interesa trabajar con nosotros.
