DrWatson.jl: a project assistant for Julia simulations, with a licence label that needs reading

A project assistant, not a simulation library

DrWatson presents itself with a joke in the title, described in the repository as the perfect sidekick to your scientific inquiries, and the package description says it is a scientific project assistant software. The distinction matters, because the interesting question about a package like this is whether it computes anything. On the evidence of the README, it does not. Nothing in the description mentions solvers, integrators, model kernels or numerical routines.

What it does instead is hold the scaffolding around an experiment. The README enumerates the responsibilities: simulations themselves, the parameters those simulations run with, where files are saved, experimental data, scripts, existing simulations, the project source code, and establishing reproducibility. That list reads like the inventory of a research group's shared drive, which is exactly the problem the package targets. Scientific code tends to accumulate in a directory where output files land next to the scripts that produced them, parameters are edited in place, and the exact configuration behind a figure cannot be recovered six months later.

The audience is therefore researchers and students who write Julia code for simulation studies rather than people building numerical libraries. The repository topics support that reading, listing science, science-research, simulations, project-management, setup-tool, project-assistant and hacktoberfest. The hacktoberfest tag in particular suggests the package is treated as a friendly entry point for first-time open source contributions, which tells you something about its intended user base.

It also tells you it is not aimed at production services. Nothing in the description suggests a server, a queue or a multi-user workflow.

The scope the README names, and where it stops naming things

It is worth being explicit about the boundary of what is documented here. The README gives the package description and a short list of concerns. It does not list function names, does not show a code example of a simulation running, and does not describe a directory layout that the package creates. The documentation site is where those details live, with a stable version at the DrWatson.jl documentation pages and a development version referenced from the README.

That is a deliberate and reasonable choice for a package whose API surface is the point. A README that tried to enumerate every helper would be noise, and the package is judged on how it makes a project directory behave rather than on how it computes. But it also means a reader has to leave the repository to answer basic questions, and the README does not establish, for example, how parameters are declared, how output paths are resolved, or how an existing run is recorded.

The repository layout gives a partial answer to the question of how the package is built. There is a `src/` directory for the implementation, a `test/` directory, a `docs/` directory holding the documentation sources, and a `paper/` directory that corresponds to the Journal of Open Source Software paper the README asks you to cite. `Project.toml` holds the package metadata, `CHANGELOG.md` the release history, `CITATION.bib` a BibTeX entry, and `CONTRIBUTING.md` the contribution process. The `.github/` directory holds the workflow definitions, and the CI badge in the README points at a workflow there.

So the package is a normal Julia package with tests and documentation in the repository, and the parts you will interact with are described on the site rather than in the README.

Adding the package from the Pkg prompt

Installation is a single step inside a Julia session. The README gives the command directly:

] add DrWatson

The `]` opens the Pkg prompt in the Julia REPL, and the package name is `DrWatson`. There is no separate build step, no binary to fetch, and no system dependency to satisfy, which is the ordinary shape for a pure Julia package.

For a first use, the README's next instruction is to read the documentation page, pointing at the development documentation for the latest version. The stable documentation is separately hosted at the DrWatson.jl stable pages, which is the one to read if you want behaviour that matches the most recent tagged release rather than the development branch.

Two details are easy to miss and both matter in practice. First, the package is on the General registry, so `] add DrWatson` pulls the registered version, and the version you get is the latest registered one rather than whatever the repository main branch currently holds. The README's own documentation link points at the development documentation, so the two can disagree. Second, because the project name contains a full stop in the GitHub URL but not in the package name, adding it is by the package name `DrWatson` with no suffix, and it should be installed through the Pkg prompt rather than by cloning the repository into your environment.

The CI badge and the codecov badge both point at the master branch in their URLs, while the default branch of the repository is listed as main, which is a small inconsistency in the badge links rather than in the package itself.

The licence is stated two different ways

There is a genuine discrepancy here that you should resolve by reading the LICENSE file rather than trusting a badge.

The README states in its disclaimer paragraph that the package is offered for free, without any monetary charge, and is provided with an MIT license. The repository licence field, however, is recorded as a custom licence that GitHub cannot classify, so the classifier shows the licence as other rather than MIT. The LICENSE file sits at the root of the repository alongside the README, and the file itself is the authoritative statement.

The most likely explanation is the standard pattern for Julia packages that were relicensed from MIT to the MIT license plus a small attribution or trademark clause, since the project description and the disclaimer share a distinctive name. GitHub's classifier only recognises a fixed list of licence identifiers, so a hybrid licence lands in the other bucket. Still, the practical point stands: the README says MIT and the metadata says something the tooling could not read, so anyone redistributing the package or shipping it inside a larger codebase should copy the LICENSE file text and satisfy whatever it actually requires.

The disclaimer in the README is also doing a second job. It makes clear that the package has no relationship with the proprietary Dr. Watson debugger implemented by Microsoft, which matters for search results and for anyone typing the name into a package manager. The naming overlap is genuine enough that the authors felt the need to say so explicitly, and they say it twice, in the description and in the disclaimer.

Citing the package when a paper comes out of the work

The README asks for something specific: if you have used DrWatson in a scientific project that led to a publication, please cite the associated paper. The citation is a Journal of Open Source Software article with the DOI 10.21105/joss.02673, and the README prints the BibTeX entry for it. The repository also carries a `CITATION.bib` file and a `paper/` directory, which is the standard arrangement for a package with a JOSS paper.

This is a small request that carries more weight than it might appear. Journals increasingly ask for a software citation alongside the methods section, and a package that ships a DOI, a BibTeX entry and a `CITATION.bib` has done the work of making that easy. The DOI resolves independently of the repository, so the citation survives a fork or a mirror.

The paper was published in 2020, and the JOSS volume and issue numbers given in the entry are volume 5, number 54, pages 2673. If you cite it, cite the paper rather than the repository, and cite the version of the package you actually used, since the paper describes the package at the time it was reviewed.

For a project with this kind of citation culture, the CHANGELOG.md in the repository becomes the record of which behaviour changed between versions, and it is the file to check when a paper or a collaborator asks what changed between two runs.

Release history: steady development, but the last tag is over a year old

The last push to the repository was on 2026-09-28, so the source is being changed. The tagged releases tell a different story. The listed releases are v2.19.1 on 2025-08-25, v2.19.0 on 2025-07-24, and v2.18.0 on 2024-09-26. So the most recent registered version predates the most recent commit by more than a year.

That gap is normal for a Julia package and not a warning sign. Julia's package workflow means that `] add DrWatson` installs the latest registered tag, while `main` may hold months of unreleased commits, and the two documentation links in the README make that split visible: the stable pages describe the released behaviour, the development pages describe what is on main right now. If you are reproducing a published result, pin to the release the paper used rather than tracking main.

The version numbers also show a package that has been through many careful releases, with patch level fixes such as v2.19.1 following the feature release v2.19.0. The CHANGELOG.md file in the repository root is where the detail lives, and for a package whose whole purpose is reproducibility, reading it before upgrading is not busywork.

One more boundary is worth stating plainly. The documentation states nothing in the README about a stability guarantee, a support commitment or a deprecation policy, and there is no indication that the package is maintained by a commercial entity or that any part of it is covered by a service level agreement.

Where DrWatson is the wrong choice

The clearest case for not using it is when your project is a single script. If you will run one simulation once and throw the result away, a directory with one script and one output file is fine, and adding a package to manage it is overhead with no payoff. The README's own list of responsibilities, simulations, parameters, saved files, experimental data, scripts and reproducibility, only becomes valuable when there are many of them.

The second case is when you need the package to compute rather than organise. DrWatson is not a solver, a model framework or a data pipeline. If the blocking problem is that your method needs a specific numerical routine, a package that helps you file results more neatly does not address it.

The third case is when you want a generic project scaffolder. DrWatson is aimed at scientific and simulation work in Julia. A web application or a data pipeline project has different conventions, and a general purpose template generator is the right shape for it. Using a simulation oriented assistant for a service codebase means accepting a layout whose assumptions about parameters, experiment folders and reproducibility do not match how your project actually runs.

There is a fourth, quieter failure mode. Project layout tools work by convention, and conventions only hold if everyone on a team follows them. If part of the group writes files outside the layout the package expects, the reproducibility guarantee quietly stops holding, and nothing in the package will warn you. That is a team process issue rather than a code defect, and it is the one to watch for in practice.

Editorial conclusion

DrWatson fits Julia researchers who run repeated simulation studies and want one agreed place for parameters, outputs and source code rather than a directory layout invented per project, and it is the wrong choice if you want a general purpose project template generator or if your simulations are a one-off script. Verify three things before adopting it: read the LICENSE file directly, because the README states the package is offered under MIT while the repository licence field is one GitHub cannot classify, check the dev documentation at the documentation site for the exact conventions on paths and parameters rather than assuming them from the README, and look at CHANGELOG.md against your Julia version, since the most recent tagged release listed here is v2.19.1 from 2025-08-25 while the last push was on 2026-09-28.

Frequently asked questions

Official sources

1. Issues
2. JuliaDynamics/DrWatson.jl on GitHub
3. Project website
4. README
5. Releases