Most tools for preparing bootable media are open-source projects. The phrase gets used loosely, so it is worth being precise about what it describes, because the structure underneath has direct consequences for the person running the software.
The repository
The defining property is published source code. Anyone can read how a tool prepares a drive, what it writes and where. That does not mean everyone reads it — but the option exists, independent researchers do examine widely used projects, and a maintainer cannot quietly include behaviour that nobody is able to see.
A repository also carries history. Every change is a recorded commit with an author and a message, so it is possible to ask when a behaviour appeared and what reasoning accompanied it. That record is often more informative than the documentation.
The licence
A licence is the document stating what you may do with the code. The two broad families behave quite differently.
| Family | Examples | Core condition |
|---|---|---|
| Copyleft | GPL, LGPL, AGPL | Modified versions distributed to others must also ship their source |
| Permissive | MIT, BSD, Apache 2.0 | Reuse with attribution, few further conditions |
Copyleft terms are why a company shipping a device built on GPL code has to make its modifications available. Permissive terms are why the same code can end up inside a closed product with nothing more than a credit line. Neither is more virtuous; they encode different intentions about what should happen downstream.
Open-source terms generally permit anyone to redistribute a copy. That permission says nothing about who maintains the software, who fixed the last defect, or whether a particular copy matches what the maintainers published. Permission to redistribute and being the source of a project are entirely separate things.
The release
A release is a tagged point in the history, packaged for use. A well-run project publishes, alongside it, three things: a changelog saying what changed, checksums for every file, and often a cryptographic signature over the checksum list.
Those three exist to answer three different questions. The changelog answers should I update. The checksum answers is my copy intact. The signature answers is the checksum list itself authentic, which matters because a checksum published next to a tampered file proves nothing at all.
Verifying a file you already have
- Take the expected hash from the publisher's own release notes, not from a page that reproduces it.
- Compute the hash of your copy locally:
certutil -hashfile file SHA256on Windows,shasum -a 256 fileon macOS,sha256sum fileon Linux. - Compare the entire string. Two hashes either match completely or do not match; there is no partial credit, and eyeballing the first six characters is not a check.
- Where a signature over the checksum file is published, verify that too. Without it, you have confirmed only that your copy matches whatever the page you read was claiming.
A mismatch has a mundane explanation far more often than a sinister one — an interrupted transfer, a resumed download, a file that was still being written. But the point of the check is that you do not have to guess which it was.
Reading a project's health
Stars and download counts measure attention, not condition. More useful signals:
| Signal | What to look at |
|---|---|
| Activity | Recent commits and releases, not the date of the first one |
| Issue handling | Whether reports get responses, and what kind |
| Documentation | Whether it describes the current release or one from three versions ago |
| Release discipline | Changelogs, checksums and signatures on every release, not some |
| Continuity | How many people can cut a release if one of them steps away |
| Security handling | Whether there is a stated way to report a vulnerability privately |
The continuity question deserves particular weight for the tools discussed on this site. Several of the most widely used utilities in this space are maintained by one person. That is not a criticism — small projects can be extremely well run — but it is a fact worth knowing before you build a workflow that assumes indefinite maintenance.
Version numbers and what they promise
Many projects follow semantic versioning: the first number changes when compatibility breaks, the second when features are added compatibly, the third for fixes. Where a project states that it follows this scheme, the version number becomes information rather than decoration, and you can judge from it alone whether an update is likely to disturb anything.
Where a project uses date-based versions or its own scheme, the changelog is the only reliable guide. Either way, an update that fixes a defect you are not experiencing is rarely urgent; an update that fixes a security issue is.
Contributing without writing code
Small projects are usually short of everything except code. A precise bug report — exact hardware, firmware version, image, and what you observed against what you expected — is genuinely valuable, and rarer than you would think. So is testing a release candidate, correcting documentation that no longer matches reality, or answering in a forum the question you struggled with last month.