Source files, definitely. Apache is an open-source server; the people who use it are used to having access to the source code of the server and modules to investigate behavior and discover bugs, and they're likely to be less trusting of closed-source code.
Regarding technical competence, what exactly are you wondering? A webmaster of an Apache server would probably be familiar with the standard way to install modules for his/her operating system - but of course that depends on the operating system. For example, on many Linux systems (e.g. Ubuntu, Fedora), programs (like Apache and some of its more popular modules) are installed from RPM or DEB files, which are a little like Windows installers: they contain precompiled versions of the program. If you want to distribute to people who run these sorts of systems, you have the option of making an RPM or DEB file out of your module, and then administrators of those systems can download your file and install it (nearly) the same way they install other packages. They would not have to have Apache's development headers to do this. If you didn't make an RPM or DEB (or whatever) file, people would still have the option of running the standard
./configure; make; make install process (or whatever process you use to compile your module from source code), but then they would need to have the headers for Apache (which they could install through their package manager, the same way they installed Apache itself).
Some other Linux distributions (e.g. Gentoo, my preference) install programs by downloading the source code and compiling it. In those distributions, everything required to compile your module would already be present on the system. All you would need to do to package it would be to create some kind of metadata file that contains information about your module and instructions for compiling it.
You might want to directly contact some of the people who will be using your module and get their feedback on packaging. A real-world usability test of sorts.