Open source - good or trojan horse?
Immediately I want to narrow the framework - the conversation is about selling a software product (php + MySQL).
The question is (about) to give the source code?
Arguments in favor of closed code.
- The vast majority of customers need the product to work and the source code is not needed.
- When the code is closed, it is easier to implement those. support - the client will not climb with his own hands where it is not necessary and will not generate new unique errors in which the hell will figure it out.
- It’s harder to steal the source code. Or rather, it can be obtained, but it is difficult to alter something serious in this “source code” - the maximum is to break the defense, to make minor changes.
- There is some developer’s hope that a closed code will save from the resale of its product by dashing people.
- There is a light hope that they will buy the product, because they will not be able to “break”, or they will be afraid to use the “broken one”.
- The people (our people :)) are used to the fact that if the code is open, it means for free!
Arguments in favor of open source.
- Sometimes the client just wants to be able to look at the code. That is, it is not even necessary to have it, but for the opportunity to be such. It may be paranoid security in a good way or just fighters for some rights.
- The client has the opportunity to make edits, and very serious ones. Up to loss of compatibility with subsequent versions of the product (although this is already possible in the minus).
- There are no problems with the decoder closed code. It is no secret that such problems are encountered (the absence of Zend and others like him, some local glitches, etc.).
- It is possible to build a community of developers who buy, say, a developer license with access to open source.
Add a little specifics.
The question of "open source" is of interest in connection with the "intra-company" discussion about the development of one of our products (CNCat). We went through different stages (open source, Zend) and are now performing obfruskateivanie (replacing variable names with meaningless) and easy encryption. When we gave the product in the open source and gave it for free - many who tyril the code and based on it made their products without any references to us. That was a little insulting and now I do not want to get burned on it again.
However, the correct positioning of open source (API, support, control, etc.) can give us the influx of third-party developers of new features, powerful feedback, debugging - in general, a new impetus.
')
So you want to get some additional arguments or thoughts on this issue. How would you act as a client, as a developer (of course it would be desirable for you to be so that they are not unfounded)? Maybe there are some established theories and proven approaches in practice (such as the free version is closed, the purchased is open)?
The question is (about) to give the source code?
Arguments in favor of closed code.
- The vast majority of customers need the product to work and the source code is not needed.
- When the code is closed, it is easier to implement those. support - the client will not climb with his own hands where it is not necessary and will not generate new unique errors in which the hell will figure it out.
- It’s harder to steal the source code. Or rather, it can be obtained, but it is difficult to alter something serious in this “source code” - the maximum is to break the defense, to make minor changes.
- There is some developer’s hope that a closed code will save from the resale of its product by dashing people.
- There is a light hope that they will buy the product, because they will not be able to “break”, or they will be afraid to use the “broken one”.
- The people (our people :)) are used to the fact that if the code is open, it means for free!
Arguments in favor of open source.
- Sometimes the client just wants to be able to look at the code. That is, it is not even necessary to have it, but for the opportunity to be such. It may be paranoid security in a good way or just fighters for some rights.
- The client has the opportunity to make edits, and very serious ones. Up to loss of compatibility with subsequent versions of the product (although this is already possible in the minus).
- There are no problems with the decoder closed code. It is no secret that such problems are encountered (the absence of Zend and others like him, some local glitches, etc.).
- It is possible to build a community of developers who buy, say, a developer license with access to open source.
Add a little specifics.
The question of "open source" is of interest in connection with the "intra-company" discussion about the development of one of our products (CNCat). We went through different stages (open source, Zend) and are now performing obfruskateivanie (replacing variable names with meaningless) and easy encryption. When we gave the product in the open source and gave it for free - many who tyril the code and based on it made their products without any references to us. That was a little insulting and now I do not want to get burned on it again.
However, the correct positioning of open source (API, support, control, etc.) can give us the influx of third-party developers of new features, powerful feedback, debugging - in general, a new impetus.
')
So you want to get some additional arguments or thoughts on this issue. How would you act as a client, as a developer (of course it would be desirable for you to be so that they are not unfounded)? Maybe there are some established theories and proven approaches in practice (such as the free version is closed, the purchased is open)?
Source: https://habr.com/ru/post/28423/
All Articles