Lambda the Ultimate

I think the term "configuration management" was meant to include everything. All of it needs to be tracked and tested.

Instead of thinking "source code needs to be tested" and "is X source code?", maybe "does X need to be tested" would work better.

For a compiler, source code is the string of characters which express a program in some language. The output of the compiler may be "object code"--corresponding to the instruction set of a machine (real or virtual), or it may be the source code for another compiler. Of course, it can be argued that a .class file is merely "source" for a JVM--one can even argue that an .exe is "source code" for the x86 instruction set.

Probably a more useful definition, and one which matters in the domain of configuration management, is that source code is whatever is generated (in whole or in part) by the intellectual activities of humans. Stuff that can be automagically regenerated (by compiling, for example), is not source. In this case, program text which is the output of a metaprogramming tool or process, is NOT source. Wizard-generated skeletons, which are filled in by humans, are source--re-running the wizard may clobber the human's changes. A binary file, which comes from a third party (or otherwise is not buildable from other sources) may be considered "source" in this view.

If an artifact is created by a person then:

It should be in a repository, supporting at minimum versioning, branching, and tagging.

It should be reviewed.

It should be tested.

It should be documented.

(requirements for review, testing, and documentation may vary prer product)

If it is created by a machine then:

It should not be in a repository.

It should not reside in the same file tree as any human-generated artifact

It should be cleanly regeneratable with a single build command and no other human intervention.

It should should be destroyed and regenerated on every complete build.

This is important because, in the real world, all changes to source code need to be documented and tested.

Surely in the real world you document and test what you need to document and test in order to achieve the goals you are trying to achieve, eg. keep a smoothly running department. If documenting X makes life easier for everyone then document X. If it doesn't, don't. Surely the definition of "source code" is irrelevant. Indeed, a type of unit that needs testing and documenting in project A might not need testing and documenting in project B so definitions get you nowhere.

Here's a slightly more theoretical perspective on this issue.

My question is, what is considered source code?

"Source code for X" is the set of strings which are accepted by a given programming language specification X, more generally, by a translator X. A translator translates from a source language to a target language. In a compiler or interpreter, the source language is a subset of the syntax, and the target language is (usually, eventually) machine code. It is called source code because a source string is a code for a string in the target language.

Asking if something is source code without specifying a particular X is meaningless, as I can always invent some X which accepts it.

But this is not the question you want to ask. What you want to ask is, "What is a programming language?" Does it need to be Turing-complete? Does any program which takes input qualify as a programming language implementation? (Banality warning:) Does it need to have an assignment statement? etc.

I have seem many posts about technology that lets you change the behavior of a program with[out] changing the code.

Yes, it's remarkable new technology called I/O.

Are SQL statements considered source code?

Of course. They are SQL source code.

What if they are in a config file?

The property of being source code for translator X does not depend on where you are stored. Similarly, the property of being an integer does not depend on whether you are notated in base 10, base 2 or base 117.

How about a config file that makes minor changes the way the program works? For example, using a different factory class based on a flag.

A config file ipso facto contains source code for a configuration language, which may be some custom little language defined implicitly by the application which reads it.

What if the changes are major? For example, one that injects code in the fashion used in Aspect Oriented Programming.

AOP code is source code for an AOP language, which may happen to have a syntax which is a superset of some other language.

This is important because, in the real world, all changes to source code need to be documented and tested.

First, I think you probably mean "the commercial world", unless you think I am living in a fantasy.

Second, I think you have it backwards. But if you think something is source code (partially) by virtue of needing to be documented and tested, then your definition of source code is at variance with my own.