See www.zabbix.com for the official Zabbix site.
Before you can start looking at the code, you must get it. You can choose between getting prebuilt release archives or getting it from the source code repository system.
You can download common released versions from Zabbix download page.
You can download latest builds from Zabbix developers page. These are like released versions, just unstable. Nightly builds are available also as Dockerized Zabbix (docker image with dev tag, e.g. monitoringartist/zabbix-xxl:dev).
Zabbix source code is kept in a git repository, located at https://git.zabbix.com/scm/zbx/zabbix.git. One must have git client installed to clone the repository.
Code can also be browsed in the Atlassian Bitbucket web UI.
On Linux, one can use either the official git commandline client or one of the available GUI clients/frontends.
Using official git client
First, make sure you have it installed. In most distributions, package is called git. Change to a directory you want to place Zabbix code in and execute:
$ git clone https://git.zabbix.com/scm/zbx/zabbix.git
This will grab all Zabbix source, including the latest version, historic versions and all development branches.
Released version snapshots are stored in the tags/ subdirectory. Few example entries:
If you want to update your copy at some later point, change to the clone directory and execute:
$ git pull
TODO: document switching to particular branches.
You can read the git commit log, seeing what messages developers attached to each change. There's also date syntax that allows to retrieve information based on dates.
$ git log --after="2019-05-09 00:00" --before="2019-05-10 00:00"
To see the changed files, use
--name-status. See git log documentation for more information.
You can also get exact code changes in a specific commit:
$ git show ca05108f305c6783695c937b2832080134dfa436
For more information on git usage read git documentation.
Applying changes to your installation
TODO: update this section for git.
Often times you may want to try one particular upstream solution to a problem. Tickets should contain a reference, which release fixed a certain problems. It can be a number of commits or just one single commit. For a single commit, it's very easy! Let's take  and 3.0 as an example! In the respective updated SVN checkout run:
$ svn diff -c r58902 > /wherever/you/want/it/r58902.patch
Copy the patch over to the target system if necessary. Where exactly you put it, doesn't matter, as long as you can access it. Looking at our patch, it references paths, starting with frontends/php/include/... If you apply your patch to a typical installation, your path is more like /usr/share/zabbix/include/... To accomodate for, we set the fitting pnum. Please refer to the patch manpage for details!
/usr/share/zabbix $ patch -p2 < /wherever/it/is/r58902.patch
The patch will probably not apply completely. The changes to the changelog file are usually rejected. Don't worry about them. Delete the remaining .orig and .rej files. Other conflicts you may encounter, must be resolved. If all goes wrong, you can reversely apply the patch. I heavily suggest to use a version control system though!
TODO: update this section for git.
For Windows you can use official Subversion commandline client like above, or one of the available GUI clients like TortoiseSVN.
Proceeding with compilation
With source retrieved, proceed on to compilation instructions.