EMZETT.Source Code
In short: The human-readable text of a program, written in a programming language.
In more detail: Translated by a compiler into machine code, or executed directly by an interpreter. “Open source” means this source code is publicly viewable (and usually also modifiable) — unlike proprietary software, where only the finished, compiled application is distributed.
In Depth
Translating source code into something a computer can execute directly runs in two fundamentally different ways: with compiled languages (C, Java via bytecode, Go, Rust), a compiler translates the complete source code into machine code or intermediate code BEFORE execution — errors are already caught at compile time, but every change requires a new compile step. With interpreted languages (Python, classic PHP), an interpreter reads the source code line by line at runtime and executes it directly, with no separate compile step — a faster development cycle, but some errors only show up at runtime, once the faulty line is actually reached.
Version control systems like Git exist specifically to make source-code changes traceable over time — especially well suited for text files (as source code almost always is), because changes can be compared line by line. The term “source code” deliberately contrasts with compiled code, bytecode or binary files — anything no longer in the original, human-written and readable form.
Open source vs. proprietary
The distinction between open and closed source code has far-reaching practical consequences: with open-source software, anyone can view the source code, find bugs, check for security vulnerabilities, and contribute their own changes — well-known licences like MIT, Apache 2.0 or GPL regulate, with different levels of strictness, what’s allowed with changes/redistribution (the GPL, for example, requires derived works to also remain open source — “copyleft” — while MIT/Apache don’t require that). Proprietary software, by contrast, only releases the finished, compiled application, and the source code remains the manufacturer’s trade secret, which makes independence from that manufacturer harder (e.g. in case of its insolvency), but enables business models based on selling licences.
Readability as a quality trait
Good source code isn’t just characterised by working, but by remaining understandable for other people (or your own future self) — meaningful variable names, a sensible split into functions, consistent formatting. Since source code is in practice read considerably more often than newly written (every bug hunt, every extension first requires understanding the existing code), readability in professional software development is often considered more important than maximum brevity or clever but hard-to-understand solutions.
Minification and obfuscation
The reverse case is interesting: when delivering JavaScript to web browsers, source code is usually “minified” (whitespace, comments and long variable names removed, to reduce file size) — the code technically remains publicly viewable (every browser downloads it), but becomes practically unreadable through minification. “Obfuscation” goes further and deliberately disguises the program logic, to make reverse engineering harder — neither changes the legal classification as open source or proprietary, but only affects the practical readability of the delivered code.
See also: Code, Pseudocode, Git