No.

First, “open source” doesn’t just mean “you can read the source”; it means that you have rights to modify it and make new versions too.

Second, compiled programs (e.g. most programs you run on a phone or a desktop PC) do not have source available for you to read.

No. You’re probably thinking of what people refer to as “source available” which means the source is there and technically no one can stop you from looking at it but you’re not free to do whatever you want with it like you are open source stuff. It’s sort of a bad terminology but it is less.loaded than “free” which can mean “free as in beer” or “free as in speech”.

Somethings aren’t even source available either. Just because you can reverse engineer something doesn’t mean the source is available. Even JavaScript which is not compiled is not always considered source available. It is often minified and obfuscated in the browser. All variable names get replaced with junk.

In summary, open source refers to specifically to your rights to use software, not just your ability to see the source.

No, for several reasons. First off, open source is open source (code), as opposed to peeking at the compiled machine code/bytecode/whatever, or actively reverse engineering it. At that point it’s no longer the source. Depending on tech and compilers, code could be very hard to read once compiled. In many cases, any descriptive names and comments are history. Some people try to make it actively harder to figure out (obfuscation, DRM) on top of that.

After that, a lot of the principial difference comes from licensing and such, “open source” is usually differentiated from “source available” but where you can’t really “legally” do anything with it other than look.

Kinda. What you’re referring to is “decompilation”, which is the process of taking the output of a compiler and trying to reverse-engineer the code that produced it. But decompiled code is really hard to read and modify, because it isn’t what humans wrote, it’s what the compiler translated it into, and that can have some unexpected changes than are mostly irreversible. And, since it’s closed source, if you somehow manage to make a change, you can’t re-release it – you don’t have the license to do so.

With open source, you see the same code as the maintainers, so it has the high-level programming concepts and good variable names, and you have permissions to fork and release your own version.

Your computer’s CPU doesn’t understand human language or code, so programs are compiled from human-readable programming languages (like C++, Rust, etc.) into binary machine code. Machine code is basically just a bunch of CPU instructions and data that are formatted specifically for your CPU’s architecture (depending on if it’s x86, ARM, etc.).

Most of the time, when you install a program/app/game, you’re only getting the compiled binary in your CPU’s machine code, so you couldn’t view the original “source code” without going through a complex process called “decompilation”. And even then, you wouldn’t have the legal rights to share or modify that code for others to use.

For something to be considered truly “open source”, it not only makes the original source code available to the user, it also publishes that code under a license like the GPL which gives the user certain rights to use, copy, and/or modify the code.

Although it’s possible to inspect the code of an installed application, that’s not the kind of code you’re probably thinking of. In many cases, the code that you can inspect is code that’s very hard to understand. You can learn about the difference between “machine code” and “high-level programming languages” to understand why you probably won’t be able to do anything of value with the code that you can inspect.

Even if you can inspect it, you can’t change it. (You could, but it would be very very difficult.)

Even if you can change it, that doesn’t make it Open Source, for reasons that others have already described.

One place where you can often inspect the source code is in a web browser. That’s still not Open Source, but it’s closer to source code and largely available to inspect.

Best wishes with your interest in learning to program!

Take a look at the definition of “Free Software”:

A program is free software if the program’s users have the four essential freedoms:

• The freedom to run the program as you wish, for any purpose (freedom 0).
• The freedom to study how the program works, and change it so it does your computing as you wish (freedom 1). Access to the source code is a precondition for this.
• The freedom to redistribute copies so you can help others (freedom 2).
• The freedom to distribute copies of your modified versions to others (freedom 3). By doing this you can give the whole community a chance to benefit from your changes. Access to the source code is a precondition for this.

The term “open source” has a more corporate-friendly connotation, but the freedoms it entails are the same.

Expanding a bit on what others have said, for anybody who is further interested (simplified; this whole discussion could be pages and pages of explanation)

The code we write (source code), and the code that makes the machine do its thing (executable code) are usually very different, and there are other programs (some are compilers, others are interpreters, I’m sure there are others still) to help translate. Hopefully my examples and walkthrough below help illustrate what others have meant by their answers and gives some context on how we got to where we are, historically

At the bare metal/electricity flowing through a processor you’re generally dealing with just sequences of 0s and 1s - usually called machine code. This sequence of “on” and “off” is the only thing hardware understands, but is really hard for humans, but it’s all we had at first. A program saved as machine code is typically called a binary (for formattings sake, I added spaces between the bytes/groups of 8 bits/binary digits)

00111110 00000001 00000110 00000001 10000000 00100110 00000000 00101110 00000000 01110111

A while later, we started to develop a way of writing things in small key words with numerical values, and wrote a program that (simplified) would replace the key words with specific sequences of 0s and 1s. This is assembly code and the program that does the replacements is called an assembler. Assemblers are pretty straight forward and assembly is a close 1:1 translation to machine code; meaning you can convert between the two

LD A, 0x01
LD B, 0x01
ADD A,B
LD H, 0x00
LD L, 0x00
LD (HL), A

These forms of code are usually your executable codes. All the instructions to get the hardware to do its thing are there, but it takes expertise to pull out the higher level meanings

This kind of writing still gets tedious and there are a lot of common things that you’d do in assembly that you might want shortcuts for. Some features for organization got added to assembly, like being able to comment code, add labels, etc but the next big coding step forward was to create higher level languages that looked more like how we write math concepts. These languages typically get compiled, by a program called a compiler, into machine code, before the code can run. Compilers working with high level languages can detect a lot of things and do a lot of tricks to give you efficient machine code; it’s not so 1:1

This kind of representation is what is generally “source code” and has a lot of semantic things that help with understandability

int main() {
  int result = 1+1;
}

There are some, very popular, high level languages now that don’t get compiled into machine code. Instead an interpreter reads the high level language and interprets it line by line. These languages don’t have a compilation step and usually don’t result in a machine code file to run. You just run the interpreter pointing to the source directly. Proprietary code that’s interpreted this way usually goes through a process called obfuscation/minimization. This takes something that looks like:

def postCommentAction(commentText, apiConnection) {
  apiConnection.connect()
  apiConnection.postComment(commentText, userInfo)
  apiConnection.close()
}

And turns it into:

def func_a(a,b){b.a();b.b(a,Z);b.c();}

It condenses things immensely, which helps performance/load times, and also makes it much less clear about what the code is doing. Just like assembly, all the necessary info is there to make it work, but the semantics are missing

So, to conclude - yes, you can inspect the raw instructions for any program and see what it’s doing, but you’re very likely going to be met with machine code (that you can turn into assembly) or minified scripts instead of the kind of source code that was used to create that program

Everything is open source if you can reverse engineer