What is source code?

Source code is a term most people have heard, but what it actually is – and why it’s one of the most important things to spell out when commissioning software – isn’t always clear. It’s worth understanding, because at its core it’s about who owns and controls what you’re paying for. Here’s the explanation.

The definition

Source code is the readable instructions developers write to tell the computer what to do. It’s written in a programming language – text humans can read, understand, and edit – and is the original that all running software is built from. Every app, web service, and system has source code at its foundation.

You can think of it as the software’s original script, or blueprint. The logic lives in the source code: what happens when a button is pressed, how data is handled, which rules apply. What you see and use on screen is the result of that code running, but the actual work – the thing that can be changed and built on – is the code.

Source code versus the executable product

The most important distinction to understand is the one between the source code and the finished product, and the blueprint analogy captures it well.

The source code is the blueprint: readable, editable, full of instructions for how everything fits together. From it, an executable product is manufactured – “built” – the program the computer actually runs. That product corresponds to the finished building: you can live in it and use it, but you can’t read it like a blueprint, and you can’t remodel it without going back to the original.

In practice, that means whoever only has the executable product can use the system but not change it. To fix a bug, add a feature, or hand development over to someone else, the source code is required. Just as you need a house’s blueprints to remodel it sensibly, you need the software’s source code to keep developing it.

Why ownership matters

This is where it becomes business-critical, and it’s the central point for a buyer. Who owns and has access to the source code determines who actually controls the system.

If you have the source code, you’re free. You can keep developing the solution, bring in whichever vendor you like to continue the work, and review exactly what was built. If you don’t have it, control sits with whoever does – and for every future change, every fix, every improvement, you’re dependent on them. A relationship that turns sour can then get very expensive, since the source code effectively becomes leverage.

That’s why ownership of and access to the source code should be explicitly set out in the contract, ideally with a requirement that the code is kept on an ongoing basis in a code repository you have access to. It’s not something to fight over afterward; it’s something to establish before the project begins. At Weapp we consider it a given that the buyer owns their source code – you’ve paid for it to be written, after all.

What comes with the code

One last thing worth knowing is that the source code is rarely enough entirely on its own. Around it sit several pieces needed for the system to actually be built and run.

• Build scripts are what turn the source code into an executable product – the recipes for how the build happens.
• Configuration governs how the system behaves in different contexts, for example the difference between a test and a production environment.
• Documentation explains how the pieces fit together, so someone who didn’t write the code can still get up to speed on it.

Without those pieces, even someone who formally owns the source code can struggle to move forward. So make sure the whole package is included when you set out ownership – the code, yes, but also everything needed to actually do something with it. If you’d like help sorting out what you actually own of your system today, get in touch.