It's not as hard to hack, decrypt, reverse engineer as you think. And Industrial Automation has been in the spotlight recently in the hacking world.
Sometimes the best security is not assume you are safe because you are niche. This is kind of like people saying they couldn't get viruses because they owned a apple/mac product. Even though it was done, and is now extremely commonly documented.
If it isn't worth your time to put into a module and license it I don't think your code is really worth that much.
99% of the value I give a customer is understanding how their system works, developing a logical approach to solving the problem(s), and documenting the system well enough they don't have to call me when something goes wrong.
How I got the information from SQL to the Perspective table and filtered it on custom criteria was never going to be a secret.
It's not SQL queries that are reusable and that the majority of time is spent on; it's all of your script libraries and global graphic templates that have had the man hours put in. If someone else can come along and just take all of that and start using it for their own projects, that's what's worth protecting. For example, imagine if someone found Nader's projects on a site and took a backup for themselves to use. They've just gained months and months of work for free, and now they have a competitive advantage because his stuff is amazing
A good example of this is the Sankey or bar race chart that was made by pure SVG and Python and it takes a month for someone like me to figure out how to create it. The resource is a combination of view and python lib which are only simply two files that can be encrypted.
Now, you have two options for selling it:
You want to sell it for $50 for each install, and you encrypt it and add some Python code to check your client's Mac address, and if it is not the same you can add trial text on it. Of course, you need to encrypt the view and lib package so no one can access it easily. (I am not saying anyone can hack it but at least no one tries to spend time to hack a $50 resource)
The Second approach is to do it with 3rth party lib like what BJIC did and create a module and pay a lot of money to Amchart for the license. ($500) Everybody knows it takes a lot of time to make it even with a ready react library and maintaining it is really hard. On the other hand, some clients even doesn't allow you to use 3rd party modules for security.
Third party modules are no more insecure than any of the custom jython that runs throughout the Ignition platform. Clients that claim that are full of [expletive]. What they are really objecting to is the inability of them to steal your code.
Make your own 3rd-party module that exposes a java-implemented system.* function that performs the SVG creation. Full stop.
Wouldn't it be more that because you can't see the code, you don't know if the module is secretly sending stuff off to dodgy servers somewhere?
Any IT department with any modern tools can see such traffic, whether in java or jython.
Just as likely that if a developer no longer supports a module you've built a dependencty on, you're rather stuck on a major version with no upgrade path. At least until you can change / replicate the functionality on your own.
IT doesn't generally think in those terms, but I've been there.
Precisely the motivation to steal the 3rd party code. 
From BIJCs point of view for module development:
We can understand this hesitation but adding nefarious code of any type into a module is a hiding to nothing. It is simple to detect rouge data packets and would be the easiest way to lose customers.
And its BIJC, not BJIC
We only develop modules we need for ourselves, we release some of them if there is interest. When a new major version (sometimes minor) is released we are in the same boat as everyone else, we can’t upgrade the modules until the SDK is updated and that can take time. The only time we would drop support is if its been incorporated into Ignition and even then if requested we help out.
I have no doubt that you, @nader.chinichian, and others are very capable individuals who can solve most problems given to them but I wouldn't equate time spent on something with value. You could post all the code you have ever written and upload all the projects you have ever made and it would still be unlikely I could use more than 5% of it in the next decade. Likewise, it is unlikely anything I have done would contribute to your own projects. And I doubt many of our customers would change what engineering firm they do business with or that we have the bandwidth to take on new customers.
Is this an argument for giving away things for free? No. It is just my statement that the work we create has value but not as much value as we would like to believe.
The person that has been most influential in my development in Ignition has been @pturmel and he gives answers away for free (although sometimes he talks at such a high level I have to really work to understand what he is saying).
To sum up my thoughts I believe the Ignition community is better off sharing ideas freely and we all benefit by learning from each other.
Definitely, but the forum is aimed at helping others with solutions to their own problems. If people were posting topics asking "Does someone have some example gwbks of projects for {insert industry here} that you can send me?", I'm sure no one would respond 
Project backups wouldn't help you anyways. Does your plant have the same number of PLCs? Do they have the same programs on them? Do they have the same tag names? Does your plant have the same layouts, database structures, communication protocols, report requirements? By the time you get to the bottom of things you might as well have made the project yourself.
The only reason I don't go uploading project backups is because the customer paid for that work and it would be against my ethical code to give it away.
However, I would help you guys solve any problem if I knew the answer off the top of my head.
For me:
The only reason I don't go uploading project backups is because the customer paid for that work there is almost certainly material under an NDA in a project backup.
I don't sell my services as "Work Made For Hire", so I am not giving up copyright over my code. My ethical standard is that any code I supply in editable form is expect to be edited, maintained, and/or redeployed at my clients' convenience, and I will happily put that in writing as a perpetual, irrevocable, royalty-free grant. But I don't permit the exclusion of my ability to cut/paste/publish/reuse my code anywhere I like, at my convenience, excluding only the clients' own material supplied under NDA.
This is true for my Ignition work, PLC code, and any stand-alone software I produce.
Software I sell as licensed products are not supplied in editable form. Ignition 3rd-party modules are not an editable form.
You miss my point. I don't talk about project template what I mean is independent, easy to use and capsulated resources which you spend a lot of time to create it to solve a general problem.
Imagine someone can create IEC60870-104 driver with using only native ignition resources like a script, UDT,...
Doesn't it make sense for other people to buy and use it?
If ignition can somehow protect it, there are more possible, people create resources and expand capabilities of ignition. As always using ignition instead of SDK is always easier and much fun.
I do understand where you are coming from however I wouldn't use your custom IEC60870-104 driver even if it was free because to me that would constitute a major production risk if your custom code fails.
By putting your code into a 3rd party module I can shift the risk to you the owner and get customer approval to use the 3rd party module and I would gladly pay at least in the thousands for such code if it saved me the equivalent time.
I do agree the SDK could be easier to use but I also haven't spent too much time trying to learn it either.
For example, I purchased the MTConnect module.
The customer approved the use of it so if the module ever fails, if the customer upgrades to 8.3 in the future, if anything goes wrong with the module I have an email in my archives stating it was ok to use the module and I am not responsible for its failures (as far as I know it has never failed by the way).
If I had instead spent 2 weeks learning the SDK, cobbled together some custom code or copied it, then I have the risk of failure forever on my shoulders. Alternatively, you find out one day I copied the code and sue me for stealing it. The risk to reward ratio just doesn't make sense.
Another case to show the importance of protecting the source code is when you have particular process related scripting running at the backend.
Firstly, you dont want client automation engineer to mess around the script.
Secondly, it could contain IP and patent that is maybe years of process experience from dozens of process eng, commissioning eng, etc.
Maybe it's just a simple script with hundreds of lines, but it may be the company's core value that worth mil $.
API could be a good option to go.
If it is that valuable, it should be easy to justify a little bit of time to make it a compiled resource instead of a script.