Connecting third-party developers to a startup?

Question

Freelance

We are going to connect freelancers to the project, I don’t really want to give all the project sources to the developers, it’s clear that we can conclude an agreement and so on, but this is not particularly encouraging. What prevents a person from raising the project and using it? Nothing. The first thing that came to mind was to put the core of the service into a composer package, cover the code with events that the developers will use, and abfuscate the core somehow.

How do they do it in general?

Please do not write about trusting developers, etc. We need possible solutions, approaches to this issue in fact.

Answer 1

I VERY love these guys :)
mmm, it's just super - when they take you to develop something, and then they don't give you the code and develop it as you want.
There have already been a lot of such questions, but especially for you I will briefly write again: ANY IDEA IS NOT COST OF ANYTHING. any code of sufficient volume, alas, has a bunch of crutches and controversial decisions, so it’s easier to write your own from scratch than to take code from a finished project.
besides, firstly, 90+% of the expenses are marketing and promotion, the code (especially the idea) is secondary, and secondly, what will we do when competitors file clones on their knees, m? any commercially viable idea will be copied hundreds of times, such things cannot be patented by and large.
of the options - do not lay out plans for the development of the project to the developers. this will be enough. that is, only you should have features (in your head or on paper, it doesn’t matter), and should be revealed during development. you can sign an NDA (if in US jurisdiction) or a non-disclosure / trade secret agreement, but this, I'm sorry, is a fart on a lighter.

Answer 2

As BasiC2k already said - the modularity of the project is the salvation in this case. In general, I'm a big believer in pre-design contracts. This is not at all a typical approach to development today, what 20 years ago, but with a hitch at the start, it allows you to painlessly scale the team over a distance. In this regard, it fits very well with the microservice architecture and, with the right architecture, allows you to distribute different parts of the system for development to several teams that do not even fully know what you are building there.
One caveat - you need a strong architect from your domain)

Answer 3

How do they do it in general?

draw up a contract, give access to the code, get the result, pay, close access to the code.
If your entire startup consists of technological know-how that provides a unique advantage and is easily copied into a new product, then it is strange that you attract freelancers to develop it. These should be internal developers - either founders or a team.
If there is no know-how, and the startup is real, that is, there is a market, customers, a problem, strategies for developing and entering this market, a well-developed business part, and so on and so forth, then the fact that someone will take your code is not must be scary to you, he can do little with him.
If there is no know-how, there is not much business part either, but there is only an idea, and you are afraid that someone will steal the code and “use” it, then apparently, apart from this idea and code, you don’t have much else in your startup, and this not a startup, but a project for the soul. If someone from this idea can make a real business and overtake you in the competition, it will not be because he stole the code from you, but because he was able to build a company and business and you were not.
Well, freelancers - coders are usually not able to do this, but for those who are able - they have already stocked up for 50 years, they don’t need your code.

Answer 4

Microservices - many do not know that this is not "optimization of a technical solution" but an optimization of "management of a technical solution".
Control and manageability is increased not only by:
- ​​the speed of the calculation
- the security of the connectivity of services (one fell - the second works)
- the speed (from simplicity) of development and testing
- more accurate monitoring.
but also (I would say first of all):
- in the manageability of development by departments and teams
- the division of responsibilities and drawing their boundaries between teams not through papers but through code.
- получение расширенной возможности контрактации не только в рамках штата, но и за юридическими пределами компании (при четкой границе у вас нет разницы по порядку работы с внутренним человеком или внешними подрядчиками).
Такой метод использовался всегда в военной и космической отрасли в США (и по всему миру дальше) сразу после второй мировой - нужно делать что-то большое и сложное, при этом управлять подрядчикам и поставщиками, чтобы все в итоге было секьюрно и безопасно.
Так разрабатываются все новые технологии (айфоны и прочие железки) - команда имеет понятную задачу, при этом эта задача не является результатом, а "мулькой", но при этом модуль который делается - именно благодаря своей "модульности" (компонент с понятными интефрейсами и закрытой внутренней самостоятельной работоспособностью) монтируется туда, где есть для этого описанные и задекларированные "коннекторы".
Это такая крайняя пограничная история - но показывающая важную часть что это работает и вопрос не глупый, как многие комментаторы побежали отвечать. Люди просто не работали видимо в условиях таких задач.
Как такую схему организовать вам я не знаю, потому что в ней должно быть главное звено - точка "сборки" всех модулей и секурности это всегда компетенция человека который ко всему имеет доступ.
Кто-то в итоге собирал айфон, кто-то в итоге собирал ракетные модули и тд - всегда есть центральная часть инженеров, которые все должны знать и ко всему иметь доступ.
Поэтому техническое решение которое работает это:
- для разработки это заказ "библиотек" и "компонентов" (любые платформы и языки имеют возможности поставки и дистрибуции таких "пакетов").
- если вам надо "майнтанить (обслуживать) "распределенно и секурно" - это микросервисы и облачка.
Чтобы все это "придумать" и "собирать вместе" вам нужен очень головастый и рукастый "архитектор" (на самом деле он называется "системный инженер" по версии INCOSE).
Решения есть - важно понимать что вы "потяните" сами.
If you have, as they say, "a mega idea but you can't do anything yourself" - you won't be able to without dependence on external talents.
If you really run into security and so on - I described a solution that is used on many projects that I designed and did (for banks and other complex customers) with the need to add people to the team so as not to give access to the entire project (primarily due to the security of the project itself and data, and the second one is about the security of the idea and theft of the code, including for draining to competitors or simply reselling).
I am ready to answer in detail on each question to everyone in the comments.

Answer 5

Insulation of modular blocks through a pre-created "glue" interface.

Answer 6

Oh, there was just recently a question about how svn differs from git. So, it differs in that it will help somewhat in solving this problem.
Although of course the issue is organizational.
The project is divided into modules.
The interaction of modules is clearly defined. The core of the project (which collects the work of all modules) - either write it yourself, or write people with a zero level of clearance :)
A separate person is involved in the development of each individual module, he receives a separate technical specification - where it is clearly stated what is at his input, what is at the output .
You ask - what does svn have to do with it? And despite the fact that it can give access to part of the repository.
Yes, the general scheme turns out to be rather confusing - well, what did you want - to climb on the Christmas tree and not scratch #opu will not work ...