#guix includes the concept of channels, or git repositories of package definitions. This gives a chance for anyone to complete the collection of packages provided by the distribution, in case this is not enough. Keep reading for an intro on how to create your own channels, or how to use the most popular third party guix channels around.
Guix itself only provides #freesoftware and #reproductible packages (no binary pre compiled blobs, then), which should be enough to most needs. Unfortunately, this is not always the case. Sometimes one needs to package #nonfree software including binary files to make work a graphic or network card, sometimes the source code of the compiler necessary to produce a package got lost somewhere in a dusty office, and cannot be found other than in a pre compiled form, impossible to bootstrap from its root.
Additionally, guix is not perfect (but getting closer). Even if becoming better thanks to contributions from the community, there are rough edges an lots of issues. One of the most frequent complaints is the time it takes for submitted patches to be review and accepted, if ever. This inconvenient is usually circunvented by creating a personal collection of package definitions.
In such situations, as in many others, package definitions may be written with help of the community (or using the guix packager !) and used normally, even if they have little chance to reach one day the main upstream guix repository (none in the case of nonfree stuff). Where these definitions live ? In topic channels. Users have the possibility to develop their own channels and use custom packages, extending guix, while submitting patches upstream in parallel. Once the patch is merged, it may be removed from the channel.

usual suspects

Other than guix channel itself, you may have a feeling of what a guix channel looks like taking a look at the guix-science organization. In there, you’ll find collections of package definitions intended to be used in a context of specific research domains, both in its free and nonfree forms. For one reason or another, they have not their place in the main guix repository, and they live their life in here. Interesting enough, guix-past channel brings old-fashioned software to the present, which reveals useful to reproduce results older than guix itself. Another interesting examples are guixrus, by the ~whereiseveryone collective, providing packages not yet fully tested, nightly releases or alpha quality software; or the guix-hpc channel, with packages related to high performance computing; also guix-bioc, containing bioconductor packages, etc. You get the idea.
To include additional channels, other than the default ones, in your ~/.config/guix/channels.scm file, follow the documentation, and check with guix describe: you’ll get a list of all the channels in use next time you do a guix pull. At this point, you’ll have plenty of new packages to install at your hands ! Just remember the discussion about substitutes: some channels provide substitute servers, some not. This might be an issue, or not, depending of the computing resources necessary to build certain packages.

your first personal channel

Guix channels are simple to create and use. Just put your #guile modules, containing your package definitions, in a git repository. To use them, complete the default guix load path as in

guix install -L ~/guix-channel PACKAGE

You may opt to include this local channel into your ~/.config/guix/channels.scm file, or include the -L flag in your commands. As an alternative, guix searches for package definitions in the $GUIX_PACKAGE_PATH, so you may put your channel path in this variable. Remember that guix builds packages by compiling source code: no substitute server will do the job for you in this case, so plan accordingly with your local resources and patience.

electronics channel

This is about #modernhw after all, so let’s see an example more on detail, my own guix-electronics channel which complements the ./gnu/packages/fpga.scm guix module. This is the channel I’m using daily, where I include all the packages I need and doesn’t yet exist upstream. When they get merged somewhere else, I remove them from here. In the meantime, I’m a happy user of my custom packages.
I classify all my package definitions in #guile modules under ./electronics/packages/MODULE.scm. This is the reason why the compilers module, for example, starts by

(define-module (electronics packages compilers)

Then, proceed as usual (check the guix repo itself for inspiration), putting your packages below

(define-public mypackage
  (package
    (name "mypackage")
    ...
    ))

I create a git repo, commit my changes and push it online to a #gitforge.
I need a .guix-channel file with the url of my channel and a version number. If the code in the channel depends on other channels other than main guix channel, one needs to specify this information in this file too. In this case, for example, several of the package definitions include a dependency on ghdl-clang, provided by guix-science channel, so I need to declare it in here too.
It is also necessary a .guix-authorizations file, with the (GPG key) list of developers with right to push to this channel. This is how guix authenticates channels. Finally, it is important to create a readme file or similar where introduce the channel (first commit, signing key fingerprint). That’s it. Include the channel introduction into your ~/.config/guix/channels.scm file, and you’ll be pulling from your online guix channel.

contributing

The advantage of using a custom channel is to benefit from an increased degree of freedom when using guix, without being dependent of someone’s else time availability to consider your particular needs. Remember, guix is a huge project which follows closely the #freesoftware paradigm, and collaboration works in two directions. You take advantage of other developers contributions to guix, while you participate yourself to improving guix repositories with your package definitions, once they have been tested.
Take for example the list of packages in my electronics channel. I have included here utilities for #vhdl code editing under #emacs, specific to the electronic digital design field, which are not yet available in guix upstream channel. There is also a cosimulation library, #cocotb, which allows coupling #python and #ghdl to simulate a design. I have submitted a patch to include this in guix itself, similarly to python-vunit; once merged, I’ll remove them from here.
Some packages, like open fpga loader are now part of guix. Some others, like the gnat ada compiler and ghdl-clang stable have been merged already on guix-science, as gnat package is obtained from binaries (and so ghdl-clang is also impacted, from guix perspective). I include here a more recent ghdl-clang, non yet released, as it includes some fixes and improvements I am interested in, without having to wait until guix incorporates a new release.
Catch the idea ?
Contributing your code to guix comes to sending #email with your patches attached, it’s that simple. Dont be intimidated by the workflow (this is used by the linux project, for example). Once your patches are submitted, a review of your code folllows, see details. Some tools, like mumi, are helpful to that purpose.
These simple steps will allow you to start contributing to guix:

git clone guix itselft
add and commit your changes, watch the commit message
don’t forget to use guix lint/style/refresh -l to check your code
use git send-email to create and send a patch
cosider reviews, if any, updating your patch accordingly with git ammend
resend a new patch including a patch version (v1, v2 ...)

Interested ? Consult the doc for details, you’ll learn a lot about how to contribute to a common good and collaboration with other people.