Las preguntas que merece la pena hacer primero.

Ingenieros, directamente. La persona de la primera llamada es la que escribe la arquitectura, publica el código y entrega el sistema. Un responsable único: sin gestor de cuenta que retransmita mensajes y sin nada que se pierda en la traducción entre quien entendió el problema y quien escribió el código. Cuando una parte del proyecto requiere de verdad a un especialista, esa persona se nombra durante la definición del alcance y trabaja en esa parte, y el mismo responsable sigue respondiendo del resultado.

Sí, y el mecanismo es concreto, no una esperanza. En los proyectos más grandes, se incorporan ingenieros para ese proyecto: nombrados durante la definición del alcance, limitados a sus requisitos y bajo el mismo acuerdo de confidencialidad y las mismas reglas de acceso que todos los demás. No se sacan de una bolsa permanente ni se retienen después. Una persona sigue siendo responsable de la arquitectura y del resultado de principio a fin, así que el trabajo escala sin el coste de coordinación ni la pérdida en la traducción que introduce un equipo permanente.

La respuesta es una mitigación, no un consuelo. La infraestructura se ejecuta en tus cuentas. El código fuente vive en tus repositorios. Las decisiones se escriben a medida que se toman, que es uno de los ocho principios de funcionamiento precisamente por esto. Nada esencial reside en una sola cabeza, de modo que otro ingeniero puede retomar el sistema sin una negociación de entrega.

A veces, y nunca en secreto. No hay externalización, ni traspaso a una agencia, ni intermediación de un mercado de freelancers. Cuando un proyecto requiere de verdad a un especialista, esa persona se nombra durante la definición del alcance, la apruebas tú antes de que empiece y se limita a esa parte del proyecto, bajo el mismo acuerdo de confidencialidad y las mismas reglas de acceso que todos los demás. Un responsable único sigue respondiendo de la arquitectura, la integración y el resultado, así que siempre sabes quién hace qué y quién responde de ello.

El acceso es de mínimo privilegio y se limita al trabajo en curso. Las credenciales se quedan en tu almacén de secretos, nunca en el código fuente ni en un hilo de chat. La seguridad es la posición de partida, no una pasada de endurecimiento añadida al final. El código y la propiedad intelectual producidos durante el encargo son tuyos, y se puede firmar un acuerdo de confidencialidad antes de hablar de ningún detalle.

El problema tal como se entiende, las restricciones dentro de las que tiene que funcionar, qué se construirá y qué no, la secuencia de etapas y qué cuenta como terminado en cada una. Nombra las suposiciones de las que depende, porque una suposición que nadie escribió es lo que luego cambia la cifra. No se factura nada hasta que ese documento esté acordado, y si la definición del alcance muestra que quien lo tiene entre manos no es la empresa adecuada, eso es lo que dice el documento.

Sí, antes de hablar de ningún detalle. Envía el tuyo y se revisa y se firma, o pídelo y se te facilita uno mutuo. Nada sobre un encargo, un sistema o una empresa se publica, se cita por escrito ni se usa como ejemplo sin permiso escrito, y eso vale exista o no un acuerdo de confidencialidad.

Mínimo privilegio, limitado al trabajo en curso y con límite de tiempo cuando la plataforma lo permite. Las credenciales se quedan en tu almacén de secretos: nunca en el código fuente, nunca en un hilo de chat, nunca en un ticket. El acceso se solicita sistema por sistema en lugar de concederse de forma amplia al principio, y se devuelve al terminar el encargo. La infraestructura se ejecuta en tus cuentas durante todo el proceso, así que revocar el acceso es algo que puedes hacer sin pedirlo.

El código fuente en tus repositorios, la infraestructura en tus cuentas y el razonamiento escrito a medida que se hacía el trabajo, no reconstruido al final. Eso significa notas de arquitectura, las decisiones y las alternativas que se descartaron, runbooks para lo que haya que operar y las limitaciones conocidas. El criterio es si un ingeniero que no participó en el desarrollo puede retomar el sistema sin una negociación de entrega.

Sí, y a menudo es la mejor forma. Puede significar encargarse de un componente de principio a fin mientras tu equipo se ocupa del resto, trabajar dentro de tus repositorios y tu proceso de revisión, o asumir la parte del stack a la que tu equipo no tiene capacidad de llegar. El documento de alcance indica qué frontera se aplica, porque una frontera poco clara entre dos equipos es la forma más fiable de perder un mes.

Las capas que compone son software libre existente y conservan sus propias licencias, decida lo que decida aquí. La licencia de las partes escritas para este proyecto no se ha decidido, así que no hay nada que anunciar ni nada que insinuar. Se indicará aquí cuando se elija. Una licencia citada hoy sería una postura tomada para una web, no una decisión tomada sobre el software.

Para desarrolladores, especialistas en sistemas y organizaciones que operan su propia infraestructura: las personas que trabajan cerca de la máquina y prefieren ser dueñas de la capa de abajo antes que negociar con ella. La mitad más útil de la respuesta es para quién no es. No es un intento de hacer Linux amable para quien no quiere una terminal. Ese problema está resuelto, y lo resolvieron otras distribuciones: un escritorio Linux gráfico es hoy realmente bueno, y construir una versión peor no ayudaría a nadie. El público de aquí ya eligió la terminal y quiere que el entorno que la rodea deje de costar días de montaje.

La intención de diseño es que la línea de comandos esté siempre ahí y nunca sea la única forma de entrar. Sentirse cómodo con una terminal debería hacer el sistema más rápido de usar, no ser el precio para entrar. Tómalo como un compromiso que puedes exigirle al proyecto y no como una función con la que planificar: la superficie que lo haría cierto está diseñada y no construida, y hoy no hay nada frente a lo que sentarse para comprobar esa afirmación.

No. La base es Void Linux, con el kernel de Linux debajo, runit como init, xbps para los paquetes e i3 como gestor de ventanas en mosaico. Son capas probadas, y reescribirlas mal sería una pérdida de tiempo para todos. No es un fork, es una composición cuidadosa: cada capa hace su trabajo y pasa el relevo limpiamente a la siguiente. Lo que se construye para este proyecto es todo lo que está encima, las herramientas, los valores por defecto y la superficie de trabajo, y esa es la parte que merece ser juzgada. No merecería la pena publicar los valores por defecto de otro con un tema encima.

Todavía no hay respuesta, y cualquier cifra impresa aquí sería inventada y no medida. Funcionar bien en máquinas modestas y antiguas es un objetivo de diseño, y se deriva de las mismas decisiones que el resto: lo que está ausente no puede costarte nada. Pero un requisito es una medición, nada es lo bastante estable para medirse, y una cifra publicada ahora es una cifra a la que una compilación futura se vería obligada sin motivo. Los requisitos se publicarán cuando se hayan medido, y no antes.

No puedes. No hay compilación: ni ISO, ni instalador, ni espejo de paquetes, ni canal de versiones, ni número de versión, ni lista de preinscripción a la que apuntarse. Tampoco hay fecha, lo que significa que no se está guardando ninguna fecha en secreto. El trabajo se documenta a medida que ocurre, y seguir esa documentación es la forma honesta de seguir el progreso real en lugar de una cuenta atrás de marketing.

Nada, porque no hay nada que instalar. Cuando haya una imagen, la intención es que se comporte como cualquier otra instalación de Linux: particionado normal, gestor de arranque normal, arranque dual normal, y documentación para las configuraciones habituales en lugar de un camino especial que solo entendemos nosotros. Nada de eso es una promesa sobre la que planificar hasta que exista una imagen y se haya probado en máquinas reales. Nadie debería reparticionar una máquina que funciona por un software sin compilación.