BIThesis: LaTeX thesis templates for Beijing Institute of Technology, packaged on CTAN

The problem it solves: a thesis that already passes the formatting check

University thesis templates are a strange product. The formatting rules are published, strict, and enforced by the academic affairs office before the document is even read, and every year a new cohort has to re-derive margins, heading styles, the cover layout and the bibliography format from scratch.

BIThesis is a LaTeX template set aimed at the undergraduate graduation design thesis and the graduate degree thesis at Beijing Institute of Technology, and it also covers other documents students write during their studies, such as literature reviews and lab reports. It describes itself as unofficial, and the project explains the word in a footnote: the project is not maintained directly by the university, but it is recognised by the school.

That recognition is specific and worth noting. The documentation states that the project has the endorsement and support of the university's academic affairs office, its graduate school and its school of computer science.

The features list is short and concrete, which is a good sign for a template project. The output meets the school's requirements for graduation theses. Content and style are separated, so all configuration is managed centrally. There is a one-click export of the blind review format, the anonymised version examiners receive. The underline on cover information adjusts its own length to the text. And the package ships several templates: the graduate thesis, the undergraduate thesis, the undergraduate thesis for an entirely English taught major, a foreign language translation of the undergraduate thesis, a lab report template and a slide template.

The class files and the content-style split behind the config keys

The repository is a dtx style LaTeX package project, which is the convention for something distributed on CTAN. The top-level entries show the working parts: a src/ directory holding the class sources, a templates/ directory with one directory per template, a handbook/ directory for the manuals, a tests/ directory, a scripts/ directory, assets/, a justfile as the task runner, a cliff.toml used to generate the changelog from commit messages, a CITATION.cff file, an .explcheckrc configuration, DEVELOPMENT.md and contributing guides in both Chinese and English, and CHANGELOG.md.

Two class files are the core of the package. The build copies src/bithesis.cls into every template directory along with a latexmkrc file:

    {{ fd_thesis_templates_exec }} cp {src/bithesis.cls,assets/latexmkrc}

and the same class file is copied into the test directories, so the tests exercise the same class the students use. A second class, src/bitreport.cls, exists for the report template, and the build copies that one to its own target directory as well.

The separation of content and style is the design decision that makes the template usable. A student edits configuration keys and writes chapters, and never touches the class file. The repository topics name xelatex as the engine, and the badges show a latexmk badge for the compiler and a CTAN badge for the package version, so the toolchain expectations are declared rather than implied.

Getting a template: download the package, do not clone the repository

The user instructions are unusually direct about this. There are three steps: install or upgrade a LaTeX distribution, download the published template package, and start writing. The download step carries an explicit warning that cloning the repository is unnecessary.

That instruction only makes sense once you know what the repository is for. The repository is the development tree, with the class sources, the tests, the build tooling and the CI configuration. The thing a student wants is a ready made package, and the project publishes that separately as a release artefact, with the download instructions in the wiki.

There is also a hosted route. The documentation points at Overleaf and TeXPage templates, so a student can open the document in a browser based editor and never install a LaTeX distribution at all. That is the fastest path to a first page, and it removes the toolchain question entirely for anyone whose local LaTeX install is missing a Chinese font package or a recent class.

For guidance there are two handbooks, an undergraduate one and a graduate one, published as PDF on the CTAN mirrors, plus a detailed configuration manual distributed as bithesis.pdf. The wiki is the main documentation, and there is an English version of the README in the repository for readers who do not work in Chinese.

The justfile: how the class files and handbooks are built

The build is driven by a justfile, a command runner, and it needs a Unix shell. The file sets the shell explicitly because brace expansion is used:

set shell := ["bash", "-uc"]

The file notes that the commands are only guaranteed to run on Linux or macOS, and that Windows users should use Git Bash or Cygwin, or consider porting the script to PowerShell. That is a real constraint for a large student body on Windows.

The recipes are organised by group. A default recipe lists what is available, the clean recipe runs git clean in interactive mode, and a private make recipe delegates to the Makefile in src/ with undefined variables as warnings and built-in rules disabled:

    make --warn-undefined-variables --no-builtin-rules {{ ARGS }}

The build group has three entries. The doc recipe produces bithesis.pdf, the cls recipe builds the class files, and the handbooks recipe runs latexmk twice in the handbook directory, once with the GRADUATE variable set, saving the output as graduate-handbook.pdf, and once without it for undergraduate-handbook.pdf:

    GRADUATE=true latexmk -gt

    latexmk -gt

A copy recipe distributes the built class file and the latexmkrc into every template directory and into the test directories, which is what keeps the tests honest.

The licence question for a class file: LPPL-1.3c

BIThesis is released under the LaTeX Project Public License, and the licence recorded for the repository is LPPL-1.3c. That is a deliberate choice for a LaTeX package and it differs from the MIT or GPL terms a typical application repository would carry.

The LPPL exists so that a document class can be modified and redistributed without the modifications being forced back onto the original author, which is what allows a class file to be improved by a community and still be distributed under the same terms. The practical consequence for a user is that you can take the class file, change it, and hand the modified version to your lab or your department without asking permission, provided you keep the licence and follow its terms. It is not a licence to treat the package as proprietary.

Distribution goes through CTAN, which is the standard archive for LaTeX packages, and the repository carries a CTAN version badge. A CTAN package is a compressed bundle with its own documentation and metadata, and the release workflow in this repository is what puts a version there.

Two details of the governance are visible in the documentation. The project states that it is recruiting maintainers, and asks for people with LaTeX experience, Git experience and an interest in helping. And it asks users to cite the repository, with a cite-this-repository panel and a CITATION.cff file so that citation metadata can be picked up automatically. For an unofficial template, tracking how it is used and by whom is a sensible way to keep the link to the university's actual requirements intact.

Where the release tag lags the repository, and who this is for

The maintenance picture has one wrinkle that a reader should notice. The repository is not archived and the last push was on 2026-10-03, which is recent work. The published releases are v3.8.12 on 2026-05-28, v3.8.11 on 2026-04-30 and v3.8.10 on 2026-04-21. So the public release line is roughly four months behind the tip of the main branch.

That gap is normal for a package that has to be tested, built and uploaded to CTAN, but it has a concrete effect: a student who downloads the latest release is not running the same code as a student who clones the repository and builds it. For most users the release is the right choice, because it is the tested artefact and the documentation describes it. For anyone who needs a fix that has landed since May, the build route is the only way to get it, and that means running the justfile with a Unix shell.

The scope limit is the other thing to be clear about. These templates encode one university's requirements, so they are the right tool for students at that institution and close to useless elsewhere, where a different set of rules applies. Even inside the institution, the documentation points readers back to the university's own announcements for the reference standards, which is the right instinct: a template can lag a rule change, and the announcement is what governs.

For everyone else, the pattern is the interesting part rather than the artefact. Separating content from style, encoding the institutional rules in a class file, and shipping the class on CTAN under the LPPL is a structure that other universities have copied, and the acknowledgements in the documentation name the other templates that informed the work here.

Editorial conclusion

Adopt BIThesis if you are a student at Beijing Institute of Technology writing a thesis, a literature review, a lab report or slides, and you want the formatting rules already encoded in a class file you can configure in one place. Do not adopt it for a thesis at another institution, since the layout targets one university's requirements. Before you start, download the published template package rather than the repository, and check the release you get against the current requirements, because the most recent public release is v3.8.12 from 2026-05-28 while the repository has moved on since its last push on 2026-10-03.

Frequently asked questions

Official sources

1. BITNP/BIThesis on GitHub
2. License: LPPL-1.3c
3. Project website
4. README
5. Releases