Esta es una pregunta que los equipos de desarrollo de software deberían pensar seriamente. Es una pregunta especialmente relevante dada la reciente adquisición de la compañía y el éxodo por el componente de Perforce Software, Inc. que lo diferencia de otros en la industria: es un equipo de soporte legendario. A diferencia de otras compañías de productos de software, Perforce no ofreció niveles de soporte. La primera persona con la que el cliente hace contacto fue un experto en el producto, un desarrollador que usó los productos (siempre comíamos nuestra propia comida para perros) y (durante mi mandato) fue bastante brillante. Digan lo que quieran sobre el software patentado con licencia, con Perforce, el dinero que los clientes gastaron en licencias de productos valió cada centavo si tenían alguna razón para contactar al soporte al cliente de Perforce. Si alguien alguna vez hace una pregunta sobre ese tema, aprovecharía la oportunidad para describir lo que hizo que ese apoyo sea notable, pero lo dejaré en este momento por ahora.
Volver a usar Perforce, el ‘sistema de control de versiones rápido “. Voy a ir al grano: la única razón por la que tendría sentido usar Perforce, hoy, es porque su tienda ya lo ha establecido y usted está en una industria que está sujeto a los estándares de cumplimiento o las políticas de TI que generalmente hacen que el cambio sea muy lento. Si la infraestructura de TI de su empresa es frágil por otras razones, ese problema es el que debería recibir la atención necesaria. Todos los demás que usan Perforce en última instancia estarían mejor convirtiéndose a Git
Perforce ofrece herramientas para hacerlo (escrito por personas de Support) y lo recomendaría a menos que esté utilizando el producto para el desarrollo personal o de ‘equipo’ de una persona. Perforce ofreció una licencia gratuita para una persona en el momento en que me fui. Supongo que eso no cambió. También proporcionó licencias gratuitas para organizaciones sin fines de lucro verificadas. Supongo que eso tampoco cambió. Si no está roto, no lo arregle necesariamente, pero sepa que lo que hizo grande a Perforce ha zarpado. El desarrollo distribuido está aquí porque, francamente, es probablemente superior. Digo probablemente porque es posiblemente una afirmación cualitativa, sin embargo, dada la escala no hay duda. Los números no mienten. La curva de aprendizaje para Git es más pronunciada que el promedio y eso puede crear desafíos de conversión para organizaciones más grandes (o más pequeñas dependiendo de las personas que se convierten).
Git es superior. Y apostaría a que Christopher Seiwald, el tipo que creó Perforce, estaría de acuerdo. Linus Torvalds era su ídolo. Hubiera tenido un cartel de él colgado en su pared si existieran. Estoy seguro de que agrietó su piel cuando Linus menospreciaba el uso de Perforce, pero Chris no negaría la realidad de un producto que escalaba mejor, funcionaba más rápido y era aún menos molesto que el suyo.
En su día, Perforce era una herramienta de desarrollo de software brillante, creada para desarrolladores de software por desarrolladores de software que también usaban el producto. Esto significa que fue diseñado, originalmente, para permanecer tan discreto y simple como deberían ser las buenas herramientas. Algo como el control de versiones no se supone que sea sexy. Se supone que solo funciona y funciona correctamente todo el tiempo sin pensar mucho en tener que gastarlo jugando. También fue diseñado por un tipo que era conciso. Y cuando digo brevemente, quiero decir que sus valores estaban alineados con su ethos de codificación: menos es más. El hombre tenía verdadero desprecio por las palabras innecesarias. Más aún para líneas de código innecesarias. (Algunas de las respuestas que recibí a mis correos electrónicos de él son ejemplos antiguos de esta religión conciso).
Fui uno de los primeros empleados de Perforce. Mi contribución fue crear el sistema de compilación y lanzamiento de la compañía. Cuando llegué allí, Christopher lanzó las compilaciones del producto compilándolas desde su máquina FreeBSD 3.x janky x86 y arrojándolas a la naturaleza a través de un archivo adjunto de correo electrónico o alguien transfiriendo un binario de su máquina a un servidor ftp. Cuando me fui había 17 productos. Más se desarrollaron posteriormente. Algunos, espero, se retiraron y las plataformas se retiraron.
Mis compilaciones incluyeron productos lanzados para más de 30 plataformas. Perforce era tan portátil que incluso yo podía portarlo a una nueva plataforma. Si quisieras, se ejecutaría en tu Apple Watch. Lo trasladamos a XBox y Atari, así que espero que no sea un rascador de cabeza. Construí el servidor y los clientes de línea de comandos en AS400 (y encontrar un AS400 real dentro de la distancia de trabajo no era trivial) y el VMS de DEC Alpha ejecutaba. Nombra un sistema operativo obsoleto y una arquitectura arcaica, y probablemente he construido p4d en él. QNX, alguien? ¿Recuerdas Itanium? ¿Qué tal BeOS en una máquina PPC o SunOS en una máquina PPC? Mis dos puertos favoritos eran el Solaris 10 de Sun en el x86 (era increíblemente rápido, incluso NFS + OpenGL y una tarjeta gráfica … ja, ja, ja) y Mac OS X en una maldita máquina x86. Pensé que el fin del mundo debía ser cerca o era el día de los inocentes cuando eso se vino abajo. Esos son unos dinosaurios que la mayoría de la gente nunca tuvo que conocer. Y soy un verdadero imbécil. En serio. En Perforce trabajé con algunas personas muy inteligentes. de ellos eran Perforce Support. Pero la compañía tiene éxito y comienza a crecer y las cosas cambian.
Entonces, probablemente no deberías casarte con Perforce si aún no lo has hecho. Si lo ha hecho, comience a buscar un buen plan de conversión o si va a comprometerse con él por un tiempo (sin juego de palabras), no espere que sea mejor de lo que tiene ahora. Las personas que podrían hacer eso se han ido. Christopher logró el sueño de Perforce. Bien por él y el resto de los primeros amigos. Los extraño. No todo el mundo. Extrañaría a Christopher, pero, bueno … no.