[SCRIPTING]WILL YOU DELIBERATELY WRITE UNCOMMON BAD CODES WITH STRANGE POOR DESIGNS TO MAKE PLAGIARISMS EASIER TO PROVE?
Posts
Pages:
1
Disclaimer: Plagiarisms should never ever be countered by this idea alone, as this idea, even if it's to be used, should be used along with some other plagiarism counters, otherwise one would fall into the "security through obscurity" application pitfall(but not the idea itself).
While in most cases, only those having high popularity and excellent reputations will have to worry about plagiarisms on a regular basis, sometimes even a dumb noob like me can be a victim on this(and unfortunately a long time ago some of my free plugins are sold by someone else without my permissions, even when it was such a blatant scam that I don't think anyone will really lose a penny there).
So I've read how some of the best and most successful plugin developers deal with plagiarisms, and I noticed that sometimes some uncommon bad codes and strange poor designs in some plugins made by the original plugin developers can actually help proving the plagiarisms, as I've seen a plugin developer listing some of them as evidences.
While I don't think those bad codes/poor designs are intentional(they're likely due to the desire/need to make tons of plugins very quickly), that case of that plugin developer inspired me to think about whether it'd be at least considerable to intentionally write uncommon bad codes with strange poor designs to make plagiarisms easier to prove(of course better implementation alternatives shouldn't be obvious nor easy/simple to swap in or it'd only stop those trying to hide their plagiarisms but are too lazy/stupid to do it well).
The reasoning behind this practice is that, while there won't be many different ways to do the exact same thing and it's likely to fall into the very same common programming pitfalls, if a scammer plagiarizes a plugin using tons of uncommon bad codes and strange poor designs without removing all those rare programming pitfalls, it'd be an easy, simple and small task to prove that it's indeed plagiarism, or at least the case would be so probable that it can be assumed as plagiarisms until proven otherwise(sometimes even beyond reasonable doubt), all due to the fact that making the same rare programming pitfalls when trying to do the same things is effectively a black swan.
On a side note: This also implies that, sometimes prioritizing plugin development speed over code quality can surprisingly help countering plagiarisms, as scammers will be harder to hide their plagiarisms in those unintended cases.
As a bonus, the plugins written this way can also be so apparently(but not actually if you know the "secret") cryptic and fragile that others can't change anything meaningful without breaking at least something else significant(but not so cryptic that plugin users can't report meaningful errors), so those trying to hide their plagiarisms will instead keep encountering serious bugs after serious bugs, therefore they'll eventually just give up plagiarizing or change to plagiarizing without hiding(and will therefore be caught very quickly).
On the other hand, the plugin developers can keep some private test suites and documentation files(of course maintaining them needs tons of extra work) that can help them work well with those apparently cryptic and fragile codes, and let the sufficiently trustworthy fellows to have somewhat controlled, limited and recorded accesses on them in case they've to solve some compatibility issues and need such accesses.
Of course, in order to keep the negative side-effects under control, at least the following conditions must be met:
1. The plugins will still keep working well on the user level without much nontrivial bugs that can't be fixed quickly(it needs the plugin developers to keep tons of codes inside their heads)
2. The plugin developers will still keep working with the plugins effectively and efficiently despite the extremely low code qualities(private test suites can help a lot here in the long term)
3. At least some fellow plugin developers will still want to address compatibility issues with said plugins even though it'd be a hellish nightmare in general(provided that those compatibility issues must be addressed on their sides)
Otherwise those plugins won't be plagiarized not because doing so would be too hard without being caught, but because there would be so few users using them that it's simply not worth plagiarizing them.
Also, bad junior programmers like me, those having next to no plugin users or those not being harassed by plagiarisms that are hard to prove shouldn't even think about actually doing this, because:
1. If you're not at least about to be a seasoned professional software engineer, it's almost certain that deliberately writing uncommon bad codes with strange poor designs will shoot yourself in your foot so hard that your plugins won't even work at all
2. If you've next to no plugin users, it probably means your popularity and reputations are so low that nearly no scammer will think that your plugins will be worth plagiarizing(there will always be exceptions though and I'm one of the few), because even the most brazen plagiarisms demand "actual work" in the views of those scammers(otherwise no one would be shameless enough to sell others' plugins without permissions using "charging for searching services" as a pathetic excuse)
3. If all you've faced are obvious plagiarisms, then the whole idea here will only do harm to everyone except the scammers and no good to anyone, as those scammers would just continue to make obvious plagiarisms anyway
In short, the whole approach might only payoff for very proficient plugin developers having tons of plugins, popularity, reputations and users, especially when they're already being severely harassed by plagiarisms that are all very hard to prove otherwise.
While I feel bad for those being harassed by plagiarisms that are hard to prove on a regular basis, I'd like to know what you'll think about incorporating this idea with your existing plagiarism counters, as I'm wondering whether this additional option can indeed further help stopping such plagiarisms :)
While in most cases, only those having high popularity and excellent reputations will have to worry about plagiarisms on a regular basis, sometimes even a dumb noob like me can be a victim on this(and unfortunately a long time ago some of my free plugins are sold by someone else without my permissions, even when it was such a blatant scam that I don't think anyone will really lose a penny there).
So I've read how some of the best and most successful plugin developers deal with plagiarisms, and I noticed that sometimes some uncommon bad codes and strange poor designs in some plugins made by the original plugin developers can actually help proving the plagiarisms, as I've seen a plugin developer listing some of them as evidences.
While I don't think those bad codes/poor designs are intentional(they're likely due to the desire/need to make tons of plugins very quickly), that case of that plugin developer inspired me to think about whether it'd be at least considerable to intentionally write uncommon bad codes with strange poor designs to make plagiarisms easier to prove(of course better implementation alternatives shouldn't be obvious nor easy/simple to swap in or it'd only stop those trying to hide their plagiarisms but are too lazy/stupid to do it well).
The reasoning behind this practice is that, while there won't be many different ways to do the exact same thing and it's likely to fall into the very same common programming pitfalls, if a scammer plagiarizes a plugin using tons of uncommon bad codes and strange poor designs without removing all those rare programming pitfalls, it'd be an easy, simple and small task to prove that it's indeed plagiarism, or at least the case would be so probable that it can be assumed as plagiarisms until proven otherwise(sometimes even beyond reasonable doubt), all due to the fact that making the same rare programming pitfalls when trying to do the same things is effectively a black swan.
On a side note: This also implies that, sometimes prioritizing plugin development speed over code quality can surprisingly help countering plagiarisms, as scammers will be harder to hide their plagiarisms in those unintended cases.
As a bonus, the plugins written this way can also be so apparently(but not actually if you know the "secret") cryptic and fragile that others can't change anything meaningful without breaking at least something else significant(but not so cryptic that plugin users can't report meaningful errors), so those trying to hide their plagiarisms will instead keep encountering serious bugs after serious bugs, therefore they'll eventually just give up plagiarizing or change to plagiarizing without hiding(and will therefore be caught very quickly).
On the other hand, the plugin developers can keep some private test suites and documentation files(of course maintaining them needs tons of extra work) that can help them work well with those apparently cryptic and fragile codes, and let the sufficiently trustworthy fellows to have somewhat controlled, limited and recorded accesses on them in case they've to solve some compatibility issues and need such accesses.
Of course, in order to keep the negative side-effects under control, at least the following conditions must be met:
1. The plugins will still keep working well on the user level without much nontrivial bugs that can't be fixed quickly(it needs the plugin developers to keep tons of codes inside their heads)
2. The plugin developers will still keep working with the plugins effectively and efficiently despite the extremely low code qualities(private test suites can help a lot here in the long term)
3. At least some fellow plugin developers will still want to address compatibility issues with said plugins even though it'd be a hellish nightmare in general(provided that those compatibility issues must be addressed on their sides)
Otherwise those plugins won't be plagiarized not because doing so would be too hard without being caught, but because there would be so few users using them that it's simply not worth plagiarizing them.
Also, bad junior programmers like me, those having next to no plugin users or those not being harassed by plagiarisms that are hard to prove shouldn't even think about actually doing this, because:
1. If you're not at least about to be a seasoned professional software engineer, it's almost certain that deliberately writing uncommon bad codes with strange poor designs will shoot yourself in your foot so hard that your plugins won't even work at all
2. If you've next to no plugin users, it probably means your popularity and reputations are so low that nearly no scammer will think that your plugins will be worth plagiarizing(there will always be exceptions though and I'm one of the few), because even the most brazen plagiarisms demand "actual work" in the views of those scammers(otherwise no one would be shameless enough to sell others' plugins without permissions using "charging for searching services" as a pathetic excuse)
3. If all you've faced are obvious plagiarisms, then the whole idea here will only do harm to everyone except the scammers and no good to anyone, as those scammers would just continue to make obvious plagiarisms anyway
In short, the whole approach might only payoff for very proficient plugin developers having tons of plugins, popularity, reputations and users, especially when they're already being severely harassed by plagiarisms that are all very hard to prove otherwise.
While I feel bad for those being harassed by plagiarisms that are hard to prove on a regular basis, I'd like to know what you'll think about incorporating this idea with your existing plagiarism counters, as I'm wondering whether this additional option can indeed further help stopping such plagiarisms :)
This isn't really about scripting for games specifically but...
Back in college, I intentionally broke my code so people wouldn't just snap pics of my screen, type it up, then submit it to the prof as their own. I just fixed the code when it's my turn to present to the prof OR if it's time to submit. Like, broken in that it would still run and anyone not paying attention will think it's fine, but upon closer inspection it's straight wrong and inadmissible. Or it just crashes. Depends on the mood, really. The profs have actually caught on to what I was doing and started calling the copycats out later on.
Like, I'm not against helping others. I would literally stop working on my own stuff if someone asks me for help and/or has a question. But these people, they don't want help; they want their work done for them. I don't do that.
Outside of that and similar settings however, I honestly don't care enough if people copy my code. In fact, most of my work are all out for public scrutiny in places like github and such. Maybe if I was actively profiting off of my work, I would add more safeguards to it, but otherwise I don't think it's worth the effort to intentionally make terrible code just to go "Ha! I caught you!" on people.
Back in college, I intentionally broke my code so people wouldn't just snap pics of my screen, type it up, then submit it to the prof as their own. I just fixed the code when it's my turn to present to the prof OR if it's time to submit. Like, broken in that it would still run and anyone not paying attention will think it's fine, but upon closer inspection it's straight wrong and inadmissible. Or it just crashes. Depends on the mood, really. The profs have actually caught on to what I was doing and started calling the copycats out later on.
Like, I'm not against helping others. I would literally stop working on my own stuff if someone asks me for help and/or has a question. But these people, they don't want help; they want their work done for them. I don't do that.
Outside of that and similar settings however, I honestly don't care enough if people copy my code. In fact, most of my work are all out for public scrutiny in places like github and such. Maybe if I was actively profiting off of my work, I would add more safeguards to it, but otherwise I don't think it's worth the effort to intentionally make terrible code just to go "Ha! I caught you!" on people.
You could just put a comment in your code that does nothing, but a person without knowledge won't know that.
public class Stringscript
{
// if string script was created by kory toombs get true value for Stringscript
// Return
}
In a really long script that might be hard to catch.
I don't think it's a good idea to sacrifice code quality for catching plagiarism. This leads to harder maintainability on the plugin author's side and hinders the learning process other creators have by inspecting (but not copying) the plugin code.
Of course plagiarism is bad, but probably an unavoidable side effect in a system where you can't obfuscate or compile your own work.
Also, in regards to your second point, I think it's actually easier to get away with copying someone elses code if the plugin is not very popular, since no one will spot the obvious overlap in functionality / code, like you said it happened to you.
Lastly, it's not really a foolproof way to spot a copycat - the offender could just argue they were "inspiried" by the original (bad) code practices or something like that. If the copied plugin provides a similiar functionality, the original will hopefully win out by being better maintained and obviously releasing first.
Of course plagiarism is bad, but probably an unavoidable side effect in a system where you can't obfuscate or compile your own work.
Also, in regards to your second point, I think it's actually easier to get away with copying someone elses code if the plugin is not very popular, since no one will spot the obvious overlap in functionality / code, like you said it happened to you.
Lastly, it's not really a foolproof way to spot a copycat - the offender could just argue they were "inspiried" by the original (bad) code practices or something like that. If the copied plugin provides a similiar functionality, the original will hopefully win out by being better maintained and obviously releasing first.
Pages:
1















