Open Source In Automation Products

There are a lot of things I like: pizza, bacon and eggs, bagels with real butter – apparently everything that pleases me comes on a plate – but there are two things I really don’t like: canned green beans and open source software. But I’ll qualify that a little bit. I absolutely hate canned green beans but I’m not a fan of Open Source software in mission critical applications. If I’m building a system to check if my water softener is adequately stocked with salt tablets, or if my patio light is actually turning on at night, or any one of a thousand similar non-consequential applications, then Open Source makes a lot of sense to me.

But if I’m running a continuous process, even for something as innocuous as dish detergent, I am not sure I want Open Source. In fact, I would think twice about Open Source for any industrial automation application. There’s a bunch of reasons I avoid it:

1. Legal issues. The fine print on some of these packages makes me wonder if a letter will arrive one day from some NY law firm to demand the source code for my entire product line due to some sentence in that Open Source license agreement. I don’t understand all that legalese and I don’t want to, and frankly, from what I understand of the legal system, all that language is open to interpretation in a court of law where all the lawyers are making $1200 an hour.

2. There’s another part of this that concerns me. When I buy software I get indemnified against infringement. I don’t get that with Open Source. I have no real way of knowing if some yokel in Afghanistan copied a bunch of someone’s proprietary code into the Open Source stack. You can be sure that the lawyers aren’t going to be looking for him. I’ll be the target.

3. Getting code running is almost never the issue. It’s certainly true of all our royalty free products: EtherNet/IP and ProfiNet IO, and I suspect it would be true of Open Source products. Just because the code runs right out of the box, that doesn’t mean you can use it properly. There is expertise required. The application needs to be considered, the kind of data you have must be evaluated; how the customers will use the system and how that particular brand of PLC uses that technology. It’s not just a matter of adding some Open Source code to your project and away you go, there’s some very hard won expertise of how to use it right in an application. You don’t get that with Open Source.

4. How do I know that the Open Source is going to be maintained in a timely fashion? Who guarantees that they will update the Open Source product to meet the ever evolving standards?

5. Who do you call when you have a problem with Open Source? If you bought X from Vendor A, you can be pretty sure that you can get vendor A on the line when your best customers has a line down. Can’t do that with pure Open Source.

6. Security issues – Because the source is open, hackers and other ne’er-do-wells can be looking for ways to exploit it and find a way into your manufacturing process. That’s orders of magnitude harder with proprietary software.

7. Who’s behind it? – Some Open Source projects are built and maintained by a few core diehards. When that’s the case, your project is at risk if they lose interest, move out of their parents’ basement, die, grow up, or otherwise move on to some other project.

Obviously, our company is engaged in developing, marketing, and supporting royalty free networking software. We’ve been doing that for over 20 years and Open Source software competes with us. I’d be lying to you if I told you that isn’t part of my issue. It is.

Still, there is no better way to get the expertise you need to do a project right than by using proprietary software like that you can get from RTA. It’s easy to use, comes with the expertise to help you use it right, and we’ll stand behind it.
And that’s a promise you won’t get from an Open Source website.