@nader.chinichian
Would it be worth it to hire someone to create the module for you from your resources? Seems like Inductive Automation used to offer custom module services.
I have to start learning Ignition SDK. 
3 Likes
Its on my list too, don’t know if I will ever get to it though.
3 Likes
Are you developing a system to sell to a client or are they paying you to develop a system for them? If it’s the latter one could argue you are being paid by them to develop a product for them therfore it 's probably morally, if not legally, theirs to keep.
Prior to developing Automation system I maintained and was in charge of maintaining them for a number of years and there is nothing more off-putting than integrators and companies that charge a lot of money to provide a service and then want to lock everything down. I personally would and have, gone out of my way to block any Integrator or developer, involved in an automation project for us, that wanted to lock down parts of the system for any other reasons than safety. Sure go ahead and provide compiled functions. objects etc. that you have developed, on your time, but don’t try and get me to pay for them.
For too many years traditional Integrators and system suppliers have tried to lock things down to make them selves indispensible, however the openess of Ignition, it’s community of developers and ease of deployment was one of the things that attracted me to it as a platform.
As an integrator I now make a special effort to involve the customer in the design and build process - encourage and train them if they wish, to maintain and develop their own system, It makes my life easier and the approach certainly hasn’t affected my buisness. If they feel the need to get another Integrator in then I haven’t done my job properly and don’t deserve them as a customer and I certainly don’t want to make the other guys job more difficult because I wasn’t very good at mine.
Show me the person who invented an original piece of software and didn’t copy parts of it from Books, Web, tutorials etc. If the average software developer was writing a book they would have been charged with plagerism a long time ago.
I strongly disagree with this, at least as a blanket statement.
Personally, I make my systems as open and maintainable as practical, with suitable grant of rights, precisely for the customer's long-term maintenance requirements (with or without me). It is morally appropriate, as you note, and is good for one's reputation. However, I make sure my contracts leave me with ownership of the code I write, as it is impossible to be efficient as an integrator if you cannot reuse your own code in other projects. I would go so far as to say that an integrator's wide exposure to many clients, industries, and ways of solving automation problems is a critical part of their value to clients. Code re-use does have to respect any NDAs you agree to, but I also make sure NDAs don't claim my IP, either.
If you follow most large company purchasing standards, where work made for hire is invoked (or its equivalent), you cannot legally reuse any code from those projects in any other projects. Or any algorithmic techniques you develop. Such purchase orders will kill your integration business. In the short term, complying with the restrictions will make you non-competitive. In the long term, not complying with the restrictions will get you sued into poverty.
Finally, one must recognize that clients want premium performance/features/functions in situations or with budget restrictions where they cannot, by themselves, pay for a custom solution. This is where software vendors, with proprietary solutions, fit it. Taken literally, following your advice would have you writing your own alternative to Ignition from scratch for every customer, leaving it behind when you move on to another client's contract.
Software vendors take risks with their own time and money to create solutions they believe their customers may want, with the intent to offer the solutions at reduced prices to many clients. The pooled payments cover the development. Or not, if the software vendor misreads the market. However, to ensure payment when the solution is deployed, locking the product is reasonable, moral, and in today's world, absolutely necessary.
Add-on modules for Ignition is a way us integrators can provide solutions to many customers where any one customer cannot cover the cost of the time.
FWIW, I have developed a couple modules where a client sponsors module development for a feature they need. I also put unpaid time into such projects to morally justify their future sale to other clients, and the sponsor gets a bunch of free licenses. (My image streamer module is one such.)
Nader wishes to generate revenue from the (astonishingly large amount of) time he's put into Perspective development. Based on his posts here, it is the kind of premium work many clients desire. If he wishes to package it up for sale as a proprietary module, more power to him. I disapprove of attempts to bully him into not doing so.
13 Likes
"You didn't build it!"
Sorry, that argument is pure BS.
3 Likes
In time ways I can see both sides. I do like to be paid for my work, but right now I also have a single custom C# solution out there that is effectively locked down from my client, but is critical for the operation of a single piece of machinery[1]. This solution has a Bus Factor of 1 and I live in fear of something happening to me (or my backups) that leaves my client totally unsupported [2]
From my commercial point of view, it’s good that I’m in control of my code. But from my clients support point of view, them having access to the inner workings of my solution would help protect their interests.
[1] It’s a high speed printer with a 7 head rotating system used to print sequential serial numbers, and looks like it was built as a one off design in the 1950’s due to its construction of heavy cast iron and green paint. My part is to ensure that the serial numbers are legible and indeed sequential.
[2] I am exploring other options that would help me sleep at night, and might be doing a rewrite in order to shake loose some 10 year old dependencies.
Hah! I hear similar comments sometimes. (For those who don't know, the Bus Factor is the number of people who, if hit by a Bus, would place the operation in jeopardy.)
But everyone is replaceable. Really. Some are just more expensive to replace, or require multiple people as replacements.
6 Likes
2 to 3 man months of development time would costs a few $$$, and that’s not counting the production down time for a process that is more critical that your regular run of the mill production line.
Yeah, but that development would start shortly after you got hit by a Bus, not when the machine dies. Yeah, the machine could die the next day, but is that likely? You’ve instructed your heir(s) to offer the source to the client at a reasonable price?
Taken literally, following your advice would have you writing your own alternative to Ignition from scratch for every customer
To bake apple pie, you must first invent the universe.
10 Likes
Assuming my client knows that I get hit by a bus 
I've had maybe 2 or 3 support calls over 10 years, so they may not know that they need to start development.
As for the machine dying, they're about to do a Win7 => Win10 upgrade. I had to make some tweaks when they went Win7 x32 to Win7 x64, so I am holding my breath right now.
I could also put the issue back on the client by saying it's their fault that they have a critical system running with a Bus Factor of 1 
2 Likes
It is only off-putting if they also want to charge you for every inquiry, if the support from the integrator is good then it isn't off-putting that they want to protect their IP. They aren't protecting themselves from the client, but from other competitors.
My company insures that programming we purchase is not locked, but we also do not claim that programming as our own or prevent integrators from re-using that work in other projects, that's a poor way to have a client\integrator relationship.
On the same note if we have to continuously fix/ask for help on a particular piece of programming, then odds are that integrator will not be doing work for us again. Not because they wanted to protect their code but because their work was not up to par. We ask for code to be unlocked, but that is one of the first lines in the document to go if an integrator disputes it. there are just other more important battles to win.
I don't know what you're talking about, I have never done an internet search on how to do something programmatically .
Seriously though, there is a large difference between copying someone's work and claiming it as your own (with or without their consent), and taking a code snippet \ method and using it to learn or improve.
Like when I discovered that Grandma's fried chicken secret was using Crisco instead of vegetable oil.
I am a big proponent of code re-use, at the same time integrators have a right to protect their 'product'.
3 Likes
It’s my own personal view and not meant to offend anyone. I’ve seen some of Nader’s stuff and I uinderstand his need - My own personal experience is that in our industry you come across all to many systems developed by someone and either password protected or “Wrapped in some other form”, a small physical change is made to the system but you can’t modify the PLC code or SCADA because it’s beern password protected 10 years ago. As the purchaser and maintainer of a system I was perfectly in my rights to disqualify a vendor if he wants to lock his products down.
I am happy with propriety solutions which are created and provided by a vendor but they are developed by them in there own time. If there is a problem with the lockdown item they need to rectify it at their own cost. After all we pay for Ignition as a product - i don’t expect Inductive to supply me with the source code for it but if I asked them to develop a module for me and i paid for it then i would expect access to the source. But liokewise if my customer wants me to develop a driver to talk to xyz piece of plant and i charge him to develop it he should have full access to the product source.
I have developed several systems that are bespoke and I have never felt the need to protect my knowledge, work or effort in various platforms, I am personally comfortable with my clients and generally don’t feel any need to protect my intellect. And yes I agree in some instances I have taken a lot more time to develop something than the job ius actually paying howver I’m pragmatic enough to realise the product I’ve developed can be reused by myself on another project. If we start going down the route of It’s minbe and I’m not letting anyone else see how i did it then we need to start licencing or copyrighting our products.
One thing I don’t agree with is that if you are contracted to develop a solution that product should remain your intellectual property. After all if you employ someone and she writes some software for you
and then leaves the company and takes what she made with her or compiles the code and takes the source with her would you be happy?
In support of your comment on copy righting and copying snippits of code - https://www.eejournal.com/article/can-you-copyright-software/ And this is refers to whole operating systems where the one vendor tries to claim that a single line of code has been copied from them.
3 Likes
I agree with you totally on both counts. If we start getting into it’s mine it’s yours tyope of arguments with our cutomers we will soon lose buisness. I am fully comfortable sharing with my customers and wouldf like to think I have built relationships on trust and common respect. Some of my competitors in earlier days made an effort to make things as difficult as possible for the client so that they wouldn’t lose the buisness. I flipped that totally - shared everything, locked nothing down but relied on openess and knowledge sharing. My customers typically maintain their own systems and now genearlly come to me to do new projects and my previous competitors can’t even get in the door.
This may also be what makes some Open source software projects so much better than similar paid for closed source solutions. I’m not saying that is always the case but there is some quality open source projects out there that are developed and maintained by passionate people - who may not be rich but they sure aren’t starving.
Again it is what i have liked about inductive from the beginning, Ignition may not be open source but Inductive are open and have built a community which is very rare in our buisness and have made information, training and resources availablke to anyone that wishes to use it rather than locking into framework agreements and sole distributorships which is very common in the Automation industry.
2 Likes
That's a strawman argument. Employee != Contractor. The employee would be stealing.
Under various law around the world employees and contractors are treated differently, including as regards copyrights. Each has a different set of "automatic" rights unless a contract says otherwise. One of those automatic rights for contractors is ownership of their own code and other intellectual property. Employees have other automatic rights, but their IP automatically belongs to their employer.
A company choosing to hire an employee versus a contractor has many trade-offs to consider, including this.
4 Likes
The contractor issue raises another issue - Here in Europe a substantial number of the Software / PLC developers working for intergrators are Contractors with their own Limted companies. This throws a spanner in nthe works a bit.
Non of them.
I just want to sell my comprehensive library to integrator but because I lack in creating java module I can’t create module like every body else.
So if I can encrypted my resources somehow I can some how not fully protect it from normal people(not expert hacker).
If your word is really true so why every body sell their module?
2 Likes
I’m not developing for certain client I’m developing ready made solution platform in specific industry application to use for integrator with 1/10 cost of time and effect I spend to create it to hope I sell it 20 times to make it profitable for me.
In past with other SCADA packages I simply ask the client target machine mac address and put mac address checking in my code and encrypted it so they only use it in only one project but sell them very very cheap price. If client ask for source I sell them with different price.
Now I understand if I want to achieve this in ignition I need to learn creating module.
For reference Check pidbot module, it is the same idea. The guy who make it know how to create module and protect it, otherwise no one will pay him any thing for his work.
3 Likes