TbSync turns account setup into one screen in Thunderbird

The problem is setup, not synchronisation

Thunderbird can talk to a lot of servers. What it cannot do well is make that setup painless, and TbSync exists to fix that specific gap. The README describes TbSync as a central user interface to manage cloud accounts and to synchronize their contact, task and calendar information with Thunderbird. Its main objective is stated in one line: to simplify the setup process for such accounts. That framing matters because it explains what the add-on is and is not. It is not a mail client, it is not a calendar application, and it does not replace the address book or calendar modules inside Thunderbird. It is the front end that sits in front of them and makes the account configuration a guided process rather than a sequence of dialogs you have to discover by yourself. The audience is Thunderbird users whose organisations put their mail, contacts, tasks and calendars behind a hosted service. The extension is distributed through the official Thunderbird add-ons site at addons.thunderbird.net/addon/tbsync/, which is where a user would look for it. The project lives in the jobisoft organisation on GitHub, and its documentation is a wiki at github.com/jobisoft/TbSync/wiki with an About: TbSync page. That wiki, rather than the README, is where the substantive documentation lives, and the README itself is mostly a licence notice for the icons.

Which protocols are in scope

The repository topics are a compact description of the protocol surface: activesync, caldav, carddav, eas, exchange, sync and thunderbird. Read together, those names describe the space the add-on operates in. Exchange and EAS point at the Microsoft family, ActiveSync being the protocol that Exchange servers expose for mobile clients and that many hosted mail services also implement. CalDAV and CardDAV are the open standards for calendars and address books respectively, and they are what most hosted providers expose. That mix is the point. A user with a corporate Exchange account, a user with a CalDAV and CardDAV provider, and a user with a hosted service that speaks ActiveSync all end up in the same Thunderbird account setup screen, handled by the same extension, rather than in three different vendor specific configuration paths. The three data types named in the README are contacts, tasks and calendar information. Thunderbird has native support for all three, which is why TbSync can stay a configuration and synchronisation layer instead of becoming another calendar application. The repository layout reflects the split. There is a src/ directory for the add-on source, a common/ directory that holds the shared layer including a common/protocol/ directory, a test/ directory for the test suite, a beta/ directory, a build.js file at the root, and an updates.json file used to publish the extension.

The build is a Node script, and the tests target the protocol layer

The package.json is minimal, which tells you this is not a bundler-driven project.

{
  "name": "tbsync",
  "version": "5.3.8",
  "scripts": {
    "build": "node build.js",
    "version": "node build.js && git add src",
    "test": "node --test common/protocol/*.test.mjs test/*.test.mjs",
    "vendor": "common/vendor.sh"
  }
}

There is no transpiler, no bundler and no framework in that list. The build is a single Node script, and the version script runs the same build and then stages the generated output in src, which tells you the build writes into the source tree rather than into a separate dist directory. The test command is more revealing. It runs node --test against common/protocol/*.test.mjs and test/*.test.mjs, using the Node built-in test runner rather than a third party framework. The glob tells you where the tests live: common/protocol/ holds protocol level tests, and test/ holds the rest. That distribution is the interesting part for a synchronisation client. The protocol layer is where the awkward behaviour lives, the differences between server implementations, the quirks of ActiveSync versus CalDAV versus CardDAV, and it is where the test suite concentrates. There is also a vendor script, common/vendor.sh, which is how third party code is brought into the tree. Shipping a Mozilla licensed extension means the dependencies have to be vendored rather than resolved at install time, and this script is the mechanism.

Releases, the beta directory and the update feed

The release cadence shows a maintained extension rather than a one off contribution. The recent tags are v5.3.8 on 2026-09-14, v5.3.7 on 2026-09-05 and v5.3.6 on 2026-08-30, so patch releases are landing every few days. The last push to the repository was on 2026-09-14, the same day as the newest tag, and the repository is not archived. The default branch is Main, and the package version matches the newest tag at 5.3.8. The beta/ directory and the updates.json file at the root of the repository indicate how the extension is published. updates.json is the manifest Thunderbird uses to discover new versions of an installed add-on, so it is part of the release mechanism rather than an incidental file. The beta directory suggests a channel for pre-release builds that sit alongside the stable ones. For an add-on, that matters more than it would for a library. Thunderbird users update from inside the client, and the extension's ability to tell the client that a new version exists is what makes a patch release reach anyone at all. The wiki at github.com/jobisoft/TbSync/wiki is the documentation home, and the homepage for the project points at the About: TbSync page there. The README itself links the add-on listing and Thunderbird, and says little else about how the add-on works, so a serious evaluation has to go past the README into the wiki and the source.

Localisation and the icon licence obligations

Two structural details in the repository are worth a look because they affect anyone who contributes or redistributes. The first is crowdin.yml at the root. Crowdin is a translation management service, and a configuration file for it in the project root means the user interface strings are translated through that service rather than by editing language files directly. For an add-on with users across many locales, that is the difference between a maintainable translation workflow and a pile of pull requests. The second is the icon attribution section of the README, which is unusually thorough. It lists each icon, its author and its licence, grouped by licence: WTFPL for spinner.gif by Yannick Croissant, CC0-1.0 for icons by Jean Victor Balin and Willleam, CC-BY 3.0 for a long list of icons by Yusuke Kamiyamane and FatCow Web Hosting, and Apache Software License 2.0 for the material design icon from Google. The tbsync-32.png, tbsync-64.png and the tab icons come from Paomedia, and the report_open.png and report_send.png are based on FatCow Web Hosting work. Two of the entries are worth noting. tab-accounts-32.png is based on a Venn Diagram by WARPAINT Media Inc., CA, taken from the Noun Project, and the tab-help-32.png icon is under GPL. The reason this matters is the MPL-2.0 licence of the project itself. MPL is a file level copyleft licence, so it requires that modifications to MPL covered files are published, while allowing the extension to be combined with proprietary code. The icon licences are a separate matter, and a CC-BY 3.0 icon carries an attribution requirement that has to survive into the distributed build.

MPL-2.0, and what a caller should check

The licence field on the repository says MPL-2.0, with a LICENSE file at the root of the tree. That is the Mozilla Public Licence, version 2.0. What it means practically is that the extension is usable inside a larger product, including a proprietary one, provided that modifications to the MPL covered files themselves are made available under the same licence. It is file level copyleft rather than the whole project copyleft of the GPL. The repository also carries CONTRIBUTORS.md, a .npmrc file, a .prettierignore file, a .gitattributes file and a .github/ directory, plus a .gitignore. The presence of a .prettierignore tells you formatting is enforced with Prettier, and the .npmrc points at a private npm registry configuration for publishing the package. There is one limit worth stating plainly. This is a Thunderbird extension, not a library, so adopting it means adopting an add-on rather than calling an API. If your requirement is to synchronise contacts and calendars in a server side service, this project does not offer that, because it is built around Thunderbird's own account, address book and calendar modules and its add-on APIs. The checks to make before deploying are these: that the version on the add-ons site matches the one you tested, that the provider you use speaks one of the protocols in scope, and that the icon attribution requirements in the README are satisfied in whatever build you distribute.

Editorial conclusion

Adopt TbSync if you are a Thunderbird user whose contacts, tasks and calendars sit behind a hosted service and the account setup is the part that stops you. Do not adopt it for server side synchronisation, because it is a Thunderbird extension rather than a library. Before you deploy it, confirm that the add-on version on the Thunderbird site matches the one you tested, that your provider speaks one of the protocols in scope, and that the icon attribution requirements listed in the README survive into whatever build you distribute.

Frequently asked questions

Official sources

1. jobisoft/TbSync on GitHub
2. License: MPL-2.0
3. Project website
4. README
5. Releases