EL OTRO CAMINO POR DELANTE
OriginalSeptiembre 2001
(Este artículo explica por qué gran parte de la próxima generación de software puede ser basada 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 que precedió a la salida a bolsa de Netscape estaba en pleno apogeo, y había mucho diálogo 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íamos software para crearlas, así que decidimos escribir algo.
Durante la primera semana o más, teníamos la intención de hacer de esto una aplicación de escritorio ordinaria. Luego, un día, tuvimos 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 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.
Resultó ser un buen plan. Ahora, como Yahoo Store, este software es el constructor 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 todos saben 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á 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 sorprendentes cosas que vimos, como algunos de los primeros visitantes a este nuevo mundo. En la medida en que el software se mueva a los servidores, lo que estoy describiendo aquí es el futuro.
¿La Próxima Cosa?
Cuando miramos hacia atrás en la era del software de escritorio, creo que nos maravillaremos de las incomodidades que la gente toleraba, 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 poseer uno. Pero los automóviles eran una gran ventaja, así que muchas personas que no eran expertos en automóviles también querían tenerlos.
Las computadoras están en esta fase ahora. Cuando posees 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 EE. UU. poseen una. Mi madre tiene una computadora que usa para correo electrónico y para llevar 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 ordinarios no deberían siquiera conocer las palabras "sistema operativo", mucho menos "controlador de dispositivo" o "parche".
Ahora hay otra forma de entregar software que salvará a los usuarios de convertirse en administradores de sistemas. Las aplicaciones 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 excepto en las aplicaciones que utilizan. Todo el desorden y las cosas cambiantes estarán en un servidor en algún lugar, mantenido 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 el software. Todo lo que necesitarás será algo con un teclado, una pantalla y un navegador web. Tal vez tenga acceso a Internet inalámbrico. Tal vez también 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 de lo que pagas por el hardware, tal como lo haces ahora con los teléfonos. [1]
Tomará aproximadamente una décima de segundo para que un clic llegue al servidor y vuelva, así que los usuarios de software altamente interactivo, como Photoshop, seguirán queriendo 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 computadoras, una latencia de una décima de segundo no sería un problema. Mi madre realmente no necesita una computadora de escritorio, y hay muchas personas como ella.
La Ventaja para los Usuarios
Cerca de mi casa hay un automóvil con un adhesivo en el parachoques que dice "muerte antes que inconvenientes". La mayoría de las personas, la mayor parte del tiempo, tomarán 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 incomodidad de este modelo se vuelve cada vez más evidente a medida que la gente se acostumbra a las redes.
El extremo delgado de la cuña aquí fue el correo electrónico basado en la web. Millones de personas ahora se dan cuenta de que deberías tener acceso a los mensajes de correo electrónico sin importar dónde estés. Y si puedes ver tu correo electrónico, ¿por qué no tu calendario? Si puedes discutir un documento con tus colegas, ¿por qué no puedes editarlo? ¿Por qué debería estar atrapados tus datos en alguna computadora sentada en un escritorio lejano?
La idea completa 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. De hecho, pueden convertirse en teléfonos, o viceversa. Y a medida que los clientes se vuelven más pequeños, tienes otra razón para no mantener tus datos en ellos: algo que llevas contigo puede perderse o ser robado. Dejar tu PDA en un taxi es como un fallo de disco, excepto que tus datos son entregados a otra persona en lugar de ser vaporizados.
Con software puramente basado en la web, ni tus datos ni las aplicaciones se mantienen 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 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 señalando a los usuarios hacia la prueba.
Después de probar la demostración, registrarse para el servicio no debería requerir nada más que llenar un breve formulario (cuanto más breve, mejor). Y eso debería ser el último trabajo que el usuario tenga que hacer. Con software basado en la web, deberías recibir nuevas versiones sin pagar extra, o hacer ningún trabajo, o posiblemente incluso saberlo.
Las actualizaciones no serán los grandes choques que son ahora. Con el tiempo, las aplicaciones crecerán silenciosamente en potencia. Esto requerirá cierto esfuerzo por parte de los desarrolladores. Tendrán que diseñar el software para que pueda actualizarse sin confundir a los usuarios. Ese es un nuevo problema, pero hay formas de resolverlo.
Con aplicaciones basadas en la web, todos usan la misma versión, y los errores pueden corregirse tan pronto como se descubren. Así que 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 al mismo tiempo. 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 aplicaciones colaborativas, pero apuesto a que los usuarios comenzarán a querer esto en la mayoría de las aplicaciones una vez que se den cuenta de que es posible. A menudo será útil permitir que dos personas editen el mismo documento, por ejemplo. Viaweb permitió que múltiples 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 usas una aplicación basada en la web, tus datos estarán más seguros. Los fallos de disco no serán cosa del pasado, pero los usuarios no oirán más sobre ellos. Ocurrirán dentro de granjas de servidores. Y las empresas que ofrecen aplicaciones basadas en la web realmente harán copias de seguridad, no solo porque tendrán verdaderos administradores de sistemas preocupándose por esas cosas, sino porque un ASP que pierde los datos de las personas estará en grandes, grandes problemas. Cuando las personas pierden sus propios datos en un fallo de disco, no pueden enojarse tanto, porque solo tienen a sí mismos a quienes enojarse. Cuando una empresa pierde sus datos por ellos, se enojarán mucho más.
Finalmente, el software basado en la web debería ser menos vulnerable a virus. Si el cliente no ejecuta nada excepto un navegador, hay menos posibilidades de ejecutar virus, y no hay datos localmente que dañar. Y un programa que atacara a los propios servidores debería encontrarlos muy bien defendidos. [2]
Para los usuarios, el software basado en la web será menos estresante. Creo que si miraras dentro del usuario promedio de Windows, encontrarías un enorme y prácticamente inexplorado deseo de software que cumpla con esa descripción. Liberado, podría ser una fuerza poderosa.
Ciudad de Código
Para los desarrolladores, la diferencia más conspicua entre el software basado en 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 software basado en la web es como diseñar una ciudad en lugar de un edificio: además de edificios, necesitas caminos, 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 utilizaban, 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 recursos o mover o restaurar datos, programas que pretendí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 servidor en tiempo real (un éxito con los visitantes, pero indispensable para nosotros también), modificaciones (incluyendo correcciones de errores) a 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 nos compró Yahoo. Los programas nos enviaban páginas, enviaban faxes y correos electrónicos a los usuarios, realizaban transacciones con procesadores de tarjetas de crédito, y se comunicaban entre sí a través de sockets, 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 las personas podrían usar para infiltrarse 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 en si nuestro ISP de upstream tenía conexiones lo suficientemente rápidas a todos los backbones. 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 en un paso habilitar a todos tus usuarios para que envíen páginas, o envíen faxes, o envíen comandos por teléfono, o procesen tarjetas de crédito, etc., simplemente instalando el hardware relevante. Siempre buscábamos nuevas formas de agregar características 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 solo binario, puede escribirse en cualquier número de lenguajes diferentes. Cuando escribes software de escritorio, prácticamente estás 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 capitalistas de riesgo) llegaron a considerarse 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 desees. [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 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 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 usaban C y C++, y esto hacía que su software fuera visiblemente inferior porque (entre otras cosas), no tenían forma de evitar la falta de estado de los scripts CGI. Si ibas a cambiar algo, todos los cambios tenían que ocurrir en una sola página, con un botón de Actualizar en la parte inferior. Como he escrito en otros lugares, al usar Lisp, que muchas personas todavía consideran 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 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 por sacar una sola pieza gigante de código. Comparaciones obvias se sugieren tanto para el proceso como para 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. Libera software como una serie de cambios incrementales en lugar de una gran explosión ocasional. Una típica empresa 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 el desarrollo de software 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 lanzas solo 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 entra 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 pescar escombros de un estanque. Nunca sabes realmente qué 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í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 en el código. Como regla general, sabes lo que está sucediendo dentro de él. No tienes el código fuente memorizado, por supuesto, pero cuando lees el código fuente lo haces como un piloto 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, y has incluso establecido mecanismos para compensarlo (por ejemplo, lanzamientos de parches). Entonces, ¿por qué preocuparse por unos pocos más? Pronto estarás lanzando características enteras que sabes que están rotas. Apple hizo esto a principios de este año. Se sintieron presionados para lanzar su nuevo sistema operativo, cuya fecha de lanzamiento ya se había retrasado cuatro veces, pero parte del software (soporte para CDs y DVDs) no estaba listo. ¿La solución? Lanzaron el sistema operativo sin las partes inacabadas, y los usuarios tendrán que instalarlas más tarde.
Con el software basado en la web, nunca tienes que lanzar software antes de que funcione, y puedes lanzarlo tan pronto como funcione.
El veterano de la industria puede estar pensando que es una idea muy bonita decir que nunca tienes que lanzar software antes de que funcione, pero ¿qué pasa cuando has prometido entregar una nueva versión de tu software para una fecha determinada? Con el software basado en la web, no harías tal promesa, porque no hay versiones. Tu software cambia de manera gradual y continua. 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 puede sonar extraño, porque siempre estábamos anunciando nuevas versiones. Esto se hacía completamente por razones de relaciones públicas. La prensa comercial, 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 menor, lo que significa un nuevo dígito después del punto decimal.
Algunos de nuestros competidores ofrecían software de escritorio y realmente tenían números de versión. Y para estos lanzamientos, el mero hecho de que esto nos parecía evidencia de su retraso, recibirían todo tipo de publicidad. No queríamos perdernos, así que comenzamos 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", poníamos un nuevo número de versión en el software y emitíamos un comunicado de prensa diciendo que la nueva versión estaba disponible de inmediato. Sorprendentemente, nadie nos llamó al respecto.
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 convirtió en Yahoo Store, ya no había una necesidad tan desesperada de publicidad, así que aunque el software continuó 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 justo allí 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 al teléfono contigo. Incluso podrías saber sobre él ya, si tienes código para notar errores incorporado en tu aplicación.
El software basado en la web se utiliza las 24 horas, así 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 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 al instante, puedes encontrar y corregir la mayoría de los errores tan pronto como aparecen. Nunca tuvimos suficientes errores en ningún momento como para preocuparnos por un sistema formal de seguimiento de errores.
Deberías probar los cambios antes de lanzarlos, por supuesto, así 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 que corrijas los errores de inmediato, el efecto neto, para el usuario promedio, es que hay muchos menos errores. Dudo que el usuario promedio de Viaweb alguna vez haya visto un error.
Corregir errores frescos es más fácil que corregir errores antiguos. Por lo general, es bastante rápido encontrar un error en un código que acabas de escribir. Cuando aparece, a menudo sabes qué está mal antes de siquiera mirar el código fuente, porque ya estabas preocupándote 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 dado que no entiendes el código tan bien, es más probable que lo corrijas de una manera poco elegante, o incluso que introduzcas más errores. [4]
Cuando atrapas errores temprano, también obtienes menos errores compuestos. Los errores compuestos son dos errores separados que interactúan: tropiezas al bajar las escaleras, y cuando alcanzas el pasamanos, este se desprende en tu mano. En el software, este tipo de error es el más difícil de encontrar y también tiende a tener las peores consecuencias. [5] El enfoque tradicional de "romper todo y luego filtrar los errores" produce inherentemente muchos errores compuestos. Y el software que se lanza en una serie de pequeños cambios tiende a no hacerlo. Los pisos se están limpiando constantemente de cualquier objeto suelto que podría quedar atrapado en algo más tarde.
Ayuda si usas 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 aplicaciones basadas en la web resulta ser realmente útil. Es difícil escribir programas enteros como código puramente funcional, pero puedes escribir partes 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 donde estás constantemente haciendo y probando pequeñas modificaciones. Escribí gran parte del editor de Viaweb en este estilo, y hicimos que nuestro lenguaje de scripting, RTML, fuera un lenguaje puramente funcional.
Las personas del negocio del software de escritorio encontrarán difícil de creer esto, 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 eran probablemente usuarios avanzados, empujando los límites. Los usuarios avanzados son más indulgentes con los errores, especialmente porque probablemente los introdujiste en el curso de agregar alguna característica que estaban pidiendo. De hecho, dado que los errores eran raros y tenías que estar haciendo cosas sofisticadas para verlos, los usuarios avanzados a menudo estaban orgullosos de atraparlos. Llamaban al soporte en un espíritu más de triunfo que de enojo, como si hubieran anotado puntos contra nosotros.
Soporte
Cuando puedes reproducir errores, cambia tu enfoque hacia el 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 están llamándote sobre un error conocido, o simplemente están haciendo algo mal y tienes que averiguar qué. En cualquiera de los casos, no hay mucho que puedas aprender de ellos. Y así tiendes a ver las llamadas de soporte como un dolor en el trasero que quieres aislar de tus desarrolladores tanto como sea posible.
No era así 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 contacto cercano con el soporte. Las personas de soporte al cliente estaban a unos diez metros de los programadores y sabían que siempre podían interrumpir cualquier cosa con un informe de un error genuino. Saldríamos de una reunión de junta para corregir un error grave.
Nuestro enfoque hacia el soporte hizo que todos fueran más felices. Los clientes estaban encantados. Solo imagina cómo se sentiría llamar a una línea de soporte y ser tratado como alguien que trae noticias importantes. A las personas de soporte al cliente les gustaba porque significaba que podían ayudar a los usuarios, en lugar de leerles guiones. Y a los programadores les gustaba porque podían reproducir errores en lugar de solo escuchar informes vagos de segunda mano sobre ellos.
Nuestra política de corregir errores sobre la marcha cambió la relación entre las personas de soporte al cliente y los hackers. En la mayoría de las empresas de software, las personas 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: las personas de soporte que escuchan sobre errores llenan algún formulario que eventualmente se pasa (posiblemente a través de control de calidad) a los programadores, quienes lo ponen en su lista de cosas por hacer. Era muy diferente en Viaweb. Dentro de un minuto de escuchar sobre un error de un cliente, las personas de soporte podían estar de pie junto a un programador escuchándolo decir "Mierda, tienes razón, es un error." A las personas de soporte les encantaba escuchar "tienes razón" de los hackers. Solían traernos errores con el mismo aire expectante que un gato te trae un ratón que acaba de matar. También los hacía más cuidadosos al juzgar la gravedad de un error, porque ahora su honor estaba en juego.
Después de que nos compró Yahoo, las personas de soporte al cliente fueron alejadas de los programadores. Solo entonces nos dimos cuenta de que efectivamente eran control de calidad y, hasta cierto punto, marketing también. Además de atrapar errores, eran los guardianes del conocimiento de cosas más vagas, similares 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 tenían razón.
Moral
Poder lanzar software de inmediato es un gran motivador. A menudo, mientras caminaba al trabajo, pensaba en algún cambio que quería hacer en el software y lo hacía ese día. Esto funcionaba para características más grandes también. Incluso si algo iba a tardar dos semanas en escribirse (pocos proyectos tardaban más), sabía que podría ver el efecto en el software tan pronto como estuviera terminado.
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. Así que archivar una idea te cuesta no solo ese retraso en implementarla, sino también todas las ideas que implementarla habría conducido. De hecho, archivar una idea probablemente incluso inhibe nuevas ideas: a medida que comienzas 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 nos metíamos en problemas por este motivo. Los inversores y analistas nos preguntaban qué teníamos planeado para el futuro. La respuesta verdadera habría sido que no teníamos 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 ventaja. No sé si alguna vez me atreví a dar esta respuesta, pero esa era la verdad. Los planes son solo otra palabra para ideas en el estante. Cuando pensábamos en buenas ideas, las implementábamos.
En Viaweb, como en muchas empresas de software, la mayoría 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 incluso conocer) un lanzamiento. No había protección contra roturas excepto el miedo a parecer un idiota ante tus pares, y eso era más que suficiente. Puede que haya dado la impresión de que simplemente avanzábamos alegremente 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 lb a 140 millas por hora en una cubierta de portaaviones en movimiento, de noche, más seguro que el adolescente promedio puede cortar un bagel.
Esta forma de escribir software es, por supuesto, una espada de doble filo. Funciona mucho mejor para un pequeño equipo de buenos y confiables programadores que para una gran empresa de mediocres, donde las malas ideas son atrapadas por comités en lugar de por las personas que las tuvieron.
Brooks al Revés
Afortunadamente, el software basado en la web requiere menos programadores. Una vez trabajé para una empresa de software de escritorio de tamaño mediano que tenía más de 100 personas trabajando en ingeniería en su conjunto. Solo 13 de estas 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, etc.
Viaweb fue escrito por solo tres personas. [7] Siempre estaba bajo presión para contratar más, porque queríamos ser comprados, y sabíamos que los compradores tendrían dificultades para pagar un alto precio 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 ahorra 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 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 al revés: a medida que los grupos se vuelven más pequeños, el desarrollo de software se vuelve exponencialmente más eficiente. No puedo recordar que los programadores de Viaweb alguna vez tuvieran una reunión real. Nunca 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 de sistemas también. Cuando estás alojando 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 restringido nuestras opciones de diseño. Y así, aunque siempre esperábamos que un día ("en un par de meses") todo estuviera lo suficientemente estable como para que pudiéramos contratar a alguien cuyo trabajo fuera solo preocuparse por los servidores, nunca sucedió.
No creo que pudiera ser de otra manera, mientras sigas desarrollando activamente el producto. El software basado en la web nunca será algo que escribas, lo revises y te vayas a casa. Es algo vivo, que se ejecuta en tus servidores en este momento. Un mal error podría no solo hacer que se bloquee el proceso de un usuario; podría hacer que se bloqueen 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.
Vigilando 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 famosa 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 les esperaban.
El software debería hacer lo que los usuarios piensan que hará. Pero no puedes tener idea de lo que los usuarios estarán pensando, créeme, hasta que los observes. Y el software basado en la web te brinda información sin precedentes sobre su comportamiento. No estás limitado a pequeños grupos focales artificiales. Puedes ver cada clic realizado por cada usuario. Tienes que considerar cuidadosamente qué vas a observar, porque no quieres violar la privacidad de los usuarios, pero incluso el muestreo estadístico más general puede ser muy útil.
Cuando tienes 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 la web, puedes observar a 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 detenerte al optimizar: eventualmente logramos que el editor de Viaweb estuviera limitado por la memoria en lugar de por la CPU, y dado que no había nada que pudiéramos hacer para disminuir el tamaño de los datos de los usuarios (bueno, nada fácil), sabíamos que podríamos detenernos allí.
La eficiencia importa para el software basado en la web, porque estás pagando por el hardware. El número de usuarios que puedes soportar por servidor es el divisor de tu costo de capital, así que si puedes hacer que tu software sea muy eficiente, puedes vender a precios más bajos que tus competidores y aún así obtener ganancias. En Viaweb logramos reducir 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 gratis ahora, si tu software es razonablemente eficiente.
Vigilar a los usuarios puede guiarte en el diseño así 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 caja 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 través de la página, por ejemplo, pero después de que varios usuarios usaron RTML para colocar botones a lo largo del lado izquierdo, hicimos eso una opción (de hecho, la predeterminada) en los estilos de página predefinidos.
Finalmente, al observar a los usuarios, a menudo puedes decir cuándo están en problemas. Y dado que el cliente siempre tiene razón, eso es una señal de algo que necesitas corregir. En Viaweb, la clave para conseguir usuarios era la prueba de manejo en línea. No era solo una serie de diapositivas construidas por personas de marketing. En nuestra prueba de manejo, los usuarios realmente usaban el software. Tomaba unos cinco minutos, y al final habían construido una tienda real y funcional.
La prueba de manejo era 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 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 caminos de clics de las personas que tomaban la prueba de manejo 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 añadí un mensaje en ese punto, diciendo a los usuarios que estaban casi terminados y recordándoles que no hicieran clic en el botón Atrás. Otra gran cosa sobre el software basado en la web es que obtienes 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 declaración muy cínica. Pero más tarde me di cuenta de que refleja la realidad: el desarrollo de software es un proceso continuo. Creo que es más limpio si cobras abiertamente tarifas de suscripción, en lugar de obligar a las personas a seguir comprando e instalando nuevas versiones para que sigan pagándote. Y afortunadamente, las suscripciones son la forma natural de facturar por aplicaciones basadas en la web.
Alojar aplicaciones es un área donde las empresas desempeñarán un papel que probablemente no será llenado 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 ideal de ingresos. En lugar de comenzar cada trimestre con una pizarra en blanco, tienes un flujo de ingresos recurrente. Debido a que tu software evoluciona gradualmente, no tienes que preocuparte de que un nuevo modelo fracase; nunca tiene que haber un nuevo modelo, per se, y si haces algo al software que a los usuarios les desagrada, lo sabrás de inmediato. No tienes problemas con facturas incobrables; si alguien no paga, simplemente puedes 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 ventajosa para las empresas de software. Si algún usuario realmente no habría comprado tu software a ningún precio, no has perdido nada si usa una copia pirata. De hecho, ganas, porque es un usuario más que ayuda a hacer de tu software 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. Esta es la razón por la que algunos software cuesta más para ejecutarse en Suns que en cajas Intel: una empresa que usa Suns no está interesada en ahorrar dinero y puede ser cobrada 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 deliberadamente hacen la vista gorda a 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 las personas deciden comprar algo y luego lo compran, como dos pasos separados. Eso es lo que pensé antes de Viaweb, en la medida en que pensé en la cuestión en absoluto. De hecho, el segundo paso puede propagarse de nuevo al primero: si algo es difícil de comprar, las personas cambiarán de opinión sobre si lo querían. Y viceversa: venderás más de algo cuando sea fácil de comprar. Compro más libros porque existe Amazon. El software basado en la web es casi la cosa más fácil del mundo para comprar, especialmente si acabas de hacer una demostración en línea. Los usuarios no deberían tener que hacer mucho más que ingresar un número de tarjeta de crédito. (Haz que hagan más a su 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 estar administrando los servidores, porque necesitas estar mejorando constantemente tanto el hardware como el software. Si renuncias al control directo de los servidores, renuncias a la mayoría de las ventajas de desarrollar aplicaciones basadas en la web.
Varios de nuestros competidores se dispararon en el pie de esta manera; generalmente, creo, porque fueron invadidos por 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 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 costos 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 serán lentas para darse cuenta). El mejor intranet es Internet. Si una empresa utiliza aplicaciones verdaderamente 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 generalmente gira 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 eran 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 de manera diplomática, 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 gestionar la seguridad, una startup tecnológica cuyo negocio completo es ejecutar servidores, o un minorista de ropa? No solo teníamos mejores personas preocupándose por la seguridad, sino que nos preocupábamos más por ello. Si alguien se infiltraba en los servidores del minorista de ropa, afectaría a, como máximo, un comerciante, probablemente podría ser silenciado, y en el peor de los casos podría hacer que una persona fuera despedida. Si alguien se infiltraba 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 mantienes debajo de tu colchón en casa, o lo pones en un banco? Este argumento se aplica a cada aspecto de la administración de servidores: no solo a la seguridad, sino también a la disponibilidad, el ancho de banda, la gestión de carga, las copias de seguridad, etc. Nuestra existencia dependía de hacer estas cosas bien. Los problemas de servidor eran el gran no-no para nosotros, como un juguete peligroso lo sería para un fabricante de juguetes, o un brote de salmonela para un procesador de alimentos.
Una gran empresa que utiliza aplicaciones basadas en la web está, en ese sentido, externalizando TI. Drástico como suena, creo que generalmente es una buena idea. Las empresas probablemente obtendrán un mejor servicio de esta manera que el que tendrían de administradores de sistemas internos. Los administradores de sistemas pueden volverse malhumorados y poco receptivos porque no están expuestos directamente a la presión competitiva: un vendedor tiene que tratar con los clientes, y un desarrollador tiene que lidiar con el software de los competidores, pero un administrador de sistemas, como un viejo soltero, tiene pocas fuerzas externas que lo mantengan en línea. [10] En Viaweb teníamos fuerzas externas de sobra para mantenernos en línea. Las personas que nos llamaban eran clientes, no solo compañeros de trabajo. Si un servidor se quedaba atascado, saltábamos; solo pensar en ello me da un golpe 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, 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 alto nivel ante empresas de consultoría web que los 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. No estaban, como regla, 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 decírselo. A $300 al mes, no podíamos permitirnos enviar un equipo de personas bien vestidas y con un sonido autoritario para hacer presentaciones a los clientes.
Una gran parte de lo que las grandes empresas pagan extra es el costo de vender 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 intranet seguirá prosperando, aunque probablemente sea una mala idea. Simplemente es más caro. No hay nada que puedas hacer sobre este enigma, así que el mejor plan es dirigirte primero a los clientes más pequeños. El resto vendrá con el tiempo.
Hijo del Servidor
Ejecutar software en el servidor no es nada nuevo. De hecho, es el modelo antiguo: las aplicaciones de mainframe son todas basadas en servidores. Si el software basado en servidores es una buena idea, ¿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 lo tendría la frase "satélite personal" hoy.
¿Por qué las computadoras de escritorio se apoderaron? 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 muchas personas se den cuenta de cuán frágiles y tentativas son las startups en la etapa más temprana. Muchas startups comienzan casi por accidente, como un par de chicos, ya sea con trabajos diurnos o en la escuela, escribiendo un prototipo de algo que podría, si parece prometedor, convertirse en una empresa. En esta etapa larval, cualquier obstáculo significativo detendrá a la startup en seco. Escribir software de mainframe requería demasiado compromiso por adelantado. Las máquinas de desarrollo eran caras, y dado que los clientes serían grandes empresas, necesitarías una fuerza de ventas que luciera impresionante para venderles. Comenzar una startup para escribir software de mainframe sería un emprendimiento mucho más serio que simplemente juntar 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 nuevo software, porque escribir aplicaciones para ellas parecía un objetivo alcanzable para las startups larvales. El desarrollo era barato, y los clientes serían personas individuales que podrías alcanzar a través de tiendas de computadoras o incluso por correo.
La aplicación que empujó a las computadoras de escritorio hacia la corriente principal fue VisiCalc, la primera hoja de cálculo. Fue escrita por dos chicos trabajando en un ático, y aún así hacía cosas que ningún software de mainframe podía hacer. [11] VisiCalc fue tal avance, en su tiempo, que la gente compró Apple IIs 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 comenzar, como hicimos nosotros, usando una computadora de escritorio como servidor. Los procesadores económicos han devorado el mercado de estaciones de trabajo (raramente incluso oyes la palabra ahora) y están casi a través del mercado de servidores; los servidores de Yahoo, que manejan cargas tan altas como cualquier en Internet, todos tienen los mismos procesadores Intel económicos 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 fue una típica startup larval. Estábamos aterrorizados de comenzar una empresa, y durante los primeros meses nos consolábamos tratando todo 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 máquina de escritorio que usábamos para el desarrollo, conectada al mundo exterior por una línea de acceso telefónico. Nuestros únicos gastos en esa fase eran 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 trabajando alrededor de su sistema operativo lleno de errores. Y si logras escribir algo que despegue, puedes descubrir que solo estabas haciendo investigación de mercado para Microsoft.
Si una empresa quiere crear una plataforma sobre la que las startups construirán, tiene que hacer que sea algo que los propios hackers quieran usar. Eso significa que tiene que ser económico y bien diseñado. El Mac fue popular entre los hackers cuando salió por primera vez, y muchos de ellos escribieron software para él. [13] Esto se ve menos con Windows, porque los hackers no lo usan. El tipo de personas que son buenas escribiendo software tienden a estar ejecutando Linux o FreeBSD ahora.
No creo que hubiéramos comenzado una startup para escribir software de escritorio, porque el software de escritorio tiene que ejecutarse en Windows, y antes de que pudiéramos escribir software para Windows tendríamos que usarlo. La web nos permitió hacer un rodeo alrededor de 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 todos tenían miedo. 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 ante la amenaza que enfrentan como lo fue IBM. Después de todo, Microsoft construyó deliberadamente su negocio en el punto ciego de IBM.
Mencioné anteriormente que mi madre realmente no necesita una computadora de escritorio. La mayoría de los usuarios probablemente no lo hagan. 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 sobre el escritorio para prevenir o restringir 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 funcione junto con servidores que controlan. Como mínimo, los archivos estarán disponibles centralmente para los usuarios que lo deseen. No espero que Microsoft llegue hasta el extremo de hacer los cálculos en el servidor, con solo un navegador como cliente, si pueden evitarlo. Si solo necesitas un navegador como cliente, no necesitas a Microsoft en el cliente, y si Microsoft no controla el cliente, no pueden empujar a los usuarios hacia sus aplicaciones basadas en servidores.
Creo que Microsoft tendrá dificultades para mantener al genio en la botella. Habrá demasiados tipos diferentes de clientes para que puedan controlarlos 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 en el mundo de las aplicaciones de escritorio.
No es tanto que un competidor los haga tropezar, sino que ellos tropezarán consigo mismos. Con el auge del software basado en la web, se enfrentarán no solo a problemas técnicos, sino a su propio pensamiento iluso. Lo que necesitan hacer es canibalizar su negocio existente, y no puedo verlos enfrentando eso. La misma determinación que los ha llevado hasta aquí ahora trabajará en su contra. IBM estaba en exactamente 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 sobre amenazar su vaca lechera, la computación de mainframe. Microsoft también se verá obstaculizado por querer salvar el escritorio. Una vaca lechera puede ser un maldito peso pesado en tu espalda.
No estoy diciendo que nadie dominará las aplicaciones basadas en servidores. Alguien probablemente lo hará eventualmente. Pero creo que habrá un buen largo período de caos alegre, al igual que hubo en los primeros días de las microcomputadoras. Ese fue un buen momento para las startups. Muchas pequeñas empresas florecieron y lo hicieron creando cosas geniales.
Startups pero Más
La startup clásica es rápida e informal, con pocas personas y poco dinero. Esas pocas personas trabajan muy duro, y la tecnología magnifica el efecto de las decisiones que toman. Si ganan, ganan en grande.
En una startup que escribe aplicaciones basadas en la web, todo lo que asocias con startups se lleva a un extremo. Puedes escribir y lanzar un producto con incluso menos personas y menos dinero. Tienes que ser aún más rápido, y puedes salirte con la tuya siendo más informal. Puedes literalmente lanzar tu producto como tres chicos 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 un cuarto lleno de hombres con gafas de pasta 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 usaban jeans en la oficina y escribían en vt100s. Ahora es un par de chicos sentados en una sala de estar con laptops. (Y resulta que los jeans no son la última palabra en informalidad).
Las startups son estresantes, y esto, desafortunadamente, también se lleva a un 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 bajo sus escritorios y así sucesivamente. Lo alarmante sobre el software basado en la web es que no hay nada que impida que esto se convierta en la norma. Las historias sobre dormir bajo los escritorios generalmente terminan: entonces, por fin, lo enviamos y todos nos fuimos a casa y dormimos una semana. El software basado en la web nunca se envía. Puedes trabajar días de 16 horas todo el tiempo que quieras. Y porque puedes, y tus competidores pueden, tiendes a estar obligado a hacerlo. Puedes, así que debes. Es la Ley de Parkinson funcionando al revés.
Lo peor no son las horas, sino la responsabilidad. Los programadores y 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 hasta los codos en código fuente, pero en algún momento pueden irse a casa y olvidarse de ello. Los administradores de sistemas nunca dejan del todo el trabajo atrás, pero cuando reciben una página 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 estábamos trabajando duro, pero se sentía 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 última 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, es una buena noticia. [15] Las aplicaciones basadas en la web ofrecen una forma directa de trabajar más que tus competidores. Ninguna startup pide más.
Solo lo Suficientemente Bueno
Una cosa que podría disuadirte de escribir aplicaciones basadas en la web es la torpeza 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 solo lo suficientemente buenas.
Hay un paralelo aquí con las primeras microcomputadoras. Los procesadores en 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 solo lo suficientemente buenos. Podías combinar uno de estos chips con algo de memoria (256 bytes en el primer Altair) y con interruptores en el panel frontal, y tendrías una computadora funcional. Poder tener tu propia computadora era tan emocionante que había muchas personas que querían comprarlas, sin importar cuán limitadas fueran.
Las páginas web no fueron diseñadas para ser una interfaz de usuario para aplicaciones, pero son solo lo suficientemente buenas. Y para un número significativo de usuarios, el software que puedes usar desde cualquier navegador será una ventaja suficiente en sí misma para superar cualquier torpeza en la interfaz de usuario. Tal vez no puedas escribir la hoja de cálculo mejor diseñada 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 un mensaje cuando se activen ciertas condiciones. Más importante aún, puedes escribir nuevos tipos de aplicaciones que ni siquiera tienen nombres aún. VisiCalc no era simplemente una versión de microcomputadora de una aplicación de mainframe, después de todo; era un nuevo tipo de aplicación.
Por supuesto, las aplicaciones basadas en servidores no tienen que ser basadas en la web. Podrías tener algún otro tipo de cliente. Pero estoy bastante seguro de que eso 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 ya una gran ventaja, y la ventaja crecerá a medida que nuevos dispositivos web proliferen. A los usuarios les gustarás 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 observado la evolución de la web tan de cerca como cualquiera, y no puedo predecir qué va a suceder con los clientes. La convergencia probablemente se avecina, 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 resulte ser .NET de Microsoft, probablemente involucrará conectar el escritorio a los servidores. A menos que AOL contraataque, serán empujados a un lado 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 seguramente 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 esto? No lo sé. Y no tienes que saberlo si apuestas por 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 corriendo a través de ellas. 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 roncan!"
Si eres un hacker que ha pensado en algún día comenzar una startup, probablemente hay dos cosas que te impiden hacerlo. Una es que no sabes nada sobre negocios. La otra es que tienes miedo de la competencia. Ninguna de estas cercas tiene corriente en ellas.
Solo hay dos cosas que tienes que saber sobre negocios: construye algo que los usuarios amen y gasta menos de lo que ingresas. Si aciertas en estas dos, estarás por delante de la mayoría de las startups. Puedes averiguar el resto a medida que avanzas.
Puede que al principio no ganes más de lo que gastas, pero mientras la brecha se cierre lo suficientemente rápido, estarás bien. Si comienzas con poco financiamiento, 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 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 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í hay algunos consejos generales. Comienza haciendo algo limpio y simple que tú mismo querrías usar. Saca una versión 1.0 rápidamente, luego continúa mejorando el software, escuchando de cerca a los usuarios mientras lo haces. El cliente siempre tiene razón, pero 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é características necesitas agregar. Lo mejor que puede ser el software es fácil, pero la forma de hacerlo es acertar con los valores predeterminados, no limitar las opciones de los usuarios. No te acomodes si el software de tus competidores es torpe; 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. Viaweb se suponía que era un constructor de tiendas en línea, pero también lo usamos para hacer nuestro propio sitio. No escuches a personas de marketing o diseñadores o gerentes de producto solo por sus títulos. Si tienen buenas ideas, úsalas, pero depende de ti decidir; el software tiene que ser diseñado por hackers que entienden el diseño, no por diseñadores que saben un poco sobre software. Si no puedes diseñar software tan bien como implementarlo, no comiences una startup.
Ahora hablemos de la competencia. Lo que temes no son presumiblemente grupos de hackers como tú, sino empresas reales, con oficinas y planes de negocio y vendedores y así sucesivamente, ¿verdad? Bueno, ellos tienen más miedo de ti de lo 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 hacer que se escriba software. He estado en ambos lados, y lo sé. Cuando Viaweb fue comprada por Yahoo, de repente me encontré trabajando para una gran empresa, y era como intentar 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 luchadores. Para una gran empresa, eran excepcionales. Pero aún así eran solo aproximadamente una décima parte tan productivos como una pequeña startup. Ninguna gran empresa puede hacerlo mucho mejor que eso. Lo que asusta de Microsoft es que una empresa tan grande puede desarrollar software en absoluto. Son como una montaña que puede caminar.
No te sientas intimidado. Puedes hacer tanto de lo que Microsoft no puede como ellos pueden hacer de 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, o conseguir espacio en estanterías en tiendas minoristas, o arrastrarte para que tu aplicación se incluya con el sistema operativo. Puedes entregar software directamente al navegador, y nadie puede interponerse entre tú y los usuarios potenciales sin impedirles navegar por la web.
Puede que no lo creas, pero te prometo que Microsoft tiene miedo de ti. Los gerentes intermedios complacientes pueden no tenerlo, pero Bill sí, porque él fue 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 en línea. Este enfoque no ha funcionado bien, en parte porque necesitas dos tipos diferentes de empresas para construir electrónica de consumo y para ejecutar un servicio en línea, y en parte porque a los usuarios les desagrada la idea. Regalar la navaja y ganar dinero con las cuchillas puede funcionar para Gillette, pero una navaja es un compromiso mucho más pequeño que un terminal web. Los fabricantes de teléfonos móviles están satisfechos de vender hardware sin intentar capturar los ingresos del servicio 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 en el país compraría 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 tal daño que los ASP (que quieren seguir en el negocio) probablemente serán cuidadosos con la seguridad.
[3] En 1995, cuando comenzamos Viaweb, se suponía que los applets de Java serían la tecnología que todos usarían para desarrollar aplicaciones basadas en servidores. Los applets nos parecían una idea anticuada. ¿Descargar programas para ejecutarse en el cliente? Más simple simplemente ir hasta el final y ejecutar los programas en el servidor. Perdimos poco tiempo en applets, pero incontables otras startups deben haber sido atraídas a este pozo de alquitrán. 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 añade "el costo de escribir software aumenta más que linealmente con su tamaño. Quizás esto se deba principalmente a corregir errores antiguos, y el costo puede ser más lineal si todos los errores se encuentran rápidamente."
[5] El tipo más difícil de error para encontrar puede ser una variante del error compuesto donde 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 esa fue la última cosa que cambiaste.
[6] Dentro de Viaweb, una vez tuvimos un concurso para describir la peor cosa sobre nuestro software. Dos personas de soporte al cliente empataron en el primer premio con entradas que aún me hacen temblar 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 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 de compra significaba precios más bajos para ti?) que me sorprendió descubrir que estaba prohibida en 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 "la juventud urbana" no intentan demasiado prevenir el robo en tiendas porque en su mercado objetivo los ladrones también son los líderes de moda.
[10] Las empresas a menudo se preguntan qué externalizar y qué no. Una posible respuesta: externaliza cualquier trabajo que no esté expuesto directamente a la presión competitiva, porque externalizarlo lo expondrá a la presión competitiva.
[11] Los dos chicos eran Dan Bricklin y Bob Frankston. Dan escribió un prototipo en Basic en un par de días, luego, durante el transcurso del siguiente año, trabajaron juntos (principalmente por la noche) para hacer una versión más poderosa 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 diurno 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. Tomó un tiempo dolorosamente largo que el boca a boca comenzara, y no comenzamos a obtener mucha cobertura de prensa hasta que contratamos a una firma de relaciones públicas (admitidamente la mejor en el 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, nuevamente. Microsoft se concentró en el negocio del software y desató un enjambre de proveedores de componentes baratos sobre el hardware de Apple. No ayudó, tampoco, que los trajes tomaran el control durante un período crítico.
[14] Una cosa que ayudaría a las aplicaciones basadas en la web, y ayudaría a mantener a la próxima generación de software de ser 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í misma, y probablemente también alentaría a las empresas a construir pequeños dispositivos web.
Entre otras cosas, un navegador de código abierto adecuado haría que HTTP y HTML continuaran evolucionando (como lo ha hecho, 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 URLs en una solicitud. Los menús desplegables también serían buenos.
Si quieres cambiar el mundo, escribe un nuevo Mosaic. ¿Piensas que es demasiado tarde? En 1998, muchas personas pensaron 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 son lo suficientemente malas. Asegúrate de que funcione en todos los sistemas operativos gratuitos primero; las cosas nuevas comienzan con sus usuarios.
[15] Trevor Blackwell, que 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 duro 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 a personas altamente calificadas para que se rompan el