Outsourced Software Development? Control The Code!

Imagine the alarm in your freelance CTO's voice as he tells you he's lost all contact with the outsourced development team for days. No response via email, Slack, or even their head office. Today, they missed a crucial deadline. He recalls a recent conversation where the team lead cited unpaid wages as a reason for declining motivation and quality. A warning sign he now regrets overlooking.

He asks if you have access to the source code or version control system. You're not sure what he's talking about, but you instantly know this means bad news.

And that's precisely why, when outsourcing software development, owning the version control system from day one is critical.

Version control is an essential part of modern software development
It is also referred to as a Version Control System (VCS), Source Code Management (SCM), Revision Control System (RCS) or Source Code Repository. Developers often simply call it "git" or "subversion" after the most popular VCS tools.

Think of VCS as the backbone of your project's progress. It's where all changes, updates, and revisions are managed and recorded forever:

• What exactly was changed, deleted or added
• Who made the change
• When and why was it made

It's like a time machine for your code, minus the paradoxes and accidental meetings with your past self.

A VCS also facilitates multiple developers to work together on the same source code
Developers can work on different versions of the project simultaneously. These versions are called 'branches', like the branches of a tree.

Typically, the development team owns and manages the VCS. Access to the VCS data or the final source code is often only granted at the project's end.

However, to avoid unnecessary risks and maintain continuous oversight, you should control the VCS right from the start.

Why you should own the VCS

1. You're not tied to your development team for code access. If you ever need to switch to a new team, you won't have to beg the previous one for the source code.
2. You have direct access to the most current version of your codebase. You want transparency and up-to-date insight into what's going on. Get a 'code review' without having to ask anyone for the actual source code.
3. There's a clear demarcation of ownership. But you should also reinforce who owns the IP through contractual agreements.
4. You can manage your VCS according to your security policies, compliance needs, and disaster recovery plans. This control is essential for audit purposes, especially for standards like ISO 27001.
5. By taking the VCS management into your own hands, you signal that you aren't a complete novice and that discrepancies might get noticed.
6. Without version control, the project history is about as reliable as your memory of what you had for lunch last Tuesday.

Great, but how do I 'own my Version Control System'?
If you don't have a CTO or someone with a tech background assisting you, consider finding someone like that ASAP. You need an independent advisor, on your side, looking out for your interests, preventing catastrophes. Their expertise can be invaluable.

You don't have a tech guru on speed dial?
While platforms like Bitbucket, GitHub, or GitLab offer user-friendly services, managing a VCS still requires technical knowledge. Without a tech background, it's best to seek help rather than attempt this alone.

Your options:

1. Hire a freelancer to set up and manage your VCS.
2. Ask a tech-savvy colleague or friend to help you get started.
3. As a last resort, have the dev team set it up, but ensure:

• You and a trusted colleague have administrative rights.
• The VCS is set to private.
• Access is restricted to prevent unauthorized changes or deletions.

Whichever option you choose, make sure you get documentation on how to access the change history and view the files/source code.

Beware of development teams that only want to use their 'own' version control
Or only offer the final version of the codebase at the project's end. This poses a significant risk that can lead to the loss of valuable work and insights. A professional team should have no issue working directly on your VCS instead of their own.

And even if they have reason to work with their own VCS, they should still be able to mirror/duplicate their VCS to yours.

The ultimate red flag would be a team that doesn't use VCS. If you encounter this, which is very unlikely, then find another team.

So how to make sure you protect what you're paying for:

1. Own your VCS, or at least have an up-to-date mirror of it.
2. Never settle for just the final version of your code.
3. If the team doesn't use VCS, find another team. No kidding here.
4. An independent tech advisor is your best ally.

By owning your VCS from day one, you're not just protecting your investment; you're ensuring transparency, maintaining control, and setting the stage for a successful project.

Thoughts? I'd love to hear them.