BiglyBT keeps the Azureus module split, and its dev setup is two roots and one dependency

A fork that kept the Azureus architecture and two of its authors

BiglyBT describes itself as a feature filled, open source, ad-free Bittorrent client forked from the original project, which is Azureus. The maintenance claim is specific in a way that is worth repeating exactly: two of the original developers plus community members maintain it, and the development history it points to is more than twenty years.

That lineage explains most of what a newcomer finds odd. The repository description still calls it a client based on the Azureus open source project, and the configuration override documented for running the development build is still named for the old project. Anyone grepping for Azureus to understand the codebase will hit these names, and they are not leftovers to be cleaned up so much as the vocabulary the code has always used.

The topic list shows the feature direction as much as the code does: bittorrent client, p2p, torrent management, and i2p alongside the usual download terms. The topic list also includes i2p, indicating it as part of the project's declared subject area.

Licensing is GPL-2.0 with the file at the root, which matters for anyone who intends to modify and redistribute the client rather than merely run it.

Two source roots, one dependency direction, and a specific SWT jar

The documented developer setup is a module wiring exercise, not a script, and the rules are short enough to hold in your head. Mark core/src and uis/src as the project roots. To the uis module add core/lib/* and one SWT jar from the uis/lib directory. To the core module add core/lib/*. Then make uis depend on core, and the README is emphatic that Core should not depend on uis.

That last constraint is the architecture in one sentence. The core holds the client logic and knows nothing about the user interface, which is what makes the platform specific UI layer swappable.

The platform jar is chosen by operating system, and picking the wrong one is the first thing that breaks a fresh build:

# one of these, chosen per platform
swt-win64.jar
swt-cocoa-64.jar
swt-linux-64.jar

The Linux jar is the GTK variant. IntelliJ IDEA performs all of these steps through its wizard, which is why the README can call the process straightforward and then hand the whole thing to an IDE.

Running the dev build needs a working directory it can write to

Launching from source is described as a few more steps, and two of them are easy to miss. The main class is com.biglybt.ui.Main in the uis module, and the working directory must be a new folder, because the application writes to it. The same paragraph explains why that is the norm rather than an accident: for an ordinary user the working directory is where the jar, executable and native libraries such as dll, so or jnilib files live.

One native file has to be placed there manually. The Windows build wants aereg.dll, referenced through the readme under core/lib/libWIN32Access, and the macOS equivalent is libOSXAccess.jnilib.

Configuration is separated on demand rather than by default. Passing the VM option -Dazureus.config.path with a directory of your choosing redirects the config away from its normal location, which is how you keep a development run from touching an installed copy. The old product name inside that property is the clearest reminder that the fork never renamed its internals.

The README does not document a command line entry point for a headless or remote mode, so the development path assumes a desktop session.

Install4j packaging and a signature that changed identity after v3.4

Binaries are built with Install4j, a multi-platform installer builder. The README states the signing history precisely, and it is the kind of detail that changes what a user sees. Binaries and installers up to and including v3.4 are signed with a digital signature of Bigly Software. Releases after v3.4 use an individual signing certificate bearing the name Arron Mogge (Open Source Developer), identified as the team member responsible for signing.

For an end user on Windows this is not cosmetic. A prompt naming Bigly Software and a prompt naming an individual developer are different trust signals, and a team that wrote policy about which signatures it accepts should know the cutover point is v3.4 rather than assuming the company name persists.

Release numbering is four components rather than semantic versioning: v3.9.0.0 in September 2025, v4.0.0.0 in December 2025, and v4.1.0.0 in May 2026. The last push to the repository was on 2026-10-15, so development on the branch continues after the latest tagged release, and the README points to a beta program changelog on a separate site for what is queued next.

Translation and coding guidelines sit in the repository as first class files

Three documents sit at the root and are linked from the README as if they were part of the product. CONTRIBUTING.md lists the ways to contribute, TRANSLATE.md covers translation work, and CODING_GUIDELINES.md sets the code conventions. PreferencesJavaCodeStyleFormatter.xml is committed alongside them, so the formatting rules are a file the IDE can apply rather than prose to remember.

Translation runs through Crowdin, indicated by the crowdin.yml file at the root. That matters for anyone building a localized build, because the string resources are the user visible surface of the client and they are maintained outside the repository.

External annotations are the other contributor facing detail. Attaching the external-annotations directory lets IntelliJ IDEA show MessageBundle strings instead of keys and reduces the number of null pointer warnings, and the README notes plainly that the definitions are a work in progress and not a complete list. So a developer should expect some residual NPE warnings that are annotation coverage gaps rather than real defects.

Project donation addresses are listed per coin, next to the build docs

The README carries a donation table that lists method against address, covering PayPal through a hosted page plus BCH, BTC, BSG, BSV, DASH, DOGE, ETH, ETC, LTC, TRX, BTT and XRP. Several of these are coins with a narrow user base, and the table is the only place in the repository where project funding appears.

Placing that next to the contribution and coding documents is a statement about how the project expects support to work: money, translated strings, and code. For a GPL-2.0 client with this history, the funding route matters less than the fact that it is documented in the same file as how to build it.

The homepage is www.biglybt.com, and a separate vote.biglybt.com page collects feature votes, which gives users an input channel that does not run through the issue tracker.

Editorial conclusion

BiglyBT is a defensible choice for someone who wants the Azureus feature set with the original developers still attached, and it is a poor fit for a headless server install where a web interface matters more than the desktop client. Before committing to a build, read the coding guidelines and the translation file at the repository root, because both are treated as part of the contribution contract rather than as optional reading, and note that releases after v3.4 are signed under an individual certificate in the name of Arron Mogge rather than under Bigly Software, which changes what an end user sees on a Windows signature prompt.

Frequently asked questions

Official sources

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