Open Sauce 2026 reunió en San Mateo, California, más de 500 exposiciones: robots caseros, impresión 3D, electrónica e inventos difíciles de clasificar.
Por si no conoces la feria, Open Sauce es un encuentro maker en el que aficionados, ingenieros, artistas y creadores muestran proyectos construidos por ellos mismos. Es algo parecido a una feria de ciencias llevada al mundo del hardware, la robótica y la cultura de internet: menos escaparate de productos terminados y más inventos que se pueden ver, tocar y discutir con quien los ha construido.
El evento es una buena fotografía del momento maker, pero también deja una pregunta que no caduca cuando se desmontan los puestos: ¿podría otra persona reconstruir esos proyectos cuando ya no tiene al autor delante?
Enseñar un cacharro terminado inspira. Publicar un vídeo ayuda. Subir un STL permite imprimir una pieza. Pero ninguna de esas cosas, por sí sola, convierte un proyecto en hardware abierto ni garantiza que sea reproducible.
Esta guía explica qué conviene compartir para que un proyecto pueda estudiarse, construirse y modificarse. Al terminar tendrás un proceso de siete pasos, una estructura de carpetas, un ejemplo completo y una prueba final para detectar lo que todavía depende de tu memoria.
No hace falta crear una enciclopedia ni esperar a tener el montaje perfecto. La idea es documentar primero una versión concreta y dejar un camino que otra persona pueda seguir sin adivinar qué tornillo, versión de librería o cable decidió estropearle la tarde.
¿Qué significa que un proyecto de hardware sea abierto?
La Open Source Hardware Association (OSHWA) define el hardware abierto como aquel cuyo diseño se publica para que cualquiera pueda estudiarlo, modificarlo, distribuirlo, fabricarlo y vender tanto el diseño como el hardware basado en él. La palabra importante no es «gratis». Es modificable.
Eso obliga a distinguir entre un archivo para usar y un archivo fuente:
- Un STL puede bastar para imprimir una pieza, pero normalmente no conserva el historial paramétrico ni las operaciones que facilitan cambiarla.
- Un PDF permite consultar un esquema, pero no sustituye al archivo editable del programa de diseño electrónico.
- Un fichero Gerber sirve para fabricar una placa, pero no reemplaza el proyecto original con el esquema y el diseño de la PCB.
- Un binario permite cargar un firmware, pero no estudiar ni adaptar su código.
Los formatos finales siguen siendo útiles: abren el proyecto a quien no utiliza el mismo programa y simplifican la fabricación. La práctica razonable es compartir el archivo fuente editable y uno o varios formatos de consulta o intercambio. OSHWA recomienda precisamente conservar los originales y añadir exportaciones accesibles cuando sea posible.
Hardware abierto tampoco significa que todo lo que aparece en una foto lo sea. Puede haber una placa comercial, una librería con otra licencia o una pieza que no se redistribuye. No pasa nada si se explica con claridad. El problema empieza cuando «open source» se usa como pegatina y el lector tiene que jugar a la arqueología digital.
Por qué conviene empezar por una versión concreta
Intentar documentar «el proyecto» como algo que cambia cada semana suele acabar en una mezcla de fotos antiguas, firmware nuevo y una lista de piezas que corresponde a la versión de en medio. Es más útil elegir una revisión que puedas poner sobre la mesa y responder cuatro preguntas:
- ¿Qué hace ahora mismo?
- ¿Qué piezas lleva esta unidad?
- ¿Qué archivos corresponden exactamente con ella?
- ¿Qué se ha probado y qué sigue pendiente?
Esa decisión simplifica todo lo demás. Puedes llamar a la versión v0.1, añadir la fecha o utilizar el sistema que prefieras, pero la misma referencia debe aparecer en el README, la BOM, el firmware y los archivos de diseño. Si después cambias la carcasa o sustituyes un sensor, ya no corriges el pasado a escondidas: preparas otra versión y explicas el cambio.
El paquete mínimo que permite reproducir un proyecto
Una persona debería poder responder estas preguntas sin escribirte un mensaje:
| Parte | Pregunta que debe resolver |
|---|---|
| Descripción | ¿Qué hace el proyecto, en qué estado está y para qué no sirve? |
| Lista de materiales | ¿Qué piezas hacen falta y qué características son críticas? |
| Diseño | ¿Dónde están los archivos editables y las exportaciones? |
| Montaje | ¿En qué orden se construye y qué herramientas requiere? |
| Software | ¿Qué placa, versión, dependencias y configuración utiliza? |
| Pruebas | ¿Cómo se comprobó y qué resultado se considera correcto? |
| Seguridad | ¿Qué riesgos existen y qué controles son necesarios? |
| Licencia y versión | ¿Qué se puede reutilizar y a qué revisión corresponde? |
1. Un README que explique el proyecto antes de soltar archivos
El README es la puerta de entrada. GitHub recomienda explicar qué hace el proyecto, por qué es útil, cómo empezar, dónde pedir ayuda y quién lo mantiene.
Para un proyecto maker conviene añadir:
- Una foto o render del resultado;
- Estado real: idea, prototipo, probado o abandonado;
- Versión documentada;
- Nivel de dificultad y herramientas especiales;
- Límites conocidos;
- Enlace directo a montaje, BOM, archivos y licencia.
«Funciona» aporta poco. «La versión 0.3 enciende el sensor y registra datos, pero todavía no se ha probado en exterior» permite decidir.
2. Una BOM que describa piezas, no una cesta de compra
La lista de materiales o BOM debe indicar cantidad, referencia dentro del diseño y característica necesaria. Un enlace de tienda puede caducar; «convertidor DC-DC de 5 V» puede ser demasiado ambiguo. Es mejor registrar el modelo cuando sea crítico y explicar qué especificación debe cumplir una alternativa.
Para tornillería, conectores y piezas impresas, incluye medidas. Para sensores y placas, indica revisión de hardware. Si un componente recuperado no tiene sustituto directo, explica su procedencia y cómo comprobarlo. Reutilizar con criterio está muy bien; obligar a buscar exactamente el mismo cadáver electrónico ya es otro deporte.
3. Archivos editables y exportaciones útiles
Organiza los archivos por función. Una estructura sencilla puede ser:
cad/: modelos originales y exportaciones STEP o STL;electronics/: esquema, PCB y salidas de fabricación;firmware/: código fuente y configuración;docs/: montaje, uso, pruebas y seguridad;images/: fotos o diagramas necesarios;bom/: lista de materiales en CSV u otro formato fácil de abrir;- raíz del proyecto: README, licencia, historial de cambios y versión.
No es una norma universal. Es una forma de evitar una carpeta llamada final_final_ahora_si_2, ese conocido estándar internacional del caos maker.
4. Instrucciones que incluyan decisiones y no solo pasos
Una secuencia de montaje dice qué hacer. Una buena documentación explica también por qué:
- Por qué esa orientación evita forzar un cable;
- Qué tolerancia necesita una pieza impresa;
- Qué conexión debe verificarse antes de alimentar;
- Qué ajuste depende del material o de la versión de placa;
- Qué parte falló y cómo se corrigió.
El razonamiento de diseño ahorra muchas copias defectuosas. También ayuda a modificar el proyecto sin desmontar una decisión que parecía decorativa, pero en realidad sujetaba medio invento.
Las fotografías deben mostrar los momentos en los que una vista general no basta: polaridad, ruta de cables, orientación de un conector, fijación mecánica y aspecto de una prueba correcta. Borra antes redes Wi-Fi, cuentas, matrículas, ubicaciones y cualquier dato personal.
5. Firmware con un entorno identificable
«Código para ESP32» no concreta lo suficiente. Registra:
- Modelo y revisión de la placa;
- Versión del entorno o framework;
- Librerías y versiones;
- Pines utilizados;
- Parámetros que el usuario debe cambiar;
- Procedimiento de compilación y carga;
- Pesultado esperado al arrancar.
Las credenciales nunca deben estar dentro del repositorio. Incluye un archivo de ejemplo con valores ficticios y explica dónde guardar los secretos localmente. Si el código no se ha compilado desde una instalación limpia, dilo. Publicar un fragmento heredado no lo convierte mágicamente en firmware validado.
6. Pruebas, resultados y fallos conocidos
La documentación gana valor cuando permite comprobar el montaje. Define una prueba pequeña y observable: qué se conecta, en qué condiciones, qué se mide y qué resultado indica que se puede continuar.
Separa siempre:
- Valor de etiqueta;
- Cálculo o estimación;
- Medición real;
- Observación sin instrumento;
- Resultado todavía pendiente.
Si el proyecto consume energía, registra tensión, corriente o energía con las condiciones de prueba. Si utiliza un sensor, explica cómo se calibró. Si una pieza soporta carga, calor o exterior, no conviertas una impresión satisfactoria en una certificación. El fallo conocido es documentación, no una confesión vergonzosa.
Cómo preparar una versión publicable, paso a paso
Aquí es donde la teoría se convierte en trabajo de taller. El orden puede adaptarse, pero cada paso debe dejar un resultado comprobable.
1. Congela el estado que vas a documentar
Pon el montaje terminado sobre la mesa, asigna una versión y haz una fotografía general. Apunta también lo que todavía no hace. Si el prototipo enciende y registra datos, pero no se ha probado en exterior, esa limitación debe aparecer desde el principio.
Resultado del paso: una versión identificada, una imagen de referencia y una descripción honesta de su estado.
2. Haz inventario antes de desmontar nada
Cuenta piezas, anota referencias y relaciona cada componente con el esquema o el montaje. Añade las herramientas que no sean evidentes. Si utilizaste una broca concreta, un programador, una crimpadora o una plantilla, el lector necesita saberlo antes de empezar, no cuando ya tiene medio cacharro abierto.
Resultado del paso: BOM con cantidades y especificaciones críticas, más una lista de herramientas.
3. Reúne los archivos que realmente generaron esa versión
Copia a una carpeta limpia el CAD original, el esquema, el diseño de PCB, el firmware y cualquier plantilla. Después añade exportaciones accesibles: STL o STEP para las piezas, PDF para consultar esquemas y archivos de fabricación cuando correspondan.
Abre cada archivo desde esa copia. Si el diseño solo funciona porque busca una textura, una librería o una ruta que vive en tu ordenador, todavía no está preparado.
Resultado del paso: fuentes editables y exportaciones que se abren sin depender de tu carpeta de trabajo.
4. Reconstruye el orden real del montaje
Escribe las acciones en el orden en que otra persona debe realizarlas: preparar, medir, cortar, fijar, conectar, comprobar y cerrar. Coloca una foto o un diagrama donde una frase no resuelva bien la orientación, la polaridad, la ruta de un cable o la posición de una pieza.
No escondas una corrección útil. Si tuviste que alargar un cable o repetir una pieza porque no cabía, explica el cambio justo en el paso donde evita repetir el fallo.
Resultado del paso: instrucciones accionables con imágenes en los puntos que admiten confusión.
5. Describe el entorno de software
Instala o prepara el entorno indicado, fija versiones de placa y dependencias, compila el firmware y anota el procedimiento. Sustituye claves y contraseñas por valores ficticios en un archivo de ejemplo.
Resultado del paso: código que puede prepararse sin conocer la configuración privada del autor.
6. Ejecuta una prueba con criterio de salida
No basta con «encender y ver si va». Define qué se conecta, qué debe observarse o medirse y qué resultado permite seguir. Si hay varias funciones, prueba primero los subsistemas y después el conjunto.
Resultado del paso: una prueba repetible, con condiciones, resultado y límites conocidos.
7. Asigna licencias y publica una release
Aclara qué licencia corresponde al hardware, al software y a la documentación; indica también qué elementos de terceros no forman parte de la apertura. Finalmente crea una release o paquete con notas de cambio y comprueba que la versión física puede relacionarse con esos archivos.
Resultado del paso: un paquete identificable que otra persona puede descargar sin mezclar revisiones.
Ejemplo resuelto: una estación ambiental de escritorio
Este ejemplo es hipotético. Sirve para ver cómo quedaría la documentación de un proyecto con una placa ESP32-S3, un sensor ambiental y una carcasa impresa en 3D.
| Elemento del paquete | Contenido del ejemplo | Qué permite comprobar |
|---|---|---|
| README | Función, versión, foto, alimentación prevista, estado y límites | Si el proyecto encaja con el uso del lector |
| BOM | Modelo exacto de placa y sensor, tornillería, cable y material de impresión | Si dispone de las piezas correctas o debe buscar alternativas |
| CAD | Archivo original editable, STEP y STL de la misma revisión | Si puede imprimir la pieza o modificarla |
| Electrónica | Diagrama de conexiones, nombres de señales y fotografía del cableado | Si cada conexión coincide con el montaje documentado |
| Firmware | Código, entorno, versiones de librerías, pines y archivo de configuración ficticio | Si puede compilarlo sin recuperar datos privados |
| Montaje | Secuencia desde la carcasa vacía hasta el cierre, con fotos intermedias | Si puede repetir el orden sin forzar piezas o cables |
| Prueba | Arranque, detección del sensor y comprobación de que entrega lecturas; sin afirmar precisión no calibrada | Si el conjunto responde y qué falta validar |
| Release | Paquete v0.1, fecha, cambios conocidos y licencias separadas |
Si todos los archivos pertenecen a la misma versión |
La decisión final es sencilla: si falta el modelo exacto del sensor, la versión de las librerías o una imagen clara del cableado, la estación puede inspirar, pero todavía obliga a adivinar. Esos huecos deben resolverse o declararse antes de llamarla reproducible.
La prueba del banco limpio
Antes de publicar una versión, imagina que el proyecto llega a una mesa vacía. No están tus cajones, tu historial del navegador ni esa librería instalada hace tres años que nadie recuerda.
Haz esta comprobación:
- Descarga solo la versión que vas a compartir, no tu carpeta de trabajo.
- Abre los archivos con las aplicaciones y versiones indicadas.
- Comprueba que la BOM apunta a todas las piezas del diseño.
- Sigue el montaje sin recurrir a notas privadas.
- Compila el firmware en un entorno limpio.
- Ejecuta la prueba documentada.
- Anota cada dato que tuviste que recordar de memoria: eso es documentación que falta.
No hace falta reconstruir físicamente cada versión si el coste no lo permite, pero hay que decir qué partes se verificaron y cuáles no. La prueba también puede hacerla otra persona. De hecho, alguien que no conoce el proyecto detecta supuestos invisibles mucho más rápido.
Cuando el conjunto sea coherente, crea una versión identificable. Las releases de GitHub permiten asociar notas y archivos a un punto concreto del historial. Así, la pieza física marcada como «v0.3» puede relacionarse con sus diseños, firmware y BOM, aunque el repositorio siga avanzando.
Licencias: una para cada tipo de material
Publicar archivos sin licencia no deja claras las condiciones de reutilización. Tampoco conviene pegar la primera licencia que suene abierta a todo el proyecto.
En un montaje pueden convivir:
- Diseños de hardware;
- Firmware o software;
- Documentación, fotografías y diagramas;
- Marcas y logotipos.
Cada parte puede necesitar un tratamiento diferente. CERN mantiene la CERN Open Hardware Licence v2 en tres variantes: permisiva, débilmente recíproca y fuertemente recíproca. La elección depende de si se quiere exigir que ciertas modificaciones se compartan bajo condiciones equivalentes. El software debe utilizar una licencia adecuada para código y la documentación puede llevar otra.
La lista de comprobación de OSHWA recuerda que las restricciones «No Comercial» y «Sin Obras Derivadas» no son compatibles con su definición de hardware abierto. Si quieres reservar esos usos, puedes compartir archivos, pero no deberías presentarlos como open source según esa definición.
Esto no es asesoramiento jurídico. Si hay intención comercial, patentes, contribuciones de terceros o dudas sobre marcas, hace falta revisar el caso concreto antes de elegir.
Seguridad: documentar no vuelve seguro un diseño
Un esquema claro puede reproducir tanto una buena decisión como un error. Si el proyecto toca red eléctrica, baterías de litio, corrientes elevadas, calor, presión, productos químicos, motores o agua, la documentación debe incluir los riesgos y las condiciones exactas.
Como mínimo, señala:
- Tensiones, corrientes, polaridad y límites conocidos;
- Protecciones necesarias y orden de desconexión;
- Química y configuración de las baterías;
- Partes calientes, móviles o sometidas a esfuerzo;
- Herramientas y equipos de protección;
- Pruebas que no se han realizado;
- Usos para los que el diseño no está validado.
Un aviso genérico de «hazlo bajo tu responsabilidad» no sustituye un diseño prudente. Los montajes de alto riesgo necesitan fuentes técnicas fiables y revisión competente antes de ofrecerse como reproducibles.
Errores frecuentes al compartir un proyecto
- Solo hay un vídeo. Enseña el proceso, pero obliga a detener, transcribir y adivinar medidas.
- Solo hay archivos de fabricación. Permiten copiar una versión, pero dificultan modificarla.
- La BOM son enlaces comerciales. Cuando cambian, desaparecen las especificaciones.
- Faltan versiones. El código actual puede no corresponder con la placa o carcasa fotografiada.
- Se ocultan los fallos. La siguiente persona repite exactamente el mismo problema.
- Todo depende del autor. Si cada duda requiere un mensaje privado, el repositorio aún no es autosuficiente.
- No se separan licencias y marcas. Abrir un diseño no autoriza a usar el nombre o logotipo del creador.
Tres niveles para empezar sin atascarse
No hace falta publicar todo a la vez. Se puede avanzar por capas:
- Compartible: README, foto, estado real, BOM básica, archivos fuente, exportaciones, licencia y riesgos principales.
- Reproducible: instrucciones, versiones, entorno de compilación, prueba de funcionamiento y fallos conocidos.
- Colaborativo: historial de cambios, releases, seguimiento de problemas, guía de contribución y decisiones de diseño.
El primer nivel ya exige más que lanzar un ZIP al mundo, pero es alcanzable. El segundo convierte el proyecto en una guía útil. El tercero facilita que otras personas no solo lo copien, sino que lo mejoren.
Checklist final antes de compartir
Antes de pulsar «publicar», comprueba:
- La versión física, el README, la BOM, el CAD y el firmware usan la misma referencia.
- La introducción dice qué hace el proyecto, para qué no sirve y qué encontrará el lector.
- La BOM contiene cantidades y especificaciones críticas, no solo enlaces de compra.
- Los archivos editables están acompañados por formatos fáciles de consultar o fabricar.
- Las instrucciones siguen acciones reales e incluyen imágenes donde hay orientación, conexión o mecanizado.
- El entorno de software y sus dependencias están identificados.
- Las pruebas separan etiqueta, estimación, medición y observación.
- Los fallos conocidos y las partes no verificadas se declaran.
- Los riesgos aparecen antes de la acción que pueden cambiar.
- Hardware, software, documentación y elementos de terceros tienen licencias o condiciones claras.
- La prueba del banco limpio puede completarse sin archivos privados ni explicaciones de memoria.
Si alguna casilla falla, no hace falta ocultar el proyecto hasta alcanzar la perfección. Publica su estado real: «prototipo compartido, pendiente de prueba externa» dice mucho más que una etiqueta de open source que el repositorio todavía no sostiene.
Si quieres seguir con electrónica, la página de Robótica y Electrónica DIY reúne placas, sensores y automatización. Para elegir y describir componentes, consulta Herramientas y materiales. Y si te interesa la parte de tecnología compartida, reparable y útil, la filosofía Solarpunk encaja de forma natural con esta manera de documentar.
Conclusión
Un proyecto maker abierto no es el archivo que sale de la máquina. Es el conjunto de decisiones que permite llegar hasta él, comprobarlo y cambiarlo.
Empieza por una versión concreta. Añade un README honesto, una BOM comprensible, los archivos editables, exportaciones accesibles, instrucciones, software reproducible, pruebas, riesgos y licencias claras. Después aplica la prueba del banco limpio.
Si alguien puede construir tu proyecto sin leerte la mente, la documentación ya está haciendo ingeniería. Y si además puede mejorarlo sin romper lo que no entendía, entonces sí: el cacharro ha empezado a vivir fuera de tu taller.
Fuentes consultadas
- Open Sauce 2026: descripción y fechas del evento y exposiciones, consultadas el 23 de julio de 2026.
- Definición de hardware abierto de OSHWA, consultada el 23 de julio de 2026.
- Buenas prácticas para hardware abierto de OSHWA, consultadas el 23 de julio de 2026.
- FAQ de hardware abierto de OSHWA, consultada el 23 de julio de 2026.
- CERN Open Hardware Licence, consultada el 23 de julio de 2026.
- Documentación de GitHub sobre README y releases, consultada el 23 de julio de 2026.
Otras guías y recursos que te pueden interesar:
Solarpunk: Qué es, Origen y Cómo…
Power bank diy, todo lo que…
Efecto botijo: cómo enfría el agua…
Cómo saber si un panel solar…
