At Great Scott Gadgets, we do not accept contributions that are assisted by or generated using LLMs. That is because we believe open source is about more than producing code. It is a community practice built around participation, shared understanding, public learning, and stewardship of a commons. Projects like HackRF and Cynthion exist and have longevity because communities have formed around them over many years. People have contributed code, reviewed pull requests, filed issues, improved documentation, answered questions, taught workshops, written tutorials, produced videos, and helped each other learn. The community IS the project. The open source code, designs, and even the hardware we sell are just the artifacts it produces.
Folks who participate in open source communities and contribute to projects not only help the projects grow, but can also gain domain knowledge, learn best practices, prove skills that employers find valuable, and develop relationships. In fact, some of the people who contributed to Great Scott Gadgets’ projects eventually joined our team. Dominic Spill began as a collaborator on Ubertooth and later worked with Great Scott Gadgets for many years. Mike Walters contributed to the HackRF project long before we hired him because it was open and accessible from the beginning. Those opportunities existed because of the collaboration that was happening in public. LLMs, by contrast, allow people to obtain code and explanations without necessarily participating in the conversations, review processes, and collaborative learning that help sustain those projects.
Advocates of vibe coding tools often argue that they lower barriers to entry by enabling users to do things they otherwise couldn’t, but whether they actually do so is debatable. In many cases, they simply replace skill barriers with dependence on proprietary services, while users of these services often trade full community participation and all its benefits for interactions mediated by LLMs trained on community-built open source projects. Our communities are already noticing a shift away from collaborative stewardship and toward transactional interactions with projects, and we’re seeing open source project maintainers left to deal with increasing volumes of generated code. When people interact privately with systems trained on communities, it gradually weakens the shared understanding of how projects work and redistributes the burden more heavily onto (often underfunded) project owners. Open source projects don’t need more code for its own sake; they need contributors who can understand the code they submit and help maintain their work over time.
We have seen increasing pressure on maintainers to simply accept that LLM-generated development is inevitable, and we reject that framing. We reject it because the thing we value most about open source is community. We want you to participate, even if you are new. We want you to read the code and documentation, ask your questions publicly, and help others. We want contributors to develop understanding through engagement with projects and with each other.
There are also project licensing considerations at play when we think about accepting contributions. Questions of authorship, attribution, and provenance are relevant to the licenses we use, such as BSD and CERN-OHL, and LLM-generated contributions can make those questions significantly fuzzier. But for us, the potential legal issues (like unresolved questions surrounding AI-generated content and copyright) are secondary to the trust issue. People and organizations use open source hardware and software because they want systems they can inspect, reproduce, modify, and depend on long-term. Open source ecosystems are strongest when people understand where code, designs, and documentation come from and who is responsible for them. When authorship and derivation become unclear, that trust can erode.
We also have serious concerns about other aspects of LLM systems, including but not limited to the environmental costs of data centers, the concentration of power in the hands of a small number of big tech companies, the treatment of workers whose labor is used to train them, and the risk of de-skilling. We don’t use LLMs internally, either. Those concerns are important, but the focus of this post is community. Open source projects succeed because people learn and create best together, and we do not want to see community-built ecosystems replaced by extractive development environments optimized for output volume rather than shared understanding. If it’s worth doing, it’s worth our full participation.