EL OTRO CAMINO POR DELANTE
OriginalSeptiembre 2001
(Este artículo explica por qué gran parte de la próxima generación de software puede ser basado en servidores, lo que significará para los programadores, y por qué este nuevo tipo de software es una gran oportunidad para las startups. Se deriva de una charla en BBN Labs.)
En el verano de 1995, mi amigo Robert Morris y yo decidimos iniciar una startup. La campaña de relaciones públicas previa a la OPI de Netscape estaba en pleno apogeo entonces, y había mucha discusión en la prensa sobre el comercio en línea. En ese momento, tal vez hubiera treinta tiendas reales en la Web, todas hechas a mano. Si iba a haber muchas tiendas en línea, se necesitaría software para crearlas, así que decidimos escribir algo.
Durante la primera semana o así, teníamos la intención de hacer esto una aplicación de escritorio normal. Luego, un día tuvimos la idea de hacer que el software se ejecutara en nuestro servidor web, usando el navegador como interfaz. Intentamos reescribir el software para que funcionara a través de la Web, y quedó claro que este era el camino a seguir. Si escribíamos nuestro software para que se ejecutara en el servidor, sería mucho más fácil para los usuarios y para nosotros también.
Este resultó ser un buen plan. Ahora, como Yahoo Store, este software es el constructor de tiendas en línea más popular, con aproximadamente 14,000 usuarios.
Cuando comenzamos Viaweb, casi nadie entendía a qué nos referíamos 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 comenzó a entenderlo. Ahora todo el mundo sabe que este es un enfoque válido. Hay un nombre ahora 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á con este modelo. Incluso Microsoft, que tiene más que perder, parece ver la inevitabilidad de mover algunas cosas fuera del escritorio. Si el software se mueve del escritorio a los servidores, significará un mundo muy diferente para los desarrolladores. Este artículo describe las sorprendentes cosas que vimos, como algunos de los primeros visitantes a este nuevo mundo. En la medida en que el software se mueva a los servidores, lo que estoy describiendo aquí es el futuro.
¿Lo Próximo?
Cuando miremos hacia atrás en la era del software de escritorio, creo que nos asombraremos de las inconveniencias que la gente soportaba, así como nos asombramos ahora de lo que los primeros propietarios de automóviles soportaban. Durante los primeros veinte o treinta años, tenías que ser un experto en automóviles para tener uno. Pero los automóviles eran tan una gran victoria que mucha gente que no era experta en automóviles quería tenerlos también.
Las computadoras están en esta fase ahora. Cuando tienes una computadora de escritorio, terminas aprendiendo mucho más de lo que querías saber sobre lo que está pasando dentro de ella. Pero más de la mitad de los hogares en EE. UU. tienen una. Mi madre tiene una computadora que usa para el correo electrónico y para mantener sus cuentas. Hace aproximadamente un año se alarmó al recibir una carta de Apple, ofreciéndole un descuento en una nueva versión del sistema operativo. Hay algo mal cuando una mujer de sesenta y cinco años que quiere usar una computadora para el correo electrónico y las cuentas tiene que pensar en instalar nuevos sistemas operativos. Los usuarios comunes ni siquiera deberían conocer las palabras "sistema operativo", mucho menos "controlador de dispositivo" o "parche".
Ahora hay otra forma de entregar software que salvará a los usuarios de convertirse en administradores de sistemas. Las aplicaciones web son programas que se ejecutan en servidores web y usan páginas web como la interfaz de usuario. Para el usuario promedio, este nuevo tipo de software será más fácil, más barato, más móvil, más confiable y a menudo más potente que el software de escritorio.
Con el 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 usan. Todo el desorden y los cambios estarán en un servidor en algún lugar, mantenidos por el tipo de personas que son buenas en ese tipo de cosas. Y entonces no necesitarás una computadora, en sí, para usar software. Todo lo que necesitarás será algo con un teclado, una pantalla y un navegador web. Tal vez tenga acceso a Internet inalámbrico. Tal vez también será tu teléfono celular. Sea lo que sea, será electrónica de consumo: algo que cuesta alrededor de $200, y que la gente elige principalmente por cómo se ve la carcasa. Pagarás más por los servicios de Internet de lo que pagas por el hardware, al igual que lo haces ahora con los teléfonos. [1]
Tomará aproximadamente una décima de segundo que un clic llegue al servidor y vuelva, por lo que los usuarios de software muy interactivo, como Photoshop, aún querrán que los cálculos se realicen en el escritorio. Pero si miras el tipo de cosas que la mayoría de la gente usa las computadoras, una latencia de una décima de segundo no sería un problema. Mi madre realmente no necesita una computadora de escritorio, y hay mucha gente como ella.
La Victoria para los Usuarios
Cerca de mi casa hay un automóvil con una calcomanía en el parachoques que dice "muerte antes de la inconveniencia". La mayoría de las personas, la mayor parte del tiempo, tomarán cualquier opción que requiera menos trabajo. Si el software basado en la web gana, será porque es más conveniente. Y parece que lo será, para los usuarios y los desarrolladores.
Para usar una aplicación puramente basada en la web, todo lo que necesitas es un navegador conectado a Internet. Entonces puedes usar una aplicación basada en la web en cualquier lugar. Cuando instalas software en tu computadora de escritorio, solo puedes usarlo en esa computadora. Peor aún, tus archivos quedan atrapados en esa computadora. La inconveniencia de este modelo se vuelve cada vez más evidente a medida que la gente se acostumbra a las redes.
El extremo delgado de la cuña aquí fue el correo electrónico basado en la web. Millones de personas ahora se dan cuenta de que deberías tener acceso a los mensajes de correo electrónico sin importar dónde estés. Y si puedes ver tu correo electrónico, ¿por qué no tu calendario? Si puedes discutir un documento con tus colegas, ¿por qué no puedes editarlo? ¿Por qué cualquiera de tus datos debería quedar atrapado en alguna computadora sentada en un escritorio lejano?
La idea de "tu computadora" se está yendo, y siendo reemplazada por "tus datos". Deberías poder acceder a tus datos desde cualquier computadora. O más bien, desde cualquier cliente, y un cliente no tiene que ser una computadora.
Los clientes no deberían almacenar datos; deberían ser como teléfonos. De hecho, pueden convertirse en teléfonos, o viceversa. Y a medida que los clientes se vuelven más pequeños, tienes otra razón para no mantener tus datos en ellos: algo que llevas contigo puede perderse o ser robado. Dejar tu PDA en un taxi es como un disco duro que se rompe, excepto que tus datos se entregan a otra persona en lugar de ser vaporizada.
Con software puramente basado en la web, ni los datos ni las aplicaciones se mantienen en el cliente. Por lo tanto, no tienes que instalar nada para usarlo. Y cuando no hay instalación, no tienes que preocuparte por que la instalación salga mal. No puede haber incompatibilidades entre la aplicación y tu sistema operativo, porque el software no se ejecuta en tu sistema operativo.
Debido a que no necesita instalación, será fácil y común probar el software basado en la web antes de "comprarlo". Deberías esperar poder probar cualquier aplicación basada en la web de forma gratuita, simplemente visitando el sitio donde se ofrece. En Viaweb, todo nuestro sitio era como una gran flecha apuntando a los usuarios hacia la prueba.
Después de probar la demostración, registrarse en el servicio no debería requerir más que llenar un breve formulario (cuanto más breve, mejor). Y ese debería ser el último trabajo que el usuario tenga que hacer. Con el software basado en la web, deberías recibir nuevas versiones sin pagar extra, sin hacer ningún trabajo o posiblemente sin siquiera saberlo.
Las actualizaciones no serán los grandes golpes que son ahora. Con el tiempo, las aplicaciones crecerán en silencio y se volverán más poderosas. Esto requerirá un esfuerzo por parte de los desarrolladores. Tendrán que diseñar software para que pueda actualizarse sin confundir a los usuarios. Ese es un nuevo problema, pero hay formas de resolverlo.
Con las aplicaciones basadas en la web, todos usan 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 más de diez errores conocidos en cualquier momento. Eso es órdenes de magnitud mejor que el software de escritorio.
Las aplicaciones basadas en la web se pueden usar por varias personas al mismo tiempo. Esta es una victoria obvia para las aplicaciones de colaboración, 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 permitía a varios usuarios editar 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 uses una aplicación basada en la web, tus datos estarán más seguros. Los fallos de disco no serán cosa del pasado, pero los usuarios ya no escucharán sobre ellos. Ocurrirán dentro de los centros de datos. Y las empresas que ofrecen aplicaciones basadas en la web realmente harán copias de seguridad, no solo porque tendrán administradores de sistemas reales preocupándose por esas cosas, sino porque un ASP que pierda los datos de las personas estará en graves problemas. Cuando las personas pierden sus propios datos en un fallo de disco, no pueden enojarse mucho, porque solo tienen a sí mismos de quienes enojarse. Cuando una empresa pierde sus datos por ellos, se enojarán mucho más.
Finalmente, el software basado en la web debería ser menos vulnerable a los virus. Si el cliente no ejecuta nada excepto un navegador, hay menos posibilidades de ejecutar virus y no hay datos locales que dañar. Y un programa que atacara a los servidores mismos debería encontrarlos muy bien defendidos. [2]
Para los usuarios, el software basado en la web será menos estresante. Creo que si miráramos dentro del usuario de Windows promedio, encontraríamos un enorme y prácticamente sin explotar deseo de software que cumpla con esa descripción. Liberado, podría ser una fuerza poderosa.
Ciudad de código
Para los desarrolladores, la diferencia más notoria entre el software basado en la web y el de escritorio es que una aplicación basada en la web no es una sola pieza de código. Será una colección de programas de diferentes tipos en lugar de un solo binario grande. Y, por lo tanto, diseñar software basado en la web es como diseñar una ciudad en lugar de un edificio: además de los edificios, necesitas carreteras, señales de tráfico, servicios públicos, policía y departamentos de bomberos, y planes tanto para el crecimiento como para varios 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 compilar estadísticas o construir índices para búsquedas, programas que ejecutábamos explícitamente para recolectar recursos o mover o restaurar datos, programas que fingían ser usuarios (para medir el rendimiento o exponer errores), programas para diagnosticar problemas de red, programas para hacer copias de seguridad, interfaces a servicios externos, software que impulsaba una impresionante colección de indicadores que mostraban estadísticas de servidores en tiempo real (un éxito con los visitantes, pero indispensable para nosotros también), modificaciones (incluidas las correcciones de errores) al software de código abierto y una gran cantidad de archivos de configuración y ajustes. Trevor Blackwell escribió un programa espectacular para mover tiendas a nuevos servidores en todo el país, sin cerrarlas, después de que nos comprara Yahoo. Los programas nos enviaban mensajes, 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 las personas podrían usar para irrumpir en tus servidores.
No terminó con el software. Pasamos mucho tiempo pensando en las configuraciones de los servidores. Construimos los servidores nosotros mismos, a partir de componentes, en parte para ahorrar dinero y en parte para obtener exactamente lo que queríamos. Tuvimos que pensar si nuestro ISP ascendente tenía conexiones lo suficientemente rápidas a todas las redes troncales. Salimos con citas a los proveedores de RAID.
Pero el hardware no es solo algo de lo que preocuparse. Cuando lo controlas, puedes hacer más por los usuarios. Con una aplicación de escritorio, puedes especificar cierto hardware mínimo, pero no puedes agregar más. Si administras los servidores, puedes habilitar en un solo paso a todos tus usuarios para que envíen mensajes a personas, envíen faxes, envíen comandos por teléfono o procesen tarjetas de crédito, etc., simplemente instalando el hardware relevante. Siempre buscamos nuevas formas de agregar funciones con hardware, no solo porque complace a los usuarios, sino también como una forma de distinguirnos de los competidores que (ya sea porque vendían software de escritorio o revendían aplicaciones web a través de ISP) no tenían control directo sobre el hardware.
Debido a que el software en una aplicación web será una colección de programas en lugar de un solo binario, se puede escribir en cualquier número de lenguajes diferentes. Cuando estás escribiendo software de escritorio, prácticamente te ves obligado a escribir la aplicación en el mismo lenguaje que el sistema operativo subyacente, lo que significa C y C++. Y así estos lenguajes (especialmente entre las personas no técnicas como gerentes y VC) llegaron a ser considerados como los lenguajes para el "desarrollo de software serio". Pero eso fue solo un artefacto de la forma en que se tenía que entregar el software de escritorio. Para el software basado en servidores, puedes usar cualquier lenguaje que quieras. [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 servidores, nadie puede decirte qué lenguaje usar, porque controlas todo el sistema, hasta el hardware. Diferentes lenguajes son buenos para diferentes tareas. Puedes usar el que mejor se adapte a 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 ibas a cambiar algo, todos los cambios tenían que ocurrir en una sola página, con un botón de Actualizar al final. Como he escrito en otro lugar, al usar Lisp, que muchas personas aún consideran 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 en que realizas 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 por sacar una sola pieza de código gigante. Surgen comparaciones obvias, tanto con el proceso como con el producto resultante.
Con el software basado en servidores, puedes hacer cambios casi como lo harías en un programa que estuvieras escribiendo para ti mismo. Lanzas el software como una serie de cambios incrementales en lugar de una gran explosión ocasional. Una empresa típica de software de escritorio podría hacer uno o dos lanzamientos al año. En Viaweb a menudo hacíamos de tres a cinco lanzamientos al día.
Cuando cambias a este nuevo modelo, te das cuenta de cuánto afecta el desarrollo de software la forma en que se lanza. Muchos de los problemas más desagradables que ves en el negocio del software de escritorio se deben a la naturaleza catastrófica de los lanzamientos.
Cuando solo lanzas una nueva versión al año, tiendes a lidiar con los errores a granel. Algún tiempo antes de la fecha de lanzamiento, ensamblas 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 personas de control de calidad interviene y comienza a contarlos, y los programadores trabajan en la lista, corrigiéndolos. Generalmente 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 sabes realmente qué está pasando dentro del software. En el mejor de los casos, terminas con una especie de corrección estadística.
Con el software basado en servidores, la mayor parte del cambio es pequeño e incremental. Eso en sí mismo es menos propenso a introducir errores. También significa que sabes qué probar con más cuidado cuando estás a punto de lanzar software: lo último que cambiaste. Terminas teniendo un control mucho más firme del código. Como regla general, sí sabes qué está pasando dentro de él. No memorizas el código fuente, por supuesto, pero cuando lo lees, lo haces como un piloto que escanea el panel de instrumentos, no como un detective que intenta desentrañar un misterio.
El software de escritorio genera un cierto fatalismo sobre los errores. Sabes que estás enviando algo cargado de errores, e incluso has establecido mecanismos para compensarlo (por ejemplo, lanzamientos de parches). Entonces, ¿por qué preocuparse por unos pocos más? Pronto estás lanzando funciones enteras que sabes que están rotas. Apple hizo esto a principios de este año. Sintieron presión por lanzar su nuevo sistema operativo, cuya fecha de lanzamiento ya se había retrasado cuatro veces, pero parte del software (soporte para CD y DVD) no estaba listo. ¿La solución? Lanzaron el sistema operativo sin las partes sin terminar, y los usuarios tendrán que instalarlas más tarde.
Con el software basado en la web, nunca tienes que lanzar software antes de que funcione, y puedes lanzarlo tan pronto como funcione.
El veterano de la industria puede estar pensando: es una idea interesante decir que nunca tienes que lanzar software antes de que funcione, pero ¿qué pasa cuando has prometido entregar una nueva versión de tu software para una fecha determinada? Con el software basado en la web, no harías tal promesa, porque no hay versiones. Tu software cambia gradual y continuamente. Algunos cambios podrían ser más grandes que otros, pero la idea de las versiones simplemente no se ajusta naturalmente al software basado en la web.
Si alguien recuerda Viaweb, esto podría sonar extraño, porque siempre anunciábamos nuevas versiones. Esto se hizo enteramente con fines de relaciones públicas. La prensa comercial, aprendimos, piensa en números de versión. Te darán una cobertura importante por un lanzamiento importante, lo que significa un nuevo primer dígito en el número de versión, y generalmente un párrafo como máximo por un lanzamiento de punto, lo que significa un nuevo dígito después del punto decimal.
Algunos de nuestros competidores ofrecían software de escritorio e incluso tenían números de versión. Y por estos lanzamientos, el mero hecho de que existieran parecía ser para nosotros una evidencia de su atraso, y obtenían todo tipo de publicidad. No queríamos quedarnos atrás, así que también empezamos a asignar números de versión a nuestro software. Cuando queríamos algo de publicidad, hacíamos una lista de todas las funciones que habíamos agregado desde la "versión" anterior, le poníamos un nuevo número de versión al software y emitíamos un comunicado de prensa diciendo que la nueva versión estaba disponible de inmediato. Sorprendentemente, nadie nos cuestionó nunca al respecto.
Para cuando nos compraron, habíamos hecho esto tres veces, así que estábamos en la Versión 4. Creo que era la Versión 4.1. 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, toda la idea de los números de versión se abandonó en silencio.
Errores
La otra gran ventaja técnica del software basado en la web es que puedes reproducir la mayoría de los errores. Tienes los datos de los usuarios justo ahí, en tu disco. Si alguien rompe tu software, no tienes que adivinar qué está pasando, como lo harías con el software de escritorio: deberías poder reproducir el error mientras hablan contigo por teléfono. Incluso podrías saberlo de antemano, si tienes código para detectar errores incorporado en tu aplicación.
El software basado en la web se usa las 24 horas del día, así que todo lo que hagas se somete de inmediato a una prueba exhaustiva. Los errores aparecen rápidamente.
A veces se acusa a las empresas de software de dejar que los usuarios depuren su software. Y eso es precisamente lo que estoy defendiendo. Para el software basado en la web, en realidad es un buen plan, porque los errores son menos frecuentes y transitorios. Cuando lanzas el software de forma gradual, empiezas con muchos menos errores. Y cuando puedes reproducir errores y lanzar cambios de inmediato, puedes encontrar y corregir la mayoría de los errores tan pronto como aparecen. Nunca tuvimos suficientes errores al mismo tiempo como para molestarnos con un sistema formal de seguimiento de errores.
Por supuesto, debes probar los cambios antes de lanzarlos, para que no se liberen errores importantes. Esos pocos que inevitablemente se filtran involucrarán casos límite y solo afectarán a los pocos usuarios que los encuentren antes de que alguien llame para quejarse. Mientras corrijas los errores de inmediato, el efecto neto, para el usuario promedio, es mucho menos errores. Dudo que el usuario promedio de Viaweb haya visto alguna vez un error.
Corregir errores recientes es más fácil que corregir errores antiguos. Por lo general, es bastante rápido encontrar un error en el código que acabas de escribir. Cuando aparece, a menudo sabes qué está mal antes de siquiera mirar el código fuente, porque ya lo estabas preocupando subconsciente. Corregir un error en algo que escribiste hace seis meses (el caso promedio si lanzas una vez al año) es mucho más trabajo. Y como no entiendes el código tan bien, es más probable que lo arregles de una manera fea o incluso que introduzcas más errores. [4]
Cuando atrapas los errores temprano, también obtienes menos errores compuestos. Los errores compuestos son dos errores separados que interactúan: tropiezas bajando las escaleras y cuando te agarras del pasamanos, este se sale de tu mano. En el software, este tipo de error es el más difícil de encontrar y también tiende a tener las peores consecuencias. [5] El enfoque tradicional de "romper todo y luego filtrar los errores" inherentemente produce muchos errores compuestos. Y el software que se lanza en una serie de pequeños cambios tiende a no tenerlos. Los pisos se barren constantemente de cualquier objeto suelto que pudiera luego atascarse en algo.
Ayuda si usas una técnica llamada programación funcional. La programación funcional significa evitar los efectos secundarios. Es algo que es más probable ver en artículos de investigación que en software comercial, pero para las aplicaciones basadas en la web resulta realmente útil. Es difícil escribir programas enteros como código puramente funcional, pero puedes escribir partes sustanciales de esa manera. Hace que esas partes de tu software sean más fáciles de probar, porque no tienen estado, y eso es muy conveniente en una situación en la que estás haciendo y probando constantemente pequeñas modificaciones. Escribí gran parte del editor de Viaweb de esta manera, y convertimos nuestro lenguaje de secuencias de comandos, RTML, en un lenguaje puramente funcional.
La gente del negocio del software de escritorio encontrará esto difícil de creer, pero en Viaweb los errores se convirtieron casi en un juego. Como la mayoría de los errores lanzados involucraban casos límite, los usuarios que los encontraban probablemente eran usuarios avanzados, que empujaban los límites. Los usuarios avanzados son más tolerantes con los errores, especialmente si probablemente los introdujiste en el curso de agregar alguna función que estaban solicitando. De hecho, debido a que los errores eran raros y tenías que estar haciendo cosas sofisticadas para verlos, los usuarios avanzados a menudo se enorgullecían de atrapar uno. Llamarían al soporte con un espíritu más de triunfo que de enojo, como si nos hubieran anotado puntos.
Soporte
Cuando puedes reproducir errores, cambia tu enfoque del soporte al cliente. En la mayoría de las empresas de software, el soporte se ofrece como una forma de hacer que los clientes se sientan mejor. O bien están llamando por un error conocido, o simplemente están haciendo algo mal y tienes que averiguar qué. En cualquier caso, no hay mucho que puedan enseñarte. Y por eso tiendes a ver las llamadas de soporte como una molestia que quieres aislar de tus desarrolladores tanto como sea posible.
Así no funcionaban las cosas en Viaweb. En Viaweb, el soporte era gratuito, porque queríamos escuchar a los clientes. Si alguien tenía un problema, queríamos saberlo de inmediato para poder reproducir el error y lanzar una corrección.
Así que en Viaweb, los desarrolladores siempre estaban en estrecho contacto con el soporte. El personal de soporte al cliente estaba a unos treinta pies de los programadores, y sabía que siempre podían interrumpir cualquier cosa con un informe de un error real. Dejaríamos una reunión de la junta para corregir un error grave.
Nuestro enfoque del soporte hizo que todos fueran más felices. Los clientes estaban encantados. Imagina 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 les gustaba porque significaba que podían ayudar a los usuarios, en lugar de leerles guiones. Y a los programadores les gustaba 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 atención 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 del Padre Dios, creadores del mundo. Cualquiera que sea el procedimiento para informar sobre errores, es probable que sea unidireccional: el personal de soporte que se entera de los errores llena un formulario que eventualmente se pasa (posiblemente a través de QA) a los programadores, quienes lo ponen en su lista de cosas por hacer. Fue muy diferente en Viaweb. En cuestión de minutos de escuchar sobre un error de un cliente, el personal de soporte podía estar parado al lado de un programador escuchándolo decir "Mierda, tienes razón, es un error". Deleitaba al personal de soporte escuchar ese "tienes razón" de los hackers. Solían traernos errores con el mismo aire expectante que un gato te trae un ratón que acaba de matar. También los hizo más cuidadosos al juzgar la gravedad de un error, porque ahora su honor estaba en juego.
Después de que nos comprara Yahoo, el personal de atención al cliente se mudó lejos de los programadores. Fue entonces cuando nos dimos cuenta de que eran efectivamente QA y, en cierta medida, también marketing. Además de detectar errores, eran los guardianes del conocimiento de cosas más vagas y similares a errores, como características que confundían a los usuarios. [6] También eran una especie de grupo de enfoque por delegación; podíamos preguntarles cuál de dos nuevas características querían los usuarios más, y siempre tenían razón.
Moral
Poder lanzar software de inmediato es un gran motivador. A menudo, mientras caminaba al trabajo, pensaba en algún cambio que quería hacer en el software y lo hacía ese mismo día. Esto funcionaba también para características más grandes. Incluso si algo iba a llevar dos semanas escribirlo (pocos proyectos llevaban más tiempo), sabía que podía ver el efecto en el software tan pronto como estuviera terminado.
Si tuviera que esperar un año para el próximo lanzamiento, habría archivado la mayoría de estas ideas, al menos por un tiempo. Pero la cosa 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. Así que archivar una idea te cuesta no solo ese retraso en implementarla, sino también todas las ideas a las que esa implementación habría dado lugar. De hecho, archivar una idea probablemente incluso inhiba nuevas ideas: cuando empiezas a pensar en alguna nueva característica, vislumbras 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 características es planificarlas. En Viaweb a veces nos metíamos en 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 planes. Teníamos ideas generales sobre cosas que queríamos mejorar, pero si lo supiéramos, ya lo habríamos hecho. ¿Qué íbamos a hacer en los próximos seis meses? Lo que pareciera la mayor victoria. No sé si alguna vez me atreví a dar esta respuesta, pero esa era la verdad. Los planes no son más que otra palabra para las ideas en el estante. 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 definitivo. Pero cuando eras el dueño, realmente lo eras: nadie, excepto el propietario de una pieza de software, tenía que aprobar (o incluso saber) un lanzamiento. No había protección contra los daños, excepto el miedo a parecer un idiota ante sus compañeros, y eso era más que suficiente. Puede que haya dado la impresión de que simplemente avanzábamos a toda prisa escribiendo código. Íbamos rápido, pero pensábamos muy cuidadosamente antes de lanzar software a esos servidores. Y prestar atención es más importante para la confiabilidad que moverse lentamente. Debido a que presta mucha atención, un piloto de la Armada puede aterrizar un avión de 40,000 libras a 140 millas por hora en la cubierta de un portaaviones que se mueve, de noche, con más seguridad que el adolescente promedio al cortar un bagel.
Esta forma de escribir software es una espada de doble filo, por supuesto. Funciona mucho mejor para un pequeño equipo de buenos y confiables programadores que para una gran empresa de mediocres, donde las malas ideas son atrapadas por comités en lugar de 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 general. Solo 13 de ellos estaban en desarrollo de productos. Todos los demás trabajaban en lanzamientos, puertos y similares. Con el software basado en la web, todo lo que necesitas (como máximo) son esos 13 personas, porque no hay lanzamientos, puertos, etc.
Viaweb fue escrito por solo tres personas. [7] Siempre estuve bajo presión para contratar más, porque queríamos que nos compraran, y sabíamos que a los compradores les costaría pagar un precio alto por una empresa con solo tres programadores. (Solución: contratamos más, pero les creamos nuevos proyectos).
Cuando puedes escribir software con menos programadores, te ahorras más que dinero. Como señaló Fred Brooks en The Mythical Man-Month, agregar personas a un proyecto tiende a ralentizarlo. El número de posibles conexiones entre los 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 por interacciones imprevistas. Afortunadamente, este proceso también funciona a la inversa: a medida que los grupos se vuelven más pequeños, el desarrollo de software se vuelve exponencialmente más eficiente. No puedo recordar que los programadores de Viaweb alguna vez tuvieran una reunión real. Nunca teníamos más que decir en un momento dado de lo que podíamos decir mientras caminábamos al almuerzo.
Si hay un inconveniente aquí, es que todos los programadores tienen que ser en cierta medida también 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 adecuadamente son las que escribieron el software. En Viaweb, nuestro sistema tenía tantos componentes y cambiaba tan frecuentemente 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 así, aunque esperábamos constantemente que algún día ("en un par de meses") todo fuera lo suficientemente estable como para poder contratar a alguien cuyo trabajo fuera simplemente preocuparse por los servidores, nunca sucedió.
No creo que pueda ser de otra manera, mientras sigas desarrollando activamente el producto. El software basado en la web nunca será algo que escribas, ingreses y te vayas a casa. Es algo vivo, que se ejecuta en tus servidores en este momento. Un error grave podría no solo hacer que se bloquee el proceso de un usuario, sino que podría bloquearlos a todos. Si un error en tu código corrompe algunos datos en el disco, tienes que arreglarlo. Y así sucesivamente. Descubrimos que no tienes que vigilar los servidores cada minuto (después del primer año más o menos), pero definitivamente quieres mantener un ojo en 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 el software basado en el 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 famosa por presentarse a los clientes en las tiendas minoristas y pedir seguirlos a casa. Si alguna vez has visto a alguien usar tu software por primera vez, sabes qué sorpresas debieron haberles esperado.
El software debe hacer lo que los usuarios piensan que hará. Pero no puedes tener idea de lo que estarán pensando los usuarios, créeme, hasta que los observes. Y el software basado en el servidor te brinda información sin precedentes sobre su comportamiento. No estás limitado a pequeños grupos de enfoque artificiales. Puedes ver cada clic realizado por cada usuario. Tienes que considerar cuidadosamente qué vas a mirar, porque no quieres violar la privacidad de los usuarios, pero incluso el muestreo estadístico más general puede ser muy útil.
Cuando tienes a los usuarios en tu servidor, no tienes que confiar en los puntos de referencia, por ejemplo. Los puntos de referencia son usuarios simulados. Con el software basado en el servidor, puedes observar a los usuarios reales. Para decidir qué optimizar, simplemente inicia sesión en un servidor y ve qué está consumiendo toda la CPU. Y sabes cuándo dejar de optimizar: eventualmente logramos que el editor de Viaweb llegara al punto en que estaba limitado por la memoria en lugar de la CPU, y dado que no había nada que pudiéramos hacer para disminuir el tamaño de los datos de los usuarios (bueno, nada fácil), sabíamos que podríamos detenernos allí.
La eficiencia es importante para el software basado en el servidor, porque estás pagando por el hardware. El número de usuarios que puedes admitir por servidor es el divisor de tu costo de capital, por lo que si puedes hacer que tu software sea muy eficiente, puedes vender a tus competidores a un precio más bajo y aún así obtener ganancias. En Viaweb logramos reducir el costo de capital por usuario a aproximadamente $5. Sería menos ahora, 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 guiarte en el diseño, así como en la optimización. Viaweb tenía un lenguaje de secuencias de comandos 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, pero después de que varios usuarios usaran RTML para colocar los botones a la izquierda lado, hicimos que esa fuera una opción (de hecho, la predeterminada) en los estilos de página predefinidos.
Finalmente, al observar a los usuarios, a menudo puedes saber cuándo tienen problemas. Y dado que el cliente siempre tiene la razón, esa es una señal de algo que necesitas arreglar. En Viaweb, la clave para conseguir usuarios fue la prueba de manejo en línea. No era solo una serie de diapositivas creadas por el personal de marketing. En nuestra prueba de manejo, los usuarios realmente usaban el software. Tomaba aproximadamente cinco minutos y al final de ella habían construido una tienda real y en funcionamiento.
La prueba de manejo fue la forma en que obtuvimos casi todos nuestros nuevos usuarios. Creo que será lo mismo para la mayoría de las aplicaciones basadas en la web. Si los usuarios pueden completar con éxito una prueba de manejo, les gustará el producto. Si se confunden o se aburren, no lo harán. Entonces, cualquier cosa que pudiéramos hacer para que más personas pasaran por la prueba de manejo aumentaría nuestra tasa de crecimiento.
Estudié los rastros de clics de las personas que realizaban la prueba de manejo y descubrí que en cierto 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). Entonces agregué un mensaje en ese punto, diciéndoles a los usuarios que estaban a punto de terminar y recordándoles que no hicieran clic en el botón Atrás. Otra gran cosa sobre el software basado en la web es que obtienes comentarios instantáneos de los cambios: el número de personas que completaban la prueba de manejo aumentó de inmediato del 60% al 90%. Y dado que el número de nuevos usuarios era una función del número de pruebas de manejo completadas, nuestro crecimiento de ingresos aumentó en un 50%, solo por ese cambio.
Dinero
A principios de la década de 1990, leí un artículo en el que alguien decía que el software era un negocio de suscripción. Al principio, esto me pareció una declaración muy cínica. Pero más tarde me di cuenta de que refleja la realidad: el desarrollo de software es un proceso continuo. Creo que es más limpio si cobras abiertamente tarifas de suscripción, en lugar de obligar a las personas a seguir comprando e instalando nuevas versiones para que sigan pagándote. Y afortunadamente, las suscripciones son la forma natural de facturar por las aplicaciones basadas en la web.
Alojar aplicaciones es un área donde las empresas desempeñarán un papel que probablemente no será ocupado por el software gratuito. Alojar aplicaciones es un gran estrés y tiene gastos reales. Nadie va a querer hacerlo gratis.
Para las empresas, las aplicaciones basadas en la web son una fuente ideal de ingresos. En lugar de comenzar cada trimestre con una pizarra en blanco, tienes un flujo de ingresos recurrente. Debido a que tu software evoluciona gradualmente, no tienes que preocuparte de que un nuevo modelo fracase; no tiene que haber un nuevo modelo, por así decirlo, y si haces algo al software que a los usuarios les disgusta, lo sabrás de inmediato. No tienes problemas con facturas incobrables; si alguien no te paga, simplemente puedes desactivar el servicio. Y no hay posibilidad de piratería.
Esa última "ventaja" puede resultar ser un problema. Cierta cantidad de piratería es ventajosa para las empresas de software. Si un usuario realmente no habría comprado tu software a ningún precio, no has perdido nada si usa una copia pirateada. De hecho, ganas, porque es un usuario más que ayuda a hacer que tu software sea 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 cobrarle a cada cliente tanto como puedan pagar. [8] El software es particularmente adecuado para la discriminación de precios, porque el costo marginal está cerca de cero. Por eso algunos software cuestan más para ejecutarse en Suns que en cajas Intel: una empresa que usa Suns no está interesada en ahorrar dinero y se le puede cobrar más sin problemas. 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 a algunos tipos de piratería. [9] Con el software basado en servidores, tendrán que encontrar 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. Podrías pensar que las personas deciden comprar algo y luego lo compran, como dos pasos separados. Eso es lo que pensé antes de Viaweb, en la medida en que pensé en la pregunta en absoluto. De hecho, el segundo paso puede propagarse hacia atrás en el primero: si algo es difícil de comprar, las personas cambiarán de opinión sobre si lo querían. Y viceversa: venderás más de algo cuando sea fácil de comprar. Compro más libros porque existe Amazon. El software basado en la web es casi lo más fácil del mundo de comprar, especialmente si acabas de hacer una demostración en línea. Los usuarios no deberían tener que hacer mucho más que ingresar un número de tarjeta de crédito. (Hazles hacer más bajo tu propio riesgo).
A veces, el software basado en la web se ofrece a través de ISP que actúan como revendedores. Esta es una mala idea. Tienes que estar administrando los servidores, porque necesitas estar mejorando constantemente tanto el hardware como el software. Si renuncias al control directo de los servidores, renuncias 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 fueron abrumados por trajes que se emocionaron 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 fueron individuos y empresas más pequeñas, y creo que esta será la regla con las aplicaciones basadas en la web. Estos son los usuarios que están listos para probar cosas nuevas, en parte porque son más flexibles y en parte porque quieren los menores costos de la nueva tecnología.
Las aplicaciones basadas en la web a menudo serán lo mejor para las grandes empresas también (aunque serán lentas en darse cuenta). El mejor intranet es Internet. Si una empresa usa aplicaciones web verdaderamente basadas, el software funcionará mejor, los servidores se administrarán mejor y los empleados tendrán acceso al sistema desde cualquier lugar.
El argumento en contra de este enfoque generalmente se basa 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 mostraron reacios a usar 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 fue fácil hacer este punto con diplomacia, pero de hecho los datos estaban casi con toda seguridad más seguros en nuestras manos que en las de ellos. ¿Quién puede contratar a mejores personas para administrar la seguridad, una startup tecnológica cuyo negocio es ejecutar servidores, o un minorista de ropa? No solo teníamos mejores personas preocupándose por la seguridad, nos preocupábamos más por ella. Si alguien irrumpía en los servidores del minorista de ropa, afectaría a lo sumo a un comerciante, probablemente se podría silenciar y, en el peor de los casos, podría hacer que despidieran a una persona. Si alguien irrumpía en los nuestros, podría afectar a miles de comerciantes, probablemente terminaría siendo noticia en CNet y podría sacarnos del negocio.
Si quieres mantener tu dinero a salvo, ¿lo guardas debajo del colchón en tu casa o lo pones en un banco? Este argumento se aplica a todos los aspectos de la administración del servidor: 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 bien estas cosas. Los problemas del servidor eran el gran no-no 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 usa aplicaciones basadas en la web está externalizando la TI en cierta medida. Por drástico que suene, creo que esto es generalmente una buena idea. Es probable que las empresas obtengan un mejor servicio de esta manera que del personal de sistemas interno. Los administradores de sistemas pueden volverse irritables e insensibles porque no están expuestos directamente a la presión competitiva: un vendedor tiene que tratar con los clientes y un desarrollador tiene que tratar con el software de los competidores, pero un administrador de sistemas, como un soltero empedernido, tiene pocas fuerzas externas que lo mantengan en línea. [10] En Viaweb teníamos fuerzas externas de sobra para mantenernos en línea. 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.
Entonces, las aplicaciones basadas en la web serán normalmente la respuesta correcta para las grandes empresas también. Sin embargo, serán las últimas en darse cuenta, al igual que lo fueron con las computadoras de escritorio. Y en parte por la misma razón: valdrá mucho dinero convencer a las grandes empresas de que necesitan algo más caro.
Siempre hay una tendencia para que los clientes ricos compren soluciones caras, incluso cuando las soluciones baratas son mejores, porque las personas que ofrecen soluciones caras pueden gastar más para venderlas. En Viaweb siempre nos enfrentábamos a esto. Perdimos varios comerciantes de alto nivel ante las empresas de consultoría web que les convencieron de que estarían mejor si pagaban medio millón de dólares por una tienda en línea a medida en su propio servidor. Como regla general, no estaban mejor, como más de uno descubrió cuando llegó la temporada de compras navideñas y aumentó la carga en su servidor. Viaweb era mucho más sofisticado que lo que la mayoría de estos comerciantes obtenían, pero no podíamos permitirnos decírselo. A $300 al mes, no podíamos permitirnos enviar un equipo de personas bien vestidas y con voz de autoridad para hacer presentaciones a los clientes.
Una gran parte de lo que las grandes empresas pagan de más es el costo de vender cosas caras a ellas. (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, a pesar de que probablemente sea una mala idea. Simplemente es más caro. No hay nada que puedas hacer al respecto, así que el mejor plan es ir primero por los clientes más pequeños. El resto vendrá con el tiempo.
Hijo del servidor
Ejecutar software en el servidor no es nada nuevo. De hecho, es el modelo antiguo: las aplicaciones de mainframe son todas basadas en el servidor. Si el software basado en el servidor es una buena idea, ¿por qué perdió la última vez? ¿Por qué los ordenadores de escritorio eclipsaron a los mainframes?
Al principio, los ordenadores de escritorio no parecían una gran amenaza. Los primeros usuarios eran todos hackers, o aficionados, como se les llamaba entonces. Les gustaban los microordenadores porque eran baratos. Por primera vez, podías tener tu propio ordenador. La frase "ordenador personal" es ahora parte del lenguaje, pero cuando se usó por primera vez, tenía un sonido deliberadamente audaz, como la frase "satélite personal" lo tendría hoy.
¿Por qué los ordenadores de escritorio se apoderaron? Creo que fue porque tenían un mejor software. Y creo que la razón por la que el software de los microordenadores era mejor es que podía ser escrito por pequeñas empresas.
No creo que mucha gente se dé cuenta de lo frágiles y vacilantes que son las startups en su etapa más temprana. Muchas startups comienzan casi por accidente, como un par de tipos, ya sea con trabajos de día o en la escuela, escribiendo un prototipo de algo que, si parece prometedor, se convertirá en una empresa. En esta etapa larvaria, cualquier obstáculo significativo detendrá la startup en seco. Escribir software para mainframe requería demasiado compromiso inicial. Las máquinas de desarrollo eran caras y, dado que los clientes serían grandes empresas, necesitarías un equipo de ventas con aspecto impresionante para venderlo. Comenzar una startup para escribir software para mainframe sería una empresa mucho más seria que simplemente hackear algo en tu Apple II por las noches.
La llegada de los ordenadores de escritorio inspiró mucho software nuevo, porque escribir aplicaciones para ellos parecía un objetivo alcanzable para las startups larvarias. El desarrollo era barato y los clientes serían personas individuales a las que podrías llegar a través de tiendas de informática o incluso por correo.
La aplicación que empujó a los ordenadores de escritorio al mercado principal 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 compró Apple IIs solo para ejecutarlo. Y este fue el comienzo de una tendencia: los ordenadores de escritorio ganaron porque las startups escribieron software para ellos.
Parece que el software basado en el servidor será bueno esta vez, porque las startups lo escribirán. Los ordenadores son tan baratos ahora que puedes empezar, como nosotros, usando un ordenador de escritorio como servidor. Los procesadores baratos se han comido el mercado de las estaciones de trabajo (rara vez se escucha la palabra ahora) y están la mayor parte del camino a través del mercado de los servidores; los servidores de Yahoo, que manejan cargas tan altas como cualquiera en Internet, tienen los mismos procesadores Intel baratos que tienes en tu ordenador de escritorio. Y una vez que hayas 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 las referencias en la prensa. [12]
Viaweb era una típica startup larvaria. Teníamos miedo de comenzar una empresa y durante los primeros meses nos consolábamos tratando todo el asunto como un experimento que podríamos cancelar en cualquier momento. Afortunadamente, había pocos obstáculos, excepto los técnicos. Mientras escribíamos el software, nuestro servidor web era el mismo ordenador de escritorio que usábamos para el desarrollo, conectado al mundo exterior a través de una línea telefónica. Nuestros únicos gastos en esa fase fueron la comida y el alquiler.
Hay aún más razones para que las startups escriban 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 en los términos de Microsoft, llamando a sus API y trabajando alrededor de su sistema operativo con errores. Y si logras escribir algo que despegue, puede que descubras que solo estabas haciendo una investigación de mercado para Microsoft.
Si una empresa quiere crear una plataforma sobre la que las startups construirán, tiene que hacer que los propios hackers quieran usarla. Eso significa que tiene que ser barata y bien diseñada. El Mac era popular entre los hackers cuando salió por primera vez, y muchos de ellos escribieron software para él. [13] Ves esto menos con Windows, porque los hackers no lo usan. El tipo de personas que son buenas escribiendo software tienden a estar ejecutando Linux o FreeBSD ahora.
No creo que hubiéramos comenzado una startup para escribir software de escritorio, porque el software de escritorio tiene que funcionar en Windows, y antes de que pudiéramos escribir software para Windows, tendríamos que usarlo. La web nos permitió dar un rodeo a Windows y entregar software que se ejecuta en Unix directamente a los usuarios a través del navegador. Esa es una perspectiva liberadora, muy parecida a la llegada de las PC hace veinticinco años.
Microsoft
Cuando llegaron los ordenadores de escritorio, IBM era el gigante al que todo el mundo le tenía miedo. Es difícil de imaginar ahora, pero recuerdo muy bien esa sensación. Ahora el gigante aterrador es Microsoft, y no creo que sean tan ciegos a la amenaza que se les avecina como lo era IBM. Después de todo, Microsoft construyó deliberadamente su negocio en el punto ciego de IBM.
Mencioné anteriormente que mi madre realmente no necesita una computadora de escritorio. La mayoría de los usuarios probablemente tampoco. Ese es un problema para Microsoft, y lo saben. Si las aplicaciones se ejecutan en servidores remotos, nadie necesita Windows. ¿Qué hará Microsoft? ¿Podrán usar su control del escritorio para evitar o limitar esta nueva generación de software?
Mi conjetura es que Microsoft desarrollará una especie de híbrido de servidor/escritorio, donde el sistema operativo funciona junto con los servidores que controlan. Como mínimo, los archivos estarán disponibles de forma centralizada para los usuarios que lo deseen. No espero que Microsoft vaya al extremo de realizar los cálculos en el servidor, con solo un navegador como cliente, si pueden evitarlo. Si solo necesitas un navegador como cliente, no necesitas a Microsoft en el cliente, y si Microsoft no controla el cliente, no pueden empujar a los usuarios hacia sus aplicaciones basadas en el servidor.
Creo que a Microsoft le costará mantener el genio en la botella. Habrá demasiados tipos diferentes de clientes para que puedan controlarlos a todos. Y si las aplicaciones de Microsoft solo funcionan con algunos clientes, los competidores podrán superarlos al ofrecer aplicaciones que funcionen desde cualquier cliente. [14]
En un mundo de aplicaciones basadas en la Web, no hay un lugar automático para Microsoft. Pueden tener éxito al hacerse un lugar, pero no creo que dominen este nuevo mundo como lo hicieron con el mundo de las aplicaciones de escritorio.
No es tanto que un competidor los haga tropezar, sino que tropezarán con ellos mismos. Con el auge del software basado en la Web, se enfrentarán no solo a problemas técnicos, sino también a su propio pensamiento optimista. Lo que necesitan hacer es canibalizar su negocio existente, y no puedo verlos enfrentando eso. La misma unidireccionalidad que los ha traído hasta aquí ahora estará trabajando en su contra. IBM se encontraba exactamente en la misma situación, y no pudieron dominarla. IBM hizo una entrada tardía y poco entusiasta en el negocio de las microcomputadoras porque estaban ambivalentes sobre amenazar su vaca lechera, la computación de mainframe. De manera similar, Microsoft se verá obstaculizada por querer salvar el escritorio. Una vaca lechera puede ser un maldito mono pesado en tu espalda.
No estoy diciendo que nadie dominará las aplicaciones basadas en servidores. Alguien probablemente lo hará eventualmente. Pero creo que habrá un buen período prolongado de alegre caos, tal como lo hubo en los primeros días de las microcomputadoras. Ese fue un buen momento para las startups. Muchas empresas pequeñas prosperaron, y lo hicieron haciendo cosas geniales.
Startups pero más
La startup clásica es rápida e informal, con pocas personas y poco dinero. Esas pocas personas trabajan muy duro, y la tecnología amplifica el efecto de las decisiones que toman. Si ganan, ganan mucho.
En una startup que escribe aplicaciones basadas en la Web, todo lo que asocias con las startups se lleva al extremo. Puedes escribir y lanzar un producto con aún menos personas y aún menos dinero. Tienes que ser aún más rápido, y puedes salirte con la tuya siendo más informal. Literalmente puedes lanzar tu producto como tres tipos sentados en la sala de estar de un apartamento, y un servidor colocalizado en un ISP. Eso 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 gafas de montura y corbatas negras estrechas, escribiendo 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 en la oficina y escribían en vt100s. Ahora son un par de tipos sentados en una sala de estar con portátiles. (Y resulta que los jeans no son la última palabra en informalidad).
Las startups son estresantes, y esto, desafortunadamente, 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 así sucesivamente. Lo alarmante de los programas de software basados en la Web es que no hay nada que impida que esto se convierta en lo predeterminado. Las historias sobre dormir debajo de los escritorios generalmente terminan: luego, por fin, lo enviamos y todos nos fuimos a casa a dormir durante una semana. El software basado en la Web nunca se envía. Puedes trabajar 16 horas al día durante el tiempo que quieras. Y porque puedes, y tus competidores pueden, tiendes a verse obligado a hacerlo. Puedes, así que debes. 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 tradicionalmente tienen sus propias preocupaciones por separado. Los programadores tienen que preocuparse por los errores, y los administradores de sistemas tienen que preocuparse por la infraestructura. Los programadores pueden pasar un largo día hasta los codos en el código fuente, pero en algún momento pueden irse a casa y olvidarse de ello. Los administradores de sistemas nunca dejan del todo el trabajo atrás, pero cuando los llaman a las 4:00 a.m., generalmente 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 simplemente escribiendo software. Trabajamos las largas horas habituales de una startup inicial. En una empresa de software de escritorio, esta habría sido la parte en la que estábamos trabajando duro, pero se sintió como unas vacaciones en comparación con la siguiente fase, cuando recibimos usuarios en nuestro servidor. El segundo mayor beneficio de vender Viaweb a Yahoo (después del dinero) fue poder descargar la responsabilidad final de todo eso 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 necesariamente es 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 forma sencilla de trabajar más que tus competidores. Ninguna startup pide más.
Solo lo suficientemente bueno
Una cosa que podría disuadirte de escribir aplicaciones basadas en la Web es la mediocridad de las páginas web como interfaz de usuario. Ese es un problema, lo admito. Había algunas cosas que realmente nos habría gustado agregar a HTML y HTTP. Sin embargo, lo que importa es que las páginas web son solo lo suficientemente buenas.
Aquí está la traducción al español del contenido:
Hay un paralelismo aquí con los primeros microordenadores. Los procesadores de esas máquinas no estaban realmente destinados a ser los CPU de los ordenadores. Fueron diseñados para ser utilizados en cosas como semáforos. Pero tipos como Ed Roberts, que diseñó el Altair, se dieron cuenta de que eran lo suficientemente buenos. Podrías combinar uno de estos chips con algo de memoria (256 bytes en el primer Altair), y conmutadores del panel frontal, y tendrías un ordenador en funcionamiento. Ser capaz de tener tu propio ordenador 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 un número significativo de usuarios, el software que puedes usar desde cualquier navegador será suficiente por sí mismo para compensar cualquier incomodidad en la interfaz de usuario. Tal vez no puedas escribir el mejor programa de hojas de cálculo usando HTML, pero puedes escribir una hoja de cálculo que varias personas puedan usar simultáneamente desde diferentes ubicaciones sin software cliente especial, o que pueda incorporar fuentes de datos en vivo, o que te avise cuando se desencadenen ciertas condiciones. Más importante aún, puedes escribir nuevos tipos de aplicaciones que ni siquiera tienen nombre todavía. VisiCalc, después de todo, no era meramente una versión para microordenador de una aplicación de mainframe, sino un nuevo tipo de aplicación.
Por supuesto, las aplicaciones basadas en servidores no tienen por qué ser web. Podrías tener algún otro tipo de cliente. Pero estoy bastante seguro de que es una mala idea. Sería muy conveniente si pudieras asumir que todo el mundo instalaría tu cliente, tan conveniente que podrías convencerte fácilmente de que lo harían, pero si no lo hacen, estás jodido. Dado que el software basado en la web no asume nada sobre el cliente, funcionará en cualquier lugar donde funcione la web. Esa es una gran ventaja ya, y la ventaja crecerá a medida que proliferen los nuevos dispositivos web. A los usuarios les gustará porque tu software simplemente funciona, y tu vida será más fácil porque no tendrás que ajustarlo para cada nuevo cliente. [16]
Siento que he seguido 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 avecine la convergencia, pero ¿dónde? No puedo elegir un ganador. Una cosa que puedo predecir es el conflicto entre AOL y Microsoft. Sea lo que sea que .NET de Microsoft termine siendo, probablemente implicará conectar el escritorio a los servidores. A menos que AOL se defienda, serán apartados a un lado o convertidos en un conducto entre el software cliente y servidor de Microsoft. Si Microsoft y AOL se meten en una guerra de clientes, lo único seguro que funcionará en ambos será navegar por la web, lo que significa que las aplicaciones web serán las únicas que funcionen en todas partes.
¿Cómo se desarrollará todo esto? No lo sé. Y no tienes que saberlo si apuestas por las aplicaciones web. Nadie puede romper eso sin romper la navegación. La web puede que no sea la única forma de entregar software, pero es una que funciona ahora y seguirá funcionando durante mucho tiempo. Las aplicaciones web son baratas de desarrollar y fáciles de entregar incluso para la startup más pequeña. Suponen mucho trabajo, y de un tipo particularmente estresante, pero eso solo mejora las probabilidades para las startups.
¿Por qué no?
E. B. White se divirtió al enterarse por un amigo granjero de que muchas cercas electrificadas no tienen corriente circulando por ellas. Las vacas aparentemente aprenden a mantenerse alejadas de ellas, y después de eso no necesitas la corriente. "¡Levantaos, vacas!", escribió, "¡Tomad vuestra libertad mientras los déspotas duermen!"
Si eres un hacker que ha pensado en algún día iniciar una startup, probablemente hay dos cosas que te impiden hacerlo. Una es que no sabes nada sobre los negocios. La otra es que tienes miedo a la competencia. Ninguna de estas cercas tiene corriente.
Hay solo dos cosas que tienes que saber sobre los negocios: construir algo que a los usuarios les encante, y ganar más de lo que gastas. Si consigues estas dos cosas, estarás por delante de la mayoría de las startups. Puedes averiguar el resto sobre la marcha.
Puede que al principio no ganes más de lo que gastas, pero siempre que la brecha se cierre lo suficientemente rápido, estarás bien. Si empiezas con pocos fondos, al menos te animará a adoptar un hábito de frugalidad. Cuanto menos gastes, más fácil será ganar más de lo que gastas. Afortunadamente, puede ser muy barato lanzar una aplicación web. Nosotros lanzamos con menos de $10,000, y hoy sería incluso más barato. Tuvimos que gastar miles 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 pagamos solo por ancho de banda. Podrías lanzar una aplicación web ahora por menos del coste de una silla de oficina de lujo.
En cuanto a construir algo que a los usuarios les encante, aquí hay algunos consejos generales. Empieza haciendo algo limpio y sencillo que tú mismo querrías usar. Saca una versión 1.0 rápidamente, luego sigue mejorando el software, escuchando atentamente a los usuarios mientras lo haces. El cliente siempre tiene razón, pero diferentes clientes tienen razón sobre cosas diferentes; los usuarios menos sofisticados te muestran lo que necesitas simplificar y aclarar, y los más sofisticados te dicen qué funciones necesitas agregar. Lo mejor que puede ser un software es fácil, pero la forma de hacerlo es conseguir los valores predeterminados correctos, no limitar las opciones de los usuarios. No te conformes si el software de tus competidores es malo; el estándar para comparar tu software es lo que podría ser, no lo que tus competidores actuales casualmente tengan. Usa tu propio software todo el tiempo. Viaweb se suponía que era un constructor de tiendas online, pero lo usábamos para hacer nuestro propio sitio también. No escuches a la gente de marketing o a los diseñadores o a los gestores de producto solo por sus títulos de trabajo. Si tienen buenas ideas, úsalas, pero eres tú quien debe decidir; el software tiene que ser diseñado por hackers que entiendan el diseño, no por diseñadores que sepan un poco de software. Si no puedes diseñar software tan bien como implementarlo, no inicies una startup.
Ahora hablemos de la competencia. Lo que temes no son presumiblemente grupos de hackers como tú, sino empresas reales, con oficinas y planes de negocios y vendedores y demás, ¿verdad? Bueno, ellos te temen más de lo que tú les temes 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 a vendedores que para una empresa de cualquier tamaño conseguir que se escriba un software. He estado en ambos lados y lo sé.
Cuando Viaweb fue comprada por Yahoo, de repente me encontré trabajando para una empresa grande, y era como tratar de correr a través de agua hasta la cintura.
No pretendo menospreciar a Yahoo. Tenían algunos buenos hackers y la alta gerencia eran verdaderos pateadores de traseros. Para ser una empresa grande, eran excepcionales. Pero aún así solo eran aproximadamente una décima parte de productivos que una pequeña startup. Ninguna empresa grande puede hacerlo mucho mejor que eso. Lo que da miedo de Microsoft es que una empresa tan grande pueda desarrollar software en absoluto. Son como una montaña que puede caminar.
No te intimides. Puedes hacer tanto como lo que Microsoft no puede, como lo que ellos pueden hacer que tú no puedes. Y nadie puede detenerte. No tienes que pedir permiso a nadie para desarrollar aplicaciones basadas en la web. No tienes que hacer acuerdos de licencia, ni conseguir espacio en los estantes de las tiendas minoristas, ni suplicar para que tu aplicación se incluya con el sistema operativo. Puedes entregar software directamente al navegador y nadie puede interponerse entre tú y los usuarios potenciales sin impedirles navegar por la web.
Puede que no lo creas, pero te prometo que Microsoft te teme. Los gerentes medios complacientes pueden que no, pero Bill sí, porque él fue como tú una vez, en 1975, la última vez que apareció una nueva forma de entregar software.
Notas
[1] Dándose cuenta de que gran parte del dinero está en los servicios, las empresas que construyen clientes ligeros generalmente han intentado 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 construir electrónica de consumo y para operar un servicio en línea, y en parte porque a los usuarios les disgusta la idea. Regalar la navaja y ganar dinero con las hojas puede funcionar para Gillette, pero una navaja es un compromiso mucho más pequeño que un terminal web. Los fabricantes de teléfonos móviles se conforman con vender hardware sin intentar capturar los ingresos por servicios también. Ese probablemente debería ser el modelo para los clientes de Internet también. Si alguien simplemente vendiera una pequeña caja bonita con un navegador web que pudieras usar para conectarte 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 meter la pata 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 meter la pata. Comprometer un servidor podría causar tanto daño que los ASP (que quieren permanecer en el negocio) probablemente serán cuidadosos con la seguridad.
[3] En 1995, cuando comenzamos Viaweb, se suponía que los applets de Java iban a ser la tecnología que todo el mundo iba a usar para desarrollar aplicaciones basadas en servidores. Los applets nos parecían una idea anticuada. ¿Descargar programas para ejecutarlos en el cliente? Más simple simplemente ir hasta el final y ejecutar los programas en el servidor. Desperdiciamos poco tiempo en los applets, pero innumerables otras startups deben haberse visto atraídas a este pozo de alquitrán. Pocos habrán escapado con vida, o Microsoft no habría podido deshacerse de Java en la versión más reciente de Explorer.
[4] Este punto se debe a Trevor Blackwell, quien agrega "el costo de escribir software aumenta más que linealmente con su tamaño. Quizás esto se deba principalmente a arreglar errores antiguos, y el costo puede ser más lineal si se encuentran rápidamente todos los errores".
[5] El tipo más difícil de error para encontrar puede ser una variante de error compuesto donde un error llega a compensar a otro. Cuando arreglas un error, el otro se vuelve visible. Pero parecerá que la corrección es la culpable, ya que fue lo último que cambiaste.
[6] Dentro de Viaweb una vez tuvimos un concurso para describir lo peor de nuestro software. Dos personas del servicio de atención al cliente empataron en el primer lugar con entradas que aún me estremezco al recordar. 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 construir 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 has oído a un minorista afirmar que su poder de compra significaba precios más bajos para ti?) que me sorprendió descubrir que estaba prohibida en los EE. UU. por la Ley Robinson-Patman de 1936. Esta ley no parece ser aplicada con vigor.
[9] En No Logo, Naomi Klein dice que las marcas de ropa preferidas por los "jóvenes urbanos" no se esfuerzan demasiado por evitar el robo en las tiendas porque en su mercado objetivo los ladrones también son los líderes de la moda.
[10] A menudo, las empresas se preguntan qué externalizar y qué no. Una posible respuesta: externaliza cualquier trabajo que no esté expuesto directamente a la presión competitiva, porque externalizarlo lo expondrá a la presión competitiva.
[11] Los dos tipos eran Dan Bricklin y Bob Frankston. Dan escribió un prototipo en Basic en un par de días, luego durante el año siguiente trabajaron juntos (principalmente por la noche) para hacer 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 nominalmente tenía un trabajo de día escribiendo software. "No había un gran riesgo en hacer un negocio", escribió Bob, "Si fracasaba, fracasaba. No era gran cosa".
[12] No es tan fácil como lo hago sonar. Nos llevó un tiempo dolorosamente largo que el boca a boca se pusiera en marcha, y no empezamos a recibir mucha cobertura de prensa hasta que contratamos a una firma de relaciones públicas (sin duda la mejor del negocio) por $16,000 por mes. Sin embargo, era cierto que el único canal significativo era nuestro propio sitio web.
[13] Si la Mac era tan genial, ¿por qué perdió? Costo, de nuevo. Microsoft se concentró en el negocio del software y desató una enjambre de proveedores de componentes baratos sobre el hardware de Apple. Tampoco ayudó que los trajes se hicieran cargo durante un período crítico.
[14] Una cosa que ayudaría a las aplicaciones basadas en la Web y ayudaría mantener a la próxima generación de software de ser eclipsado por Microsoft, sería un buen navegador de código abierto. Mozilla es de código abierto, pero parece haber sufrido por haber sido corporativo software durante tanto tiempo. Un navegador pequeño y rápido que se mantuviera activamente sería una gran cosa en sí misma y probablemente también alentaría a las empresas a construir pequeños aparatos web.
Entre otras cosas, un navegador de código abierto adecuado haría que HTTP y HTML continúen evolucionando (como lo ha hecho Perl). Ayudaría mucho a las aplicaciones basadas en la Web poder distinguir entre seleccionar un enlace y seguirlo; todo lo que necesitarías para hacer esto sería una mejora trivial de HTTP, para permitir múltiples URL en una solicitud. Los menús desplegables 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 pensaba que era demasiado tarde para lanzar un nuevo motor de búsqueda, pero Google les demostró lo contrario. Siempre hay espacio para algo nuevo si las opciones actuales apestan lo suficiente. Asegúrate de que funcione en todos los sistemas operativos libres primero: las cosas nuevas comienzan con sus usuarios.
[15] Trevor Blackwell, que probablemente sepa más sobre esto a partir de experiencia personal que nadie, escribe:
"Iría más lejos al decir que debido a que el software basado en servidores es tan difícil para los programadores, provoca un cambio económico fundamental alejarse de las grandes empresas. Requiere el tipo de intensidad y dedicación de los programadores que solo estarán dispuestos a proporcionar cuando sea su propia empresa. Las empresas de software pueden contratar personas calificadas para trabajar en un entorno no demasiado exigente, y pueden contratar personas no calificadas para soportar penalidades, pero no pueden contratar personas muy calificadas para romper sus traseros. Dado que el capital ya no es necesario, las grandes empresas tienen poco que aportar a la mesa".
[16] En la versión original de este ensayo, aconsejé evitar JavaScript. Ese fue 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 borradores de este documento; a Dan Bricklin y Bob Frankston por 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.