The tracker tells you who else has the files you want, in a nutshell.
Basic bittorrent outline:
You download a .torrent file which contains (amongst other things) a list of files, their hashes, and a list of trackers to connect to.
Your BitTorrent client connects to the tracker and says "Hi, who else has or is looking for these files"?
It returns a list of these people (aka "peers") and your BitTorrent client then connects directly to peers to download the files (and upload them to other people).
And all this time I thought a torrent file had the actual peers in it. So you don't even really need the .torrent if you have the addresses of some trackers that know where the files are that you want?
You would also need the torrent's hash (which enable you to specify to the tracker which files you want exactly). That's how magnet link [1] works - they contain the torrent's hash and optionally a list of trackers (most clients today support DHT [2], a decentralized tracker-less way to find peers).
I made a few simplifications for brevity and "these files" was one of them. What the .torrent actually contains is a list of the files and how those files are divided up into chunks of equal size (say half a megabyte per chunk). The bulk of the torrent is a list of hashes of each chunk, which allows your client to verify the data it has received from other peers. If you then take a hash of <<the part of the torrent that lists the files and the chunk hashes>> the resulting hash is known as the infohash. The infohash describes this particular torrent uniquely, and it's the infohash you send to the tracker when asking for peers.
Hopefully from this explanation you can see that you need it for two purposes, one so you can give the right infohash to the tracker, and two so you can verify the data you receive from peers.
A minor detail: The codebase was open source for a long time already, just on their own git and available on what.cd/gazelle and the IRC channel instead of GitHub.
