Apollo-11 is a transcription archive, and its lint glob misses the Translations directory
GitHub describes it as Original Apollo 11 Guidance Computer (AGC) source code for the command and lunar modules.. The repository metadata lists Assembly as its primary language. The metadata lists the NOASSERTION license. This article stays within the project description and details documented in the GitHub repository README.
At a glance
- What is it?
- Apollo-11 holds the digitized Apollo Guidance Computer listings for the command module and the lunar module, transcribed from hardcopy scans at the MIT Museum. It is an archive rather than a buildable project, its contribution model is proofreading against those scans, and its one automated check has a case-sensitivity bug.
- Who is it for?
- Apollo-11 earns a place as a provenance-grade transcription, where each listing names its own revision and the contribution model is proofreading against the original scans. It is not a buildable artifact: the repository ships no compiler and delegates assembling to Virtual AGC, and its only dependency is a markdown linter.
- Can I use it commercially?
- Check first. The repository uses a licence we do not classify automatically, so read its LICENSE file before any commercial use.
- Is it still maintained?
- Yes. The repository last received commits 77 days ago.
- What is it written in?
- Mainly Assembly, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 29, 2026, and from our analysis. They are not legal advice.
Editorial analysis
The lint glob says translations/ but the directory is Translations/
The repository has exactly one automated check, and it has a case bug. The lint script is:
markdownlint-cli2 *.md translations/*.md Comanche055/*.md Luminary099/*.md --config .markdownlint.ymlThe glob names translations in lower case. The directory at the top level of the repository is Translations, with a capital T. What this cannot do is lint the translated readmes on a case-sensitive filesystem, which is what a Linux runner or container gives you. The shell expands translations/*.md against a name that does not exist, the glob stays literal, markdownlint-cli2 receives a path with a wildcard in it, and the one file this repository is most likely to receive is a translated README. The same script also reaches into Comanche055 and Luminary099 for markdown, while the artifacts those directories are known to hold are .agc assembly listings, so the coverage is aimed wider than the content.
The only tool in the repository is a markdown linter
There is no build system here, and the package manifest is candid about it. The dependencies object is empty, and the only entry in devDependencies is markdownlint-cli2 at 0.16.0, alongside a lint script and a lint:fix script that runs the same globs with a fix flag. There is a bun.lockb at the root, so even the linting step assumes a JavaScript runtime and a lockfile. What this cannot do is compile the source you came for. The readme does not offer a build; it says that if you are interested in compiling the original source code, you should check out Virtual AGC, which is a separate project. So the repository's contribution to running this code is a pointer. Read it as a transcription with a documentation check attached, because that is what the tooling supports, and go elsewhere to assemble anything.
The license metadata says NOASSERTION while the attribution says public domain
There is a gap between how the project describes its own rights and how a tool reads them. The license recorded for the repository is NOASSERTION, which is the value a detector emits when it cannot classify something. A LICENSE.md file does sit at the root, and the attribution table in the readme states Copyright as Public domain, naming Comanche055 and Luminary099 as parts of the source for Colossus 2A and Luminary 1A. What this cannot do is satisfy an automated check. A license scanner, a dependency audit, or a corporate compliance review will read NOASSERTION and stop there rather than open a Markdown file to discover the public domain claim. Anyone shipping this code inside a process that gates on detected licenses has to resolve it by hand, and should treat the public domain statement as something to verify against LICENSE.md rather than something the tooling confirmed.
Contributing means proofreading against scans, not improving code
The contribution model is narrow on purpose, and the readme states it directly. Pull requests are welcome for any issues identified between the transcriptions in the repository and the original source scans for Luminary 099 and Comanche 055, and for any files that may have been missed. The project describes its goal as being a repository for the original Apollo 11 source code, and the readme asks that you read CONTRIBUTING.md before opening a pull request. What this cannot do is accept modernization. A patch that ports the assembly, refactors it, renames symbols, or adds tooling is not a correction against a scan, so it falls outside what the project asks for. The result is a codebase frozen in 1969 by design, and a reader should approach it as a historical document rather than as a starting point for something new.
Each listing records its own revision and assembly timestamp
The source carries its own provenance inside the text, which is unusual and useful. The command module listing is identified as revision 055 of AGC program Comanche, assembled by NASA, with the stamp 2021113-051. 10:28 APR. 1, 1969. The lunar module listing is revision 001 of AGC program LMY99, stamped 2021112-061. 16:27 JUL. 14, 1969. The assembler named in the attribution table is yaYUL, not the original NASA tooling, which tells you the listings were re-assembled by a modern tool to produce them. What this cannot do is remove the ambiguity of which transcription you hold. A revision number and a date let you say precisely which build a given file came from, and they let a contributor check a disputed character against a scan of that specific revision instead of against a vague notion of the program.
Two programs, two GitHub milestones, and no releases
Progress is tracked through GitHub milestones rather than through a release history. The readme carries two badges, one labelled Comanche and one labelled Luminary, each pointing at its own milestone on the repository, and the project publishes a public roadmap separately. The repository has no GitHub releases, so there is no version to install and no tag to pin. What this cannot do is give you a way to tell which transcription is complete. A milestone is a progress marker maintained by hand, and with no tagged snapshots you cannot diff two points in the transcription work, which is awkward for a project whose stated purpose is to converge on an accurate, complete copy. A reader tracking the effort should watch the milestones, and a reader building something should assume they are reading whatever state the default branch happens to be in.
The chain of custody ends at a hardcopy, not at a master
The repository is explicit about where its contents came from, and the trail is worth reading because it explains what the code can be checked against. The source was transcribed or otherwise adapted from digitized images of a hardcopy from the MIT Museum, with the digitization performed by Paul Fjeld and arranged for by Deborah Douglas. On the software side, CONTRACT_AND_APPROVALS.agc in the command module directory records that the program is intended for use in the command module as specified in report R-577, prepared under DSR project 55-23870, sponsored by the Manned Spacecraft Center of NASA through contract NAS 9-4065 with the Instrumentation Laboratory at MIT in Cambridge, Massachusetts. It was submitted by Margaret H. Hamilton as Colossus Programming Leader and approved by six officials, all dated 28 Mar 69. What this cannot do is make the transcription self-validating. Every disputed character is settled against a scan of one physical hardcopy, so accuracy depends on that copy being faithful, and there is no second independent source in the repository to cross-check it against.
Editorial conclusion
Apollo-11 earns a place as a provenance-grade transcription, where each listing names its own revision and the contribution model is proofreading against the original scans. It is not a buildable artifact: the repository ships no compiler and delegates assembling to Virtual AGC, and its only dependency is a markdown linter. Before you rely on it, read LICENSE.md yourself, since the license metadata resolves to NOASSERTION, and treat the absence of modernization as a design decision rather than an oversight.
Frequently asked questions
apollo 11 software code
The Apollo-11 repository holds the original Apollo Guidance Computer source for the command module as Comanche055, part of Colossus 2A, and for the lunar module as Luminary099, part of Luminary 1A. Both were transcribed from digitized images of a hardcopy held at the MIT Museum.
Can I compile the Apollo-11 source code from this repository?
Not from this repository alone. The readme says that if you are interested in compiling the original source code you should check out Virtual AGC, and the repository itself ships no build script and no compiler. Its only dependency is markdownlint-cli2, used for a lint script.
What license is the Apollo-11 source code under?
The attribution table in the readme states Copyright as Public domain, and a LICENSE.md file sits at the root of the repository. The license metadata for the repository itself reads NOASSERTION, so automated license detection does not resolve it without reading the file.
What kind of changes does Apollo-11 accept?
Pull requests are welcome for issues identified between the transcriptions in the repository and the original source scans for Luminary 099 and Comanche 055, and for any files that may have been missed. The readme asks that you read CONTRIBUTING.md before opening a pull request.