This talk will present a historical narrative of the background behind how the NeTV + Milkymist inspire the HDMI2USB then helped the NeTV2 projects and how they all became interlinked through events like Congress! From the study of this history, we will attempt to distill a few core lessons learned that can hopefully be applied to other open hardware projects.
Open hardware projects tend to evolve differently from open software projects. Even though it’s very easy to fork an open software project, pull requests and merges help ensure the main branch of a project continues to improve. Furthermore, open software projects tend to evolve along with their tools, as evidenced by the concurrent maturation of Servo and Rust, or Linux and Git. In contrast, open hardware projects tend to fork and then fracture the community as they gain commercial success and go closed, as evidenced in the evolution of the 3D printer and drone communities. There are also few examples of hardware projects that co-evolve with their tools.
This talk will present a historical narrative of the background behind each of these projects and how they became interlinked. From the study of this history, we will attempt to distill a few core lessons learned that can hopefully be applied to other open hardware projects.
One important lesson is that open anything takes time and patience, and so the project itself needs to be in a space where it can move at an appropriate pace to grow a healthy community while maintaining relevance against potentially better-funded closed-source options.
Another lesson is the importance of crowdfunding as a mechanism to marshall community around a given release, as opposed to relying upon sources of financing that expect direct returns on investment (such as venture capital or loans).
A final example of a lesson we will discuss is the importance of picking the right tools to co-evolve with the project. While many open source options alternatives exist to closed-source tools, it’s problematic if the design tools somehow limit the hardware implementation or introduces flaws in the design itself -- and hardware, unlike software, cannot be patched. Migen/LiteX are front-end tooling for describing FPGA designs (“gateware”), and their output being a bitstream means it can be in the hardware space while enjoying the privilege of easy patching and updates. Furthermore, Migen/LiteX offer critical features and performance metrics unavailable in the closed-source alternatives, meaning that these are not simply design tools, they are also core to enabling the competitiveness of the hardware itself.