|
|
Applications -
Automation Business -
Communications -
Engineering Practices -
HMI -
Information Resources -
LinuxPLC Project -
Motion Control -
Open Control -
PCs in Automation -
Plant Networking -
PLCs -
Programming Languages -
Process Control -
Sensors -
Software
Re: New forum topic - Open Control
Feb 14, 2002 12:12 pm, by Alex Pavloff
Text :
One of my products is in this boat. Its a leaky boat too, as the company and people that created the software have vanished off the face of the
earth. We have the source code, but quite frankly, it doesn't help us much, as we don't have the faintest clue of where to look to fix the problems. Open sourcing a product might help, but unsupported code is unsupported code, no matter what the license is. You're still going to need someone familiar with the code willing to fix the problems.
The other problem that companies like mine might have is that licensing issues may discourage me, as an OEM, from adding features to my product to make it better than the other guys. I add a new feature, and poof, all my competitors that are using the same open source system have them. (I realize, of course, that this is entirely dependent on the licensing, and has nothing to do with the OS or anything).
Sure, the end user gets lots of features, but I'm not the end user! I'm the OEM! I can no longer differentiate my product from other on a technical
level -- removing ONE of the ways I can get ahead of my competitors.
Alex Pavloff
Software Engineer
Eason Technology
Reply
Re: New forum topic - Open Control
Feb 15, 2002 9:45 am, by Greg Goodman
> One of my products is in this boat. Its a leaky boat too, as the company
> and people that created the software have vanished off the face of the
> earth. We have the source code, but quite frankly, it doesn't help us much,
> as we don't have the faintest clue of where to look to fix the problems.
> Open sourcing a product might help, but unsupported code is unsupported
> code, no matter what the license is. You're still going to need someone
> familiar with the code willing to fix the problems.
You're a software engineer, in possession of the code you depend on, with what seems to be a strong motive for gaining familiarity with it.
I assume you're busy, that you're time is at a premium, but you only have a few options. Assuming that you have a legal right to do anything with the source (and I'll assume you do, if only for the sake of discussion):
1. live with the problems
2. replace the system with something supported
3. fix the problems yourself
4. pay somebody else to fix the problems for you
#1 may actually be an option, depending on the severity of the situation.
#2 is expedient, but probably pretty costly, and leaves you at risk to end up in the same situation you're in now if your new vendor goes belly up.
#3 & #4 are less disruptive to your plant than #2, and probably less costly (assuming that the problems are not fundamental design flaws in
your current system). Whether you or a contractor fixes the existing system, there's a learning curve to work through, and an expense (either the cost of the contractor, or the alternative disposition of your time). The advantage I see that #3 has over #4 is that you end up owning the expertise you will continue to depend on.
As with all such choices, there's a cost-benefit analysis to be done, but you do have the choice. If your current system were completely closed, your only choice would be how long you live with a faulty and unsupported system until you replace it.
> The other problem that companies like mine might have is that licensing
> issues may discourage me, as an OEM, from adding features to my product to
> make it better than the other guys. I add a new feature, and poof, all my
> competitors that are using the same open source system have them. (I
> realize, of course, that this is entirely dependent on the licensing, and
> has nothing to do with the OS or anything).
I understand your concern. OEMs are, in fact, capable of believing that there's no point in improving the system they offer their clients if
competitors might also benefit.
However, the circumstance you describe doesn't support that concern.
a) If an OEM's product is based on open source, or contains open source components, then the OEM's competitive advantage does not and cannot
depend on the features of the open source. Everybody already has the open source, so the competitive advantage must lie in market
penetration, or in quality of service (expertise, availability, etc), or in the features of the proprietary components.
b) There is, in fact, a benefit to adding a feature that other vendors then adopt. As the author and copyright holder, your name is in the
code they distribute; you and your expertise are being advertised to their clients. As the author of a module or feature, you are the recognized expert, and clients - either yours or your competitors' - are as likely to come to you for support and enhancement of that feature as they are to go to the vendor that supplied it.
c) Arguing from a different tack, I (and most open source advocates) maintain that you will not survive in the marketplace if your competitive advantage rests entirely on features you've implemented in your software that are unavailable anywhere else. Short of a patented software mechanism (a concept I strongly oppose), there is no feature you can provide that won't be copied and/or improved on by a competitor as soon as it is shown to be of value to the customer. All you gain from your proprietary feature is whatever market advantage accrues to being first. And that's an advantage you have to earn over and over and over, as your competitors release the next version of their software that incorporates you ideas.
> Sure, the end user gets lots of features, but I'm not the end user! I'm the
> OEM! I can no longer differentiate my product from other on a technical
> level -- removing ONE of the ways I can get ahead of my competitors.
This is true. For the most part, open source is about protecting software users from vendors, not protecting vendors from their competition. This is not to say that vendors are necessarily abusive or coercive or rapacious toward their customers; it is simply that the nature of the relationship between a customer and the vendor of a closed system places the customer at an inherent disadvantage. The open source model presumes that software is a commodity component of a larger system, and that vendors make money on something other than software unit sales.
Regards,
Greg Goodman
Chiron Consulting
Reply
|
