Author: Juan Galt
Compiled by: AididiaoJP, Foresight News
The debate between open source and closed source has persisted for over a decade in Bitcoin and the broader crypto industry. Bitcoin proponents have long argued that the global financial infrastructure must be built publicly, where transparency and auditability are non-negotiable principles when real money is at stake. However, the application layer and traditional finance have often not been convinced.
The recent theft involving the Coldcard hardware wallet has thrust the true meaning of "open source" into the spotlight. Users lost over $100 million worth of Bitcoin (more than 1500 BTC). This incident reveals an awkward reality: even many die-hard Bitcoin users have a rather limited understanding of the philosophy of open source software development and its failure modes.
Principles and Terminology
The terminology surrounding open source is not simple. Free and Open Source Software (FOSS) and Free/Libre and Open Source Software (FLOSS) refer to software that complies with formal definitions of user freedom.
The Free Software Foundation (FSF) defines "free software" with four essential freedoms:
- Freedom 0: The freedom to run the program as you wish, for any purpose.
- Freedom 1: The freedom to study how the program works, and change it so it does your computing as you wish (access to the source code is a precondition for this).
- Freedom 2: The freedom to redistribute copies so you can help others.
- Freedom 3: The freedom to distribute copies of your modified versions to others (access to the source code is a precondition for this).
The FSF emphasizes that "free" refers to freedom, not price. The common mantra among open source advocates is: "'Free' as in 'free speech', not 'free beer.'"
The Open Source Initiative's (OSI) Open Source Definition lists ten additional practical criteria, including: free redistribution without royalties, the source code must be provided in a form suitable for modification, allowance for creating and distributing derivative works, and no discrimination against persons, groups, or fields of endeavor (including commercial use). Only licenses that fully satisfy all ten criteria can be formally termed "open source."
"Source available" or "source viewable" is a different matter. Code may be publicly readable, but the license may restrict commercial sales rights. Coldcard's firmware is an example—it uses the MIT license but with an additional license condition. This clause explicitly prohibits "selling" the software, defined as providing it to a third party for a fee or other consideration, where the value of the product or service is entirely or substantially derived from the software itself. In other words, Coldcard firmware cannot be used for commercial purposes.
The license condition states plainly: "Is this Open Source? No." It notes that with this added clause, the software meets many elements of the open source definition but not all, and thus should not be called open source.
These distinctions are important. Making source code public merely creates the possibility of inspection; granting all the rights in the free software or open source definitions is what makes FOSS. However, sporting an "open source" badge is not the end goal itself. Critics argue that the commercial freedom within open source unlocks the incentive for third parties to test and review code, incentives which might otherwise not exist.
The four freedoms are the philosophical core of open source. In practice, it's built on an economic assumption: that enough motivated people will actually review the code. When this assumption fails, the system plays out a classic "tragedy of the commons"—a shared resource is overused or neglected due to individual short-term self-interest, leading to overall degradation. Everyone has an incentive to take a little more (or contribute a little less), and the collective resource suffers. Sometimes incentives are aligned, sometimes they are not at all.
A Bitcoin developer put it more bluntly: "Using test mocks and stubs with open source code is irresponsible and shortsighted. Open source code is considered safe because anyone can verify it. If you're not willing to do the bare minimum testing for the functionality you actually depend on, you're being a parasite."
Therefore, open source itself does not automatically create security; it only creates the possibility of verification. Whether verification actually occurs depends on incentives, skill, and attention. Historically, good FOSS becomes more robust as vulnerabilities are found, disclosed, and fixed, forming a solid foundation for others to build upon. The Linux kernel is a prime example—it powers the vast majority of the world's servers, cloud infrastructure, Android devices, and embedded systems, making it one of the most widely deployed pieces of software ever.
Bitcoin Core: A Real-World Model of Open Source
Bitcoin Core, as the reference implementation of Bitcoin, is another classic case of large-scale, purely open-source software operating in reality. It uses the MIT license, and its development process is designed to be public from the ground up.
Anyone can submit a pull request. Code review is the primary filtering mechanism and a recommended entry path for newcomers. Reviewers use formal terminology: Concept ACK (agree with the goal), Approach ACK (agree with the goal and method), ACK with a specific commit hash (tested and approved for merging), or NACK (disagree, with technical reasoning required).
Maintainers weigh contributor consensus against technical merit before merging. The bar is higher for consensus-critical changes, typically requiring a Bitcoin Improvement Proposal (BIP) and years of thorough discussion on the bitcoin-dev mailing list and IRC.
There is no privileged class of "Bitcoin Core developers." Trust is earned by demonstrating competence over the long term. Maintainers exist only out of practical necessity—to audit merged code, manage releases, perform basic vetting—but the output is pure open-source code that anyone can inspect, compile, fork, or run. Those whose code is merged into Bitcoin Core are typically referred to as Bitcoin Core contributors.
Long-time open-source Bitcoin developer Calle recently summarized: "People who think Core is some kind of shadowy, opaque operation are either too lazy or too stupid to bother looking for themselves. Everything they do is public, anyone can participate, and the end product is purely open-source code."
Funding for this work primarily comes from non-profit and grant structures, such as Brink, OpenSats, Spiral, etc., rather than traditional corporate product roadmaps. Technical discussions happen on the public bitcoin-dev mailing list and the #bitcoin-core-dev IRC channel on Libera Chat. Proposals are scrutinized rigorously before and after pull request submission. Issues and pull requests on GitHub often have comment histories spanning a decade. The result is a development culture that prioritizes correctness and auditability over speed or commercial feature iteration.
The Economics of Open Source
The majority of users of open-source or source-available software never read the code themselves. They rely on the assumption that "someone else is reviewing." In the Coldcard case, a critical entropy flaw lay dormant in the public firmware for roughly five years before it was exploited and thus discovered.
This bug was introduced during a major rewrite in 2021. That rewrite also removed the remaining GPL code derived from Trezor. Trezor, the first hardware wallet, is currently the second-largest in the self-custody industry. The core problematic library was libngu, which replaced trezor-crypto but received minimal external review—after over five years of production use, it had only 7 stars and fewer than 20 forks. In contrast, trezor-crypto has 512 stars and 212 forks, while the more modern trezor-firmware has 793 forks and 1800 stars. Source availability alone did not bring the significant scrutiny needed. Critics argue this is because other funded, capable for-profit companies were restricted from using it, lacking commercial incentive. Note: Star and Fork are core metrics on GitHub measuring a project's popularity and activity. Star means favoriting/liking; Fork means copying the repository.
The stakes in the Bitcoin space are far higher than in most software domains. A critical flaw can be directly converted into liquid funds on the open market. The first half of the stolen Coldcard funds remains in a few addresses; the hacker might be caught one day, but subsequent copycats were more cautious, and some have successfully stolen more Bitcoin and laundered it (according to Galaxy Research, total losses reached at least 1700 BTC). Bitcoin's censorship resistance and immutable transactions provide both a powerful incentive for attackers and a Darwinian filter: only projects that continuously attract high-quality review, and whose users and companies take protective measures seriously, can survive in the long run.
License choice shapes these incentives. A pure open-source license maximizes the pool of potential reviewers and forks. A restricted "source-available" license, while reducing commercial "free-riding," also shrinks the group of people who simultaneously have the legal right and the economic motive to invest deep attention. Consequently, the burden of code review falls back on the company itself, making it somewhat closer to closed-source than open-source.
How AI is Changing Open-Source and Closed-Source Development
Artificial intelligence is altering the balance between open-source and closed-source.
Following the Coldcard incident, a volunteer project called Bitcoin Red Team, led by developers like Calle and Rob Hamilton of AnchorWatch and supported by OpenSats, used cutting-edge AI models to scan hundreds of open-source Bitcoin codebases. In an intensive period, the team submitted thousands of findings, with dozens rated as critical or high severity, covering hundreds of projects. Responsible disclosure was given to maintainers first, then made public. This demonstrated that systematic AI-assisted review can find vulnerabilities at a scale and speed previously unattainable for human teams.
Notably, Bitcoin Red Team found that Chinese open-source weight models were far more reliable than closed-source American models. Even American models with web access and top-tier permissions refused to answer Bitcoin Red Team's queries, which American developers found regrettable.
Meanwhile, the flood of AI-generated code is creating new "denial-of-service" pressure on FOSS maintainers. Reviewing AI output often takes more time than generating it. Some open-source projects outside Bitcoin have begun restricting their issue trackers or enacting strict anti-AI contribution rules, just to maintain basic operations.
On the closed-source side, the traditional advantage of "security through obscurity" is being eroded. Modern AI models can read, deobfuscate, probe endpoints, and reason about code at incredible speeds. The practical difference between open-source and closed-source now mainly boils down to backend code that never ships. Closed-source code ultimately relies on the quality of professional audits, the speed of patch deployment, and incentive structures that keep those with access motivated to review seriously.
Bitcoin and the broader crypto industry are placing unusual pressure on free and open-source software. Real monetary value, adversarial economics, and now AI-scale analysis are forcing software models to evolve. Returning to pre-digital analog systems is hardly an option for the infrastructure underpinning modern society. Only projects that are thoroughly audited stand a chance of surviving under the combined pressure of AI-assisted hackers and digital-first finance.
