The post has been translated automatically. Original language: Russian
Open source code does not mean that the author is obliged to relinquish control over the project.
It's important to keep two things separate:
the right to use the code and the right to be called the official version of the product.
The code can be opened
The company may allow:
- study the source code;
- change it;
- create your own versions;
- suggest fixes and improvements.
At the same time, the main repository remains under the control of the author of the project.
It is the author who decides which changes will be included in the official version.
The official version is available separately
Someone can take the open source code and make their own build.
But this does not mean that such an assembly should be considered official.
The author of the project can separately control:
- Product name;
- logo;
- official website;
- the main repository;
- official builds;
- updates;
- certification;
- technical support.
For example, a third-party developer can modify the program and release their own version.
But it should not give the impression that this version has been verified or approved by the authors of the original project.
Why is this necessary?
For serious software, it's not just the source code that matters.
It is important to understand:
exactly which code was tested, compiled, and released by the product developer.
This is especially important for industrial software, security systems, operating systems, and other solutions where an error can have serious consequences.
In this case, open source provides transparency and the possibility of joint development.
And the official repository and verified builds give confidence to a specific version.
Is it possible to accept changes from the community
Yes.
Developers can create their own changes and propose them to the main project.
Next, the project team:
- checks the change;
- testing it;
- fine-tune it if necessary.;
- accepts or rejects;
- includes the accepted change in the official version.
This is a common development model for many open source projects.
However, the license and the project rules are different things.
The license defines what a person has the right to do with the code.
The project rules determine which changes the author is willing to accept into the official repository.
The main thing
Open source does not necessarily mean that there is no control center.
You can build a model:
the code is open — development is available to everyone — changes can be proposed — the official version is released and checked by one organization.
This allows you to combine the openness of development with responsibility for the final product.
But here comes the following question:
is it possible to go even further and allow the study and modification of the code, but limit its use in real products?
This is what brings us to the boundary between Open Source and our own license.
This is discussed in the latest article in the series.
Открытый исходный код не означает, что автор обязан отказаться от контроля над проектом.
Важно разделять две вещи:
право использовать код и право называться официальной версией продукта.
Код можно открыть
Компания может разрешить:
- изучать исходный код;
- изменять его;
- создавать собственные версии;
- предлагать исправления и улучшения.
При этом основной репозиторий остаётся под управлением автора проекта.
Именно автор решает, какие изменения войдут в официальную версию.
Официальная версия — отдельно
Кто-то может взять открытый код и сделать свою сборку.
Но это не означает, что такая сборка должна считаться официальной.
Автор проекта может отдельно контролировать:
- название продукта;
- логотип;
- официальный сайт;
- основной репозиторий;
- официальные сборки;
- обновления;
- сертификацию;
- техническую поддержку.
Например, сторонний разработчик может изменить программу и выпустить собственную версию.
Но он не должен создавать впечатление, что эта версия проверена или одобрена авторами исходного проекта.
Зачем это нужно
Для серьёзного программного обеспечения важен не только исходный код.
Важно понимать:
какой именно код был проверен, собран и выпущен разработчиком продукта.
Это особенно важно для промышленного ПО, систем безопасности, операционных систем и других решений, где ошибка может иметь серьёзные последствия.
В таком случае открытый код даёт прозрачность и возможность совместной разработки.
А официальный репозиторий и проверенные сборки дают доверие к конкретной версии.
Можно ли принимать изменения от сообщества
Да.
Разработчики могут создавать свои изменения и предлагать их в основной проект.
Дальше команда проекта:
- проверяет изменение;
- тестирует его;
- при необходимости дорабатывает;
- принимает или отклоняет;
- включает принятое изменение в официальную версию.
Это обычная модель развития многих открытых проектов.
При этом лицензия и правила проекта — разные вещи.
Лицензия определяет, что человек имеет право делать с кодом.
Правила проекта определяют, какие изменения автор готов принять в официальный репозиторий.
Главное
Открытый код не обязательно означает отсутствие центра управления.
Можно построить модель:
код открыт — разработка доступна всем — изменения можно предлагать — официальную версию выпускает и проверяет одна организация.
Это позволяет совместить открытость разработки с ответственностью за конечный продукт.
Но здесь возникает следующий вопрос:
можно ли пойти ещё дальше и разрешить изучение и изменение кода, но ограничить его использование в реальных продуктах?
Именно это уже приводит нас к границе между Open Source и собственной лицензией.
Об этом — в последнем материале серии.
Share
