EL OTRO CAMINO A SEGUIR
OriginalSeptember 2001
(Este artículo explica por qué gran parte de la próxima generación de software puede ser basado en servidores, lo que eso 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 comenzar una startup. La campaña de relaciones públicas previa a la salida a bolsa de Netscape estaba en pleno apogeo entonces, y había mucha conversación en la prensa sobre el comercio en línea. En ese momento, puede que hubiera treinta tiendas reales en la Web, todas hechas a mano. Si iba a haber muchas tiendas en línea, tendría que haber software para hacerlas, así que decidimos escribir algo.
Durante la primera semana más o menos, teníamos la intención de hacer de esto una aplicación de escritorio ordinaria. Entonces, 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 a través de la Web, y estaba 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.
Esto resultó ser un buen plan. Ahora, como Yahoo Store, este software es el creador de tiendas en línea más popular, con alrededor de 14.000 usuarios.
Cuando comenzamos 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 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 será escrita en 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 fuera del escritorio y hacia 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 mueva hacia los servidores, lo que estoy describiendo aquí es el futuro.
¿Lo siguiente?
Cuando miremos hacia atrás en la era del software de escritorio, creo que nos maravillaremos de las molestias que la gente soportó, al igual que ahora nos maravillamos de lo que soportaron los primeros propietarios de automóviles. Durante los primeros veinte o treinta años, tenías que ser un experto en automóviles para tener un automóvil. 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á sucediendo dentro de ella. Pero más de la mitad de los hogares en los EE. UU. tienen uno. Mi madre tiene una computadora que usa para el correo electrónico y para llevar las 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 saber las palabras "sistema operativo", y mucho menos "controlador de dispositivo" o "parche".
Ahora hay otra forma de entregar software que salvará a los usuarios de convertirse en administradores del sistema. Las aplicaciones basadas en la web son programas que se ejecutan en servidores web y utilizan páginas web como usuario interfaz. 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 utilizan. Todo lo desordenado y cambiante estará sentado en un servidor en algún lugar, mantenido por el tipo de personas que son buenas en ese tipo de cosas. Y así no necesitarás normalmente una computadora, per se, para usar software. Todo lo que necesitarás será algo con un teclado, una pantalla y un navegador web. Tal vez tenga acceso inalámbrico a Internet. Tal vez también sea 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 en función de cómo se ve la carcasa. Pagarás más por los servicios de Internet que por el hardware, al igual que lo haces ahora con los teléfonos. [1]
Tomará aproximadamente una décima de segundo para que un clic llegue al servidor y regrese, por lo que los usuarios de software muy interactivo, como Photoshop, todavía 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 para, una décima de segundo de latencia no sería una 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 incomodidad". La mayoría de la gente, la mayoría de las veces, tomará 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á, tanto para los usuarios como para 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, tú solo puedes usarlo en esa computadora. Peor aún, tus archivos son atrapados en esa computadora. La incomodidad de este modelo se vuelve más y 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 debes tener acceso a los mensajes de correo electrónico sin importar dónde te encuentres. 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é deberían estar atrapados tus datos en alguna computadora sentada en un escritorio lejano?
Toda la idea de "tu computadora" está desapareciendo y siendo reemplazada por "tus datos". Deberías poder acceder a tus datos desde cualquier computadora. O más bien, cualquier cliente, y un cliente no tiene que ser una computadora.
Los clientes no deberían almacenar datos; deberían ser como teléfonos. En de hecho, pueden convertirse en teléfonos, o viceversa. Y como 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 bloqueo de disco, excepto que tus datos son entregados a otra persona en lugar de ser vaporizado.
Con el software puramente basado en la web, ni tus datos ni las aplicaciones se mantienen en el cliente. Entonces no tienes que instalar nada para usarlo. Y cuando no hay instalación, no tienes que preocuparte de 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 yendo al sitio donde se ofrece. En Viaweb, todo nuestro sitio era como una gran flecha que apuntaba a los usuarios hacia la prueba de manejo.
Después de probar la demostración, registrarse para el servicio no debería requerir nada más que completar un breve formulario (cuanto más breve, mejor). Y ese debería ser el último trabajo que el usuario tiene que hacer. Con la web software, deberías obtener nuevas versiones sin pagar extra, o hacer ningún trabajo, o posiblemente incluso saberlo.
Las actualizaciones no serán las grandes sorpresas que son ahora. Con el tiempo, las aplicaciones crecerán silenciosamente más poderosas. Esto requerirá algún esfuerzo de parte de los desarrolladores. Tendrán que diseñar software para que se pueda actualizar sin confundir a los usuarios. Ese es un nuevo problema, pero hay formas de resolverlo.
Con las aplicaciones basadas en la web, todos utilizan la misma versión, y los errores se pueden corregir tan pronto como se descubren. Entonces, el software basado en la web debería tener muchos menos errores que el software de escritorio. En Viaweb, dudo que alguna vez hayamos tenido diez errores conocidos en un momento dado. Eso es órdenes de magnitud mejor que el software de escritorio.
Las aplicaciones basadas en la web pueden ser utilizadas por varias personas al mismo tiempo. Esta es una victoria 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 dejar 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 quisieran hacerlo, pero resultó que muchos lo hicieron.
Cuando utilizas una aplicación basada en la web, tus datos estarán más seguros. Los bloqueos de disco no serán cosa del pasado, pero los usuarios no escucharán sobre ellos más. Sucederán dentro de las granjas de servidores. Y las empresas que ofrecen aplicaciones basadas en la web realmente harán copias de seguridad, no solo porque tendrán administradores del sistema reales preocupándose por esas cosas, sino porque un ASP que pierde los datos de la gente estará en un gran, gran problema. Cuando la gente pierde sus propios datos en un bloqueo de disco, no pueden enojarse tanto, porque solo tienen a sí mismos para 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 más que un navegador, hay menos posibilidad de ejecutar virus y no hay datos locales que dañar. Y un programa que atacara 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 miraras dentro del usuario promedio de Windows, encontrarías un deseo enorme y prácticamente sin explotar de software que cumpla con esa descripción. Desatado, podría ser una fuerza poderosa.
Ciudad de código
Para los desarrolladores, la diferencia más notable entre la web y el software 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 gran binario. Y así, diseñar la web el software es como diseñar una ciudad en lugar de un edificio: así como edificios, necesitas carreteras, señales de tráfico, servicios públicos, policía y departamentos de bomberos, y planes para el crecimiento y 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 para mover o restaurar datos, programas que pretendían ser usuarios (para medir el rendimiento o exponer errores), programas para diagnosticar la red problemas, programas para hacer copias de seguridad, interfaces a servicios externos, software que impulsaba una impresionante colección de diales que mostraban estadísticas del servidor en tiempo real (un éxito entre los visitantes, pero indispensable para nosotros también), modificaciones (incluidas correcciones de errores) a código abierto software, y una gran cantidad de archivos de configuración y ajustes. Trevor Blackwell escribió un programa espectacular para mover tiendas a nuevas servidores en todo el país, sin cerrarlos, después de que fuimos comprados por Yahoo. Los programas nos enviaron mensajes, enviaron faxes y correos electrónicos a los usuarios, realizaron transacciones con procesadores de tarjetas de crédito y se comunicaron entre sí a través de sockets, tuberías, solicitudes http, ssh, paquetes udp, memoria compartida y archivos. Parte de Viaweb incluso consistió en la ausencia de programas, ya que una de las claves de la seguridad de Unix es no ejecutar utilidades innecesarias que la gente pueda usar para romper en tus servidores.
No terminó con el software. Pasamos mucho tiempo pensando en las configuraciones del servidor. Construimos los servidores nosotros mismos, desde 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 lo suficientemente rápido conexiones a todas las redes troncales. Nosotros en serie fechado 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 tú administra los servidores, puedes en un paso habilitar a todos tus usuarios para enviar mensajes a la gente, o enviar faxes, o enviar comandos por teléfono, o procesar tarjetas de crédito, etc., simplemente instalando el hardware relevante. Nosotros siempre buscamos nuevas formas de agregar funciones con hardware, no solo porque complacía 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.
Debido a que el software en una aplicación basada en la web será una colección de programas en lugar de un solo binario, se puede escribir en cualquier número de idiomas 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, es decir, C y C++. Y así, estos lenguajes (especialmente entre personas no técnicas como gerentes y capitalistas de riesgo) llegaron a considerarse como los lenguajes para "serios" desarrollo de software. 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 servidor puedes usar cualquier idioma que quieras. [3] Hoy en día, muchos de los mejores hackers están utilizando lenguajes muy alejados de C y C++: Perl, Python e incluso Lisp.
Con el software basado en servidor, nadie puede decirte qué idioma usar, porque controlas todo el sistema, hasta el hardware. Los diferentes idiomas son buenos para diferentes tareas. Tú puedes usar el que sea mejor para cada uno. 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 utilizaron C y C++, y esto hizo que su software fuera visiblemente inferior porque (entre otras cosas), no tenían forma de evitar el carácter sin estado de los scripts CGI. Si fueras a cambiar algo, todos los cambios tenían que ocurrir en una página, con un botón Actualizar en la parte inferior. Como he escrito en otra parte, por utilizando Lisp, que muchas personas todavía consideran un lenguaje de investigación, pudimos hacer que el editor de Viaweb se comportara más como el software de escritorio.
Lanzamientos
Uno de los cambios más importantes en este nuevo mundo es la forma en que haces lanzamientos. En el negocio del software de escritorio, hacer un lanzamiento es un trauma enorme, en el que toda la empresa suda y se esfuerza para sacar una sola pieza de código gigante. Las comparaciones obvias sugieren en sí mismas, tanto al proceso como al producto resultante.
Con el software basado en servidor, puedes realizar cambios casi como lo harías en un programa que estuvieras escribiendo para ti mismo. Tú liberas software como una serie de cambios incrementales en lugar de una ocasional gran explosión. 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 software el desarrollo se ve afectado por 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 errores al por mayor. Algún tiempo antes de la fecha de lanzamiento, ensamblas una nueva versión en la que la mitad del código ha sido arrancado y reemplazado, introduciendo innumerables errores. Luego, un escuadrón 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 lo que está sucediendo dentro del software. En el mejor de los casos, terminas con una especie de corrección estadística.
Con el software basado en servidor, la mayoría de los cambios son pequeños e incrementales. Eso en sí mismo es menos probable que introduzca 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 con un agarre mucho más firme del código. Como regla general, sí 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 escaneando el panel de instrumentos, no como un detective tratando de desentrañar algún misterio.
El software de escritorio genera un cierto fatalismo sobre los errores. Tú sabes que estás enviando algo cargado de errores, e incluso has configurado mecanismos para compensarlo (por ejemplo, lanzamientos de parches). Entonces ¿por qué preocuparse por unos pocos más? Pronto estarás lanzando funciones completas que sabes que están rotas. Apple hizo esto a principios de este año. Ellos sintieron presión para lanzar su nuevo sistema operativo, cuya fecha de lanzamiento ya había deslizado 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 podría estar pensando, es una idea que suena bien 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 esa promesa, porque no hay versiones. Tu software cambia gradualmente y continuamente. Algunos cambios podrían ser más grandes que otros, pero la idea de versiones simplemente no encaja naturalmente en el software basado en la web.
Si alguien recuerda Viaweb, esto podría sonar extraño, porque siempre estábamos anunciando nuevas versiones. Esto se hizo completamente para PR propósitos. La prensa especializada, aprendimos, piensa en números de versión. Te darán una cobertura importante para 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 para una versión puntual, lo que significa un nuevo dígito después del decimal punto.
Algunos de nuestros competidores ofrecían software de escritorio y en realidad tenían números de versión. Y para estos lanzamientos, el mero hecho de que nos pareció evidencia de su atraso, obtendrían todo tipo de publicidad. No queríamos quedarnos atrás, así que empezamos a dar números de versión a nuestro software también. Cuando queríamos algo publicidad, haríamos una lista de todas las funciones que habíamos agregado desde el último "lanzamiento", pegaríamos un nuevo número de versión en el software, y emitir un comunicado de prensa diciendo que la nueva versión estaba disponible inmediatamente. Sorprendentemente, nadie nos llamó por eso.
Para cuando nos compraron, habíamos hecho esto tres veces, así que estábamos en la versión 4. Versión 4.1 si recuerdo correctamente. Después de que Viaweb se convirtiera en Yahoo Store, ya no había una necesidad tan desesperada de publicidad, por lo que, aunque el software siguió evolucionando, toda la idea de los números de versión se abandonó silenciosamente.
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 ahí mismo en tu disco. Si alguien rompe tu software, no tienes que intentar adivinar qué está pasando, como lo harías con el software de escritorio: deberías poder reproducir el error mientras están en el teléfono contigo. Incluso podrías saberlo de antemano, si tienes código para detectar errores integrado en tu aplicación.
El software basado en la web se utiliza durante todo el día, por lo que todo lo que haces se pone inmediatamente a prueba. Los errores aparecen rápidamente.
Las empresas de software a veces son acusadas de dejar que los usuarios depuren su software. Y eso es precisamente lo que estoy defendiendo. Para la web el software es en realidad un buen plan, porque los errores son menos y transitorios. Cuando lanzas software gradualmente, obtienes muchos menos errores para empezar. Y cuando puedes reproducir errores y lanzar cambios al instante, puedes encontrar y corregir la mayoría de los errores tan pronto como aparezcan. Nunca tuvimos suficientes errores al mismo tiempo para molestarnos con un sistema formal de seguimiento de errores.
Debes probar los cambios antes de lanzarlos, por supuesto, para que no se lancen errores importantes. Esos pocos que inevitablemente se escapan implicarán casos límite y solo afectarán a los pocos usuarios que los encuentren antes de que alguien llame para quejarse. Como siempre que arregles los errores de inmediato, el efecto neto, para el promedio usuario, son muchos menos errores. Dudo que el usuario promedio de Viaweb alguna vez viera un error.
Arreglar errores recientes es más fácil que arreglar 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 lo que está mal incluso antes de mirar la fuente, porque ya estabas preocupado por ello subconscientemente. Arreglar 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 introduzcas más errores. [4]
Cuando detectas errores temprano, también obtienes menos errores compuestos. Los errores compuestos son dos errores separados que interactúan: te tropiezas bajando las escaleras, y cuando alcanzas el pasamanos, 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 tradicional "romper todo y luego filtrar los errores" enfoque inherentemente produce muchos errores compuestos. Y el software que se lanza en un serie de pequeños cambios inherentemente tiende a no hacerlo. Los pisos son constantemente barridos de cualquier objeto suelto que pueda quedar atascado más tarde en algo.
Ayuda si utilizas una técnica llamada programación funcional. La programación funcional significa evitar los efectos secundarios. Es algo que es más probable que veas en trabajos de investigación que en comerciales software, pero para aplicaciones basadas en la web resulta ser realmente útil. Es difícil escribir programas completos como código puramente funcional pero puedes escribir trozos sustanciales de esta manera. Hace esas partes de tu software más fáciles de probar, porque no tienen estado, y eso es muy conveniente en una situación donde estás constantemente haciendo y probando pequeñas modificaciones. Escribí mucho del editor de Viaweb en este estilo, e hicimos nuestro lenguaje de scripting, RTML, 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. Dado que la mayoría de los errores lanzados involucraban casos límite, los usuarios que los encontraron eran propensos a ser usuarios avanzados, empujando el sobre. Los usuarios avanzados son más indulgentes con los errores, especialmente porque probablemente los introdujiste en el proceso de agregar alguna función que estaban pidiendo. 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 ira, como si nos hubieran marcado puntos.
Soporte
Cuando puedes reproducir errores, cambia tu enfoque al cliente apoyo. En la mayoría de las empresas de software, el soporte se ofrece como una forma de hacer que los clientes se sientan mejor. Te están llamando por un error conocido, o simplemente están haciendo algo mal y tienes que descubrir qué. En cualquier caso, no hay mucho que puedas aprender de ellos. Y así tiendes a ver las llamadas de soporte como un dolor en el culo que quieres aislar de tus desarrolladores tanto como posible.
Así no es como funcionaban las cosas en Viaweb. En Viaweb, el soporte era gratis, 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 solución.
Entonces, en Viaweb, los desarrolladores siempre estaban en contacto cercano con apoyo. La gente de atención al cliente estaba a unos treinta pies de distancia de los programadores, y sabían que siempre podían interrumpir cualquier cosa con un informe de un error genuino. Dejaríamos una junta directiva reunión para arreglar un error grave.
Nuestro enfoque al soporte hizo que todos fueran más felices. Los clientes eran encantados. Imagínate cómo se sentiría llamar a una línea de soporte y ser tratado como alguien que trae noticias importantes. El cliente a la gente de soporte le gustó porque significaba que podían ayudar a los usuarios, en lugar de leerles guiones. Y a los programadores les gustó porque podían reproducir errores en lugar de solo escuchar vagos informes de segunda mano sobre ellos.
Nuestra política de corregir errores sobre la marcha cambió la relación entre la gente de atención al cliente y los hackers. En la mayoría de las empresas de software la gente de soporte está mal pagada escudos humanos, y los hackers son pequeñas copias de Dios Padre, creadores del mundo. Cualquiera que sea el procedimiento para informar errores, es probable que sea unidireccional: la gente de soporte que se entera de los errores llena algún formulario que eventualmente se transmite (posiblemente a través de QA) a los programadores, quienes lo ponen en su lista de cosas por hacer. Era muy diferente en Viaweb. Dentro de un minuto de enterarse de un error de un cliente, el soporte la gente podía estar de pie junto a un programador escuchándolo decir "Mierda, tienes razón, es un error". A la gente de soporte le encantaba escuchar ese "tienes razón" de los hackers. Solían traernos errores con el mismo aire expectante que un gato que te trae un ratón que ha acabado de matar. También los hizo más cuidadosos al juzgar el gravedad de un error, porque ahora su honor estaba en juego.
Después de que Yahoo nos comprara, la gente de atención al cliente fue trasladado lejos de los programadores. Fue solo entonces que nos dimos cuenta de que eran efectivamente QA y en cierta medida marketing también. Además de detectar errores, eran los guardianes de el conocimiento de cosas más vagas, parecidas a errores, como las funciones que confundían a los usuarios. [6] También eran una especie de grupo de enfoque sustituto; podríamos preguntarles cuál de las dos nuevas funciones querían más los usuarios, y ellos siempre tenían razón.
Moral
Poder lanzar software inmediatamente es una gran motivación. A menudo, mientras caminaba al trabajo, se me ocurría algún cambio que quería hacer al software, y hacerlo ese día. Esto funcionó para más grandes características también. Incluso si algo iba a tomar dos semanas para escribir (pocos proyectos tardaron más), sabía que podía ver el efecto en el software tan pronto como terminara.
Si hubiera tenido que esperar un año para el próximo lanzamiento, habría archivado la mayoría de estas ideas, por un tiempo al menos. Lo que pasa con las ideas, sin embargo, 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. Entonces, archivar una idea te cuesta no solo ese retraso en implementarla, sino también todas las ideas que implementarla habría llevado a. De hecho, archivar una idea probablemente incluso inhiba nuevas ideas: cuando empiezas a pensar en alguna nueva función, ves el estante y piensas "pero ya tengo muchas cosas nuevas que quiero hacer para el próximo lanzamiento".
Lo que las grandes empresas hacen en lugar de implementar funciones es planificarlas ellos. En Viaweb, a veces nos encontrábamos con problemas en este sentido. Los inversores y analistas nos preguntaban qué teníamos planeado para el futuro. La respuesta veraz habría sido que no teníamos ningún planes. Teníamos ideas generales sobre cosas que queríamos mejorar, pero si supiéramos cómo 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 fue la verdad. Los planes son solo otra palabra para ideas en el estante. Cuando se nos ocurrían buenas ideas, las implementábamos.
En Viaweb, como en muchas empresas de software, la mayoría del código tenía un propietario definido propietario. Pero cuando poseías algo, realmente lo poseías: nadie excepto el propietario de un trozo de software tenía que aprobar (o incluso saber sobre) un lanzamiento. No había protección contra roturas excepto el miedo a parecer un idiota ante sus compañeros, y eso fue más que suficiente. Puede que haya dado la impresión de que simplemente seguimos alegremente escribiendo código. Fuimos rápidos, pero pensamos muy cuidadosamente antes de lanzar software en esos servidores. Y prestar atención es más importante para la confiabilidad que moverse lentamente. Porque presta mucha atención, un piloto de la Marina puede aterrizar un avión de 40,000 libras a 140 millas por hora en un lanzamiento cubierta de portaaviones, de noche, más seguro que el adolescente promedio puede 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 programadores de confianza que para una gran empresa de mediocres, donde las malas ideas son atrapadas por los comités en lugar de por las personas que las tuvieron.
Brooks a la inversa
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 estos estaban en desarrollo de productos. Todos los demás estaban trabajando en lanzamientos, puertos, etc. Con el software basado en la web, todo lo que necesitas (como máximo) son las 13 personas, porque no hay lanzamientos, puertos, y así sucesivamente.
Viaweb fue escrito por solo tres personas. [7] Siempre estaba bajo presión para contratar más, porque queríamos que nos compraran, y sabíamos que los compradores tendrían dificultades para pagar un precio alto por una empresa con solo tres programadores. (Solución: contratamos más, pero creamos nuevos proyectos para ellos.)
Cuando puedes escribir software con menos programadores, te ahorras más que dinero. Como Fred Brooks señaló en El mito del hombre-mes, agregar personas a un proyecto tiende a ralentizarlo. El número de posibles conexiones 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 juntos, y más errores obtendrán de 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 recuerdo que los programadores de Viaweb alguna vez hayan tenido una reunión real. Nunca tuvimos más que decir en un momento dado de lo que podíamos decir mientras caminábamos a almorzar.
Si hay un inconveniente aquí, es que todos los programadores tienen que ser hasta cierto punto administradores del sistema también. Cuando estás hospedando 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 un límite definido entre software e infraestructura. Declarar arbitrariamente tal límite habría limitado nuestras opciones de diseño. Y así, aunque estábamos constantemente esperando que algún día ("en un par de meses") todo sería lo suficientemente estable como para poder contratar a alguien cuyo trabajo fuera solo para 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 va a ser algo que escribas, registres y te vayas a casa. Es un vivo cosa, corriendo en tus servidores ahora mismo. Un error grave podría no solo bloquear el proceso de un usuario; podría bloquearlos a todos. Si un error en tu código corrompe algunos datos en el disco, tienes que arreglarlo. Y así en. 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 lanzas código tarde en la noche y luego te vas a casa.
Observando a los usuarios
Con el 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 tiendas minoristas y pedir seguirlos a casa. Si alguna vez has visto a alguien usar tu software por primera vez, sabes qué sorpresas deben haber esperado.
El software debe hacer lo que los usuarios piensan que hará. Pero no puedes tener ninguna idea de lo que los usuarios estarán pensando, créeme, hasta que los veas ellos. Y el software basado en servidor te brinda información sin precedentes sobre su comportamiento. No te limitas a pequeños, artificiales grupos de enfoque. Puedes ver cada clic realizado por cada usuario. Tú tienes que considerar cuidadosamente qué vas a mirar, porque no quieres violar la privacidad de los usuarios, pero incluso la más general el muestreo estadístico puede ser muy útil.
Cuando tienes a los usuarios en tu servidor, no tienes que depender de puntos de referencia, por ejemplo. Los puntos de referencia son usuarios simulados. Con el software basado en servidor, puedes ver usuarios reales. Para decidir qué optimizar, solo inicia sesión en un servidor y mira qué está consumiendo todo la CPU. Y también sabes cuándo dejar de optimizar: eventualmente hicimos que el editor de Viaweb llegara al punto en que estaba limitado por la memoria en lugar de limitado por la CPU, y como 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 así que detente ahí.
La eficiencia es importante para el software basado en servidor, porque estás pagando por el hardware. La cantidad 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 por debajo de los competidores y aún así obtener un beneficio. En Viaweb, el costo de capital por usuario bajó a alrededor de $5. Sería menos ahora, probablemente menos que el costo de enviar ellos 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 y en la optimización. Viaweb tenía un lenguaje de scripting 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 el predefinido los estilos de página no podían hacer lo que querían. Originalmente, el editor puso barras de botones en toda la página, por ejemplo, pero después de una serie de usuarios utilizaron RTML para colocar botones hacia abajo a la izquierda lado, hicimos eso un 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 están en problemas. Y como el cliente siempre tiene la razón, esa es una señal de algo que necesitas arreglar. En Viaweb, la clave para obtener usuarios fue la prueba de manejo en línea. No era solo una serie de diapositivas construidas por gente de marketing. En nuestra prueba de manejo, los usuarios realmente usaron el software. Tomó unos cinco minutos, y al final de eso habían construido una tienda real y funcional.
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 una prueba de manejo con éxito, les gustará el producto. Si se confunden o se aburren, no lo harán. Así que cualquier cosa que pudiéramos hacer para que más personas completaran la prueba de manejo aumentaría nuestra tasa de crecimiento.
Estudié los rastros de clics de las personas que hacían la prueba de manejo 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, diciéndoles a los usuarios que estaban casi terminando, y recordándoles que no hicieran clic en el botón Atrás. Otra gran cosa de las aplicaciones basadas en la Web es que obtienes retroalimentación instantánea de los cambios: el número de personas que completaban la prueba de manejo aumentó inmediatamente 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 parecía una afirmació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 las tarifas de suscripción, 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 es poco probable que sea llenado por el software libre. El alojamiento de aplicaciones es mucho 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 empezar 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; nunca tiene que haber un nuevo modelo, per se, y si haces algo al software que a los usuarios les odie, lo sabrás de inmediato. No tienes problemas con las facturas impagables; si alguien no te paga, puedes simplemente desactivar el servicio. Y no hay posibilidad de piratería.
Esa última "ventaja" puede acabar siendo un problema. Cierta cantidad de piratería es para beneficio de las empresas de software. Si algún usuario realmente no hubiera comprado tu software a ningún precio, no has perdido nada si utiliza una copia pirata. De hecho, ganas, porque es un usuario más que ayuda a que tu software sea el estándar, o que podría comprar una copia más tarde, cuando se gradúe de la escuela secundaria.
Cuando pueden, a las empresas les gusta hacer algo llamado discriminación de precios, lo que significa cobrar a cada cliente todo lo que pueda pagar. [8] El software es particularmente adecuado para la discriminación de precios, porque el coste marginal es casi nulo. Esta es la razón por la que algunos programas cuestan más de ejecutar en Suns que en cajas Intel: una empresa que utiliza Suns no está interesada en ahorrar dinero y puede ser cobrada con seguridad más. La piratería es efectivamente el nivel más bajo de discriminación de precios. Creo que las empresas de software entienden esto y hacen la vista gorda deliberadamente a 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. Podrías pensar que la gente decide comprar algo, y luego lo compra, como dos pasos separados. Eso es lo que yo pensaba antes de Viaweb, en la medida en que pensaba en la cuestión en absoluto. De hecho, el segundo paso puede propagarse hacia atrás en el primero: si algo es difícil de comprar, la gente cambiará de opinión sobre si lo quería o no. Y viceversa: venderás más de algo cuando sea fácil de comprar. Yo 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 introducir un número de tarjeta de crédito. (Haz que hagan más a 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, normalmente, creo, porque estaban abrumados por los trajes que estaban emocionados por 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 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 costes más bajos de la nueva tecnología.
Las aplicaciones basadas en la Web a menudo serán lo mejor para las grandes empresas también (aunque tardarán en darse cuenta). La mejor intranet es Internet. Si una empresa utiliza verdaderas 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 en contra de este enfoque suele girar en torno a 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 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 fue fácil hacer este punto diplomáticamente, 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 mejor gente para gestionar la seguridad, una empresa de tecnología de nueva creación cuyo negocio es ejecutar servidores, o un minorista de ropa? No solo teníamos a gente mejor preocupándose por la seguridad, sino que nos preocupábamos más por ella. Si alguien irrumpiera en los servidores del minorista de ropa, afectaría como mucho 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 irrumpiera en los nuestros, podría afectar a miles de comerciantes, probablemente acabaría siendo noticia en CNet, y podría hacer que nos quedáramos sin negocio.
Si quieres mantener tu dinero seguro, ¿lo guardas debajo del colchón en casa, o lo metes en un banco? Este argumento se aplica a todos los aspectos de la administración del servidor: no solo la seguridad, sino el 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 del servidor eran el gran no-no para nosotros, como un juguete peligroso 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 las TI. Por drástico que parezca, creo que esto es generalmente una buena idea. Las empresas es probable que obtengan un mejor servicio de esta manera que si lo hicieran con administradores de sistemas internos. Los administradores de sistemas pueden volverse gruñones e irresponsables porque no están directamente expuestos a la presión competitiva: un vendedor tiene que tratar con los clientes, y un desarrollador tiene que tratar con el software de la competencia, pero un administrador de sistemas, como un viejo soltero, tiene pocas fuerzas externas para mantenerlo en línea. [10] En Viaweb teníamos fuerzas externas de sobra para mantenernos en línea. La gente que nos llamaba eran clientes, no solo compañeros de trabajo. Si un servidor se atascaba, dábamos un salto; solo pensar en ello me da un vuelco de adrenalina, años después.
Así que 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, como 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 existe una tendencia a que los clientes ricos compren 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 estuvimos en contra de esto. Perdimos varios comerciantes de gama alta a empresas de consultoría web que los convencieron de que estarían mejor si pagaban medio millón de dólares por una tienda online hecha a medida en su propio servidor. Por regla general, no estaban mejor, como más de uno descubrió cuando llegó la temporada de compras navideñas y las cargas aumentaron en su servidor. Viaweb era mucho más sofisticado que lo que la mayoría de estos comerciantes consiguieron, pero no podíamos permitirnos decírselo. A 300 dólares al mes, no podíamos permitirnos enviar un equipo de gente bien vestida y con un sonido autoritario para hacer presentaciones a los clientes.
Una gran parte de lo que las grandes empresas pagan extra es el coste de venderles cosas caras. (Si el Departamento de Defensa paga mil dólares por los 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. Simplemente es más caro. No hay nada que puedas hacer con este enigma, así que el mejor plan es ir a por los clientes más pequeños primero. 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 servidor. Si el software basado en servidor es una idea tan buena, ¿por qué perdió la última vez? ¿Por qué las computadoras de escritorio eclipsaron a los mainframes?
Al principio, las computadoras de escritorio no parecían una gran amenaza. Los primeros usuarios fueron todos hackers, o aficionados, como se les llamaba entonces. Les gustaban las microcomputadoras porque eran baratas. Por primera vez, podías tener tu propia computadora. La frase "computadora personal" forma parte del lenguaje ahora, pero cuando se usó por primera vez tenía un sonido deliberadamente audaz, como la frase "satélite personal" tendría hoy en día.
¿Por qué se impusieron las computadoras de escritorio? Creo que fue porque tenían mejor software. Y creo que la razón por la que el software de microcomputadora era mejor era que 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 empresas de nueva creación en la etapa más temprana. Muchas empresas de nueva creación 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 podría, si parece prometedor, convertirse en una empresa. En esta etapa larvaria, cualquier obstáculo significativo detendrá la empresa de nueva creación en seco. Escribir software de mainframe requería demasiado compromiso por adelantado. Las máquinas de desarrollo eran caras, y como los clientes serían grandes empresas, necesitarías un equipo de ventas de aspecto impresionante para vendérselo. Iniciar una empresa de nueva creación para escribir software de mainframe sería una empresa mucho más seria que simplemente piratear algo en tu Apple II por las noches. Y así, no se obtuvieron muchas empresas de nueva creación que escribieran aplicaciones de mainframe.
La llegada de las computadoras de escritorio inspiró mucho software nuevo, porque escribir aplicaciones para ellas parecía un objetivo alcanzable para las empresas de nueva creación larvarias. El desarrollo era barato, y los clientes serían personas individuales a las que se podía llegar a través de las tiendas de informática o incluso por correo.
La aplicación que impulsó a las computadoras de escritorio a la corriente 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: las computadoras de escritorio ganaron porque las empresas de nueva creación escribieron software para ellas.
Parece que el software basado en servidor será bueno esta vez, porque las empresas de nueva creación lo escribirán. Las computadoras son tan baratas ahora que puedes empezar, como hicimos nosotros, usando una computadora de escritorio como servidor. Los procesadores baratos se han comido el mercado de las estaciones de trabajo (ya casi ni se oye la palabra ahora) y están en camino de comerse el mercado de los servidores; los servidores de Yahoo, que se ocupan de cargas tan altas como las de cualquier otro en Internet, tienen todos los mismos procesadores Intel baratos que tienes en tu computadora 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 empresa de nueva creación larvaria típica. Estábamos aterrorizados de empezar una empresa, y durante los primeros meses nos consolamos 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 la misma computadora de escritorio que usábamos para el desarrollo, conectada a el mundo exterior por una línea de acceso telefónico. Nuestros únicos gastos en esa fase fueron la comida y el alquiler.
Hay aún más razones para que las empresas de nueva creación escriban software basado en la Web ahora, 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 con su sistema operativo con errores. Y si consigues escribir algo que despegue, puedes descubrir que simplemente estabas haciendo investigación de mercado para Microsoft.
Si una empresa quiere crear una plataforma sobre la que las empresas de nueva creación construirán, tiene que hacerla algo que los propios hackers quieran usar. Eso significa que tiene que ser barata y bien diseñada. La Mac era popular entre los hackers cuando salió al mercado, y muchos de ellos escribieron software para ella. [13] Esto se ve menos con Windows, porque los hackers no lo usan. El tipo de gente que es buena en escribir software tiende a ejecutar Linux o FreeBSD ahora.
No creo que hubiéramos empezado una empresa de nueva creación para escribir software de escritorio, porque el software de escritorio tiene que ejecutarse en Windows, y antes de que pudiéramos escribir software para Windows, tendríamos que usarlo. La Web nos permitió hacer 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 las computadoras de escritorio, IBM era el gigante del que todo el mundo tenía miedo. Es difícil de imaginar ahora, pero recuerdo la sensación muy bien. Ahora el gigante aterrador es Microsoft, y no creo que sean tan ciegos a la amenaza que se les avecina como lo fue IBM. Después de todo, Microsoft construyó deliberadamente su negocio en el punto ciego de IBM.
Mencioné antes que mi madre no necesita realmente una computadora de escritorio. La mayoría de los usuarios probablemente no la necesitan. 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 prevenir, o restringir, esta nueva generación de software?
Mi conjetura es que Microsoft desarrollará algún tipo de híbrido servidor/escritorio, donde el sistema operativo funcione junto con los servidores que controlan. Como mínimo, los archivos estarán disponibles centralmente para los usuarios que lo deseen. No espero que Microsoft llegue al extremo de hacer los cálculos en el servidor, con solo un navegador como cliente, si puede evitarlo. Si solo necesitas un navegador para un cliente, no necesitas Microsoft en el cliente, y si Microsoft no controla el cliente, no puede empujar a los usuarios hacia sus aplicaciones basadas en servidor.
Creo que Microsoft tendrá dificultades para mantener al genio en la botella. Habrá demasiados tipos diferentes de clientes para que los controlen todos. Y si las aplicaciones de Microsoft solo 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 automático para Microsoft. Puede que tengan éxito en hacerse un hueco, 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 sus propios deseos. Lo que necesitan hacer es canibalizar su negocio existente, y no puedo verlos enfrentándose a eso. La misma mentalidad que los ha llevado hasta aquí ahora trabajará en su contra. IBM estaba 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 eran ambivalentes a la hora de amenazar a su vaca lechera, la informática de mainframe. Microsoft se verá igualmente obstaculizado por el deseo de salvar el escritorio. Una vaca lechera puede ser un maldito mono pesado en tu espalda.
No estoy diciendo que nadie vaya a dominar las aplicaciones basadas en servidor. Al final, probablemente alguien lo hará. Pero creo que habrá un buen período de tiempo de caos alegre, como lo hubo en los primeros días de las microcomputadoras. Esa fue una buena época para las empresas de nueva creación. Muchas pequeñas empresas florecieron, y lo hicieron creando cosas geniales.
Empresas de nueva creación, pero más aún
La empresa de nueva creación 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 empresa de nueva creación que escribe aplicaciones basadas en la Web, todo lo que asocias con las empresas de nueva creación se lleva al extremo. Puedes escribir y lanzar un producto con aún menos gente y aún menos dinero. Tienes que ser aún más rápido, y puedes permitirte ser más informal. Literalmente puedes lanzar tu producto como tres tipos sentados en la sala de estar de un apartamento, y un servidor alojado en un ISP. 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 gafas de pasta 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 para ir a la oficina y escribían en vt100. 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 dormían debajo de sus escritorios, etc. Lo alarmante de las aplicaciones basadas en la web es que no hay nada que impida que esto se convierta en el valor predeterminado. Las historias sobre dormir debajo de los escritorios suelen terminar así: finalmente lo enviamos y todos nos fuimos a casa y dormimos 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 como puedes, y tus competidores también, tiendes a verte obligado a hacerlo. Puedes, así que debes. Es la Ley de Parkinson funcionando a la inversa.
Lo peor no son las horas, sino la responsabilidad. Los programadores y los administradores del sistema tradicionalmente tienen sus propias preocupaciones separadas. Los programadores tienen que preocuparse por los errores, y los administradores del sistema 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 del sistema nunca dejan del todo el trabajo atrás, pero cuando los llaman a las 4:00 AM, 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 del sistema, 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 temprana. 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 llevamos a los usuarios a nuestro servidor. El segundo mayor beneficio de vender Viaweb a Yahoo (después del dinero) fue poder descargar la responsabilidad final de todo sobre los hombros de una gran empresa.
El software de escritorio obliga a los usuarios a convertirse en administradores del sistema. 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 forma sencilla de superar a tus competidores. Ninguna startup pide más.
Lo suficientemente bueno
Una cosa que podría disuadirte de escribir aplicaciones basadas en la web es la debilidad de las páginas web como interfaz de usuario. Ese es un problema, lo admito. Hubo algunas cosas que realmente nos hubiera gustado agregar a HTML y HTTP. Lo que importa, sin embargo, es que las páginas web son lo suficientemente buenas.
Hay un paralelismo aquí con las primeras microcomputadoras. Los procesadores de esas máquinas no estaban realmente destinados a ser las CPU de las computadoras. 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 de panel frontal, y tendrías una computadora que funciona. Poder tener tu propia computadora era tan emocionante que había mucha gente que quería comprarlas, sin importar lo limitadas 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á una victoria en sí mismo que compensará cualquier torpeza en la interfaz de usuario. Tal vez no puedas escribir la hoja de cálculo más atractiva usando HTML, pero puedes escribir una hoja de cálculo que varias personas puedan usar simultáneamente desde diferentes ubicaciones sin software de cliente especial, o que pueda incorporar fuentes de datos en vivo, o que pueda enviarte una página cuando se activan ciertas condiciones. Más importante aún, puedes escribir nuevos tipos de aplicaciones que aún no tienen nombre. VisiCalc no fue simplemente una versión de microcomputadora de una aplicación de mainframe, después de todo, fue un nuevo tipo de aplicación.
Por supuesto, las aplicaciones basadas en servidor no tienen que estar basadas en la 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 todos instalarían tu cliente, tan conveniente que podrías convencerte fácilmente de que todos lo harían, pero si no lo hacen, estás acabado. Debido a 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 visto la evolución de la web tan de cerca como cualquier otra persona, y no puedo predecir qué va a pasar con los clientes. La convergencia probablemente esté llegando, 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 Microsoft .NET resulte ser, probablemente implicará conectar el escritorio a los servidores. A menos que AOL se defienda, o bien serán marginados o convertidos en una tubería entre el cliente de Microsoft y el software del servidor. Si Microsoft y AOL entran en una guerra de clientes, lo único seguro que funcionará en ambos será navegar por la web, lo que significa que las aplicaciones basadas en la web serán el único tipo que funcione en todas partes.
¿Cómo se desarrollará todo? No lo sé. Y no tienes que saberlo 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 entregar 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. Son 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 de un amigo granjero que muchas cercas electrificadas no tienen corriente pasando por ellas. Las vacas aparentemente aprenden a mantenerse alejadas de ellas, y después de eso ya no necesitas 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 comenzar una startup, probablemente haya dos cosas que te impidan hacerlo. Una es que no sabes nada de negocios. La otra es que tienes miedo de la competencia. Ninguna de estas cercas tiene corriente.
Solo hay dos cosas que debes saber sobre los negocios: crea algo que a los usuarios les encante y gana más de lo que gastas. Si logras estas dos cosas, estarás por delante de la mayoría de las startups. Puedes averiguar el resto sobre la marcha.
Es posible 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 comienzas con poco presupuesto, al menos te animará a tener 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 basada en la web. Lanzamos con menos de $10,000, y sería aún más barato hoy. 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 basada en la web ahora por menos del costo de una silla de oficina elegante.
En cuanto a crear algo que a los usuarios les encante, aquí tienes algunos consejos generales. Comienza creando algo limpio y simple que te gustaría usar tú mismo. Publica una versión 1.0 rápidamente, luego continúa mejorando el software, escuchando atentamente a los usuarios mientras lo haces. El cliente siempre tiene razón, pero los diferentes clientes tienen razón sobre diferentes cosas; 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 el software es fácil, pero la forma de hacerlo es configurar los valores predeterminados correctamente, no limitar las opciones de los usuarios. No te complazcas 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 tienen. Usa tu software tú mismo, todo el tiempo. Se suponía que Viaweb era un creador de tiendas online, pero también lo usamos para crear nuestro propio sitio. No escuches a los profesionales del marketing, diseñadores o gerentes de producto solo por sus cargos. Si tienen buenas ideas, úsalas, pero tú decides; el software debe ser diseñado por hackers que entienden el diseño, no por diseñadores que saben un poco de software. Si no puedes diseñar software tan bien como implementarlo, no comiences una startup.
Ahora hablemos de la competencia. Lo que te da miedo no son presumiblemente grupos de hackers como tú, sino empresas reales, con oficinas, planes de negocios, vendedores, etc., ¿verdad? Bueno, ellos tienen más miedo de ti que tú de 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 obtener software escrito. He estado en ambos lados, y lo sé. Cuando Viaweb fue comprado por Yahoo, de repente me encontré trabajando para una gran empresa, y fue como intentar correr por agua hasta la cintura.
No quiero menospreciar a Yahoo. Tenían algunos buenos hackers, y la alta gerencia eran verdaderos patea traseros. Para una gran empresa, eran excepcionales. Pero aún así solo eran aproximadamente una décima parte de lo productivos que una pequeña startup. Ninguna gran empresa puede hacer 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 que Microsoft no puede como 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, o conseguir espacio en los estantes de las tiendas minoristas, o 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 lo prometo, Microsoft tiene miedo de ti. Es posible que los gerentes intermedios complacientes no lo estén, 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] Al darse 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 online. Este enfoque no ha funcionado bien, en parte porque necesitas dos tipos diferentes de empresas para construir electrónica de consumo y ejecutar un servicio online, y en parte porque a los usuarios les disgusta la idea. Regalar la navaja y ganar dinero con las cuchillas puede funcionar para Gillette, pero una navaja es mucho menor compromiso que una terminal web. Los fabricantes de teléfonos celulares están satisfechos 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 de aspecto agradable con un navegador web que pudieras usar para conectarte a través de cualquier ISP, cada tecnófobo del país compraría uno.
[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 servidor hará que los desarrolladores presten más atención a no cometer errores. Poner en peligro un servidor podría causar tanto daño que los ASP (que quieren seguir en el negocio) son propensos a tener cuidado con la seguridad.
[3] En 1995, cuando comenzamos Viaweb, los applets de Java se suponía que eran la tecnología que todos iban a usar para desarrollar aplicaciones basadas en servidor. Los applets nos parecieron una idea anticuada. ¿Descargar programas para ejecutar en el cliente? Más simple simplemente ir hasta el final y ejecutar los programas en el servidor. No perdimos tiempo en applets, pero innumerables otras startups deben haber sido atraídas a esta trampa. Pocos pueden haber escapado con vida, o Microsoft no podría haberse salido 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 "el costo de escribir software aumenta más que linealmente con su tamaño. Tal vez esto se deba principalmente a la corrección de errores antiguos, y el costo puede ser más lineal si todos los errores se encuentran rápidamente".
[5] El tipo de error más difícil de encontrar puede ser una variante de error compuesto donde un error sucede para compensar 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 de atención al cliente empataron por el primer premio con entradas que todavía me hacen temblar al recordarlas. Arreglamos ambos problemas inmediatamente.
[7] Robert Morris escribió el sistema de pedidos, que los compradores usaban para realizar 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 fueron escritos 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 adquisitivo 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 rigor.
[9] En No Logo, Naomi Klein dice que las marcas de ropa favorecidas por "jóvenes urbanos" no se esfuerzan demasiado por evitar los robos en tiendas porque en su mercado objetivo los ladrones también son los líderes de la moda.
[10] Las empresas a menudo se preguntan qué externalizar y qué no. Una posible respuesta: externaliza cualquier trabajo que no esté directamente expuesto a la presión competitiva, porque externalizarlo lo expondrá a la presión competitiva.
[11] Los dos tipos fueron Dan Bricklin y Bob Frankston. Dan escribió un prototipo en Basic en un par de días, luego durante el transcurso de el próximo año 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 fallaba, fallaba. No es gran cosa".
[12] No es tan fácil como lo hago sonar. Se tardó un tiempo dolorosamente largo en que el boca a boca comenzara a funcionar, y no comenzamos a obtener mucha cobertura de prensa hasta que contratamos a un empresa de relaciones públicas (admitidamente 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ó un enjambre de proveedores de componentes baratos en 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 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 software corporativo durante tanto tiempo. Un navegador pequeño y rápido que se mantuviera activamente sería una gran cosa en sí mismo, y probablemente también animarí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 continuaran evolucionando (como por ejemplo 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 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 les demostró que estaban equivocados. Siempre hay espacio para algo nuevo si las opciones actuales apestan lo suficiente. Asegúrate de que funcione en todos los sistemas operativos gratuitos primero: las cosas nuevas comienzan con sus usuarios.
[15] Trevor Blackwell, quien probablemente sabe más sobre esto por 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 que se aleja de las grandes empresas. Requiere el tipo de intensidad y dedicación de los programadores que solo estarán dispuestos a brindar cuando se trata de su propia empresa. Las empresas de software pueden contratar personas calificadas para que trabajen en un entorno no muy exigente, y pueden contratar personas no calificadas para que soporten las dificultades, pero no pueden contratar personas altamente calificadas para que se rompan el trasero. Dado que el capital ya no es necesario, las grandes empresas tienen poco que aportar".
[16] En la versión original de este ensayo, aconsejé evitar Javascript. Ese 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 documento; 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.