El caso para construir algo maravilloso solo

He estado construyendo Derw por mi cuenta desde el año pasado. Recientemente, alguien me preguntó si trabajo con otros, y la respuesta es no, y eso es algo intencional.

Como mencioné en mi última publicación, la comunidad es algo que planeo construir una vez que llegue a 1.0.0. Pero ¿qué pasa con la construcción de un equipo? Idiomas como Roc lograron construir un equipo incluso antes de que el repositorio se hiciera público, con varias personas contribuyendo con más de 100 confirmaciones. Creo que eso es genial, y creo firmemente en mejorar las cosas trabajando juntos. Dicho esto, hay beneficios al evitar trabajar directamente con otros.

Trabajar solo significa que no tiene que compartir el contexto de sus cambios con otros. Eso no significa que no realice un seguimiento de los cambios que ha realizado o que no los informe. Pero si hay un cambio que quiero hacer, puedo hacerlo sin consultar a otros. Esto es particularmente útil, por ejemplo, cuando quiero reescribir un archivo de TypeScript a Derw. Sin colisiones con otros PR, sin necesidad de advertir a nadie "hey, volveré a escribir este archivo".

Puede ajustarse a su propio horario y ajustarlo si es necesario. Cada uno tiene sus propias prioridades, y sin esperar a que alguien termine algo y sin que alguien espere a que tú termines algo, puedes avanzar a tu propio ritmo. Los usuarios finales tendrán un impacto en esta línea de tiempo, si los escucha, pero cuando trabaja principalmente en su tiempo libre, es importante poder tomarse unos días libres y jugar en su lugar.

Los equipos de trabajo salen y organizan talleres, reuniones y fiestas para discutir su visión del producto en el que están trabajando. En proyectos de código abierto, no tienes ese lujo. Las visiones y los planes deben comunicarse en forma de texto y, a menudo, pasan a un segundo plano para trabajar solo en la visión en su cabeza. Los objetivos compartidos deben establecerse a través de largas conversaciones y RFC. Trabajando solo, no necesita eso en la misma medida: si va a tener usuarios, necesita decirles aproximadamente cuáles son sus objetivos con un proyecto, pero no necesita tener una discusión de ida y vuelta. sobre una característica. Puedes simplemente construirlo. Esto no significa que las visiones de otros para su proyecto no sean útiles, ni significa que nunca necesite discutir una característica con alguien. Pero puede hacerlo a pedido, según sea necesario, lo que facilita su ejecución.

Si uno de sus objetivos con un proyecto es simplemente aprender, al construir algo por su cuenta, debe aprender todas las partes difíciles, así como las partes familiares. Es posible que solo haya usado webpack en el pasado, pero su proyecto es más adecuado para esbuild. Nunca ha tenido que interactuar con la recolección de basura en Node, pero para obtener el rendimiento que desea, se vuelve relevante. Un equipo puede ayudarlo a guiarlo a través de su conocimiento colectivo de todas esas piezas aleatorias, pero el autoaprendizaje puede funcionar igual de bien.

Algunos ven los estilos de desarrollo como el de Elm como un defecto, porque trabajar de forma esencialmente aislada va en contra del código abierto. Yo no lo veo así: un creador con una opinión y dirección fuerte conduce a una creación más pura y coherente. Puede que no haga todo lo que la comunidad quiere, o puede que implemente las cosas de una manera que alguien no prefiera. Pero desde el comienzo de una biblioteca, marco o línea de vida de un idioma, es especialmente importante tener una fuerza impulsora, alguien que pueda ver a dónde quiere ir y actuar en consecuencia. . Más tarde, podría ser una buena idea compartir esa carga y convertirse en un BDFL estilo Python. Al principio, verse empujado en múltiples direcciones puede fragmentar tanto la visión como la implementación.

Con Derw, probablemente seguiré trabajando sin un equipo central durante bastante tiempo, probablemente después de 1.0.0. Puedo obtener todas las diferentes funciones, como pruebas integradas, formato integrado, múltiples idiomas de destino y administración de paquetes para que funcionen a la manera de Derw porque tengo el contexto de lo que quiero que sea Derw y cómo deben encajar las partes. Eventualmente, probablemente tenga sentido incorporar a otras personas que puedan contribuir en la línea de mi propia visión, pero sospecho que eso no será posible por un tiempo. Siempre me pongo en contacto con la gente cuando tengo una idea que quiero discutir: colegas, amigos, chat, Twitter. Estas contribuciones son excelentes y valiosas y han dado lugar a varios aspectos interesantes de Derw. Pero puedo tomar ese conocimiento colectivo sobre una característica específica e implementarlo yo mismo, y esa es probablemente la mejor manera para un nuevo idioma.

¿Te gusta esta publicación? Sígueme en Twitter para mantenerte actualizado, destaca a Derw en Github o