Source code is the human-readable set of instructions that programmers write in a programming language to define what a piece of software does. Within software fundamentals, it is the original, editable form of a program: the text that people read, review, change and store, before a compiler, interpreter or build system turns it into something a computer can run.
Every application, operating system and library starts as source code. Its form decides who can understand, modify and audit the software, which is why source code sits at the center of software licensing, maintenance and security.
How source code becomes running software
A processor cannot execute source code directly. It executes machine code, a sequence of binary instructions specific to its architecture, such as x86-64 or ARM64. The path from source code to execution depends on the language and its toolchain, but it always involves translation into a lower-level form.
The table below compares the three main execution models and the artifacts each one produces.
| Model | What happens to the source | Typical languages | Result |
|---|---|---|---|
| Ahead-of-time compilation | Compiled and linked before distribution | C, C++, Rust, Go | Native executable file |
| Bytecode with a virtual machine | Compiled to bytecode, then run or JIT-compiled | Java, C#, Kotlin | Bytecode run by a runtime |
| Interpretation | Parsed and executed at run time | Python, JavaScript, Ruby | Source shipped with an interpreter |
These models are not strictly separate. Modern JavaScript engines and the Java virtual machine use just-in-time (JIT) compilation, which translates frequently executed parts into machine code while the program runs. Python compiles source files into cached bytecode before interpreting them.
A typical compiled build has several stages. The preprocessor or parser reads the text and checks syntax, the compiler produces object code, and the linker combines object files with a software library to create the final binary. Build tools such as Make, CMake, Gradle or Cargo automate these steps.
What a source code base contains
In practice, source code is rarely a single file. A real code base (also called a repository) holds program files together with everything needed to build, configure and test the software.
| Component | Purpose | Example |
|---|---|---|
| Program files | Implement the logic | main.c, app.py, Server.java |
| Build scripts | Describe how to compile and package | Makefile, CMakeLists.txt, build.gradle |
| Dependency manifests | List external libraries and versions | package.json, requirements.txt, Cargo.toml |
| Configuration files | Set defaults and environment options | .env.example, config.yaml |
| Tests | Verify behavior automatically | Unit and integration test suites |
| Comments and documentation | Explain intent for human readers | Inline comments, README files |
Source code is almost always kept in a version control system, most often Git. Version control records every change with its author and time, allows parallel work on branches and makes it possible to rebuild any earlier software version exactly. Without it, tracing when a software bug was introduced becomes guesswork.
Source code compared with related forms of software
Source code is often confused with the files that are derived from it. The distinction matters because only the source code is practical to modify; derived forms can be inspected but not edited meaningfully.
| Form | Readable by people | Editable in practice | Main role |
|---|---|---|---|
| Source code | Yes | Yes | Development and maintenance |
| Bytecode | Partly, with tools | No | Portable execution on a runtime |
| Machine code | Only with a disassembler | No | Direct execution by the CPU |
| Minified or obfuscated code | Barely | No | Smaller or harder-to-copy distribution |
Decompilation can reconstruct an approximation of source code from a binary, but it loses comments, original names and much of the structure. For this reason, licenses such as the GNU General Public License define source code as “the preferred form of the work for making modifications”, which excludes generated or obfuscated output.
Source code, licensing and access
Who may see and change source code is a legal and commercial decision, not a technical one. Source code is protected by copyright from the moment it is written, so the license defines what others may do with it.
- Open-source software publishes its source code under a license that permits use, modification and redistribution, such as MIT, Apache 2.0 or GPL.
- Proprietary software usually ships only binaries and keeps the source code as a trade secret.
- Source-available licenses allow reading the code but restrict commercial use or redistribution.
- Source code escrow deposits proprietary code with a third party so a customer can maintain the software if the vendor disappears.
Access to source code also matters for security auditing. Public code can be reviewed by anyone, while closed code depends on the vendor and contracted auditors. Openness does not guarantee security by itself; it only makes independent review possible.
Common problems with source code
Most long-term software costs come from maintaining existing source code, not from writing new code. The recurring problems below are well known to experienced teams.
- Secrets committed to the repository, such as passwords or API keys, remain in the version history even after deletion.
- Technical debt accumulates when quick fixes replace clear design, making each later change slower and riskier.
- Missing or outdated comments describe what the code once did rather than what it does now.
- Unpinned dependencies let a build pull a different library version tomorrow and break without any change to the code itself.
- Lost build knowledge, when only one person knows how to compile the project, makes the source code practically unusable.
A plain-language summary
Source code is the written recipe for a program. Programmers type it in a language that people can read, with words, symbols and numbers. A computer cannot follow that text directly.
Special tools translate the recipe into the ones and zeros a processor understands. The translated version runs fast but is almost impossible for people to read. That is why the source code is the version that matters for fixing and changing software. Whoever holds it can improve the program. Whoever has only the finished app cannot.
An example from practice
A small team maintains an internal invoicing application written in Python. A customer reports that totals are rounded incorrectly for one currency. A developer opens the source code in the Git repository, searches for the rounding function and finds that it uses binary floating-point numbers instead of a decimal type.
The developer changes four lines, adds a unit test that reproduces the rounding error and submits the change for code review. A colleague reads the diff, confirms the fix and approves it. The build server runs all tests and packages a new release. Because the team had complete source code, tests and history, the bug was traced, fixed and shipped within one working day, and the history shows exactly when and why the change was made.