Goonhub
09-08-2017, 10:27 PM
OH BOY IM BACK ON THIS SHIT AGAIN
In this thread, I will propose a suggestion regarding a "psuedo-open" style of code publicity, in which the Gooncode source is sterilized of code which is necessary to hide from the public and released publicly on an annual or otherwise regular interval, so as to enrich the coding community and further the healthy nature of the Goonstation community.
THE PROPOSITION
Gooncode should be made public on a regular basis. This would entail purging of sensitive code, as seen in the recovery period following the leak. For example, this would include such sections as Telescience Secrets and Secret Recipes. If particularly desired, it could also include fundamental legacy code that would not feasibly be changed by patchmakers in order to alleviate worries of gooncode derivatives, but as this has not been done with the 2016 release, I doubt its necessity. An annual release date would be a good schedule to maintain, as it allows a somewhat modern reference point at all times, with a refresher when it starts to become truly necessary. In addition, this could be aligned with the summer to minimize workload for those of the code maintainers currently in education, if any. Needless to say, the schedule of code releases is not the focal point of this suggestion, and should be taken with a grain of salt.
ARGUMENTS IN FAVOR
There are a variety of reasons for this suggestion, focusing on the welfare of the patching community and health of the codebase. Firstly, we can see that as time progresses, more things break in the code. This is the nature of BYOND. Due to the nigh-mystical nature of the engine, almost anything can proverbially shit the bed at any given moment for any given reason. This is, of course, bad. Regular code releases would help mitigate this, allowing for community hobbyist coders to help with bugs that the proper code maintainers may not have the time, energy, or will to fix. Whereas simply having one person tackle an issue may result in a solution eventually, exposing the problem to an entire community who, for whatever reason, may be particularly interested in a particular issue being solved would dramatically reduce the time it takes for such problems. It provides a wider span of perspectives which is a boon to problem solving, and as mentioned, may expose individuals with a vested interest in the broken mechanic to the code, allowing the issue to be taken on by someone with an actual incentive to solving it (eg, being able to play with their favorite obscure nerd toy.)
Additionally, fresh code allows for patchmakers to more efficiently design patches. Updated core code could completely invalidate a patch, and all the patches currently incorporated were "silently added" in a sense, that is, their actual implementation and status may differ from their original implementation by the patchmaker themselves. Regardless of this, however, is pure quality-of-life. Even if a patch could be verified to be not edited at all in its official implementation, prospective patchers may need to independently assemble the patch and all relevant previous patches that may affect it if they wish to change a feature affecting this patch. This is an obstacle to patching so extreme that it quells potential patches without fail, when a fresh release would provide complete and modern relevant code. I believe that this assembled modern code would allow a new wave of patching on an annual basis, no longer limiting patchers to merely prayers and what they think is still relevant.
REFUTATION OF COMMON CRITICISMS
In my experience, this suggestion has been somewhat controversial. Overall opinion seems to be general apathy (which I hope this massive effortpost will change), although proper criticisms do need to be addressed.
Fundamental code has not changed dramatically.
We must understand that it is no easy task to incorporate code of foreign codebases. Years of separation has rendered these codebases very distinct in many ways. Were code to be "stolen", there is absolutely no reason it would not have already been done. Both the main code and patches are public. While differences make a lot of, well, difference for actual gooncode patchers, they matter much less to patchers of other codes, who in order to use our code would already be making significant edits to the code in order to get it to work. Either directly taking patch code, 2016 code, or simply by eyeballing an addition, a coder would be able to replicate it in their own code with enough labor, and as taking code from other bases is already an investment of significant labor, problems that face our community patchers would matter much less to them.
Not all desired features are worth porting actual code for.
While the idea of outright stealing code is a romantic one, it is not necessarily a true one. In many cases, the labor associated with actually porting code simply is not worth the trouble. It would be more advantageous for many situations to simply observe the mechanic one would like to use in their own codebase and code it themselves. This is both the case for particularly simple features which aren't worth the trouble of dissecting, and particularly large features which are so tremendously bound to fundamentals that a port isn't feasible. This leaves coders a narrow range of medium-sized fundamental-ish shit, which they likely would have already taken if they so desired it.
They already can, see point one of previous claim.
Who cares?
Seriously, hating furries so much that you're outraged at the idea of them having fun the same way you do seems incredibly unhealthy. See someone.
Fundamental code and patches are all publicly available.
A public release would only serve to compile patches and code, along with all the derivative tweaks to code made in the time since the previous release. As that means almost all foundational code is already public, we can conclude a compilation would be no more damaging to such a coder than it currently is.
Such coders could request their code be made nonpublicized along with secrets.
Similar to artists who ask that their art is not posted elsewhere, it would not be hard to compile a "do not republish" list if such a thing is absolutely necessary. Using this theoretical list, snippets or features could be removed along with things such as telescience zones when preparing for the release.
CONCLUSION
I hope that this post has served well to outline the merits of such an action, as well as address common concerns with it. I feel as though the patching community that has grown from the leak has been an incredible boon to our community as a whole. We've seen a metric fuckton of amazing content, overdue fixes, and just plain narrowly obscure tweaks that have really improved the game as a whole in a way that an isolated and often preoccupied closed source coding team simply can't manage due to limits on time, energy, patience, and interest in the game. A course of action following the spirit of this post would go an incredibly long way in giving the community a hand in further perpetuating this brilliant streak of change for Goonstation.
also, you don't know how bad this text editor is until you try making something slightly professional with it, jesus fuck
In this thread, I will propose a suggestion regarding a "psuedo-open" style of code publicity, in which the Gooncode source is sterilized of code which is necessary to hide from the public and released publicly on an annual or otherwise regular interval, so as to enrich the coding community and further the healthy nature of the Goonstation community.
THE PROPOSITION
Gooncode should be made public on a regular basis. This would entail purging of sensitive code, as seen in the recovery period following the leak. For example, this would include such sections as Telescience Secrets and Secret Recipes. If particularly desired, it could also include fundamental legacy code that would not feasibly be changed by patchmakers in order to alleviate worries of gooncode derivatives, but as this has not been done with the 2016 release, I doubt its necessity. An annual release date would be a good schedule to maintain, as it allows a somewhat modern reference point at all times, with a refresher when it starts to become truly necessary. In addition, this could be aligned with the summer to minimize workload for those of the code maintainers currently in education, if any. Needless to say, the schedule of code releases is not the focal point of this suggestion, and should be taken with a grain of salt.
ARGUMENTS IN FAVOR
There are a variety of reasons for this suggestion, focusing on the welfare of the patching community and health of the codebase. Firstly, we can see that as time progresses, more things break in the code. This is the nature of BYOND. Due to the nigh-mystical nature of the engine, almost anything can proverbially shit the bed at any given moment for any given reason. This is, of course, bad. Regular code releases would help mitigate this, allowing for community hobbyist coders to help with bugs that the proper code maintainers may not have the time, energy, or will to fix. Whereas simply having one person tackle an issue may result in a solution eventually, exposing the problem to an entire community who, for whatever reason, may be particularly interested in a particular issue being solved would dramatically reduce the time it takes for such problems. It provides a wider span of perspectives which is a boon to problem solving, and as mentioned, may expose individuals with a vested interest in the broken mechanic to the code, allowing the issue to be taken on by someone with an actual incentive to solving it (eg, being able to play with their favorite obscure nerd toy.)
Additionally, fresh code allows for patchmakers to more efficiently design patches. Updated core code could completely invalidate a patch, and all the patches currently incorporated were "silently added" in a sense, that is, their actual implementation and status may differ from their original implementation by the patchmaker themselves. Regardless of this, however, is pure quality-of-life. Even if a patch could be verified to be not edited at all in its official implementation, prospective patchers may need to independently assemble the patch and all relevant previous patches that may affect it if they wish to change a feature affecting this patch. This is an obstacle to patching so extreme that it quells potential patches without fail, when a fresh release would provide complete and modern relevant code. I believe that this assembled modern code would allow a new wave of patching on an annual basis, no longer limiting patchers to merely prayers and what they think is still relevant.
REFUTATION OF COMMON CRITICISMS
In my experience, this suggestion has been somewhat controversial. Overall opinion seems to be general apathy (which I hope this massive effortpost will change), although proper criticisms do need to be addressed.
- Claim: Code releases would encourage use of code in other codebases.
Fundamental code has not changed dramatically.
We must understand that it is no easy task to incorporate code of foreign codebases. Years of separation has rendered these codebases very distinct in many ways. Were code to be "stolen", there is absolutely no reason it would not have already been done. Both the main code and patches are public. While differences make a lot of, well, difference for actual gooncode patchers, they matter much less to patchers of other codes, who in order to use our code would already be making significant edits to the code in order to get it to work. Either directly taking patch code, 2016 code, or simply by eyeballing an addition, a coder would be able to replicate it in their own code with enough labor, and as taking code from other bases is already an investment of significant labor, problems that face our community patchers would matter much less to them.
Not all desired features are worth porting actual code for.
While the idea of outright stealing code is a romantic one, it is not necessarily a true one. In many cases, the labor associated with actually porting code simply is not worth the trouble. It would be more advantageous for many situations to simply observe the mechanic one would like to use in their own codebase and code it themselves. This is both the case for particularly simple features which aren't worth the trouble of dissecting, and particularly large features which are so tremendously bound to fundamentals that a port isn't feasible. This leaves coders a narrow range of medium-sized fundamental-ish shit, which they likely would have already taken if they so desired it.
- Claim: Furry servers in particular could use gooncode.
They already can, see point one of previous claim.
Who cares?
Seriously, hating furries so much that you're outraged at the idea of them having fun the same way you do seems incredibly unhealthy. See someone.
- Claim: Coders may not want their code publicized.
Fundamental code and patches are all publicly available.
A public release would only serve to compile patches and code, along with all the derivative tweaks to code made in the time since the previous release. As that means almost all foundational code is already public, we can conclude a compilation would be no more damaging to such a coder than it currently is.
Such coders could request their code be made nonpublicized along with secrets.
Similar to artists who ask that their art is not posted elsewhere, it would not be hard to compile a "do not republish" list if such a thing is absolutely necessary. Using this theoretical list, snippets or features could be removed along with things such as telescience zones when preparing for the release.
CONCLUSION
I hope that this post has served well to outline the merits of such an action, as well as address common concerns with it. I feel as though the patching community that has grown from the leak has been an incredible boon to our community as a whole. We've seen a metric fuckton of amazing content, overdue fixes, and just plain narrowly obscure tweaks that have really improved the game as a whole in a way that an isolated and often preoccupied closed source coding team simply can't manage due to limits on time, energy, patience, and interest in the game. A course of action following the spirit of this post would go an incredibly long way in giving the community a hand in further perpetuating this brilliant streak of change for Goonstation.
also, you don't know how bad this text editor is until you try making something slightly professional with it, jesus fuck
