EL OTRO CAMINO POR DELANTE
OriginalSeptiembre de 2001
(Este artículo explica por qué gran parte de la próxima generación de software puede estar basada en servidores, qué significará eso para los programadores y por qué este nuevo tipo de software es una gran oportunidad para las empresas emergentes. Se deriva de una charla en BBN Labs).
En el verano de 1995, mi amigo Robert Morris y yo decidimos crear una empresa nueva. La campaña de relaciones públicas que precedió a la salida a bolsa de Netscape estaba en pleno auge y en la prensa se hablaba mucho del comercio electrónico. En aquella época, en la Web había unas treinta tiendas reales, todas ellas hechas a mano. Si iba a haber muchas tiendas en línea, haría falta un software para crearlas, así que decidimos escribir algunas.
Durante la primera semana, más o menos, teníamos la intención de convertirla en una aplicación de escritorio normal. Un día, se nos ocurrió la idea de hacer que el software se ejecutara en nuestro servidor web, utilizando el navegador como interfaz. Intentamos reescribir el software para que funcionara en la web y estaba claro que esa era la manera de hacerlo. Si escribíamos nuestro software para que se ejecutara en el servidor, sería mucho más fácil para los usuarios y también para nosotros.
Resultó ser un buen plan. En la actualidad, Yahoo Store es el software para crear tiendas en línea más popular, con aproximadamente 14.000 usuarios.
Cuando iniciamos Viaweb, casi nadie entendía lo que queríamos decir cuando decíamos que el software se ejecutaba en el servidor. No fue hasta que se lanzó Hotmail un año después que la gente empezó a entenderlo. Ahora todo el mundo sabe que se trata de un enfoque válido. Ahora existe un nombre para lo que éramos: un proveedor de servicios de aplicaciones o ASP.
Creo que gran parte de la próxima generación de software se escribirá siguiendo este modelo. Incluso Microsoft, que es el que más tiene que perder, parece ver la inevitabilidad de trasladar algunas cosas del escritorio. Si el software se traslada del escritorio a los servidores, significará un mundo muy diferente para los desarrolladores. Este artículo describe las cosas sorprendentes que vimos, como algunos de los primeros visitantes de este nuevo mundo. En la medida en que el software se traslade a los servidores, lo que estoy describiendo aquí es el futuro.
¿El siguiente paso?
Cuando echemos la vista atrás a la era del software de escritorio, creo que nos maravillaremos de los inconvenientes que soportaba la gente, igual que nos maravillamos ahora de lo que soportaban los primeros propietarios de automóviles. Durante los primeros veinte o treinta años, había que ser un experto en coches para tener uno. Pero los coches supusieron un gran éxito, y mucha gente que no era experta en coches también quería tenerlos.
Los ordenadores están en esa fase ahora. Cuando tienes un ordenador de sobremesa, acabas aprendiendo mucho más de lo que querías saber sobre lo que ocurre en su interior. Pero más de la mitad de los hogares de Estados Unidos tienen uno. Mi madre tiene un ordenador que utiliza para el correo electrónico y para llevar las cuentas. Hace un año aproximadamente se alarmó al recibir una carta de Apple en la que le ofrecían un descuento en una nueva versión del sistema operativo. Algo no va bien cuando una mujer de sesenta y cinco años que quiere utilizar un ordenador para el correo electrónico y las cuentas tiene que pensar en instalar nuevos sistemas operativos. Los usuarios normales ni siquiera deberían conocer las palabras "sistema operativo", y mucho menos "controlador de dispositivo" o "parche".
Ahora existe otra forma de distribuir software que evitará que los usuarios se conviertan en administradores de sistemas. Las aplicaciones basadas en la Web son programas que se ejecutan en servidores Web y utilizan páginas Web como interfaz de usuario. Para el usuario medio, este nuevo tipo de software será más sencillo, más barato, más móvil, más fiable y, a menudo, más potente que el software de escritorio.
Con un software basado en la Web, la mayoría de los usuarios no tendrán que pensar en nada más que en las aplicaciones que utilizan. Todo el material desordenado y cambiante estará en un servidor en algún lugar, mantenido por el tipo de personas que son buenas en ese tipo de cosas. Y por lo tanto, normalmente no necesitará una computadora, per se, para usar software. Todo lo que necesitará será algo con un teclado, una pantalla y un navegador Web. Tal vez tenga acceso inalámbrico a Internet. Tal vez también sea su teléfono celular. Sea lo que sea, será un producto electrónico de consumo: algo que cueste alrededor de $200 y que la gente elija principalmente en función de cómo se vea la carcasa. Pagará más por los servicios de Internet que por el hardware, tal como lo hace ahora con los teléfonos. [1]
Se necesitará aproximadamente una décima de segundo para que un clic llegue al servidor y vuelva, por lo que los usuarios de software altamente interactivo, como Photoshop, seguirán queriendo que los cálculos se realicen en el escritorio. Pero si nos fijamos en el tipo de cosas para las que la mayoría de la gente utiliza los ordenadores, una latencia de una décima de segundo no sería un problema. Mi madre no necesita realmente un ordenador de escritorio, y hay mucha gente como ella.
La victoria para los usuarios
Cerca de mi casa hay un coche con una pegatina en el parachoques que dice "La muerte antes que los inconvenientes". La mayoría de la gente, la mayor parte del tiempo, elegirá la opción que requiera menos trabajo. Si el software basado en la Web triunfa, será porque es más cómodo. Y parece que así será, tanto para los usuarios como para los desarrolladores.
Para utilizar una aplicación basada exclusivamente en la Web, lo único que se necesita es un navegador conectado a Internet. De esta forma, se puede utilizar una aplicación basada en la Web en cualquier lugar. Cuando se instala un software en el ordenador de sobremesa, sólo se puede utilizar en ese ordenador. Y lo que es peor, los archivos quedan atrapados en ese ordenador. Los inconvenientes de este modelo se hacen cada vez más evidentes a medida que la gente se acostumbra a las redes.
El punto débil de este problema fue el correo electrónico basado en la Web. Millones de personas se han dado cuenta de que deberían tener acceso a sus mensajes de correo electrónico sin importar dónde se encuentren. Y si pueden ver su correo electrónico, ¿por qué no su calendario? Si pueden discutir un documento con sus colegas, ¿por qué no pueden editarlo? ¿Por qué sus datos deberían estar atrapados en algún ordenador ubicado en un escritorio lejano?
La idea de "su computadora" está desapareciendo y será reemplazada por "sus datos". Usted debería poder acceder a sus datos desde cualquier computadora. O mejor dicho, desde cualquier cliente, y un cliente no tiene por qué ser una computadora.
Los clientes no deberían almacenar datos, deberían ser como los teléfonos. De hecho, pueden convertirse en teléfonos, o viceversa. Y a medida que los clientes se hacen más pequeños, tienes otra razón para no guardar tus datos en ellos: algo que llevas contigo se puede perder o te lo pueden robar. Dejar tu PDA en un taxi es como una avería en el disco, excepto que tus datos se entregan a otra persona en lugar de evaporarse.
Con un software basado exclusivamente en la Web, ni los datos ni las aplicaciones se guardan en el cliente, por lo que no es necesario instalar nada para utilizarlo. Y cuando no hay instalación, no hay que preocuparse de que la instalación salga mal. No puede haber incompatibilidades entre la aplicación y el sistema operativo, porque el software no se ejecuta en el sistema operativo.
Como no necesita instalación, será fácil y habitual probar el software basado en la Web antes de "comprarlo". Es de esperar que pueda probar cualquier aplicación basada en la Web de forma gratuita, simplemente visitando el sitio donde se ofrece. En Viaweb, nuestro sitio era como una gran flecha que señalaba a los usuarios la opción de prueba.
Después de probar la demostración, la suscripción al servicio no debería requerir más que rellenar un breve formulario (cuanto más breve, mejor). Y ese debería ser el último trabajo que el usuario tenga que hacer. Con un software basado en la Web, debería obtener nuevas versiones sin pagar más, ni realizar ningún trabajo, y posiblemente ni siquiera saber de su existencia.
Las actualizaciones no serán tan impactantes como lo son ahora. Con el tiempo, las aplicaciones se volverán silenciosamente más potentes. Esto requerirá un cierto esfuerzo por parte de los desarrolladores. Tendrán que diseñar el software de manera que pueda actualizarse sin confundir a los usuarios. Se trata de un problema nuevo, pero hay formas de resolverlo.
En las aplicaciones basadas en la Web, todo el mundo utiliza la misma versión y los errores se pueden corregir tan pronto como se descubren. Por lo tanto, el software basado en la Web debería tener muchos menos errores que el software de escritorio. En Viaweb, dudo que hayamos tenido diez errores conocidos al mismo tiempo. Eso es mucho mejor que el software de escritorio.
Las aplicaciones web pueden ser utilizadas por varias personas al mismo tiempo. Esto es una ventaja obvia para las aplicaciones colaborativas, pero apuesto a que los usuarios comenzarán a querer esto en la mayoría de las aplicaciones una vez que se den cuenta de que es posible. A menudo será útil permitir que dos personas editen el mismo documento, por ejemplo. Viaweb permitió que varios usuarios editaran un sitio simultáneamente, más porque esa era la forma correcta de escribir el software que porque esperábamos que los usuarios lo quisieran, pero resultó que muchos lo hicieron.
Cuando utilice una aplicación basada en la Web, sus datos estarán más seguros. Los fallos de disco no serán cosa del pasado, pero los usuarios ya no se enterarán de ellos. Se producirán en granjas de servidores. Y las empresas que ofrezcan aplicaciones basadas en la Web harán copias de seguridad, no sólo porque habrá verdaderos administradores de sistemas que se preocuparán por esas cosas, sino porque un ASP que pierda los datos de los usuarios tendrá grandes problemas. Cuando los usuarios pierden sus propios datos en un fallo de disco, no pueden enfadarse tanto, porque sólo pueden enfadarse consigo mismos. Cuando una empresa pierde sus datos por ellos, se enfadan mucho más.
Por último, el software basado en la Web debería ser menos vulnerable a los virus. Si el cliente no ejecuta nada más que un navegador, hay menos posibilidades de que se ejecuten virus y no hay datos locales que puedan dañarse. Y un programa que atacara a los propios servidores debería encontrarlos muy bien defendidos. [2]
Para los usuarios, el software basado en la Web resultará menos estresante. Creo que si se mirase al usuario medio de Windows se descubriría un deseo enorme y prácticamente inexplotado de software que cumpla con esa descripción. Si se desatara, podría convertirse en una fuerza poderosa.
Ciudad de Código
Para los desarrolladores, la diferencia más evidente entre el software basado en la Web y el de escritorio es que una aplicación basada en la Web no es un único fragmento de código, sino una colección de programas de distintos tipos, en lugar de un único y gran binario. Por eso, diseñar un software basado en la Web es como diseñar una ciudad en lugar de un edificio: además de edificios, se necesitan carreteras, señales de tráfico, servicios públicos, departamentos de policía y bomberos, y planes tanto para el crecimiento como para diversos tipos de desastres.
En Viaweb, el software incluía aplicaciones bastante grandes con las que los usuarios hablaban directamente, programas que esos programas usaban, programas que se ejecutaban constantemente en segundo plano buscando problemas, programas que intentaban reiniciar las cosas si se rompían, programas que se ejecutaban ocasionalmente para recopilar estadísticas o crear índices para búsquedas, programas que ejecutábamos explícitamente para recolectar recursos o para mover o restaurar datos, programas que simulaban ser usuarios (para medir el rendimiento o exponer errores), programas para diagnosticar problemas de red, programas para hacer copias de seguridad, interfaces con servicios externos, software que manejaba una impresionante colección de diales que mostraban estadísticas de servidores en tiempo real (un éxito entre los visitantes, pero indispensable para nosotros también), modificaciones (incluidas correcciones de errores) de software de código abierto y una gran cantidad de archivos de configuración y ajustes. Trevor Blackwell escribió un programa espectacular para trasladar tiendas a nuevos servidores en todo el país, sin cerrarlas, después de que Yahoo nos comprara. Los programas nos buscaban, enviaban faxes y correos electrónicos a los usuarios, realizaban transacciones con procesadores de tarjetas de crédito y se comunicaban entre sí a través de sockets, tuberías, solicitudes http, ssh, paquetes udp, memoria compartida y archivos. Parte de Viaweb incluso consistía en la ausencia de programas, ya que una de las claves de la seguridad de Unix es no ejecutar utilidades innecesarias que la gente podría usar para entrar en sus servidores.
No se limitó a diseñar software. Pasamos mucho tiempo pensando en las configuraciones de los servidores. Los construimos nosotros mismos, a partir de componentes, en parte para ahorrar dinero y en parte para conseguir exactamente lo que queríamos. Tuvimos que pensar si nuestro proveedor de servicios de Internet tenía conexiones lo suficientemente rápidas a todas las redes troncales. Salimos con proveedores RAID en serie.
Pero el hardware no es sólo algo de lo que preocuparse. Cuando lo controlas, puedes hacer más por los usuarios. Con una aplicación de escritorio, puedes especificar un hardware mínimo, pero no puedes agregar más. Si administras los servidores, puedes permitir en un solo paso que todos tus usuarios llamen a personas, envíen faxes, envíen comandos por teléfono, procesen tarjetas de crédito, etc., simplemente instalando el hardware correspondiente. Siempre buscamos nuevas formas de agregar características con el hardware, no sólo porque complaciera a los usuarios, sino también como una forma de diferenciarnos de los competidores que (ya sea porque vendían software de escritorio o revendían aplicaciones basadas en la Web a través de ISP) no tenían control directo sobre el hardware.
Como el software de una aplicación basada en la Web será una colección de programas en lugar de un único binario, se puede escribir en cualquier cantidad de lenguajes diferentes. Cuando se escribe software de escritorio, prácticamente se está obligado a escribir la aplicación en el mismo lenguaje que el sistema operativo subyacente, es decir, C y C++. Y por eso estos lenguajes (especialmente entre personas no técnicas como gerentes y VC) llegaron a ser considerados como los lenguajes para el desarrollo de software "serio". Pero eso era solo un artefacto de la forma en que se tenía que entregar el software de escritorio. Para el software basado en servidor se puede usar cualquier lenguaje que se desee. [3] Hoy en día, muchos de los mejores hackers están usando lenguajes muy alejados de C y C++: Perl, Python e incluso Lisp.
Con el software basado en servidor, nadie puede decirte qué lenguaje usar, porque tú controlas todo el sistema, hasta el hardware. Diferentes lenguajes son buenos para diferentes tareas. Puedes usar el que sea mejor para cada una. Y cuando tienes competidores, "puedes" significa "debes" (volveremos a esto más adelante), porque si no aprovechas esta posibilidad, tus competidores lo harán.
La mayoría de nuestros competidores usaban C y C++, y esto hacía que su software fuera visiblemente inferior porque (entre otras cosas) no tenían forma de evitar la falta de estado de los scripts CGI. Si uno iba a cambiar algo, todos los cambios debían realizarse en una página, con un botón Actualizar en la parte inferior. Como he escrito en otro lugar, al usar Lisp , que mucha gente todavía considera un lenguaje de investigación, podíamos hacer que el editor de Viaweb se comportara más como un software de escritorio.
Lanzamientos
Uno de los cambios más importantes en este nuevo mundo es la forma de hacer los lanzamientos. En el negocio del software de escritorio, hacer un lanzamiento es un gran trauma, en el que toda la empresa suda y se esfuerza para sacar al mercado un único fragmento de código gigante. Las comparaciones obvias se hacen evidentes, tanto con el proceso como con el producto resultante.
Con el software basado en servidor, puedes hacer cambios casi como lo harías en un programa que escribiste tú mismo. El software se lanza como una serie de cambios incrementales en lugar de una gran explosión ocasional. Una empresa de software de escritorio típica puede hacer uno o dos lanzamientos al año. En Viaweb, a menudo hacíamos entre tres y cinco lanzamientos al día.
Cuando se cambia a este nuevo modelo, se comprende en qué medida el desarrollo de software se ve afectado por la forma en que se lanza. Muchos de los problemas más desagradables que se ven en el negocio del software de escritorio se deben a la naturaleza catastrófica de los lanzamientos.
Cuando se lanza una única versión nueva al año, se tiende a solucionar los errores de forma masiva. Algún tiempo antes de la fecha de lanzamiento se crea una nueva versión en la que se ha eliminado y reemplazado la mitad del código, lo que introduce innumerables errores. Luego, un equipo de control de calidad interviene y comienza a contarlos, y los programadores van recorriendo la lista para corregirlos. Por lo general, no llegan al final de la lista y, de hecho, nadie está seguro de dónde está el final. Es como sacar escombros de un estanque. Nunca se sabe realmente qué está sucediendo dentro del software. En el mejor de los casos, se termina con una especie de corrección estadística.
En el caso del software basado en servidores, la mayoría de los cambios son pequeños e incrementales, lo que en sí mismo hace que sea menos probable que se produzcan errores. También significa que sabes qué es lo que debes probar con más cuidado cuando estás a punto de lanzar un software: lo último que cambiaste. Terminas teniendo un control mucho más firme del código. Como regla general, sabes lo que está sucediendo dentro de él. No tienes el código fuente memorizado, por supuesto, pero cuando lees el código fuente lo haces como un piloto que escanea el panel de instrumentos, no como un detective que intenta desentrañar algún misterio.
El software de escritorio genera cierto fatalismo en relación con los errores. Sabes que estás lanzando algo cargado de errores e incluso has establecido mecanismos para compensarlos (por ejemplo, lanzamientos de parches). Entonces, ¿por qué preocuparte por unos cuantos más? Pronto estarás lanzando funciones completas que sabes que están rotas. Apple hizo esto a principios de este año. Se sintieron presionados para lanzar su nuevo sistema operativo, cuya fecha de lanzamiento ya se había pospuesto cuatro veces, pero parte del software (soporte para CD y DVD) no estaba listo. ¿La solución? Lanzar el sistema operativo sin las partes inacabadas, y los usuarios tendrán que instalarlas más tarde.
Con el software basado en la Web, nunca es necesario lanzar el software antes de que funcione, y se puede lanzar tan pronto como funcione.
El veterano de la industria puede estar pensando que es una buena idea decir que nunca hay que lanzar un software antes de que funcione, pero ¿qué pasa cuando se ha prometido entregar una nueva versión del software en una fecha determinada? Con el software basado en la Web, no se haría una promesa así, porque no hay versiones. El software cambia de forma gradual y continua. Algunos cambios pueden ser más importantes que otros, pero la idea de las versiones simplemente no encaja de forma natural en el software basado en la Web.
Si alguien recuerda Viaweb, esto puede sonar extraño, porque siempre estábamos anunciando nuevas versiones. Esto se hacía únicamente con fines de relaciones públicas. Aprendimos que la prensa especializada piensa en números de versión. Te darán una cobertura importante para un lanzamiento importante, es decir, un nuevo primer dígito en el número de versión, y generalmente un párrafo como máximo para un lanzamiento puntual, es decir, un nuevo dígito después del punto decimal.
Algunos de nuestros competidores ofrecían software de escritorio y, de hecho, tenían números de versión. Y para estos lanzamientos, cuyo mero hecho nos parecía una prueba de su atraso, recibían todo tipo de publicidad. No queríamos quedarnos atrás, así que empezamos a darle números de versión también a nuestro software. Cuando queríamos algo de publicidad, hacíamos una lista de todas las características que habíamos añadido desde el último "lanzamiento", poníamos un nuevo número de versión en el software y emitíamos un comunicado de prensa diciendo que la nueva versión estaba disponible de inmediato. Sorprendentemente, nadie nos llamó la atención al respecto.
Cuando nos compraron, ya lo habíamos hecho tres veces, así que estábamos en la versión 4. Versión 4.1, si no recuerdo mal. Después de que Viaweb se convirtiera en Yahoo Store, ya no había una necesidad tan desesperada de publicidad, así que, aunque el software siguió evolucionando, la idea de los números de versión se abandonó en silencio.
Insectos
La otra gran ventaja técnica del software basado en la Web es que se pueden reproducir la mayoría de los errores. Tienes los datos de los usuarios ahí mismo, en tu disco. Si alguien estropea tu software, no tienes que intentar adivinar qué está pasando, como harías con el software de escritorio: deberías poder reproducir el error mientras están hablando por teléfono contigo. Es posible que incluso ya lo sepas, si tienes un código para detectar errores integrado en tu aplicación.
El software basado en la Web se utiliza las 24 horas del día, por lo que todo lo que haces se somete inmediatamente a un análisis minucioso. Los errores aparecen rápidamente.
A las empresas de software se les acusa a veces de dejar que los usuarios depuren su software. Y eso es precisamente lo que estoy defendiendo. En el caso del software basado en la Web, en realidad es un buen plan, porque los errores son menos frecuentes y transitorios. Cuando se lanza el software de forma gradual, se tienen muchos menos errores al principio. Y cuando se pueden reproducir los errores y lanzar cambios al instante, se pueden encontrar y corregir la mayoría de los errores tan pronto como aparecen. Nunca hemos tenido suficientes errores a la vez como para molestarnos en tener un sistema formal de seguimiento de errores.
Por supuesto, deberías probar los cambios antes de publicarlos, de modo que no se publiquen errores importantes. Los pocos que inevitablemente se cuelen implicarán casos límite y solo afectarán a los pocos usuarios que los encuentren antes de que alguien llame para quejarse. Siempre que arregles los errores de inmediato, el efecto neto, para el usuario promedio, es que habrá muchos menos errores. Dudo que el usuario promedio de Viaweb haya visto alguna vez un error.
Corregir errores nuevos es más fácil que corregir errores antiguos. Normalmente es bastante rápido encontrar un error en el código que acabas de escribir. Cuando aparece, a menudo sabes qué es lo que está mal incluso antes de mirar el código fuente, porque ya te estabas preocupando por ello de forma subconsciente. Corregir un error en algo que escribiste hace seis meses (el caso promedio si publicas una vez al año) es mucho más trabajo. Y como no entiendes tan bien el código, es más probable que lo arregles de forma desagradable o incluso introduzcas más errores. [4]
Cuando se detectan errores a tiempo, también se obtienen menos errores compuestos. Los errores compuestos son dos errores separados que interactúan: te tropiezas al bajar las escaleras y, cuando intentas alcanzar el pasamanos, se te cae en la mano. En el software, este tipo de error es el más difícil de encontrar y también suele tener las peores consecuencias. [5] El enfoque tradicional de "romper todo y luego filtrar los errores" produce inherentemente muchos errores compuestos. Y el software que se lanza en una serie de pequeños cambios tiende inherentemente a no hacerlo. Los pisos se barren constantemente para limpiarlos de cualquier objeto suelto que pueda quedar atrapado más tarde en algo.
Resulta de ayuda utilizar una técnica llamada programación funcional, que implica evitar los efectos secundarios. Es algo que es más probable ver en artículos de investigación que en software comercial, pero resulta muy útil para aplicaciones basadas en la Web. Es difícil escribir programas enteros como código puramente funcional, pero se pueden escribir fragmentos sustanciales de esta manera. Hace que esas partes del software sean más fáciles de probar, porque no tienen estado, y eso es muy conveniente en una situación en la que se están realizando y probando pequeñas modificaciones constantemente. Escribí gran parte del editor de Viaweb en este estilo, e hicimos que nuestro lenguaje de programación, RTML , fuera un lenguaje puramente funcional.
A la gente del sector del software de escritorio le resultará difícil creerlo, pero en Viaweb los errores se convirtieron casi en un juego. Dado que la mayoría de los errores publicados implicaban casos límite, los usuarios que los encontraban probablemente eran usuarios avanzados que buscaban algo más. Los usuarios avanzados son más indulgentes con los errores, especialmente porque probablemente los introdujiste al añadir alguna característica que estaban pidiendo. De hecho, como los errores eran poco frecuentes y tenías que estar haciendo cosas sofisticadas para verlos, los usuarios avanzados a menudo se sentían orgullosos de detectar uno. Llamaban al servicio de asistencia con un espíritu más de triunfo que de enfado, como si nos hubieran ganado puntos.
Apoyo
Cuando se pueden reproducir errores, cambia el enfoque de la atención al cliente. En la mayoría de las empresas de software, la atención al cliente se ofrece como una forma de hacer que los clientes se sientan mejor. O bien te llaman por un error conocido o simplemente están haciendo algo mal y tienes que averiguar qué es. En cualquier caso, no hay mucho que puedas aprender de ellos. Por eso, tiendes a ver las llamadas de atención al cliente como una molestia que quieres aislar de tus desarrolladores tanto como sea posible.
En Viaweb no funcionaba así. En Viaweb, el soporte era gratuito porque queríamos saber la opinión de los clientes. Si alguien tenía un problema, queríamos saberlo de inmediato para poder reproducir el error y publicar una solución.
En Viaweb, los desarrolladores siempre estaban en contacto directo con el servicio de asistencia. El personal de atención al cliente estaba a unos diez metros de los programadores y sabía que siempre podían interrumpir cualquier cosa con un informe de un error genuino. Salíamos de una reunión de la junta para solucionar un error grave.
Nuestro enfoque de soporte hizo que todos se sintieran más felices. Los clientes estaban encantados. Imagínense cómo se sentiría llamar a una línea de soporte y ser tratado como alguien que trae noticias importantes. Al personal de soporte al cliente le gustó porque significaba que podían ayudar a los usuarios, en lugar de leerles scripts. Y a los programadores les gustó porque podían reproducir errores en lugar de simplemente escuchar informes vagos de segunda mano sobre ellos.
Nuestra política de corregir errores sobre la marcha cambió la relación entre el personal de soporte al cliente y los hackers. En la mayoría de las empresas de software, el personal de soporte son escudos humanos mal pagados, y los hackers son pequeñas copias de Dios Padre, creadores del mundo. Cualquiera que sea el procedimiento para informar de errores, es probable que sea unidireccional: el personal de soporte que se entera de los errores rellena un formulario que finalmente se envía (posiblemente a través de QA) a los programadores, que lo ponen en su lista de cosas por hacer. Era muy diferente en Viaweb. En menos de un minuto de oír hablar de un error de un cliente, el personal de soporte podía estar de pie junto a un programador y oírle decir "Mierda, tienes razón, es un error". Al personal de soporte le encantaba oír que los hackers decían "tienes razón". Solían traernos los errores con el mismo aire expectante con el que un gato te trae un ratón que acaba de matar. También los hizo más cuidadosos a la hora de juzgar la gravedad de un error, porque ahora su honor estaba en juego.
Después de que Yahoo nos comprara, el personal de atención al cliente se alejó de los programadores. Fue entonces cuando nos dimos cuenta de que, en realidad, ellos también se encargaban del control de calidad y, en cierta medida, del marketing. Además de detectar errores, eran los guardianes del conocimiento de cosas más vagas, parecidas a errores, como las características que confundían a los usuarios. [6] También eran una especie de grupo de discusión delegado; podíamos preguntarles cuál de las dos nuevas características querían más los usuarios, y siempre tenían razón.
Moral
Poder lanzar un software de inmediato es un gran motivador. A menudo, mientras iba caminando al trabajo, pensaba en algún cambio que quería hacer en el software y lo hacía ese mismo día. Esto también funcionaba con funciones más importantes. Incluso si algo iba a llevar dos semanas escribirse (pocos proyectos llevaban más tiempo), sabía que podía ver el efecto en el software tan pronto como estuviera terminado.
Si hubiera tenido que esperar un año para el siguiente lanzamiento, habría dejado de lado la mayoría de estas ideas, al menos durante un tiempo. Sin embargo, lo que pasa con las ideas es que conducen a más ideas. ¿Alguna vez has notado que cuando te sientas a escribir algo, la mitad de las ideas que terminan en él son las que se te ocurrieron mientras lo escribías? Lo mismo sucede con el software. Trabajar para implementar una idea te da más ideas. Por lo tanto, dejar de lado una idea te cuesta no solo ese retraso en la implementación, sino también todas las ideas a las que habría llevado su implementación. De hecho, dejar de lado una idea probablemente incluso inhibe nuevas ideas: cuando empiezas a pensar en alguna característica nueva, ves el estante y piensas "pero ya tengo muchas cosas nuevas que quiero hacer para el próximo lanzamiento".
Lo que hacen las grandes empresas en lugar de implementar funciones es planificarlas. En Viaweb a veces nos topamos con problemas por este motivo. Los inversores y analistas nos preguntaban qué teníamos planeado para el futuro. La respuesta sincera habría sido que no teníamos ningún plan. Teníamos ideas generales sobre las cosas que queríamos mejorar, pero si supiéramos cómo lo habríamos hecho ya. ¿Qué íbamos a hacer en los próximos seis meses? Lo que pareciera el mayor logro. No sé si alguna vez me atreví a dar esta respuesta, pero esa era la verdad. Los planes son solo otra forma de decir ideas que tenemos en la estantería. Cuando se nos ocurrían buenas ideas, las implementábamos.
En Viaweb, como en muchas empresas de software, la mayor parte del código tenía un propietario definido. Pero cuando eras dueño de algo, realmente lo eras: nadie, excepto el propietario de un software, tenía que aprobar (o incluso saber acerca de) un lanzamiento. No había protección contra fallas, excepto el miedo a parecer un idiota ante los colegas, y eso era más que suficiente. Puede que haya dado la impresión de que simplemente avanzamos alegremente escribiendo código. Fuimos rápidos, pero pensamos muy detenidamente antes de lanzar software a esos servidores. Y prestar atención es más importante para la confiabilidad que avanzar lentamente. Debido a que presta mucha atención, un piloto de la Marina puede aterrizar un avión de 40.000 libras a 140 millas por hora en la cubierta de un portaaviones que se balancea, de noche, con más seguridad de la que un adolescente promedio puede cortar un bagel.
Por supuesto, esta forma de escribir software es un arma de doble filo. Funciona mucho mejor para un equipo pequeño de buenos y confiables programadores que para una gran empresa de programadores mediocres, donde las malas ideas son detectadas por comités en lugar de por las personas que las tuvieron.
Brooks al revés
Afortunadamente, el software basado en la Web requiere menos programadores. Una vez trabajé para una empresa de software de escritorio de tamaño mediano que tenía más de 100 personas trabajando en ingeniería en su conjunto. Solo 13 de ellas estaban en el desarrollo de productos. El resto trabajaba en versiones, puertos, etc. Con el software basado en la Web, todo lo que se necesita (como máximo) son las 13 personas, porque no hay versiones, puertos, etc.
Viaweb fue escrita por sólo tres personas. [7] Siempre tuve presión para contratar más, porque queríamos que nos compraran y sabíamos que a los compradores les resultaría difícil pagar un precio alto por una empresa con sólo tres programadores. (Solución: contratamos más, pero creamos nuevos proyectos para ellos).
Cuando se puede escribir software con menos programadores, se ahorra algo más que dinero. Como señaló Fred Brooks en The Mythical Man-Month, añadir gente a un proyecto tiende a ralentizarlo. La cantidad de conexiones posibles entre desarrolladores crece exponencialmente con el tamaño del grupo. Cuanto más grande sea el grupo, más tiempo pasarán en reuniones negociando cómo funcionará su software en conjunto y más errores tendrán a causa de interacciones imprevistas. Afortunadamente, este proceso también funciona a la inversa: a medida que los grupos se hacen más pequeños, el desarrollo de software se vuelve exponencialmente más eficiente. No recuerdo que los programadores de Viaweb hayan tenido nunca una reunión real. Nunca teníamos más que decir en un momento dado de lo que podíamos decir mientras caminábamos hacia el almuerzo.
Si hay una desventaja aquí, es que todos los programadores tienen que ser también, en algún grado, administradores de sistemas. Cuando se aloja software, alguien tiene que estar vigilando los servidores y, en la práctica, las únicas personas que pueden hacer esto correctamente son las que escribieron el software. En Viaweb, nuestro sistema tenía tantos componentes y cambiaba con tanta frecuencia que no había una frontera definida entre el software y la infraestructura. Declarar arbitrariamente tal frontera habría limitado nuestras opciones de diseño. Y, aunque esperábamos constantemente que un día ("en un par de meses") todo fuera lo suficientemente estable como para poder contratar a alguien cuyo trabajo fuera sólo preocuparse por los servidores, nunca sucedió.
No creo que pueda ser de otra manera, siempre y cuando sigas desarrollando activamente el producto. El software basado en la Web nunca va a ser algo que escribas, registres y te vayas a casa. Es algo que está en vivo y que se ejecuta en tus servidores ahora mismo. Un error grave puede no solo bloquear el proceso de un usuario, sino que puede bloquearlos a todos. Si un error en tu código corrompe algunos datos en el disco, tienes que solucionarlo. Y así sucesivamente. Descubrimos que no tienes que vigilar los servidores cada minuto (después del primer año aproximadamente), pero definitivamente quieres estar atento a las cosas que has cambiado recientemente. No publicas código tarde por la noche y luego te vas a casa.
Observando a los usuarios
Con un software basado en servidor, estás en contacto más cercano con tu código. También puedes estar en contacto más cercano con tus usuarios. Intuit es famoso por presentarse a los clientes en las tiendas minoristas y pedirles que los acompañen a sus casas. Si alguna vez has visto a alguien usar tu software por primera vez, sabes qué sorpresas le deben haber aguardado.
El software debe hacer lo que los usuarios creen que hará. Pero no puedes tener idea de lo que los usuarios estarán pensando, créeme, hasta que los observes. Y el software basado en servidor te brinda información sin precedentes sobre su comportamiento. No estás limitado a grupos de discusión pequeños y artificiales. Puedes ver cada clic que hace cada usuario. Tienes que pensar cuidadosamente lo que vas a observar, porque no quieres violar la privacidad de los usuarios, pero incluso el muestreo estadístico más general puede ser muy útil.
Cuando tienes usuarios en tu servidor, no tienes que depender de pruebas comparativas, por ejemplo. Las pruebas comparativas son usuarios simulados. Con software basado en servidor, puedes observar usuarios reales. Para decidir qué optimizar, solo tienes que iniciar sesión en un servidor y ver qué está consumiendo toda la CPU. Y también sabes cuándo dejar de optimizar: finalmente logramos que el editor de Viaweb llegara al punto en que estaba limitado por la memoria en lugar de por la CPU, y como no había nada que pudiéramos hacer para reducir el tamaño de los datos de los usuarios (bueno, nada fácil), sabíamos que era mejor parar allí.
La eficiencia es importante para el software basado en servidores, porque estás pagando por el hardware. La cantidad de usuarios que puedes soportar por servidor es el divisor de tu costo de capital, por lo que si puedes hacer que tu software sea muy eficiente, puedes vender más barato que la competencia y aún así obtener ganancias. En Viaweb logramos reducir el costo de capital por usuario a aproximadamente $5. Ahora sería menos, probablemente menos que el costo de enviarles la factura del primer mes. El hardware es gratis ahora, si tu software es razonablemente eficiente.
Observar a los usuarios puede guiarlo tanto en el diseño como en la optimización. Viaweb tenía un lenguaje de programación llamado RTML que permitía a los usuarios avanzados definir sus propios estilos de página. Descubrimos que RTML se convirtió en una especie de buzón de sugerencias, porque los usuarios solo lo usaban cuando los estilos de página predefinidos no podían hacer lo que querían. Originalmente, el editor colocaba barras de botones a lo largo de la página, por ejemplo, pero después de que varios usuarios usaran RTML para colocar botones en el lado izquierdo, hicimos que esa fuera una opción (de hecho, la predeterminada) en los estilos de página predefinidos.
Por último, observando a los usuarios, a menudo se puede saber cuándo tienen problemas. Y como el cliente siempre tiene la razón, eso es señal de que hay algo que hay que solucionar. En Viaweb, la clave para conseguir usuarios fue la prueba de manejo en línea. No se trataba simplemente de una serie de diapositivas creadas por el personal de marketing. En nuestra prueba de manejo, los usuarios realmente utilizaron el software. Les llevó unos cinco minutos y, al final, habían creado una tienda real y funcional.
La prueba de manejo fue la forma en que obtuvimos casi todos nuestros nuevos usuarios. Creo que sucederá lo mismo con la mayoría de las aplicaciones basadas en la Web. Si los usuarios pueden superar la prueba de manejo con éxito, les gustará el producto. Si se confunden o se aburren, no les gustará. Por lo tanto, cualquier cosa que podamos hacer para que más personas realicen la prueba de manejo aumentará nuestra tasa de crecimiento.
Estudié los rastros de clics de las personas que hacían la prueba y descubrí que en un determinado paso se confundían y hacían clic en el botón Atrás del navegador. (Si intentas escribir aplicaciones basadas en la Web, descubrirás que el botón Atrás se convierte en uno de tus problemas filosóficos más interesantes). Así que añadí un mensaje en ese punto, avisando a los usuarios de que casi habían terminado y recordándoles que no hicieran clic en el botón Atrás. Otra gran ventaja del software basado en la Web es que se obtiene una respuesta instantánea de los cambios: la cantidad de personas que completaron la prueba aumentó inmediatamente del 60% al 90%. Y como la cantidad de nuevos usuarios era una función de la cantidad de pruebas completadas, nuestro crecimiento de los ingresos aumentó un 50%, solo por ese cambio.
Dinero
A principios de los años 90 leí un artículo en el que alguien decía que el software era un negocio de suscripción. Al principio me pareció una afirmación muy cínica, pero después me di cuenta de que refleja la realidad: el desarrollo de software es un proceso continuo. Creo que es más limpio si se cobran tarifas de suscripción abiertamente, en lugar de obligar a la gente a seguir comprando e instalando nuevas versiones para que sigan pagándote. Y, afortunadamente, las suscripciones son la forma natural de facturar las aplicaciones basadas en la Web.
El alojamiento de aplicaciones es un área en la que las empresas desempeñarán un papel que probablemente no pueda ser cubierto por el software gratuito. El alojamiento de aplicaciones genera mucho estrés y conlleva gastos reales. Nadie va a querer hacerlo de forma gratuita.
Para las empresas, las aplicaciones basadas en la Web son una fuente ideal de ingresos. En lugar de empezar cada trimestre desde cero, se dispone de un flujo de ingresos recurrente. Como el software evoluciona gradualmente, no hay que preocuparse de que un nuevo modelo fracase; nunca es necesario que haya un nuevo modelo, per se, y si se hace algo con el software que los usuarios odian, se sabrá de inmediato. No hay problemas con facturas incobrables; si alguien no quiere pagar, se puede simplemente desconectar el servicio. Y no hay posibilidad de piratería.
Esa última "ventaja" puede convertirse en un problema. Cierta cantidad de piratería beneficia a las empresas de software. Si algún usuario realmente no hubiera comprado su software a ningún precio, usted no ha perdido nada si utiliza una copia pirateada. De hecho, usted gana, porque es un usuario más que ayuda a convertir su software en el estándar, o que podría comprar una copia más adelante, cuando se gradúe de la escuela secundaria.
Cuando pueden, a las empresas les gusta hacer algo llamado discriminación de precios, que significa cobrar a cada cliente lo que pueda permitirse. [8] El software es particularmente adecuado para la discriminación de precios, porque el costo marginal es cercano a cero. Esta es la razón por la que algunos programas cuestan más para ejecutarse en Suns que en equipos Intel: una empresa que utiliza Suns no está interesada en ahorrar dinero y puede pagar más tranquilamente. La piratería es efectivamente el nivel más bajo de discriminación de precios. Creo que las empresas de software entienden esto y deliberadamente hacen la vista gorda ante algunos tipos de piratería. [9] Con el software basado en servidor van a tener que encontrar alguna otra solución.
El software basado en la Web se vende bien, especialmente en comparación con el software de escritorio, porque es fácil de comprar. Se podría pensar que la gente decide comprar algo y luego lo compra, como dos pasos separados. Eso es lo que pensaba antes de Viaweb, en la medida en que pensé en la cuestión. De hecho, el segundo paso puede propagarse hacia el primero: si algo es difícil de comprar, la gente cambiará de opinión sobre si lo quería o no. Y viceversa: se venderá más de algo cuando sea fácil de comprar. Compro más libros porque existe Amazon. El software basado en la Web es lo más fácil del mundo para comprar, especialmente si acabas de hacer una demostración en línea. Los usuarios no deberían tener que hacer mucho más que introducir un número de tarjeta de crédito. (Haz que hagan más bajo tu propio riesgo.)
En ocasiones, el software basado en la Web se ofrece a través de proveedores de servicios de Internet que actúan como revendedores, lo que no es una buena idea. Hay que administrar los servidores, porque es necesario mejorar constantemente tanto el hardware como el software. Si se renuncia al control directo de los servidores, se renuncia a la mayoría de las ventajas de desarrollar aplicaciones basadas en la Web.
Varios de nuestros competidores se dispararon en el pie de esta manera, generalmente, creo, porque estaban invadidos por ejecutivos que estaban entusiasmados con este enorme canal potencial y no se dieron cuenta de que arruinaría el producto que esperaban vender a través de él. Vender software basado en la Web a través de ISP es como vender sushi a través de máquinas expendedoras.
Clientes
¿Quiénes serán los clientes? En Viaweb, inicialmente eran particulares y pequeñas empresas, y creo que esto será lo habitual en el caso de las aplicaciones web. Se trata de usuarios que están dispuestos a probar cosas nuevas, en parte porque son más flexibles y en parte porque quieren los costes más bajos de las nuevas tecnologías.
Las aplicaciones basadas en la Web también suelen ser la mejor opción para las grandes empresas (aunque tardarán en darse cuenta de ello). La mejor intranet es Internet. Si una empresa utiliza aplicaciones basadas en la Web, el software funcionará mejor, los servidores estarán mejor administrados y los empleados tendrán acceso al sistema desde cualquier lugar.
El argumento contra este enfoque suele basarse en la seguridad: si el acceso es más fácil para los empleados, también lo será para los malos. Algunos comerciantes más grandes se mostraban reacios a utilizar Viaweb porque pensaban que la información de las tarjetas de crédito de los clientes estaría más segura en sus propios servidores. No era fácil plantear este punto de forma diplomática, pero, de hecho, los datos estaban casi con toda seguridad más seguros en nuestras manos que en las suyas. ¿Quién puede contratar a mejores personas para gestionar la seguridad, una empresa de nueva creación cuyo negocio consiste en gestionar servidores o una cadena de ropa? No sólo teníamos mejores personas que se preocupaban por la seguridad, sino que nosotros nos preocupábamos más por ella. Si alguien entraba en los servidores de la cadena de ropa, afectaría como máximo a un comerciante, probablemente podría ser silenciado y, en el peor de los casos, podría hacer que una persona fuera despedida. Si alguien entraba en los nuestros, podría afectar a miles de comerciantes, probablemente acabaría como noticia en CNet y podría dejarnos sin negocio.
Si desea mantener su dinero seguro, ¿lo guarda debajo del colchón en su casa o lo deposita en un banco? Este argumento se aplica a todos los aspectos de la administración de servidores: no solo a la seguridad, sino también al tiempo de actividad, el ancho de banda, la gestión de la carga, las copias de seguridad, etc. Nuestra existencia dependía de hacer estas cosas bien. Los problemas con los servidores eran un gran problema para nosotros, como un juguete peligroso lo sería para un fabricante de juguetes o un brote de salmonela para un procesador de alimentos.
Una gran empresa que utiliza aplicaciones basadas en la Web está, en esa medida, externalizando la TI. Por muy drástico que suene, creo que, en general, es una buena idea. Es probable que las empresas obtengan un mejor servicio de esta manera que si lo hicieran con administradores de sistemas internos. Los administradores de sistemas pueden volverse irritables y poco receptivos porque no están expuestos directamente a la presión competitiva: un vendedor tiene que tratar con los clientes y un desarrollador tiene que lidiar con el software de la competencia, pero un administrador de sistemas, como un viejo soltero, tiene pocas fuerzas externas que lo mantengan a raya. [10] En Viaweb teníamos muchas fuerzas externas que nos mantenían a raya. Las personas que nos llamaban eran clientes, no solo compañeros de trabajo. Si un servidor se atascaba, saltábamos; solo pensar en eso me da una descarga de adrenalina, años después.
Por lo tanto, las aplicaciones basadas en la Web también serán, en general, la respuesta adecuada para las grandes empresas. Sin embargo, serán las últimas en darse cuenta, como sucedió con los ordenadores de escritorio. Y en parte por la misma razón: costará mucho dinero convencer a las grandes empresas de que necesitan algo más caro.
Siempre existe una tendencia entre los clientes ricos a comprar soluciones caras, incluso cuando las soluciones baratas son mejores, porque la gente que ofrece soluciones caras puede gastar más para venderlas. En Viaweb siempre nos enfrentamos a esto. Perdimos a varios comerciantes de alto nivel a manos de empresas de consultoría web que los convencieron de que les iría mejor si pagaban medio millón de dólares por una tienda online hecha a medida en su propio servidor. Por lo general, no les iba mejor, como más de uno descubrió cuando llegó la temporada de compras navideñas y se pusieron a trabajar en su servidor. Viaweb era mucho más sofisticada que lo que la mayoría de estos comerciantes tenían, pero no podíamos permitirnos decírselo. A 300 dólares al mes, no podíamos permitirnos enviar un equipo de personas bien vestidas y con voz autoritaria para hacer presentaciones a los clientes.
Una gran parte de lo que las grandes empresas pagan de más es el coste de venderles cosas caras (si el Departamento de Defensa paga mil dólares por asientos de inodoro, es en parte porque cuesta mucho vender asientos de inodoro por mil dólares). Y esta es una de las razones por las que el software de intranet seguirá prosperando, aunque probablemente sea una mala idea: es simplemente más caro. No hay nada que se pueda hacer para solucionar este enigma, así que el mejor plan es ir primero a por los clientes más pequeños. El resto llegará con el tiempo.
Hijo del servidor
La ejecución de software en el servidor no es nada nuevo. De hecho, es el modelo antiguo: las aplicaciones de mainframe se basan todas en servidores. Si el software basado en servidores es una idea tan buena, ¿por qué perdió la última vez? ¿Por qué los ordenadores de sobremesa eclipsaron a los mainframes?
Al principio, los ordenadores de sobremesa no parecían una gran amenaza. Los primeros usuarios eran todos hackers (o aficionados, como se los llamaba entonces). Les gustaban los microordenadores porque eran baratos. Por primera vez, uno podía tener su propio ordenador. La frase «ordenador personal» forma parte del lenguaje actual, pero cuando se utilizó por primera vez tenía un sonido deliberadamente audaz, como el de «satélite personal» de hoy.
¿Por qué las computadoras de escritorio se hicieron cargo? Creo que fue porque tenían un mejor software. Y creo que la razón por la que el software de microcomputadoras era mejor era porque podía ser escrito por pequeñas empresas.
No creo que mucha gente se dé cuenta de lo frágiles y tentativas que son las startups en su fase inicial. Muchas de ellas empiezan casi por accidente: como un par de chicos, ya sea con trabajos fijos o en la escuela, escribiendo un prototipo de algo que podría, si parece prometedor, convertirse en una empresa. En esta fase larvaria, cualquier obstáculo significativo detendrá a la startup en seco. Escribir software para mainframe requería demasiado compromiso al principio. Las máquinas de desarrollo eran caras y, como los clientes serían grandes empresas, se necesitaba una fuerza de ventas de aspecto impresionante para vendérselo. Iniciar una startup para escribir software para mainframe sería una tarea mucho más seria que simplemente improvisar algo en tu Apple II por las noches. Y por eso no había muchas startups que escribieran aplicaciones para mainframe.
La llegada de los ordenadores de escritorio inspiró la creación de muchos programas nuevos, porque escribir aplicaciones para ellos parecía una meta alcanzable para las empresas emergentes. El desarrollo era barato y los clientes eran personas individuales a las que se podía llegar a través de tiendas de informática o incluso por correo.
La aplicación que hizo que los ordenadores de escritorio se convirtieran en algo común fue VisiCalc , la primera hoja de cálculo. Fue escrita por dos tipos que trabajaban en un ático y, sin embargo, hacía cosas que ningún software de mainframe podía hacer. [11] VisiCalc fue un avance tan grande, en su época, que la gente compraba Apple II solo para ejecutarlo. Y este fue el comienzo de una tendencia: los ordenadores de escritorio triunfaron porque las empresas emergentes escribieron software para ellos.
Parece que el software basado en servidores será bueno esta vez, porque las empresas emergentes lo escribirán. Los ordenadores son tan baratos ahora que se puede empezar, como hicimos nosotros, usando un ordenador de sobremesa como servidor. Los procesadores baratos se han comido el mercado de las estaciones de trabajo (ahora ya casi no se oye esa palabra) y han conquistado casi todo el mercado de servidores; los servidores de Yahoo, que manejan cargas tan altas como cualquier otro en Internet, tienen todos los mismos procesadores Intel baratos que tienes en tu ordenador de sobremesa. Y una vez que has escrito el software, todo lo que necesitas para venderlo es un sitio web. Casi todos nuestros usuarios llegaron directamente a nuestro sitio a través del boca a boca y de referencias en la prensa. [12]
Viaweb era una típica startup en ciernes. Nos aterrorizaba crear una empresa y durante los primeros meses nos consolamos pensando que todo era un experimento que podíamos cancelar en cualquier momento. Afortunadamente, hubo pocos obstáculos, salvo los técnicos. Mientras escribíamos el software, nuestro servidor web era la misma computadora de escritorio que usábamos para el desarrollo, conectada al mundo exterior mediante una línea telefónica. Nuestros únicos gastos en esa fase fueron la comida y el alquiler.
Ahora, las empresas emergentes tienen más motivos para escribir software basado en la Web, porque escribir software de escritorio se ha vuelto mucho menos divertido. Si quieres escribir software de escritorio ahora, lo haces según los términos de Microsoft, llamando a sus API y trabajando con su sistema operativo lleno de errores. Y si logras escribir algo que tenga éxito, es posible que descubras que simplemente estabas haciendo una investigación de mercado para Microsoft.
Si una empresa quiere crear una plataforma que sirva de base a las empresas emergentes, tiene que hacer que sea algo que los propios hackers quieran utilizar. Eso significa que tiene que ser barato y estar bien diseñado. El Mac era popular entre los hackers cuando salió al mercado y muchos de ellos desarrollaron software para él. [13] Esto se ve menos con Windows, porque los hackers no lo utilizan. El tipo de personas que son buenas escribiendo software tienden a utilizar Linux o FreeBSD en la actualidad.
No creo que hubiéramos creado una empresa para escribir software de escritorio, porque el software de escritorio tiene que funcionar en Windows y antes de poder escribir software para Windows tendríamos que usarlo. La Web nos permitió eludir a Windows y ofrecer software que se ejecuta en Unix directamente a los usuarios a través del navegador. Es una perspectiva liberadora, muy parecida a la llegada de los PC hace veinticinco años.
Microsoft
Cuando aparecieron los ordenadores de sobremesa, IBM era el gigante al que todo el mundo temía. Ahora resulta difícil imaginarlo, pero recuerdo muy bien la sensación. Ahora el gigante que da miedo es Microsoft, y no creo que sean tan ciegos a la amenaza que se les plantea como lo era IBM. Después de todo, Microsoft construyó deliberadamente su negocio en el punto ciego de IBM.
Mencioné antes que mi madre en realidad no necesita una computadora de escritorio. La mayoría de los usuarios probablemente no la necesiten. Eso es un problema para Microsoft y ellos lo saben. Si las aplicaciones se ejecutan en servidores remotos, nadie necesita Windows. ¿Qué hará Microsoft? ¿Podrán usar su control del escritorio para prevenir o limitar esta nueva generación de software?
Supongo que Microsoft desarrollará algún tipo de híbrido entre servidor y escritorio, donde el sistema operativo trabajará junto con los servidores que ellos controlan. Como mínimo, los archivos estarán disponibles de forma centralizada para los usuarios que lo deseen. No espero que Microsoft llegue al extremo de realizar los cálculos en el servidor, con solo un navegador como cliente, si pueden evitarlo. Si solo necesitas un navegador para un cliente, no necesitas a Microsoft en el cliente, y si Microsoft no controla el cliente, no pueden impulsar a los usuarios hacia sus aplicaciones basadas en servidor.
Creo que a Microsoft le resultará difícil mantener al genio dentro de la botella. Habrá demasiados tipos de clientes diferentes para que puedan controlarlos todos. Y si las aplicaciones de Microsoft sólo funcionan con algunos clientes, los competidores podrán superarlos ofreciendo aplicaciones que funcionen desde cualquier cliente. [14]
En un mundo de aplicaciones basadas en la Web, no hay un lugar fijo para Microsoft. Puede que consiga hacerse un lugar, pero no creo que domine este nuevo mundo como lo hizo con el de las aplicaciones de escritorio.
No es tanto que un competidor los haga tropezar, sino que ellos mismos se tropezarán. Con el auge del software basado en la Web, se enfrentarán no sólo a problemas técnicos, sino a sus propias ilusiones. Lo que necesitan hacer es canibalizar su negocio actual, y no puedo imaginar que se enfrenten a eso. La misma obstinación que los ha traído hasta aquí ahora estará trabajando en su contra. IBM estaba exactamente en la misma situación, y no pudieron dominarla. IBM entró tardíamente y a medias en el negocio de los microordenadores porque no estaban seguros de amenazar a su gallina de los huevos de oro, la informática mainframe. Microsoft también se verá obstaculizado por el deseo de salvar el escritorio. Una gallina de los huevos de oro puede ser un mono muy pesado sobre tu espalda.
No digo que nadie dominará las aplicaciones basadas en servidores. Probablemente alguien lo hará en algún momento. Pero creo que habrá un largo período de caos alegre, como en los primeros días de las microcomputadoras. Fue una buena época para las empresas emergentes. Muchas pequeñas empresas florecieron y lo hicieron creando cosas geniales.
Las startups, pero más
La startup clásica es rápida e informal, con poca gente y poco dinero. Esas pocas personas trabajan muy duro y la tecnología magnifica el efecto de las decisiones que toman. Si ganan, ganan a lo grande.
En una startup que desarrolla aplicaciones web, todo lo que se asocia con las startups se lleva al extremo. Se puede escribir y lanzar un producto con menos gente y menos dinero. Hay que ser aún más rápido y se puede salir del paso siendo más informal. Se puede lanzar literalmente un producto con tres personas sentadas en la sala de estar de un apartamento y un servidor conectado a un proveedor de servicios de Internet. Nosotros lo hicimos.
Con el tiempo, los equipos se han vuelto más pequeños, más rápidos y más informales. En 1960, el desarrollo de software significaba una sala llena de hombres con anteojos de montura de carey y corbatas negras estrechas, que escribían diligentemente diez líneas de código al día en formularios de codificación de IBM. En 1980, era un equipo de ocho a diez personas que usaban jeans para ir a la oficina y tecleaban en computadoras vt100. Ahora son un par de tipos sentados en una sala de estar con computadoras portátiles. (Y resulta que los jeans no son la última palabra en informalidad).
Las empresas emergentes son estresantes y, por desgracia, esto también se lleva al extremo con las aplicaciones basadas en la Web. Muchas empresas de software, especialmente al principio, tienen períodos en los que los desarrolladores duermen debajo de sus escritorios y cosas así. Lo alarmante del software basado en la Web es que no hay nada que impida que esto se convierta en la norma. Las historias sobre dormir debajo de los escritorios suelen terminar: luego, por fin, lo lanzamos y todos nos fuimos a casa y dormimos durante una semana. El software basado en la Web nunca se lanza. Puedes trabajar 16 horas al día durante el tiempo que quieras. Y como puedes, y tus competidores también, tiendes a verte obligado a hacerlo. Puedes, por lo tanto, debes hacerlo. Es la Ley de Parkinson funcionando al revés.
Lo peor no son las horas, sino la responsabilidad. Los programadores y los administradores de sistemas tienen, tradicionalmente, sus propias preocupaciones. Los programadores tienen que preocuparse por los errores y los administradores de sistemas tienen que preocuparse por la infraestructura. Los programadores pueden pasar un día entero sumergidos en código fuente, pero en algún momento pueden irse a casa y olvidarse de ello. Los administradores de sistemas nunca dejan atrás el trabajo, pero cuando reciben una llamada a las 4:00 de la mañana, normalmente no tienen que hacer nada muy complicado. Con las aplicaciones basadas en la Web, estos dos tipos de estrés se combinan. Los programadores se convierten en administradores de sistemas, pero sin los límites claramente definidos que normalmente hacen que el trabajo sea soportable.
En Viaweb, pasamos los primeros seis meses escribiendo software. Trabajamos las largas horas habituales de una startup. En una empresa de software de escritorio, esta habría sido la parte en la que trabajamos más duro, pero parecía unas vacaciones en comparación con la siguiente fase, cuando incorporamos usuarios a nuestro servidor. El segundo beneficio más importante de vender Viaweb a Yahoo (después del dinero) fue poder dejar la responsabilidad final de todo sobre los hombros de una gran empresa.
El software de escritorio obliga a los usuarios a convertirse en administradores de sistemas. El software basado en la Web obliga a los programadores a hacerlo. Hay menos estrés en total, pero más para los programadores. Eso no es necesariamente una mala noticia. Si eres una startup que compite con una gran empresa, es una buena noticia. [15] Las aplicaciones basadas en la Web ofrecen una manera sencilla de superar a tus competidores. Ninguna startup pide más.
Sólo lo suficientemente bueno
Una cosa que puede disuadirte de escribir aplicaciones basadas en la Web es la poca calidad de las páginas Web como interfaz de usuario. Es un problema, lo admito. Había algunas cosas que realmente nos hubiera gustado añadir a HTML y HTTP. Sin embargo, lo que importa es que las páginas Web sean lo suficientemente buenas.
Existe un paralelismo con los primeros microordenadores. Los procesadores de esas máquinas no estaban pensados para ser las CPU de los ordenadores, sino para usarse en cosas como los semáforos. Pero tipos como Ed Roberts, que diseñó el Altair , se dieron cuenta de que eran lo suficientemente buenos. Se podía combinar uno de estos chips con algo de memoria (256 bytes en el primer Altair) e interruptores en el panel frontal y se tenía un ordenador que funcionaba. Poder tener un ordenador propio era tan emocionante que había mucha gente que quería comprarlos, por limitados que fueran.
Las páginas web no fueron diseñadas para ser una interfaz de usuario para aplicaciones, pero son lo suficientemente buenas. Y para una cantidad significativa de usuarios, un software que se pueda utilizar desde cualquier navegador será suficiente por sí mismo para compensar cualquier incomodidad en la interfaz de usuario. Tal vez no se pueda escribir la hoja de cálculo más atractiva usando HTML, pero se puede escribir una hoja de cálculo que varias personas puedan usar simultáneamente desde diferentes ubicaciones sin un software cliente especial, o que pueda incorporar fuentes de datos en vivo, o que pueda enviarle una página cuando se activen ciertas condiciones. Más importante aún, se pueden escribir nuevos tipos de aplicaciones que aún no tienen nombre. Después de todo, VisiCalc no era simplemente una versión para microcomputadoras de una aplicación de mainframe: era un nuevo tipo de aplicación.
Por supuesto, las aplicaciones basadas en servidores no tienen por qué estar basadas en la Web. Se podría tener otro tipo de cliente, pero estoy bastante seguro de que es una mala idea. Sería muy conveniente si pudieras suponer que todo el mundo instalaría tu cliente (tan conveniente que podrías convencerte fácilmente de que todos lo harían), pero si no lo hacen, estás en problemas. Como el software basado en la Web no presupone nada sobre el cliente, funcionará en cualquier lugar donde funcione la Web. Esa es una gran ventaja ya, y la ventaja aumentará a medida que proliferen nuevos dispositivos Web. A los usuarios les gustará tu software porque simplemente funciona, y tu vida será más fácil porque no tendrás que modificarlo para cada nuevo cliente. [16]
Siento que he observado la evolución de la Web tan de cerca como cualquiera, y no puedo predecir lo que va a pasar con los clientes. Probablemente se produzca una convergencia, pero ¿hacia dónde? No puedo elegir un ganador. Una cosa que sí puedo predecir es el conflicto entre AOL y Microsoft. Sea lo que sea el .NET de Microsoft, probablemente implicará conectar el escritorio a los servidores. A menos que AOL contraataque, o bien serán dejados de lado o se convertirán en una conexión entre el software cliente y el servidor de Microsoft. Si Microsoft y AOL entran en una guerra de clientes, lo único que funcionará con seguridad en ambos será navegar por la Web, lo que significa que las aplicaciones basadas en la Web serán las únicas que funcionarán en todas partes.
¿Cómo se desarrollará todo esto? No lo sé. Y no es necesario que lo sepas si apuestas por las aplicaciones basadas en la Web. Nadie puede romper eso sin romper la navegación. La Web puede no ser la única forma de distribuir software, pero es una que funciona ahora y seguirá funcionando durante mucho tiempo. Las aplicaciones basadas en la Web son baratas de desarrollar y fáciles de entregar incluso para la startup más pequeña. Implican mucho trabajo y de un tipo particularmente estresante, pero eso solo mejora las probabilidades para las startups.
¿Por qué no?
A EB White le hizo gracia saber, por boca de un amigo granjero, que muchas vallas electrificadas no tienen corriente eléctrica. Al parecer, las vacas aprenden a mantenerse alejadas de ellas y, a partir de ese momento, ya no necesitan la corriente. "¡Levántense, vacas!", escribió, "¡Tomen su libertad mientras los déspotas roncan!".
Si eres un hacker que ha pensado en algún día crear una startup, probablemente haya dos cosas que te lo impidan. Una es que no sabes nada de negocios. La otra es que tienes miedo de la competencia. Ninguna de estas barreras tiene corriente.
Hay solo dos cosas que debes saber sobre negocios: crear algo que los usuarios amen y ganar más de lo que gastas. Si logras hacer bien estas dos cosas, estarás por delante de la mayoría de las empresas emergentes. Puedes descubrir el resto sobre la marcha.
Puede que al principio no ganes más de lo que gastas, pero mientras la brecha se cierre lo suficientemente rápido, estarás bien. Si empiezas con fondos insuficientes, al menos fomentarás el hábito de la frugalidad. Cuanto menos gastes, más fácil será ganar más de lo que gastas. Afortunadamente, puede resultar muy barato lanzar una aplicación basada en la Web. Nosotros la lanzamos con menos de 10.000 dólares, y hoy sería incluso más barata. Tuvimos que gastar miles de dólares en un servidor y miles más para obtener SSL. (La única empresa que vendía software SSL en ese momento era Netscape). Ahora puedes alquilar un servidor mucho más potente, con SSL incluido, por menos de lo que pagábamos solo por el ancho de banda. Podrías lanzar una aplicación basada en la Web ahora por menos del costo de una elegante silla de oficina.
En cuanto a crear algo que los usuarios amen, aquí hay algunos consejos generales. Empiece por hacer algo limpio y simple que usted mismo quiera usar. Saque una versión 1.0 rápidamente, luego continúe mejorando el software, escuchando atentamente a los usuarios mientras lo hace. El cliente siempre tiene razón, pero diferentes clientes tienen razón sobre diferentes cosas; los usuarios menos sofisticados le muestran lo que necesita simplificar y aclarar, y los más sofisticados le dicen qué características necesita agregar. Lo mejor que puede ser un software es fácil, pero la forma de hacerlo es acertar con los valores predeterminados, no limitar las opciones de los usuarios. No se confíe si el software de sus competidores es deficiente; el estándar con el que comparar su software es lo que podría ser, no lo que sus competidores actuales tengan. Use su software usted mismo, todo el tiempo. Viaweb se suponía que era un creador de tiendas en línea, pero lo usamos también para crear nuestro propio sitio. No escuche a la gente de marketing, diseñadores o gerentes de producto solo por sus títulos laborales. Si tienen buenas ideas, úselas, pero usted debe decidir; El software debe ser diseñado por hackers que entiendan de diseño, no por diseñadores que sepan un poco de software. Si no puedes diseñar software y también implementarlo, no inicies una startup.
Ahora hablemos de la competencia. Lo que temes no son los grupos de hackers como tú, sino las empresas reales, con oficinas, planes de negocios, vendedores y demás, ¿no? Bueno, ellos te tienen más miedo a ti que tú a ellos, y tienen razón. Es mucho más fácil para un par de hackers averiguar cómo alquilar un espacio de oficina o contratar vendedores que para una empresa de cualquier tamaño escribir un software. He estado en ambos lados y lo sé. Cuando Yahoo compró Viaweb, de repente me encontré trabajando para una gran empresa, y fue como intentar correr con el agua hasta la cintura.
No pretendo menospreciar a Yahoo. Tenían buenos hackers y los directivos eran unos auténticos pateadores de traseros. Para ser una gran empresa, eran excepcionales, pero su productividad era apenas una décima parte de la de una pequeña empresa emergente. Ninguna gran empresa puede hacerlo mucho mejor que eso. Lo que da miedo de Microsoft es que una empresa tan grande pueda desarrollar software. Son como una montaña que puede caminar.
No se deje intimidar. Usted puede hacer tanto como Microsoft no puede, como ellos pueden hacer que usted no puede. Y nadie puede impedírselo. No tiene que pedirle permiso a nadie para desarrollar aplicaciones basadas en la Web. No tiene que hacer acuerdos de licencia, ni conseguir espacio en las estanterías de las tiendas minoristas, ni humillarse para que su aplicación se incluya en el sistema operativo. Puede entregar el software directamente al navegador, y nadie puede interponerse entre usted y los usuarios potenciales sin impedirles navegar por la Web.
Puede que no lo creas, pero te aseguro que Microsoft te tiene miedo. Puede que los complacientes mandos intermedios no, pero Bill sí, porque él fue tú en 1975, la última vez que apareció una nueva forma de distribuir software.
Notas
[1] Al darse cuenta de que gran parte del dinero está en los servicios, las empresas que crean clientes ligeros generalmente han tratado de combinar el hardware con un servicio en línea . Este enfoque no ha funcionado bien, en parte porque se necesitan dos tipos diferentes de empresas para fabricar productos electrónicos de consumo y para ejecutar un servicio en línea, y en parte porque los usuarios odian la idea. Regalar la maquinilla de afeitar y ganar dinero con las hojas puede funcionar para Gillette, pero una maquinilla de afeitar es un compromiso mucho menor que un terminal web. Los fabricantes de teléfonos celulares se conforman con vender hardware sin tratar de capturar también los ingresos por servicios. Probablemente ese debería ser también el modelo para los clientes de Internet. Si alguien vendiera simplemente una pequeña caja de aspecto agradable con un navegador web que pudiera usarse para conectarse a través de cualquier ISP, todos los tecnófobos del país comprarían una.
[2] La seguridad siempre depende más de no cometer errores que de cualquier decisión de diseño, pero la naturaleza del software basado en servidores hará que los desarrolladores presten más atención a no cometer errores. Poner en riesgo un servidor podría causar tanto daño que los ASP (que quieren seguir en el negocio) probablemente sean cuidadosos con la seguridad.
[3] En 1995, cuando iniciamos Viaweb, se suponía que los applets de Java serían la tecnología que todo el mundo iba a utilizar para desarrollar aplicaciones basadas en servidor. Los applets nos parecían una idea pasada de moda. ¿Descargar programas para ejecutarlos en el cliente? Era más sencillo simplemente ejecutar los programas en el servidor. No perdimos mucho tiempo con los applets, pero incontables otras empresas emergentes debieron caer en este pozo de alquitrán. Pocos podrían haber escapado con vida, o Microsoft no habría podido salirse con la suya al eliminar Java en la versión más reciente de Explorer.
[4] Este punto se debe a Trevor Blackwell, quien agrega que "el costo de escribir software aumenta más que linealmente con su tamaño. Quizás esto se deba principalmente a la reparación de errores antiguos, y el costo puede ser más lineal si todos los errores se detectan rápidamente".
[5] El tipo de error más difícil de encontrar puede ser una variante de error compuesto, en el que un error compensa a otro. Cuando se corrige un error, el otro se hace visible, pero parecerá que la corrección es la culpable, ya que eso fue lo último que se cambió.
[6] En Viaweb organizamos una vez un concurso para describir lo peor de nuestro software. Dos personas del servicio de atención al cliente empataron por el primer premio y todavía me estremezco al recordar sus respuestas. Solucionamos ambos problemas de inmediato.
[7] Robert Morris escribió el sistema de pedidos que los compradores usaban para hacer pedidos. Trevor Blackwell escribió el generador de imágenes y el administrador que los comerciantes usaban para recuperar pedidos, ver estadísticas y configurar nombres de dominio, etc. Yo escribí el editor que los comerciantes usaban para crear sus sitios. El sistema de pedidos y el generador de imágenes se escribieron en C y C++, el administrador principalmente en Perl y el editor en Lisp .
[8] La discriminación de precios es tan generalizada (¿cuántas veces ha oído usted a un minorista afirmar que su poder adquisitivo significaba precios más bajos para usted?) que me sorprendió descubrir que estaba prohibida en los EE.UU. por la Ley Robinson-Patman de 1936. Esta ley no parece aplicarse con rigor.
[9] En No Logo, Naomi Klein dice que las marcas de ropa preferidas por la "juventud urbana" no se esfuerzan demasiado por evitar los hurtos en las tiendas porque en su mercado objetivo los ladrones también son los líderes de la moda.
[10] Las empresas se preguntan a menudo qué deben externalizar y qué no. Una posible respuesta: externalizar cualquier trabajo que no esté directamente expuesto a la presión competitiva, porque al externalizarlo se expondrá a la presión competitiva.
[11] Los dos eran Dan Bricklin y Bob Frankston. Dan escribió un prototipo en Basic en un par de días y, a lo largo del año siguiente, trabajaron juntos (sobre todo de noche) para crear una versión más potente escrita en lenguaje de máquina 6502. Dan estaba en la Escuela de Negocios de Harvard en ese momento y Bob tenía un trabajo nominal de día escribiendo software. "No había un gran riesgo en hacer negocios", escribió Bob, "si fallaba, fallaba. No era gran cosa".
[12] No es tan fácil como lo hago parecer. La publicidad boca a boca tardó muchísimo en ponerse en marcha y no empezamos a conseguir mucha cobertura de prensa hasta que contratamos a una empresa de relaciones públicas (la mejor del sector, sin duda) por 16.000 dólares al mes. Sin embargo, era cierto que el único canal importante era nuestro propio sitio web.
[13] Si el Mac era tan bueno, ¿por qué perdió? Por el costo, una vez más. Microsoft se concentró en el negocio del software y desató una multitud de proveedores de componentes baratos en el hardware de Apple. Tampoco ayudó que los ejecutivos tomaran el control durante un período crítico.
[14] Una cosa que ayudaría a las aplicaciones basadas en la Web y ayudaría a evitar que la próxima generación de software se vea eclipsada por Microsoft sería un buen navegador de código abierto. Mozilla es de código abierto, pero parece haber sufrido por haber sido un software corporativo durante tanto tiempo. Un navegador pequeño y rápido que se mantuviera en forma activa sería una gran cosa en sí misma y probablemente también alentaría a las empresas a construir pequeños dispositivos Web.
Entre otras cosas, un navegador de código abierto adecuado haría que HTTP y HTML siguieran evolucionando (como lo ha hecho Perl, por ejemplo). Ayudaría mucho a las aplicaciones basadas en la Web poder distinguir entre seleccionar un enlace y seguirlo; todo lo que se necesitaría para hacer esto sería una mejora trivial de HTTP, para permitir múltiples URL en una solicitud. Los menús en cascada también serían buenos.
Si quieres cambiar el mundo, escribe un nuevo Mosaic. ¿Crees que es demasiado tarde? En 1998, mucha gente pensó que era demasiado tarde para lanzar un nuevo motor de búsqueda, pero Google demostró que estaban equivocados. Siempre hay lugar para algo nuevo si las opciones actuales son lo suficientemente malas. Asegúrate primero de que funcione en todos los sistemas operativos gratuitos: las cosas nuevas comienzan con sus usuarios.
[15] Trevor Blackwell, quien probablemente sabe más sobre esto por experiencia personal que nadie, escribe:
"Yo iría más allá y diría que, como el software basado en servidores es tan duro para los programadores, provoca un cambio económico fundamental que los aleja de las grandes empresas. Requiere el tipo de intensidad y dedicación de los programadores que sólo estarán dispuestos a ofrecer cuando se trate de su propia empresa. Las empresas de software pueden contratar a personas cualificadas para trabajar en un entorno no demasiado exigente y pueden contratar a personas no cualificadas para soportar las dificultades, pero no pueden contratar a personas muy cualificadas para que se esfuercen al máximo. Como ya no se necesita capital, las grandes empresas tienen poco que ofrecer".
[16] En la versión original de este ensayo, aconsejé evitar el uso de Javascript. Era un buen plan en 2001, pero Javascript ahora funciona.
Gracias a Sarah Harlin, Trevor Blackwell, Robert Morris, Eric Raymond, Ken Anderson y Dan Giffin por leer los borradores de este artículo; a Dan Bricklin y Bob Frankston por la información sobre VisiCalc; y nuevamente a Ken Anderson por invitarme a hablar en BBN.
Encontrarás este ensayo y otros 14 en Hackers & Painters .