Por qué ralentizar el desarrollo de nuevas funciones puede ser la mejor manera de mantener los proyectos de código abierto
Comentario: A menudo, lo mejor que puede hacer un mantenedor de proyectos de código abierto es ralentizar el desarrollo de nuevas características.
Imagen: Arturo, Getty Images/iStockphoto
La gran mayoría de los proyectos de código abierto atraen a un pequeño grupo de colaboradores comprometidos. Siempre ha sido así. Los mejores de estos proyectos consiguen hacer más con menos. SolveSpace es uno de esos ejemplos, y su éxito se debe en gran parte a un mantenedor de proyectos particularmente leal, Whitequark. Si bien hace una gran cantidad de trabajo importante para mejorar el código existente del proyecto, parte de su trabajo más importante (y, por extensión, parte del trabajo más importante que puede hacer cualquier encargado del mantenimiento del proyecto) es simplemente asegurarse de que el código nuevo no rompa el código anterior. . Resulta que no es tan simple.
La importancia de la continuidad
Cobertura de lectura obligada para desarrolladores
John Byrd dijo: «Los buenos programadores escriben buen código. Los grandes programadores no escriben código. Los programadores zen eliminan código». Puede que sea una exageración, pero la idea detrás de esto es sólida: a medida que las bases de código se acumulan con el tiempo, y los buenos ingenieros invertirá el tiempo necesario para eliminar la deuda técnica del código.Como dijo una vez DJ Walker-Morgan: «Líneas eliminadas [of code] es la última quema en la tierra que acumula la deuda técnica. »
Resulta que este concepto de limpieza y gobernanza es especialmente importante en el liderazgo de proyectos de código abierto. Hablando con Whitequark, aunque escribe menos código y revisa más en estos días, enfatiza que su trabajo es «garantizar la viabilidad a largo plazo del proyecto». Para algunos proyectos, esto puede incluir encontrar financiación o atraer nuevos talentos de desarrollo. Whitequark hace estas cosas.
Mirar: Cómo construir una carrera de desarrollador exitosa (PDF gratuito) (República tecnológica)
Pero ella hace más: «Reviso el código enviado por los colaboradores y co-mantenedores y me aseguro de que esos cambios no nos lleguen más tarde». (Énfasis mío).
A lo largo de los años, ha utilizado su experiencia en programación de sistemas para «rediseñar algunas de las partes más desafiantes de SolveSpace», incluida la compatibilidad con HiDPI y Unicode, la internacionalización, la capacidad de prueba y la implementación de una capa de abstracción de interfaz de usuario, lo que permite los próximos puertos de Web Assembly. . Así que hace lo que algunos podrían considerar un «trabajo de verdad». Ella pone el proyecto en una mejor base para atraer a usuarios y desarrolladores.
Al hacerlo, enfatiza, sigue un principio fundamental: «Hecho es mejor que perfecto, pero
Un mañana roto es peor que no hacer nada. ’ Entonces, continúa, mientras que “el desarrollo lento puede ser frustrante para los usuarios, y [might] enajenando a unos pocos,… [if] espacio de solución
si [to remain relevant, she needs to] Hacerlo mejor que cuando lo encontré, incluso si eso significa mejorar a un ritmo más lento. »
cuando atrás es en realidad adelante
Hemos visto este mismo principio en otros proyectos. Apache Cassandra es un buen ejemplo reciente. En conversaciones con expertos de Cassandra, hubo un momento en que la estabilidad era primordial en la comunidad de Cassandra, y Apple, Netflix y otros grandes usuarios de Cassandra se unieron al objetivo cuando los usuarios se quedaron atascados en la versión 3.11.
Suena genial lanzar otra versión, pero los usuarios de Cassandra están cansados de revalidar sus bases de datos cada dos meses cuando se lanza una nueva versión. El esfuerzo de Cassandra 4.0 es un esfuerzo comunitario de base amplia para poner en orden la casa de Cassandra.
Esto lleva a un punto interesante compartido por SolveSpace, Cassandra y otros proyectos: los mejores administradores de un proyecto suelen ser quienes lo utilizan. Whitequark no solo estaba trabajando en el proyecto SolveSpace: necesitaba un programa CAD 3D paramétrico de código abierto para construir bridas y otras partes físicas. Dado el uso extensivo de Cassandra por parte de Apple, debe asegurarse de que la base de datos sea sólida como una roca. Este intento cauteloso de garantizar que estos proyectos avancen lentamente es la mejor manera de garantizar que el negocio o proyecto resultante pueda avanzar rápidamente.
Divulgación: trabajo en AWS, pero este artículo no tiene nada que ver con mi trabajo allí.
