NetLogo is a multi-module Scala codebase where the desktop app and the headless runner share one core

The repository README is a support router, not a user guide

The first line of the README sets the scope. This page is for open source developers interested in the source code for NetLogo, and other users should visit the NetLogo home page, the NetLogo Forum and the NetLogo users group on Google.

What follows is a help directory, and it is a surprisingly good description of the project's community structure. There are separate routes for reporting a bug, for learning NetLogo, for help with modelling, for suggesting a new feature, for extension and controlling API support, for building from source, and for everything else. Seven destinations, each aimed at a different kind of question.

The bug report route is worth reading, because it says something about how the project handles user models. If you have encountered a bug in the latest version of NetLogo, it might be worth checking the Issues page to see if other users have already reported it, and if not, open a GitHub issue or email the bugs list. If possible, please include a model displaying the bug as well as information about what you were doing when the issue occurred, because including the model and the buggy interaction makes fixing the problem much easier and ensures the exact problem is fixed. If the model is not public, send it to the bugs mailing list, which is private and where your model will not be shared publicly.

That last point is a design decision worth noting. NetLogo models are small programs, and the fastest path to a fix is usually to run the failing model. A bug report without one is a much slower ticket, and the project is explicit about that.

The learning path is a tutorial, a textbook and a course archive

The section for people learning NetLogo points at three things, and they are a good model of what learning an agent-based modelling tool actually involves.

The first is the tutorial, which comes with NetLogo and introduces the basic concepts. The second is a textbook that explains the concepts underlying NetLogo, An Introduction to Agent-Based Modeling, available as a paper book or an ebook from MIT Press. The third is the archives of an introductory course on NetLogo titled Introduction to Agent-Based Modeling, available on Complexity Explorer.

The distinction matters. The tutorial teaches you the language. The textbook teaches you why the language is shaped the way it is, which is the part that separates someone who can write a NetLogo model from someone who can design an experiment. The course archive gives you a sequence of assignments, which is the closest thing to a curriculum the project offers.

For modelling questions, the README points at the NetLogo resources page and says the best place to ask questions is the NetLogo Forum, while noting that the NetLogo users Google group frequently tackles questions on modelling but is moderated, so most messages do not go through until at least the next business day. That caveat is the reason the forum is listed first.

For feature suggestions, the answer is a search of the issue tracker followed by an enhancement request on GitHub, or an email to the feedback list. The README is honest that the resources available to add new features are limited.

Three runtimes and three parsers live in one build

The top-level entries describe the shape of the system better than any paragraph could.

netlogo-core/
netlogo-gui/
netlogo-headless/
parser-core/
parser-jvm/
parser-js/
shared/
behaviorsearch
models
macros/
extensions/

Three runtime modules is the key structural fact. netlogo-core/ holds the model engine, netlogo-gui/ is the desktop application, and netlogo-headless/ is the version that runs a model without an interface, which is what you use to run a batch of experiments or to drive a model from a script.

The parsers are split the same way, and the split is not arbitrary. parser-core/ holds the grammar, while parser-jvm/ and parser-js/ provide the two concrete parser implementations, one for the JVM and one for JavaScript. That is how the same NetLogo language can be compiled in a desktop application and in a browser.

The remaining directories are the supporting cast. shared/ is the code used by more than one module, behaviorsearch/ is a separate tool for searching behaviour space, macros/ holds the language's macro support, extensions/ is where extensions live, models/ holds models, autogen/ and helio/ are build and runtime support, and bin/, dist/ and project/ are the sbt build outputs and definition.

The practical consequence for a user is that the desktop app and the headless runner are the same model engine with different front ends. A model written for the GUI runs unchanged in a headless batch, and that is the property that makes NetLogo usable for research rather than only for demonstration.

Building from source is an sbt build the project asks you to expect trouble with

The building section is short and unusually candid about expectations.

The goal is that users are able to build NetLogo from source on their platform of choice, Mac, OS X, or Linux, with more information on the Building wiki page. And then the instruction for anyone whose build does not work: post to the netlogo-devel Google Group and request help. The wording is that they are trying to make building NetLogo easy and would love to hear suggestions or problems.

The build system is sbt. The root has build.sbt, a.sbtopts file and a.jdks.yaml for the JDK configuration, and there is a classycle.sbt for the classfile cycle analysis. The.jdks.yaml and the sbt layout follow sbt conventions, and the project also carries a.gitmodules file, which in a project with this many submodules usually means dependencies that are not in the main tree.

Package hosting is handled by Cloudsmith, which the README describes as graciously provided, and the badge says OSS hosting by Cloudsmith. So the artefacts you build against come from a repository the project does not host itself.

The.gitattributes,.gitignore and.github/ directories complete the standard layout, and CITATION.cff at the root is the file to look at if you need to cite the software, which is worth knowing for a project used in published teaching material.

Extensions and the controlling API are two different integration surfaces

The support section for developers is the one that describes the two ways to extend or embed NetLogo, and the README routes each to its own wiki page: the extensions API for extension developers and the controlling API for embedding developers.

The distinction is worth spelling out, because the two solve opposite problems. An extension adds new primitives to the modelling language, so it is written against the extensions API and becomes part of what a model can say. The controlling API is for the opposite direction: running and driving NetLogo from outside, which is what a browser-based modelling environment, a web front end or a research pipeline needs.

Both audiences are told to start in the wiki, and both are pointed at the netlogo-devel Google Group, with the note that extension and embedding developers often have fairly specific questions. The separate group exists because the questions are different in kind from the modelling questions that the forum handles.

The upstream repository for extension development is the Extensions API wiki page, and the project also maintains a separate user-facing site at netlogo.org, the forum at forum.netlogo.org, and the users group.

For an adopter, the practical question is whether your use case needs the language extended, the application embedded, or neither. If neither, the desktop application and the headless runner are the whole product, and the download page at netlogo.org/download is the route.

The 7.x line is where fixes land, the alpha is where the next release is going

The release history has a familiar shape for a desktop application project. The recent releases are v7.1.0-alpha1 on 2026-08-14, v7.0.4 on 2026-05-01 and v7.0.3 on 2025-12-10.

So the current stable line is 7.0.x, with patch releases through it, and a 7.1.0 alpha published ahead of the next minor version. The version scheme is the usual one for an application with plugins, where the major version tracks breaking changes to the language or the API and the minor version tracks new features that extensions can rely on.

The maintenance record is healthy. The repository is not archived, the default branch is main, and the last push was on 2026-10-15, two months after the 7.1.0 alpha.

The licence is GPL-2.0, with the LICENSE file at the repository root, and the repository is maintained by the Center for Connected Learning and Computer-Based Modeling at Northwestern University, which is also why the bug list and the feedback list sit on ccl.northwestern.edu addresses.

For a teacher or a researcher, the practical takeaway is that the stable line is what you want in a classroom, and that the alpha exists for people who need a feature that is not in 7.0.x yet.

Editorial conclusion

NetLogo fits a classroom, a research group or a student who wants to build a model in a language meant for modelling rather than for general purpose programming, and who needs the same model to run headless in a batch job. It does not fit a production service that wants a general library, and it does not fit someone who expects a one-command source build on an arbitrary platform. Before building, read the Building wiki page, expect to work through the sbt build, and note that the 7.x line is where fixes land while the 7.1.0 alpha shows where the next release is heading.

Frequently asked questions

Official sources

1. License: GPL-2.0
2. NetLogo/NetLogo on GitHub
3. Project website
4. README
5. Releases