You have in one hand a group of volunteers who don't necessarily have as much time as is needed to make changes to the game on a regular basis, and on the other hand motivated people who have their own point of view as to what direction the project should take. This lead to the woop fork, and the way the fork is handled is a massive obstacle to the reunification of the two sides: instead of open sourcing all the changes, the woop AC client is completely closed-source, for the wrong reasons.
* people who download the alternative client have to trust the person who compiled it, which leads to sometimes unecessary/inaccurate accusations when the behaviour of the executable is unexpected and it's not possible to check the code to realise that said behaviour is not malicious. People who download the official archives provided by cubers.net don't necessarily recompile the entire game when they download it, and thus also trust the person who compiled the executable to be non-malicious, but at least having the possibility to do it is a proof of good faith when someone notices something weird happening (I'm refering to the executable getting a snapshot of all the processes running).
* open sourcing a project allows users who can code to contribute, and help the official maintainers in numerous ways: implement features, fix bugs, make optimisation suggestions, even address security issues. Not open sourcing a project is a big cut in how much the community will give back to it, and it's also a risk to leave bugs/vulnerabilities that potentially an educated user would have spotted if they had been able to read the code.
* close sourcing a project in the name of security is a fallacy (called "security by obscurity") that I cannot trash talk about enough. It will not protect it from cheaters, it will not make it less susceptible to being exploited (from a security point of view), and it will not prevent wannabe cheaters to have new ideas about how to go undetected when cheating. It barely reduces the chances of having someone discover that one thing that you are trying to hide from the least technical people: just look at how successful cheat developers are in games like Counter Strike, if they go through industry-level obfuscation techniques and raw ASM, that one guy in the community that will be able to do all that in AC will make a fortune with his cheats, and you will have completely shoot yourself in the foot for nothing. Most people were probably influenced by the close-sourcing of the "anticheat" server code and think it's ok because AC did it, but it's not.
* open sourcing the code of critical infrastructure, such as authentication servers or masterservers, is also a proof of good faith, and prevents the community from criticising woop's effort to improve the game (which understandably results in the clan centralizing all the traffic through servers of their own).
If the code was open, it would benefit from the things I listed above, but it could more importantly act as a branch that the core developers would pick the improvments that they think fit the game from, both teams would share security patches (more features always results in security vulnerabilities), and both teams could work more or less independently from each other.
The only issue with my logic is: the woop client looks much more like a hard fork from the original project than an experimental version of a match client. The alternative client has a different masterserver, an experimental implementation of an authentication protocol that would take time to test and integrate in the original game, and with that I assume some additional infrastructure.
Unless both sides compromise and work things out, there's no point posting polls about whether some features should get merged upstream, there will just be two AC with each a different flavour (and the gap will go wider as time goes on).
* people who download the alternative client have to trust the person who compiled it, which leads to sometimes unecessary/inaccurate accusations when the behaviour of the executable is unexpected and it's not possible to check the code to realise that said behaviour is not malicious. People who download the official archives provided by cubers.net don't necessarily recompile the entire game when they download it, and thus also trust the person who compiled the executable to be non-malicious, but at least having the possibility to do it is a proof of good faith when someone notices something weird happening (I'm refering to the executable getting a snapshot of all the processes running).
* open sourcing a project allows users who can code to contribute, and help the official maintainers in numerous ways: implement features, fix bugs, make optimisation suggestions, even address security issues. Not open sourcing a project is a big cut in how much the community will give back to it, and it's also a risk to leave bugs/vulnerabilities that potentially an educated user would have spotted if they had been able to read the code.
* close sourcing a project in the name of security is a fallacy (called "security by obscurity") that I cannot trash talk about enough. It will not protect it from cheaters, it will not make it less susceptible to being exploited (from a security point of view), and it will not prevent wannabe cheaters to have new ideas about how to go undetected when cheating. It barely reduces the chances of having someone discover that one thing that you are trying to hide from the least technical people: just look at how successful cheat developers are in games like Counter Strike, if they go through industry-level obfuscation techniques and raw ASM, that one guy in the community that will be able to do all that in AC will make a fortune with his cheats, and you will have completely shoot yourself in the foot for nothing. Most people were probably influenced by the close-sourcing of the "anticheat" server code and think it's ok because AC did it, but it's not.
* open sourcing the code of critical infrastructure, such as authentication servers or masterservers, is also a proof of good faith, and prevents the community from criticising woop's effort to improve the game (which understandably results in the clan centralizing all the traffic through servers of their own).
If the code was open, it would benefit from the things I listed above, but it could more importantly act as a branch that the core developers would pick the improvments that they think fit the game from, both teams would share security patches (more features always results in security vulnerabilities), and both teams could work more or less independently from each other.
The only issue with my logic is: the woop client looks much more like a hard fork from the original project than an experimental version of a match client. The alternative client has a different masterserver, an experimental implementation of an authentication protocol that would take time to test and integrate in the original game, and with that I assume some additional infrastructure.
Unless both sides compromise and work things out, there's no point posting polls about whether some features should get merged upstream, there will just be two AC with each a different flavour (and the gap will go wider as time goes on).
