El Otro Camino por Delante | undefined

Septiembre de 2001

(Este artículo explica por qué gran parte de la próxima generación de software puede basarse en servidores, qué significará eso para los programadores y por qué este nuevo tipo de software es una gran oportunidad para las startups. Está derivado de una charla en BBN Labs.)

En el verano de 1995, mi amigo Robert Morris y yo decidimos empezar una startup. La campaña de relaciones públicas previa a la salida a bolsa de Netscape estaba a todo dar entonces, y había mucha conversación en la prensa sobre el comercio en línea. En ese momento, podría haber habido treinta tiendas reales en la Web, todas hechas a mano. Si iba a haber muchas tiendas en línea, necesitaría 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 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 estaba claro que ese 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 creador de tiendas en línea más popular, con aproximadamente 14.000 usuarios.

Cuando empezamos Viaweb, casi nadie entendía lo que queríamos decir cuando decíamos que el software se ejecutaba en el servidor. No fue hasta que se lanzó Hotmail un año después que la gente empezó a entenderlo. Ahora todo el mundo sabe que este es un enfoque válido. Ahora hay un nombre para lo que éramos: un Proveedor de Servicios de Aplicaciones, o ASP.

Creo que gran parte de la próxima generación de software se escribirá con este modelo. Incluso Microsoft, que tiene más que perder, parece ver la inevitabilidad de mover algunas cosas 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 cosas sorprendentes 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 describo aquí es el futuro.

La Próxima Cosa?

Cuando miremos hacia atrás a la era del software de escritorio, creo que nos maravillaremos de las inconveniencias que la gente soportaba, así como ahora nos maravillamos 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 una victoria tan grande que a mucha gente que no era experta en automóviles también le gustaba tenerlos.

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 una. 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 correo electrónico y cuentas tiene que pensar en instalar nuevos sistemas operativos. Los usuarios comunes ni siquiera deberían conocer las palabras "sistema operativo", y mucho menos "controlador de dispositivo" o "parche".

Ahora hay otra forma de entregar software que evitará que los usuarios se conviertan en administradores de sistemas. Las aplicaciones basadas en la Web son programas que se ejecutan en servidores web y utilizan páginas web como interfaz de usuario. Para el usuario 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. Toda la parte sucia y cambiante estará en algún servidor, mantenida por el tipo de personas que son buenas en ese tipo de cosas. Y así, normalmente no necesitarás una computadora, per se, para usar software. Todo lo que necesitarás será algo con un teclado, una pantalla y un navegador web. Quizás tenga acceso a Internet inalámbrico. Quizás también sea tu teléfono móvil. 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 que por el hardware, tal como lo haces ahora con los teléfonos. [1]

Tomará aproximadamente una décima parte 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 para las que la mayoría de la gente usa las computadoras, una décima de segundo de latencia 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 coche con una pegatina que dice "la muerte antes que la inconveniencia". La mayoría de la gente, la mayor parte del tiempo, tomará la 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. Así que 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 están 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.

La punta de lanza 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é alguno de tus datos debería estar atrapado en alguna computadora sentada en un escritorio lejano?

Toda la idea de "tu computadora" está desapareciendo, y está siendo reemplazada por "tus datos". Deberías poder acceder a tus datos desde cualquier computadora. O mejor dicho, cualquier cliente, y un cliente no tiene por qué 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 guardar tus datos en ellos: algo que llevas contigo puede perderse o ser robado. Dejar tu PDA en un taxi es como una falla de disco, excepto que tus datos se entregan a alguien más en lugar de ser vaporizados.

Con software puramente basado en la Web, ni tus datos ni las aplicaciones se guardan en el cliente. Así que 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 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 dirigía a los usuarios a la prueba.

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 tenga que hacer. Con el software basado en la Web, deberías recibir nuevas versiones sin pagar extra, o sin hacer ningún trabajo, o posiblemente incluso sin saberlo.

Las actualizaciones no serán las grandes sorpresas que son ahora. Con el tiempo, las aplicaciones se volverán silenciosamente más potentes. Esto requerirá un esfuerzo por parte de los desarrolladores. Tendrán que diseñar software de manera que pueda actualizarse sin confundir a los usuarios. Ese es un problema nuevo, 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 alguna vez tuviéramos 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 ventaja obvia para las aplicaciones colaborativas, pero sospecho 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 que varios usuarios editaran un sitio simultáneamente, más porque esa era la forma correcta de escribir el software que porque esperáramos que los usuarios lo quisieran, pero resultó que muchos sí.

Cuando uses una aplicación basada en la Web, tus datos estarán más seguros. Las fallas de disco no serán cosa del pasado, pero los usuarios ya no oirán hablar de ellas. 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 preocupados por tales cosas, sino porque una ASP que pierda los datos de las personas estará en grandes, grandes problemas. Cuando las personas pierden sus propios datos en una falla de disco, no pueden enfadarse tanto, porque solo tienen a quién culpar. Cuando una empresa pierde sus datos por ellos, se enfadará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 los servidores mismos los encontraría 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 esa descripción. Desatado, podría ser una fuerza poderosa.

Ciudad de Código

Para los desarrolladores, la diferencia más visible 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 único binario grande. Y así, diseñar software basado en la Web es como diseñar una ciudad en lugar de un edificio: además de edificios, necesitas carreteras, señales de tráfico, servicios públicos, departamentos de policía y 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 interactuaban directamente, programas que esos programas usaban, programas que se ejecutaban constantemente en segundo plano buscando problemas, programas que intentaban reiniciar 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 basura de recursos o para 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 controlaba una impresionante colección de diales que mostraban estadísticas de servidores en tiempo real (un éxito entre los visitantes, pero indispensable para nosotros también), modificaciones (incluyendo 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 apagarlas, después de que fuimos comprados por Yahoo. Los programas nos enviaban notificaciones, 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, pipes, solicitudes http, ssh, paquetes udp, memoria compartida y archivos. Parte de Viaweb incluso consistía en la ausencia de programas, ya que una de las claves de la seguridad de Unix es no ejecutar utilidades innecesarias que la gente podría usar para entrar en 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 de enlace ascendente tenía conexiones lo suficientemente rápidas a todas las troncales. Salimos con 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 notificaciones, faxes, 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 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 ISPs) 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 único binario, puede escribirse en cualquier número de lenguajes diferentes. Cuando escribes software de escritorio, estás prácticamente 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 personas no técnicas como gerentes y VCs) llegaron a ser considerados como los lenguajes para el desarrollo de software "serio". Pero eso fue solo un artefacto de la forma en que el software de escritorio tenía que ser entregado. Para el software basado en servidores, puedes usar cualquier lenguaje que quieras. [3] Hoy en día, muchos de los mejores hackers usan 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 sea mejor para cada una. Y cuando tienes competidores, "puedes" significa "debes" (volveremos a esto más adelante), porque si no aprovechas esta posibilidad, tus competidores lo harán.

La mayoría de nuestros competidores usaban C y C++, y esto hacía que su software fuera visiblemente inferior porque (entre otras cosas) no tenían forma de evitar la falta de estado de los scripts CGI. Si ibas a cambiar algo, todos los cambios tenían que ocurrir en una página, con un botón de Actualizar en la parte inferior. Como he escrito en otro lugar, al usar Lisp, que mucha gente todavía considera un lenguaje de investigación, pudimos hacer que el editor de Viaweb se comportara más como software de escritorio.

Lanzamientos

Uno de los cambios más importantes en este nuevo mundo es la forma en que haces los 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 lanzar una sola pieza de código gigante. Sugieren 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 software como una serie de cambios incrementales en lugar de una explosión ocasional y grande. 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 se ve afectado el desarrollo de software 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 lanzas solo una nueva versión al año, tiendes a lidiar con los 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 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 sabe dónde está el final. Es como pescar 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 servidores, la mayor parte del cambio es pequeño e incremental. 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 control mucho más firme sobre el código. Como regla general, sabes lo que está sucediendo dentro de él. Por supuesto, no tienes el código fuente memorizado, pero cuando lees el código, 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. 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 algunos más? Pronto estarás lanzando funciones completas que sabes que están rotas. Apple hizo esto a principios de este año. Se sintieron presionados a lanzar su nuevo sistema operativo, cuya fecha de lanzamiento ya se había pospuesto cuatro veces, pero parte del software (soporte para CD y DVD) no estaba listo. ¿La solución? Lanzaron el sistema operativo sin las partes incompletas, 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 que suena bien decir que nunca tienes que lanzar software antes de que funcione, pero ¿qué sucede cuando has prometido entregar una nueva versión de tu software en 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 pueden 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 enteramente con fines de relaciones públicas. 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 un lanzamiento puntual, lo que significa un nuevo dígito después del punto decimal.

Algunos de nuestros competidores ofrecían software de escritorio y de hecho tenían números de versión. Y para estos lanzamientos, el mero hecho de que pareciera evidencia de su atraso, recibí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 de publicidad, hacíamos una lista de todas las características que habíamos agregado desde el último "lanzamiento", 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ó.

Para cuando fuimos comprados, habíamos hecho esto tres veces, así que estábamos en la Versión 4. Versión 4.1 si mal no recuerdo. Después de que Viaweb se convirtió en Yahoo Store, ya no había una necesidad tan desesperada de publicidad, por lo que, aunque el software continuó evolucionando, toda la idea de 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 allí 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 ellos están al teléfono contigo. Incluso podrías saberlo ya, si tienes código para detectar errores integrado en tu aplicación.

El software basado en la Web se usa las veinticuatro horas del día, por lo que todo lo que haces se pone inmediatamente a prueba. 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 exactamente lo que estoy defendiendo. Para el software basado en la Web, en realidad es 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 instantáneamente, puedes encontrar y corregir la mayoría de los errores tan pronto como aparecen. Nunca tuvimos suficientes errores en un momento dado para molestarnos con un sistema formal de seguimiento de errores.

Deberías probar los cambios antes de lanzarlos, por supuesto, por lo que no deberían lanzarse errores importantes. Esos pocos que inevitablemente se escapan involucrarán casos límite y solo afectarán a los pocos usuarios que los encuentren antes de que alguien llame para quejarse. Siempre y cuando corrijas los errores de inmediato, el efecto neto, para el usuario promedio, es muchos menos errores. Dudo que el usuario promedio de Viaweb haya visto alguna vez un error.

Corregir errores frescos es más fácil que corregir los viejos. Generalmente 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 el código fuente, porque ya te estabas preocupando por ello subconscientemente. 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 corrijas de una manera fea, o incluso que 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 buscas el pasamanos, este se te desprende en la 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" produce inherentemente muchos errores compuestos. Y el software que se lanza en una serie de pequeños cambios inherentemente tiende a no hacerlo. Los pisos se barren constantemente de cualquier objeto suelto que pueda atascarse en algo más tarde.

Ayuda si utilizas una técnica llamada programación funcional. La programación funcional significa evitar efectos secundarios. Es algo que es más probable que veas en artículos de investigación que en software comercial, pero para las aplicaciones basadas en la Web resulta ser realmente útil. Es difícil escribir programas completos como código puramente funcional, pero puedes escribir fragmentos sustanciales de esta 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 en este estilo, y hicimos de nuestro lenguaje de scripting, RTML, un lenguaje puramente funcional.

Las personas del negocio del software de escritorio encontrarán 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 encontraban probablemente eran usuarios avanzados, que llevaban las cosas al límite. Los usuarios avanzados son más indulgentes con los errores, especialmente porque probablemente los introdujiste al agregar alguna característica que estaban pidiendo. De hecho, dado que los errores eran raros y tenías que hacer cosas sofisticadas para verlos, los usuarios avanzados a menudo estaban orgullosos de atrapar uno. Llamaban a soporte con un espíritu más de triunfo que de enfado, como si hubieran ganado puntos contra nosotros.

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 te llaman por un error conocido, o simplemente están haciendo algo mal y tú tienes que averiguar qué. En cualquier caso, no hay mucho que puedas aprender de ellos. Y así, tiendes a ver las llamadas de soporte como una molestia que quieres aislar de tus desarrolladores tanto como sea posible.

Así no es como 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 solución.

Así que en Viaweb los desarrolladores siempre estaban en estrecho contacto con el soporte. La gente de atención al cliente estaba a unos treinta pies de los programadores, y sabían que siempre podían interrumpir cualquier cosa con el informe de un error genuino. Dejábamos una reunión de junta para corregir un error grave.

Nuestro enfoque del soporte hizo que todos estuvieran 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. A la gente de atención al cliente le 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 solo 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 de Dios Padre, creadores del mundo. Cualquiera que sea el procedimiento para informar errores, es probable que sea unidireccional: el personal de soporte que escucha sobre errores completa algún formulario que eventualmente se pasa (posiblemente a través de QA) a los programadores, quienes lo agregan a su lista de cosas que hacer. Era muy diferente en Viaweb. Un minuto después de escuchar sobre un error de un cliente, el personal de soporte podía estar al lado de un programador escuchándolo decir "Mierda, tienes razón, es un error". Encantaba al personal de soporte escuchar ese "tienes razón" de los hackers. Solían traernos errores con el mismo aire expectante con el que un gato te trae un ratón que acaba de matar. También los hacía más cuidadosos al juzgar la gravedad de un error, porque ahora su honor estaba en juego.

Después de que fuimos comprados por Yahoo, el personal de atención al cliente fue trasladado lejos de los programadores. Solo entonces nos dimos cuenta de que eran efectivamente QA y, en cierta medida, también marketing. Además de atrapar errores, eran los guardianes del conocimiento de cosas más vagas, parecidas a errores, como características que confundían a los usuarios. [6] También eran una especie de grupo focal proxy; podíamos preguntarles cuál de dos nuevas características querían más los usuarios, y siempre acertaban.

Moral

Ser capaz de lanzar software de inmediato es un gran motivador. A menudo, mientras caminaba hacia el trabajo, pensaba en algún cambio que quería hacer en el software, y lo hacía ese día. Esto funcionó también para características más grandes. Incluso si algo iba a llevar dos semanas escribirlo (pocos proyectos llevaban más), sabía que podía ver el efecto en el software tan pronto como estuviera hecho.

Si hubiera tenido que esperar un año para el próximo lanzamiento, habría archivado la mayoría de estas ideas, al menos por un tiempo. La cosa sobre 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 pensaste mientras lo escribías? Lo mismo sucede con el software. Trabajar para implementar una idea te da más ideas. Por lo tanto, archivar una idea te cuesta no solo ese retraso en su implementación, sino también todas las ideas a las que la implementación habría llevado. De hecho, archivar una idea probablemente incluso inhibe nuevas ideas: a medida que 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 las grandes empresas hacen en lugar de implementar características es planificarlas. En Viaweb, a veces tuvimos problemas por eso. Los inversores y analistas nos preguntaban qué teníamos planeado para el futuro. La respuesta honesta habría sido, 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 ganancia. No sé si alguna vez me atreví a dar esta respuesta, pero esa era la verdad. Los planes son solo otra palabra para las ideas en el estante. Cuando pensábamos en buenas ideas, las implementábamos.

En Viaweb, como en muchas empresas de software, la mayor parte del código tenía un propietario definido. Pero cuando poseías algo, realmente lo poseías: nadie, excepto el propietario de una pieza de software, tenía que aprobar (o siquiera saber) un lanzamiento. No había protección contra fallos excepto el miedo a parecer un idiota ante tus compañeros, y eso era más que suficiente. Puede que haya dado la impresión de que simplemente avanzábamos sin cuidado escribiendo código. Íbamos rápido, pero pensábamos muy cuidadosamente antes de lanzar software en esos servidores. Y prestar atención es más importante para la fiabilidad que moverse lentamente. Debido a que presta mucha atención, un piloto de la Marina puede aterrizar un avión de 40.000 libras a 140 millas por hora en la cubierta de un portaaviones que se balancea, de noche, de manera más segura que el adolescente promedio puede cortar un bagel.

Esta forma de escribir software es un arma de doble filo, por supuesto. Funciona mucho mejor para un equipo pequeño de buenos programadores de confianza que para una gran empresa de mediocres, donde las malas ideas son detectadas por comités en lugar de por las personas que las tuvieron.

Brooks al Revés

Afortunadamente, el software basado en la Web requiere menos programadores. Una vez trabajé para una empresa de software de escritorio de tamaño mediano que tenía más de 100 personas trabajando en ingeniería en general. Solo 13 de ellas estaban en desarrollo de productos. El resto trabajaba en lanzamientos, portabilidades, etc. Con el software basado en la Web, todo lo que necesitas (como máximo) son las 13 personas, porque no hay lanzamientos, portabilidades, etc.

Viaweb fue escrito por solo tres personas. [7] Siempre estuve bajo presión para contratar más, porque queríamos ser comprados, 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, 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 conexiones posibles entre desarrolladores crece exponencialmente con el tamaño del grupo. Cuanto más grande sea el grupo, más tiempo pasarán en reuniones negociando cómo funcionará su software 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 reducen, el desarrollo de software se vuelve exponencialmente más eficiente. No recuerdo que los programadores de Viaweb tuvieran alguna vez una reunión real. Nunca tuvimos más que decir en un momento dado de lo que podíamos decir mientras íbamos a almorzar.

Si hay una desventaja aquí, es que todos los programadores tienen que ser, hasta cierto punto, administradores de sistemas también. Cuando estás alojando software, alguien tiene que vigilar los servidores, y en la práctica, las únicas personas que pueden hacerlo correctamente son las que escribieron el software. En Viaweb, nuestro sistema tenía tantos componentes y cambiaba con tanta frecuencia que no había una frontera definida entre el software y la infraestructura. Declarar arbitrariamente tal frontera nos habría limitado en 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 solo preocuparse por los servidores, nunca sucedió.

No creo que pudiera ser de otra manera, siempre y cuando sigas desarrollando activamente el producto. El software basado en la Web nunca será algo que escribes, guardas y te vas a casa. Es una cosa viva, ejecutándose en tus servidores ahora mismo. Un error grave podría no solo bloquear 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 corregirlo. 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 lanzas código tarde en la noche y luego te vas a casa.

Observando a los Usuarios

Con el software basado en servidores, 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 pedirles que los sigan 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 créeme, no puedes tener ni idea de lo que pensarán los usuarios hasta que los observes. Y el software basado en servidores te brinda información sin precedentes sobre su comportamiento. No estás limitado a grupos focales pequeños y artificiales. Puedes ver cada clic hecho 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 depender de benchmarks, por ejemplo. Los benchmarks son usuarios simulados. Con software basado en servidores, puedes observar usuarios reales. Para decidir qué optimizar, simplemente inicia sesión en un servidor y ve qué está consumiendo toda la CPU. Y también sabes cuándo dejar de optimizar: eventualmente llevamos el editor de Viaweb al punto en que estaba limitado por la memoria en lugar de por la CPU, y como no había nada que pudiéramos hacer para disminuir el tamaño de los datos de los usuarios (bueno, nada fácil), supimos que podríamos detenernos allí.

La eficiencia importa para el software basado en servidores, porque pagas por el hardware. El número de usuarios que puedes soportar por servidor es el divisor de tu costo de capital, por lo que si puedes hacer que tu software sea muy eficiente, puedes vender por debajo del precio de los competidores y aun así obtener ganancias. En Viaweb, redujimos el costo de capital por usuario a alrededor de $5. Sería menos ahora, probablemente menos que el costo de enviarles la factura del primer mes. El hardware es gratuito ahora, si tu software es razonablemente eficiente.

Observar a los usuarios puede guiarte tanto en el diseño como 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 los estilos de página predefinidos no podían hacer lo que querían. Originalmente, el editor colocaba barras de botones a lo ancho de la página, por ejemplo, pero después de que varios usuarios usaron RTML para colocar botones en el lado izquierdo lado, lo convertimos en 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 están en problemas. Y como el cliente siempre tiene la razón, eso es una señal de algo que necesitas arreglar. En Viaweb, la clave para conseguir usuarios era la prueba en línea. No era solo una serie de diapositivas creadas por el personal de marketing. En nuestra prueba, los usuarios realmente usaron el software. Tomó unos cinco minutos, y al final, habían construido una tienda real y funcional.

La prueba fue la forma en que conseguimos 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 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 aumentaría nuestra tasa de crecimiento.

Estudié los rastros de clics de las personas que realizaban la prueba y descubrí que en un 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). Así que agregué un mensaje en ese punto, diciendo a los usuarios que casi habían terminado, y recordándoles que no hicieran clic en el botón Atrás. Otra gran cosa del software basado en la Web es que obtienes retroalimentación instantánea de los cambios: el número de personas que completaban la prueba aumentó inmediatamente del 60% al 90%. Y dado que el número de nuevos usuarios era una función del número de pruebas completadas, nuestros ingresos aumentaron un 50%, solo con 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 declaración muy cínica. Pero luego 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 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.

Alojamiento de aplicaciones es un área donde las empresas jugarán un papel que es poco probable que sea cubierto por software gratuito. Alojar aplicaciones es mucho estrés y tiene gastos reales. Nadie querrá hacerlo gratis.

Para las empresas, las aplicaciones basadas en la Web son una fuente de ingresos ideal. 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; nunca tiene que haber un nuevo modelo, per se, y si haces algo en el software que a los usuarios no les gusta, lo sabrás de inmediato. No tienes problemas con facturas incobrables; si alguien no te paga, puedes simplemente apagar el servicio. Y no hay posibilidad de piratería.

Esa última "ventaja" puede resultar ser un problema. Una cierta cantidad de piratería es una ventaja para las empresas de software. Si algún usuario realmente no hubiera 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 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, que significa cobrar a cada cliente tanto como puedan permitirse. [8] El software es particularmente adecuado para la discriminación de precios, porque el costo marginal está cerca de cero. Es por eso que 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 de forma segura. La piratería es efectivamente el nivel más bajo de discriminación de precios. Creo que las empresas de software entienden esto y deliberadamente hacen la vista gorda ante algunos tipos de piratería. [9] Con el software basado en servidores, tendrán 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 pensaba antes de Viaweb, en la medida en que pensaba en la cuestión. De hecho, el segundo paso puede propagarse hacia el primero: si algo es difícil de comprar, la gente cambiará de opinión sobre si lo quería. 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 simplemente de lo más fácil de comprar en el mundo, 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. (Haz que hagan más bajo tu propio riesgo).

A veces, el software basado en la Web se ofrece a través de ISPs que actúan como revendedores. Esta es una mala idea. Tienes que administrar los servidores, porque necesitas mejorar 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.

Varias de nuestras competidoras se dispararon en el pie de esta manera, generalmente, creo, porque fueron invadidas por trajes que estaban entusiasmados con este enorme canal potencial, y no se dieron cuenta de que arruinaría el producto que esperaban vender a través de él. Vender software basado en la Web a través de ISPs 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 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 tardarán en darse cuenta). La mejor intranet es Internet. Si una empresa utiliza aplicaciones basadas en la Web reales, 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 centra 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 la tarjeta 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 certeza más seguros en nuestras manos que en las suyas. ¿Quién puede contratar 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 preocupadas 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 máximo a un comerciante, probablemente podría encubrirse, y en el peor de los casos podría resultar en el despido de una persona. Si alguien irrumpiera en los nuestros, podría afectar a miles de comerciantes, probablemente terminaría como noticia en CNet, y podría sacarnos del negocio.

Si quieres mantener tu dinero seguro, ¿lo guardas debajo de tu colchón en casa o lo pones en un banco? Este argumento se aplica a todos los aspectos de la administración de servidores: no solo a la seguridad, sino también al tiempo de actividad, ancho de banda, gestión de carga, 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 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 TI. Tan drástico como suena, creo que es una buena idea en general. Las empresas probablemente obtendrán un mejor servicio de esta manera que con administradores de sistemas internos. Los administradores de sistemas pueden volverse gruñones y poco receptivos 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 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 muchas fuerzas externas 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; el simple hecho de pensarlo me da una descarga de adrenalina, años después.

Por lo tanto, las aplicaciones basadas en la Web serán normalmente la respuesta correcta también para las grandes empresas. Serán las últimas en darse cuenta, sin embargo, 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 enfrentamos a esto. Perdimos varios comerciantes de alta gama ante 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 hecha 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 las cargas aumentaron en su servidor. Viaweb era mucho más sofisticado que lo que la mayoría de estos comerciantes obtuvieron, pero no podíamos permitirnos decirles. A $300 al mes, no podíamos permitirnos enviar un equipo de personas bien vestidas y con voz autorizada para hacer presentaciones a los clientes.

Una gran parte de lo que las grandes empresas pagan extra es el costo de venderles cosas caras. (Si el Departamento de Defensa paga mil dólares por asientos de inodoro, es en parte porque cuesta mucho vender asientos de inodoro por mil dólares.) Y esta es una razón por la que el software de intranet seguirá prosperando, aunque probablemente sea una mala idea. Es simplemente más caro. No hay nada que puedas hacer al respecto de este dilema, por lo 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 están todas basadas en servidores. Si el software basado en servidores 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 eran 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" es parte del lenguaje ahora, pero cuando se usó por primera vez, tenía un sonido deliberadamente audaz, como la frase "satélite personal" hoy.

¿Por qué las computadoras de escritorio se impusieron? Creo que fue porque tenían mejor software. Y creo que la razón por la que el software de microcomputadoras 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 startups en la 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 podría, si parece prometedor, convertirse en una empresa. En esta etapa larvaria, cualquier obstáculo significativo detendrá la startup 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 una fuerza de ventas impresionante para venderlo. Comenzar una startup para escribir software de mainframe sería una tarea mucho más seria que simplemente hackear algo en tu Apple II por las noches. Y así, no obtuviste muchas startups escribiendo 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 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 computadoras o incluso por correo.

La aplicación que impulsó las computadoras de escritorio al mercado masivo fue VisiCalc, la primera hoja de cálculo. Fue escrita por dos tipos que trabajaban en un ático, y sin embargo hacía cosas que ningún software de mainframe podía hacer. [11] VisiCalc fue un avance tan grande, en su época, que la gente compraba Apple II solo para ejecutarlo. Y este fue el comienzo de una tendencia: las computadoras de escritorio ganaron porque las startups escribieron software para ellas.

Parece que el software basado en servidores será bueno esta vez, porque las startups lo escribirán. Las computadoras son tan baratas ahora que puedes empezar, como lo hicimos nosotros, usando una computadora de escritorio como servidor. Los procesadores baratos se han comido el mercado de estaciones de trabajo (casi ni siquiera escuchas la palabra ahora) y están en la mayor parte del mercado de servidores; los servidores de Yahoo, que manejan cargas tan altas como cualquiera en Internet, todos tienen los mismos procesadores Intel baratos que tienes en tu máquina 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 referencias en la prensa. [12]

Viaweb era una startup larvaria típica. Teníamos pánico de empezar una empresa, y durante los primeros meses nos consolamos tratándolo todo como un experimento que podríamos cancelar en cualquier momento. Afortunadamente, hubo pocos obstáculos excepto los técnicos. Mientras escribíamos el software, nuestro servidor web era la misma máquina de escritorio que usábamos para el desarrollo, conectada al mundo exterior por una línea telefónica. Nuestros únicos gastos en esa fase fueron comida y alquiler.

Hay aún más razones para que las startups 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 sorteando su sistema operativo con errores. Y si logras escribir algo que tenga éxito, puedes descubrir que simplemente estabas haciendo investigación de mercado para Microsoft.

Si una empresa quiere crear una plataforma sobre la que las startups construyan, tiene que hacerla algo que los propios hackers quieran usar. 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 iniciado una startup para escribir software de escritorio, porque el software de escritorio tiene que ejecutarse en Windows, y antes de poder escribir software para Windows, tendríamos que usarlo. La Web nos permitió evitar 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 al que todos temían. Es difícil imaginarlo ahora, pero recuerdo muy bien la sensación. Ahora el gigante aterrador es Microsoft, y no creo que sean tan ciegos a la amenaza que enfrentan como lo fue IBM. Después de todo, Microsoft construyó deliberadamente su negocio en el punto ciego de IBM.

Mencioné antes que mi madre realmente no necesita una computadora de escritorio. La mayoría de los usuarios probablemente no. Eso es un problema para Microsoft, y ellos lo saben. Si las aplicaciones se ejecutan en servidores remotos, nadie necesita Windows. ¿Qué hará Microsoft? ¿Podrán usar su control del escritorio para prevenir, o limitar, esta nueva generación de software?

Mi suposición es que Microsoft desarrollará algún tipo de híbrido servidor/escritorio, donde el sistema operativo trabaje junto con servidores que ellos controlan. Como mínimo, los archivos estarán disponibles centralmente para los usuarios que lo deseen. No espero que Microsoft llegue al extremo de realizar los cálculos en el servidor, con solo un navegador como cliente, si pueden evitarlo. Si solo necesitas un navegador como 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 servidores.

Creo que Microsoft tendrá dificultades para mantener al genio en la botella. Habrá demasiados tipos diferentes de clientes para que los controlen a 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. Pueden tener éxito en 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 ellos mismos tropezarán. Con el auge del software basado en la Web, se enfrentarán no solo a problemas técnicos, sino también a sus propios pensamientos deseosos. Lo que necesitan hacer es canibalizar su negocio existente, y no veo que lo hagan. La misma determinación 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 a medias en el negocio de las microcomputadoras porque eran ambivalentes acerca de amenazar su vaca lechera, la computación mainframe. Microsoft se verá igualmente obstaculizada por querer salvar el escritorio. Una vaca lechera puede ser un mono muy pesado en tu espalda.

No digo que nadie vaya a dominar las aplicaciones basadas en servidores. Alguien probablemente lo hará eventualmente. Pero creo que habrá un largo período de alegre caos, al igual que en los primeros días de las microcomputadoras. Esa fue una buena época para las startups. Muchas pequeñas empresas florecieron, e lo hicieron haciendo cosas geniales.

Startups, pero más aún

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 magnifica el efecto de las decisiones que toman. Si ganan, ganan a lo grande.

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 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 colocalizado 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 habitación llena de hombres con gafas de montura de cuerno y corbatas negras estrechas, escribiendo industriosamente 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 vestían jeans en la oficina y escribían en vt100s. Ahora son un par de tipos sentados en una sala de estar con laptops. (Y los jeans resultan no ser 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 demás. Lo alarmante del software basado 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 suelen terminar: "entonces, por fin 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 todo el tiempo que quieras. Y como puedes, y tus competidores pueden, 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 de sistemas tradicionalmente tienen sus propias preocupaciones separadas. 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 con las manos en el código fuente, pero en algún momento pueden irse a casa y olvidarse de él. Los administradores de sistemas nunca abandonan del todo el trabajo, pero cuando se les llama a las 4:00 AM, 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 solo 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 trabajábamos duro, pero se sintió como unas vacaciones en comparación con la siguiente fase, cuando llevamos 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 de sistemas. El software basado en la Web obliga a los programadores a hacerlo. Hay menos estrés en total, pero más para los programadores. Eso no es necesariamente una mala noticia. Si eres una startup compitiendo con una gran empresa, son buenas noticias. [15] Las aplicaciones basadas en la Web ofrecen una forma sencilla de trabajar más duro que tus competidores. Ninguna startup pide más.

Simplemente 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 nos hubiera gustado realmente agregar a HTML y HTTP. Lo que importa, sin embargo, es que las páginas web son simplemente lo suficientemente buenas.

Hay un paralelo aquí con las primeras microcomputadoras. Los procesadores de esas máquinas no estaban realmente destinados a ser las CPU de las computadoras. Estaban diseñados para usarse en cosas como semáforos. Pero tipos como Ed Roberts, que diseñó el Altair, se dieron cuenta de que eran simplemente lo suficientemente buenos. Podías combinar uno de estos chips con algo de memoria (256 bytes en el primer Altair), y paneles frontales con interruptores, y tendrías una computadora funcional. El poder tener tu propia computadora era tan emocionante que había mucha gente que quería comprarlas, por muy limitadas que fueran.

Las páginas web no fueron diseñadas para ser una interfaz de usuario para aplicaciones, pero son simplemente lo suficientemente buenas. Y para un número significativo de usuarios, el software que puedes usar desde cualquier navegador será una victoria en sí misma lo suficientemente grande como para compensar cualquier torpeza en la interfaz de usuario. Quizás 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 cliente especial, o que pueda incorporar flujos de datos en vivo, o que pueda enviarte notificaciones 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 servidores no tienen por qué ser 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 jodido. 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 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 cualquiera, y no puedo predecir lo que sucederá con los clientes. La convergencia probablemente está llegando, pero ¿hacia dónde? No puedo elegir un ganador. Una cosa que puedo predecir es el conflicto entre AOL y Microsoft. Sea lo que sea que resulte ser el .NET de Microsoft, probablemente implicará conectar el escritorio a los servidores. A menos que AOL contraataque, serán apartados o convertidos en un conducto entre el software cliente y servidor de Microsoft. Si Microsoft y AOL entran en una guerra de clientes, lo único que funcionará seguro en ambos será navegar por la Web, lo que significa que las aplicaciones basadas en la Web serán las únicas que funcionen 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 que no sea 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 por un amigo granjero que muchas vallas electrificadas no tienen corriente. Las vacas aparentemente aprenden a mantenerse alejadas de ellas, y después de eso no necesitas la corriente. "¡Levántense, vacas!", escribió, "¡Tomen su libertad mientras los déspotas duermen!"

Si eres un hacker que ha pensado en algún día empezar una startup, probablemente hay dos cosas que te lo impiden. Una es que no sabes nada de negocios. La otra es que tienes miedo a la competencia. Ninguna de estas vallas tiene corriente.

Solo hay dos cosas que necesitas saber sobre negocios: construye algo que los usuarios amen, y gasta más de lo que gastas. Si aciertas estas dos, 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 empiezas con poca financiación, al menos fomentará 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 hoy sería aún 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 pagábamos solo por el ancho de banda. Podrías lanzar una aplicación basada en la Web ahora por menos del costo de una silla de oficina elegante.

En cuanto a construir algo que los usuarios amen, aquí tienes algunos consejos generales. Empieza por hacer algo limpio y simple que quieras usar tú mismo. Lanza 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 la razón, pero diferentes clientes tienen razón en diferentes cosas; los usuarios menos sofisticados te muestran lo que necesitas simplificar y aclarar, y los más sofisticados te dicen qué características necesitas agregar. Lo mejor que puede ser el software es fácil, pero la forma de hacerlo es acertar con las configuraciones predeterminadas, no limitar las opciones de los usuarios. No te complazcas si el software de tus competidores es mediocre; el estándar con el que comparar tu software es lo que podría ser, no lo que tus competidores actuales tienen. Usa tu propio software, todo el tiempo. Viaweb se suponía que era un creador de tiendas en línea, pero también lo usamos para crear nuestro propio sitio. No escuches a los profesionales de marketing, diseñadores o gerentes de producto solo por sus títulos de trabajo. Si tienen buenas ideas, úsalas, pero depende de ti decidir; el software tiene que ser diseñado por hackers que entienden de diseño, no por diseñadores que saben un poco de software. Si no puedes diseñar software tan bien como implementarlo, no empieces una startup.

Ahora hablemos de la competencia. Lo que te asusta no son presumiblemente grupos de hackers como tú, sino empresas reales, con oficinas y planes de negocio y vendedores y demás, ¿verdad? Bueno, 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 espacio de oficina o contratar vendedores que para una empresa de cualquier tamaño escribir software. 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 tratar de correr a través de agua hasta la cintura.

No quiero menospreciar a Yahoo. Tenían algunos buenos hackers, y la alta dirección eran verdaderos "butt-kickers". Para una gran empresa, eran excepcionales. Pero aun así, eran solo aproximadamente una décima parte de productivos que una pequeña startup. Ninguna gran empresa puede hacerlo mucho mejor que eso. Lo que da miedo de Microsoft es que una empresa tan grande pueda desarrollar software. Son como una montaña que puede caminar.

No te intimides. Puedes hacer tanto como Microsoft no puede hacer como ellos pueden hacer lo 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 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 lo prometo, Microsoft te tiene miedo. Los gerentes intermedios complacientes puede que no, pero Bill sí, porque él también fue tú una vez, allá por 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 fabrican clientes ligeros generalmente han intentado combinar el hardware con un servicio en línea. Este enfoque no ha funcionado bien, en parte porque necesitas dos tipos diferentes de empresas para fabricar electrónica de consumo y para ejecutar un servicio en línea, 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 un compromiso mucho menor que un terminal web. Los fabricantes de teléfonos móviles se contentan con vender hardware sin intentar capturar también los ingresos del servicio. Ese debería ser probablemente el modelo para los clientes de Internet también. Si alguien vendiera simplemente una caja de aspecto agradable 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 cometer errores que de cualquier decisión de diseño, pero la naturaleza del software basado en servidores hará que los desarrolladores presten más atención a no cometer errores. Comprometer un servidor podría causar un daño tal que las ASP (que quieren permanecer en el negocio) probablemente serán cuidadosas con la seguridad.

[3] En 1995, cuando comenzamos Viaweb, se suponía que las applets de Java serían la tecnología que todos usarían para desarrollar aplicaciones basadas en servidores. Las applets nos parecieron una idea anticuada. ¿Descargar programas para ejecutarlos en el cliente? Más simple es ir hasta el final y ejecutar los programas en el servidor. Perdimos poco tiempo en applets, pero innumerables otras startups deben haber sido atraídas a este pantano. Pocas pueden haber escapado vivas, 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 añade "el costo de escribir software aumenta más que linealmente con su tamaño. Quizás 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 del error compuesto en el que un error compensa a otro. Cuando corriges un error, el otro se vuelve visible. Pero parecerá que la corrección es la culpable, ya que eso 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 en el primer premio con entradas que todavía me dan escalofríos al recordarlas. Corregimos ambos problemas de inmediato.

[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 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 (¿con qué frecuencia 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 rigurosamente.

[9] En No Logo, Naomi Klein dice que las marcas de ropa favoritas de los "jóvenes urbanos" no intentan demasiado evitar los hurtos en tiendas porque en su mercado objetivo los ladrones de tiendas 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á así 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 máquina 6502. Dan estaba en la Harvard Business School 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 era gran cosa".

[12] No es tan fácil como lo hago sonar. Tardó mucho tiempo en que el boca a boca cobrara impulso, y no empezamos a recibir mucha cobertura de prensa hasta que contratamos una agencia de relaciones públicas (admitidamente la mejor del negocio) por $16,000 al mes. Sin embargo, era cierto que el único canal significativo era nuestro propio sitio web.

[13] Si el 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 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 a evitar que la próxima generación de software sea 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 algo genial en sí mismo, y probablemente también animaría a las empresas a construir pequeños electrodomésticos 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 enormemente 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 también serían buenos.

Si quieres cambiar el mundo, escribe un nuevo Mosaic. ¿Crees que es demasiado tarde? En 1998, mucha gente pensó que era demasiado tarde para lanzar un nuevo motor de búsqueda, pero Google demostró que estaban equivocados. Siempre hay 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:

"Yo iría más lejos al decir que debido a que el software basado en servidores es tan difícil para los programadores, causa un cambio económico fundamental lejos 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 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, recomendé 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 artículo; a Dan Bricklin y Bob Frankston por la información sobre VisiCalc; y nuevamente a Ken Anderson por invitarme a hablar en BBN.

Encontrarás este ensayo y otros 14 en Hackers & Painters.