You may have experienced the problem of not trusting your coders, and how you can prevent your source code from being leaked or stolen - At the beginning I'll only speak about different ways to secure your code, and only at the end of the articles about the morality of not trusting your developers, and whether it's worth it.
Modularity / Access Control
This first approach will actually protect most of your source code from being viewed and edited by unwanted people.
What is a module and modularization?
Modularization is actually more a software development concept that helps to organize and deploy software. As a result, parts can eventually be easily expanded, maintained, and modified.
Classes / functions can already be called a module when they are independent of each other and don't need to see each other to work, but when someone talks about a module it usually means: microservice.
The idea of microservices probably became very popular through AWS and similar cloud server providers, as they make it very easy to deploy additional new servers.
The ultimate goal of microservices is to make the respective services as independent of each other as possible.
This means that each service only carries out a partial task and is separated from other systems. Typically, these services then communicate using interface APIs that use JSON or XML to share data.
With such standardized interfaces, each service works with others without having to know the architecture of the other.
This brings with it some benefits, but also some drawbacks. Let's have a look at them:
Pros
1. Privacy (information hiding)
This first pro is probably the reason why you're reading this article right now. If the source code doesn't need to be seen by everyone, it's easier for you to conceal the code from rogue coders.
Every Coder only has access to one small part of the App and not whole source code.
This way confidential Algorithms, API keys or other constants can easily be kept hidden from other services (coders you don't trust) because they only see the results and not the inner workings.
2. Combinability
This pro and all the following pros are the actual reason why modularization is normally used in software development.
Because each service is independent, different technologies can easily be combined as long as the interface (JSON, XML) remains the same.
This is also great if you are using some old technology and want to switch to a new one. You can easily re-write services one by one instead of having to rewrite the whole app. This reduces the risk of errors and things being missed out.
3. Stability and scalability
Netflix is a good example here: If a service fails, they can simply redirect the requests to another server that has the same service without having major downtimes.
Furthermore, you can also balance the load well and, if there are too many new customers, simply switch additional servers to the services you need (login servers, for example, rarely need to be expanded, but streaming servers do).
If you want to learn more about Netflix’s Modularization, check out this video where Josh Evans talks about the vibrant world of Netflix microservices.
4. Parallel development
Like i already kind of mentioned in Pro 2, if you want you can work on small parts of your app without others being effected or having to be changed.
Development teams work independently of one another and can deploy in independent cycles.
Cons
1. Data consistency problems
This is a problem only really occurs when people don't work right. As long as there is a master database with master data that everyone uses instead of hard coding variables this problem should not occur - But it still does in the real world...
Master data could differ between services if developers are not careful to change them everywhere / use a master data source.
2. Service discovery service required for large projects
If you have many services in a large app, it can be cumbersome to integrate every small service with all the addresses of the other services. Therefore, entire service discovery services are necessary whose only job is to search for other services and to save / distribute their addresses
3. Extra work
If you didn't start your Project with this in mind it could take some time to re-write/ reorganize all your code you already wrote by breaking it all apart - it could also be that your projects is quite small and this whole modularization concept does not make that much sense for the extra work it would take.
Code sample
Now I just want to give a little imaginary code example of how micro-services would interact with each other through API interfaces. I'm going to take the Amazon search feature as an example, but Amazon is very unlikely to use this exact approach - I just needed some sample domain.
Request:
https://search.amazon.com?searchTerm=Smartphone&results=5
Result:
{
"search term": "smartphone",
"results": 5,
"date": "11/10/2020 10:30:05",
"0": {
"Name": "Samsung Galaxy S2",
"price": "$500.99"
},
"1": {
"Name": "Google Pixel 4",
"price": "$300.49"
},
"2": {
"Name": "Motorola 3310",
"price": "$999.45"
},
"3": {
"Name": "OneNote 2",
"price": "$400.99"
},
"4": {
"Name": "Samsung Galaxy S10",
"price": "$890.99"
}
}
If you want to learn more about Modularization you should check out this great video, in which Michael Bryzek highlights specific key decisions that have a very direct effect on the efficiency and longevity of a microservice architecture, including infrastructure, event streaming, continuous deployment, language choice and more all to ensure that teams and systems remain efficient and scalable.
Source Control
This method will only protect your code from being modified in a harmful way but not from being seen.
What is Source Control?
Source control (or version management) is a method used to log changes to documents, files or source text. All versions are kept even after changes are made with a time stamp and username and can be retrieved later.
The best known example in the software field is possibly Git. All versions are chains of which the last version is valid - but branches and forks may also be made. Because basic information such as username and time is documented for each version update, it is possible to monitor exactly who has changed what and when.
If necessary - for example in the event of unintended or malicious changes - you can easily go back to the previous version.
If you want to learn more about GitHub and version control in general, check out this beginner guide to GitHub.
NDA / Legal
The US Commission on New Technological Uses of Copyrighted Works (CONTU) announced in 1974 that it was possible to patent computer programs and software source code.
This has opened the door for NDAs and proprietary applications and allows software not only to be technically shielded from cracking and distribution, but also through legal means.
What is a NDA?
A non-disclosure agreement (NDA) is simply an arrangement between two parties where the party receiving confidential information agrees to be bound by confidentiality and not to reveal or use confidential information without the permission of the party exchanging confidential information.
The NDA can be unilateral (or one-way) where only one party discloses confidential information and the other party agrees to be bound to confidentiality and not to exploit the information.
In a mutual agreement, all parties share sensitive details that they want to keep private.
Normally, in a mutual agreement, the bargaining power is far more balanced and the terms of the agreement are established for the good of both parties, not just the person making the disclosures - but if you get a job you normally get a one-way NDA because the benefit you get is the job...
NDAs are normally used in business relationships as they allow parties to participate in initial negotiations without fear that their trade secrets or other forms of confidential information will be leaked or stolen.
But keep in mind: a NDA is just a formality. Even those who are in support of NDAs know that it will do little to protect their property.
Some people may be scared by NDAs, but others won't. The best thing the NDA will do for you is that you can sue someone and get some money back, but your code will still be out there. If you want to learn more on how to legally secure your software from reverse engineering, see section 2.3 "Legal/EULA/License" in this software cracking post.
Collaboration / Trust
Now I'm going to talk about the morality of not trusting your employees...
You're here exactly because you don't trust your employees, but what if you could do that?
One very quick way to get rid of good developers, or at least to drain their morale and commitment, is to show them that you don't trust them.
In reality, they're likely to start thinking about ways they can get the code out though they're almost definitely not going through with it and if they can come up with a way they're going to think you're not just paranoid but also dumb. (There are organizations where this degree of caution is warranted, but in most companies- especially start-ups - this is not considered to be one of them.)
If you make people feel like they are in a fulfilling, successful and lucrative relationship, they will stick with you. And that's exactly the same thing for contractors and employees. Nothing will stop the employees from leaving and taking the source code with them, except for an incentive to stay.
So make your work pleasant and worth working on, rather than wasting resources on freakish (Yes I know this word is really judgmental but that's what most employees will think) control.
Is all this even worth it?
If you recruit good people, they will be able to rewrite the program they wrote again later. If you recruit bad people, you're fucked differently and sunk no matter what because they certainly won't be able to build the software you need.
In short, this should be very low on the list of stuff to think about. Concentrate on recruiting good people and ignore this.
The least important aspect of your startup is your program and source code. It can ruin your company if you've lost it but it probably has very little value to anyone if they've just obtained the code.
Most software developers, in a few months, could copy the core of almost every application just by looking at the compiled application. It's not going to be exactly the same because it won't have all the features, but it'll have just what it needs, and it'll probably be more efficient, as they won't waste time implementing the errors that someone else has made.
It's certainly more than enough to compete, likely even better.
Even better if they've already written the code for you - now they already know the challenges they're going to face and what to avoid. They could rewrite what they already had in a fraction of the time it took to do it for the first time.
Not having the source code is more of an inconvenience than a hindrance. What is a hindrance, particularly to the developer, is not to have a business built around the app.
Your clients, your staff, your business plan, your brand, your culture, etc. If you don't have that stuff yet you have an unproven idea and an implementation that hasn't worked out yet, and there are a dozen or so of that. Startups excel, not because they replicate what another organization does, but because they do so by becoming bigger, better, and quicker. You can't do that by using the same source code.
When businesses buy other technology companies, it's less about the source code and more for the talent who wrote the source code-the real world code is messy and probably already outdated.
The asset is the Brand behind the code, which is largely contained in the mind of the developers, and not something you can keep them from. It is already revealed to the world through the products you develop. If you don't want your developers to take their experience with them, your best defense is to keep them satisfied and keep them from quitting. That usually doesn't involve not trusting them and putting on physical locks that do more to frustrate them in their work than anything else.