Source Code
Source code is the human-readable text of a program, written in a programming language by developers and stored in ordinary text files. It is the form in which software is written, read, reviewed and changed, as opposed to machine code, the binary instructions a processor actually executes. A program such as a web browser or an operating system kernel is, at its origin, a large collection of source files, often thousands of them, that describe its behavior in precise detail.
The defining property of source code is that it is written for people first and machines second. A compiler or interpreter tolerates any layout, yet developers use meaningful names, indentation, comments and consistent style so that colleagues, and their future selves, can understand intent. Because it is plain text, source code can be searched, compared line by line, emailed, and edited with any text editor or an integrated development environment. Machine code, by contrast, is a stream of numbers specific to a processor family such as x86-64 or ARM; it can be disassembled back into assembly, but the names, structure and comments are lost, which is why reading a compiled program is so much harder than reading its source. Text encodings matter here, and modern projects almost always store source files as UTF-8.
Source code becomes a running program through a build process, and the relationship is one-directional in practice. A compiler translates source into object files, a linker joins them with libraries into an executable, and packaging tools bundle the result for distribution; interpreted languages skip some steps and read the source or its bytecode at runtime. The same source can produce different binaries for different processors and optimization settings, and reproducible-build efforts aim to make the output bit-for-bit identical from the same input. Distributing only the binary hides the source, which is why proprietary software is typically shipped that way.
Version control systems record the history of source code, and Git is overwhelmingly the standard one. Earlier tools such as RCS, CVS and Subversion kept a central server, while Git, written by Linus Torvalds in 2005 to manage the Linux kernel after a licensing dispute over its previous tool, is distributed: every clone holds the full history. Changes are saved as commits, each identified by a cryptographic hash of its contents, and branches let people work in parallel and merge later. Hosting services such as GitHub, launched in 2008, added pull requests, issue tracking and automated testing around Git. The practical payoff is that any change can be explained, compared and undone, which is hard to achieve with files named "final_v2_really_final". Git tracks text well but handles huge binary files poorly, and it is not a backup, since a repository copy on one machine shares that machine's fate.
Having source code is different from having permission to use it, and secrets in source code are a classic pitfall. Copyright applies to code by default, so a licence decides what others may do; open-source licences such as the GPL, MIT and Apache 2.0 grant rights to read, modify and redistribute, though open source does not mean free of obligations, and "source available" is a different category again. Source also tends to collect passwords, API keys and tokens by accident, and once committed to history they remain retrievable even after a later commit deletes them, so they must be rotated rather than merely removed. For machine learning, the code for a model is only part of the story; results also depend on training data and exact library versions, which are pinned in the repository to make experiments repeatable.
Read source code as the editable, reviewable statement of what software is meant to do: readable text that humans own and version, from which the machine-code form is derived and never the reverse.