T
The greater the difficulty the more glory in surmounting it. Skillful pilots gain their reputation from storms and tempests. -Epictetus
Has Control.com given up already?
Has Control.com given up already?
K
Ken Crater
Sadly, we have had to discontinue our open control systems efforts, at least for the forseeable future. A combination of circumstances, including one of the softest markets in recent history, made it virtually impossible for us to establish a new control paradigm.
Another factor which weighed heavily was the reluctance of major end users to change their controls strategies. Although there is a great outcry for openness, the cost of switching from legacy technology to *anything* (including open controls) is so large as to represent a defacto lock-in.
At this point, although it's been 15 years since "open systems" seemed a foregone conclusion, I'd have to say that we're still some distance from being able to make open control a reality. However, I do not see that as a rationale for accepting things as they are. There are any number of incremental strategies that will begin to provide benefits to companies. Chief among these is the further adoption of open protocols (where we will continue to do quite a bit of work), since they create an environment where technology transitions can be more readily accomplished.
In the meantime, Control.com will continue to give voice to the automation engineers who are faced with the daily task of making all this stuff work together. I'd encourage you to keep up the pressure for openness, since even incremental change is better than none at all.
Regards to all,
Ken Crater, President
Control.com Inc.
ken@ control.com
Another factor which weighed heavily was the reluctance of major end users to change their controls strategies. Although there is a great outcry for openness, the cost of switching from legacy technology to *anything* (including open controls) is so large as to represent a defacto lock-in.
At this point, although it's been 15 years since "open systems" seemed a foregone conclusion, I'd have to say that we're still some distance from being able to make open control a reality. However, I do not see that as a rationale for accepting things as they are. There are any number of incremental strategies that will begin to provide benefits to companies. Chief among these is the further adoption of open protocols (where we will continue to do quite a bit of work), since they create an environment where technology transitions can be more readily accomplished.
In the meantime, Control.com will continue to give voice to the automation engineers who are faced with the daily task of making all this stuff work together. I'd encourage you to keep up the pressure for openness, since even incremental change is better than none at all.
Regards to all,
Ken Crater, President
Control.com Inc.
ken@ control.com
R
Richard Higginbotham
> >What happened to the Control.com Open Control
> >Laboratory? Why is there no
> >activity in promoting choice any longer? ...
> >Has Control.com given up already?
>
> Sadly, we have had to discontinue our open control systems efforts, at
> least for the forseeable future. A combination of circumstances,
> including one of the softest markets in recent history, made
> it virtually
> impossible for us to establish a new control paradigm.
I would add that there are still groups working on open choices, but such efforts take a lot of time *and* user participation. Many people wanting to skin the same cat in slightly different ways probably doesn't help much easier.
> Another factor which weighed heavily was the reluctance of major end
> users to change their controls strategies. Although there is a great
> outcry for openness, the cost of switching from legacy technology to
> *anything* (including open controls) is so large as to represent a
> defacto lock-in.
I respectfully disagree, (not in your reasons but in the attitudes of end users). I think given the choice, users would switch, I know some that certainly would. The problem is that they don't have any options that are technically equivalant. There isn't any option that is on par with what is offered by the major vendors. Asking them to support such future projects is equivilant to asking them to write blank checks since theres no one who would be held responsible if the project was never finished or was flawed and whos very goals were somewhat nebulous from an end users prospective (will it support *my* existing equipment, etc. etc.). Its a catch 22. Its hard to build something Open with very little support and its hard to get people to support something that isn't built yet (they can't make that connection with how it will help them, and so can't very well convince management to spend money to support it). It hard enough to get people to spend money for something they could get for free (why not let someone else finance it or do all the work) without them not having some concrete product to base thier justifications on. Sure you can charge for support, I'm sure theres no end to the line of integrators who would be willing to do so, and its the status quo for the end users now... Then you run into questions of who controls the development, how do we make sure it doesn't end up the same as the current proprietary solutions because integrator/vendor/etc. A wants to hedge out B.
I can't help but wonder if there were some central, organized body, with clear (inclusive) goals and an actual schedual for those goals to be
completed and metrics for how well they were completed, if there wouldn't be more user support. None of that exists yet. Even though I am willing to devote a lot of my spare time to one of those nebulous projects and wish there were more people who were interested in supporting the goals of an open control system with more than just well wishes, I understand the the reluctance to help out.
Someones got to make a large initial investment, and they need a good reason to do it. Until then, its going to be a long time before theres an open *alternative* (not just in name only). Its many man years of work (20 to 30 maybe) to make something thats polished and competitive with whats out there now.
regards,
Richard Higginbotham
> >Laboratory? Why is there no
> >activity in promoting choice any longer? ...
> >Has Control.com given up already?
>
> Sadly, we have had to discontinue our open control systems efforts, at
> least for the forseeable future. A combination of circumstances,
> including one of the softest markets in recent history, made
> it virtually
> impossible for us to establish a new control paradigm.
I would add that there are still groups working on open choices, but such efforts take a lot of time *and* user participation. Many people wanting to skin the same cat in slightly different ways probably doesn't help much easier.
> Another factor which weighed heavily was the reluctance of major end
> users to change their controls strategies. Although there is a great
> outcry for openness, the cost of switching from legacy technology to
> *anything* (including open controls) is so large as to represent a
> defacto lock-in.
I respectfully disagree, (not in your reasons but in the attitudes of end users). I think given the choice, users would switch, I know some that certainly would. The problem is that they don't have any options that are technically equivalant. There isn't any option that is on par with what is offered by the major vendors. Asking them to support such future projects is equivilant to asking them to write blank checks since theres no one who would be held responsible if the project was never finished or was flawed and whos very goals were somewhat nebulous from an end users prospective (will it support *my* existing equipment, etc. etc.). Its a catch 22. Its hard to build something Open with very little support and its hard to get people to support something that isn't built yet (they can't make that connection with how it will help them, and so can't very well convince management to spend money to support it). It hard enough to get people to spend money for something they could get for free (why not let someone else finance it or do all the work) without them not having some concrete product to base thier justifications on. Sure you can charge for support, I'm sure theres no end to the line of integrators who would be willing to do so, and its the status quo for the end users now... Then you run into questions of who controls the development, how do we make sure it doesn't end up the same as the current proprietary solutions because integrator/vendor/etc. A wants to hedge out B.
I can't help but wonder if there were some central, organized body, with clear (inclusive) goals and an actual schedual for those goals to be
completed and metrics for how well they were completed, if there wouldn't be more user support. None of that exists yet. Even though I am willing to devote a lot of my spare time to one of those nebulous projects and wish there were more people who were interested in supporting the goals of an open control system with more than just well wishes, I understand the the reluctance to help out.
Someones got to make a large initial investment, and they need a good reason to do it. Until then, its going to be a long time before theres an open *alternative* (not just in name only). Its many man years of work (20 to 30 maybe) to make something thats polished and competitive with whats out there now.
regards,
Richard Higginbotham
M
Maguire, Kevin
I think Richard says it right here:
<<Someones got to make a large initial investment, and they need a good reason to do it. Until then, its going to be a long time before theres an open *alternative* (not just in name only). Its many man years of work (20 to 30 maybe) to make something thats polished and competitive with whats out there now.>>
Is it really a wonder why no one (or group) is willing to make the enormous investment required to develop and support a truly "Open" system that can compete functionally with the "non-Open" systems that are commercially available???
- And then, not have the opportunity to recoup that investment??
There have been many emails about this subject, but I don't remember reading any offers by anyone to fund this project.
The best thing users can do is to organize and participate in standards committees, create standards and then demand that their vendors support the standards.
Capitalism works the best (flame-shield in place).
Kevin Maguire
(These views are entirely my own and not my corporate sponsor)
<<Someones got to make a large initial investment, and they need a good reason to do it. Until then, its going to be a long time before theres an open *alternative* (not just in name only). Its many man years of work (20 to 30 maybe) to make something thats polished and competitive with whats out there now.>>
Is it really a wonder why no one (or group) is willing to make the enormous investment required to develop and support a truly "Open" system that can compete functionally with the "non-Open" systems that are commercially available???
- And then, not have the opportunity to recoup that investment??
There have been many emails about this subject, but I don't remember reading any offers by anyone to fund this project.
The best thing users can do is to organize and participate in standards committees, create standards and then demand that their vendors support the standards.
Capitalism works the best (flame-shield in place).
Kevin Maguire
(These views are entirely my own and not my corporate sponsor)
C
Curt Wuollet
That is certainly one way to do it, but I disagree that it's the only way of doing it. After all, there isn't anything that large initial
investment can buy that isn't provided by people. Being paid is one reason to provide it, but it's illogical to suggest that there couldn't be other reasons for providing same. Linux, for example, would be very much the same with or without the folks trying to make money from it. One thousand users seriously committed to finding and using an open alternative would make it happen faster than any conceivable sum of money. Whether they were willing to pay for it or not. Although being
willing to pay for it _would_ provide that good reason mentioned.
Regards
cww
investment can buy that isn't provided by people. Being paid is one reason to provide it, but it's illogical to suggest that there couldn't be other reasons for providing same. Linux, for example, would be very much the same with or without the folks trying to make money from it. One thousand users seriously committed to finding and using an open alternative would make it happen faster than any conceivable sum of money. Whether they were willing to pay for it or not. Although being
willing to pay for it _would_ provide that good reason mentioned.
Regards
cww
H
Higginbotham Ricky
Kevin:
> The best thing users can do is to organize and participate in
> standards
> committees, create standards and then demand that their
> vendors support the
> standards.
Hah, What do you mean? We have standards now, we have all kinds of standards. Profibus, devicenet, IEC 1131 (who hoo, all our software is
transparent now), Siemens, AB, etc. etc. How are you going to demand support for those standards? Willing to rip out all your equipment? You guys are intelligent, trained professionals, do you really believe those silly sales pitches. This game is old, and you are the one being played.
Don't let your ego blind you from the economic reality. They don't make money by helping thier competitors.
> Capitalism works the best (flame-shield in place).
What? Free and Open Software aren't contrary to capitolism my friend. It
gets bandied about that way by people who either dont like (vendors, etc.)
or dont understand it, but its not. You have no need to look past RedHat or
IBM to see thats true.
You see nothing is *truely* free, its not that someone doesn't pay for it, its who, how, where, and perhaps most importantly *why*. When people say Free Software, they really mean free *to you*. Someone else paid the price.
The problem you have isn't capitolism, its the product itself. Someone is selling you *software* and *hardware*, they have NO, let me repeat that, *NO* interest in helping thier competitors out by allowing you to interoperate with *anything* they don't make. Thats capitolism. Their purpose isn't to serve you (surely you don't honestly believe those
salesmen), its to get you to buy thier product. *Thats* how they make money. Not by selling you a *service* (like *writing* good software), but
by selling you a *product*. They have no interest in making thier product all that great (support contracts after all), operating with other equipment, or anything else they dont feel like doing. As long as thier customers are dumb enough to put up with it, and have no other choices, they can keep on doing what they have always done.
When you *buy* free software, you are not paying for a product (you are given the product), you pay for the services. Theres no lock in, *anyone*
can develope Open Source Software, so they have to consentrate on *serving* you. Interoperability is a benefit to both the end user and the developer and the integrators. If they don't provide good service you can choose
another developer/vendor/integrator with very little cost to you (no equipment to rip out, no people to retrain) because the product is the same, its only who provides the service that changes.
> Is it really a wonder why no one (or group) is willing to
> make the enormous
> investment required to develop and support a truly "Open"
> system that can
> compete functionally with the "non-Open" systems that are commercially
> available???
>
> - And then, not have the opportunity to recoup that investment??
Pick 10 large corps with the standard software/support agreements: WW, Siemens, ABB, whatever. For the same price they pay for support for those systems they supposedly aren't happy with, they could fund an Open Source project and have something usable in a few years. Again, capitolism.
>From a cost/benefit prospective, its amazing to me no one has done it yet.
I suppose the problem is that thier blindly waiting on the vendors to do it, or someone, anyone else to foot the bill. Still, Its actually happening, there are efforts underway that are making progress. People trying to help
end users despite themselves. The work going on now is out of sheer good will. It may be slow, but at least its steady and with the best intentions of end users at heart.
But you know what, keep telling Siemens you need them to be able to support all thier equipment with your spanking new AB based control system. If that makes sense to you, if you truely believe they'd have to be anything but dirt stupid to open up and make everything transparent, then good luck. Life is going to teach you alot about capitolism.
regards,
Richard Higginbotham
> The best thing users can do is to organize and participate in
> standards
> committees, create standards and then demand that their
> vendors support the
> standards.
Hah, What do you mean? We have standards now, we have all kinds of standards. Profibus, devicenet, IEC 1131 (who hoo, all our software is
transparent now), Siemens, AB, etc. etc. How are you going to demand support for those standards? Willing to rip out all your equipment? You guys are intelligent, trained professionals, do you really believe those silly sales pitches. This game is old, and you are the one being played.
Don't let your ego blind you from the economic reality. They don't make money by helping thier competitors.
> Capitalism works the best (flame-shield in place).
What? Free and Open Software aren't contrary to capitolism my friend. It
gets bandied about that way by people who either dont like (vendors, etc.)
or dont understand it, but its not. You have no need to look past RedHat or
IBM to see thats true.
You see nothing is *truely* free, its not that someone doesn't pay for it, its who, how, where, and perhaps most importantly *why*. When people say Free Software, they really mean free *to you*. Someone else paid the price.
The problem you have isn't capitolism, its the product itself. Someone is selling you *software* and *hardware*, they have NO, let me repeat that, *NO* interest in helping thier competitors out by allowing you to interoperate with *anything* they don't make. Thats capitolism. Their purpose isn't to serve you (surely you don't honestly believe those
salesmen), its to get you to buy thier product. *Thats* how they make money. Not by selling you a *service* (like *writing* good software), but
by selling you a *product*. They have no interest in making thier product all that great (support contracts after all), operating with other equipment, or anything else they dont feel like doing. As long as thier customers are dumb enough to put up with it, and have no other choices, they can keep on doing what they have always done.
When you *buy* free software, you are not paying for a product (you are given the product), you pay for the services. Theres no lock in, *anyone*
can develope Open Source Software, so they have to consentrate on *serving* you. Interoperability is a benefit to both the end user and the developer and the integrators. If they don't provide good service you can choose
another developer/vendor/integrator with very little cost to you (no equipment to rip out, no people to retrain) because the product is the same, its only who provides the service that changes.
> Is it really a wonder why no one (or group) is willing to
> make the enormous
> investment required to develop and support a truly "Open"
> system that can
> compete functionally with the "non-Open" systems that are commercially
> available???
>
> - And then, not have the opportunity to recoup that investment??
Pick 10 large corps with the standard software/support agreements: WW, Siemens, ABB, whatever. For the same price they pay for support for those systems they supposedly aren't happy with, they could fund an Open Source project and have something usable in a few years. Again, capitolism.
>From a cost/benefit prospective, its amazing to me no one has done it yet.
I suppose the problem is that thier blindly waiting on the vendors to do it, or someone, anyone else to foot the bill. Still, Its actually happening, there are efforts underway that are making progress. People trying to help
end users despite themselves. The work going on now is out of sheer good will. It may be slow, but at least its steady and with the best intentions of end users at heart.
But you know what, keep telling Siemens you need them to be able to support all thier equipment with your spanking new AB based control system. If that makes sense to you, if you truely believe they'd have to be anything but dirt stupid to open up and make everything transparent, then good luck. Life is going to teach you alot about capitolism.
regards,
Richard Higginbotham
C
Curt Wuollet
It's not all about money, it's about committment.
If enough people make it important, it will happen. Sure it's easier and more profitable to just go along and I wouldn't ask anyone to devote more than they can afford. I recieved an offlist
message to the effect that it was a waste of time because I'd never make a nickel from it and this whole Open discussion was bad for business. Even to the point that I may never work in automation again.
To that, I quote:
If ye love wealth better than liberty, the tranquility of servitude better than the animating contest of freedom, go home from us in peace. We ask not your counsels or arms. Crouch down and lick the hands which feed you. May your
chains set lightly upon you, and may posterity forget that ye were our countrymen.
-- Samuel Adams, speech at the Philadelphia State House, August 1, 1776.
Things are the way they are only because people accept them.
Regards
cww
If enough people make it important, it will happen. Sure it's easier and more profitable to just go along and I wouldn't ask anyone to devote more than they can afford. I recieved an offlist
message to the effect that it was a waste of time because I'd never make a nickel from it and this whole Open discussion was bad for business. Even to the point that I may never work in automation again.
To that, I quote:
If ye love wealth better than liberty, the tranquility of servitude better than the animating contest of freedom, go home from us in peace. We ask not your counsels or arms. Crouch down and lick the hands which feed you. May your
chains set lightly upon you, and may posterity forget that ye were our countrymen.
-- Samuel Adams, speech at the Philadelphia State House, August 1, 1776.
Things are the way they are only because people accept them.
Regards
cww
A
Alex Pavloff
Bull!
Most of the major developers on the Linux Kernel list work for some company or another and are paid to do what they do. A check through MAINTAINERS will show you whose working on it, and there are recognizable companies in that list. A large portion of the top kernel developers work for Red Hat.
Another example -- the gcc compiler. A quick scan through the MAINTAINERS file there shows a majority of @redhat.com address.
The growth and adoption of Linux and open source software is primarly due to the desire of companies to spend large amounts of money to get the job done, not because a single guy said "oh, I think I'm going to write an OS today". You can start with one guy, but there is far, far too much work to be done to rely on guys working in their spare time and "bored grad students".
Look how far BSD has gotten. It's another unix-like free free OS, but since it has a small community and no major companies supporting it, it's a niche product.
Good intentions alone do NOT make products.
Alex Pavloff
Software Engineer
Eason Technology
Most of the major developers on the Linux Kernel list work for some company or another and are paid to do what they do. A check through MAINTAINERS will show you whose working on it, and there are recognizable companies in that list. A large portion of the top kernel developers work for Red Hat.
Another example -- the gcc compiler. A quick scan through the MAINTAINERS file there shows a majority of @redhat.com address.
The growth and adoption of Linux and open source software is primarly due to the desire of companies to spend large amounts of money to get the job done, not because a single guy said "oh, I think I'm going to write an OS today". You can start with one guy, but there is far, far too much work to be done to rely on guys working in their spare time and "bored grad students".
Look how far BSD has gotten. It's another unix-like free free OS, but since it has a small community and no major companies supporting it, it's a niche product.
Good intentions alone do NOT make products.
Alex Pavloff
Software Engineer
Eason Technology
M
Martinicky, Brian
Hi Richard,
I'll bite on a few of your statements...
> <snip>
>
> The problem you have isn't capitolism, its the product itself. Someone is selling you *software* and *hardware*, they have NO, let me repeat that, *NO* interest in helping thier competitors out by allowing you to interoperate with *anything* they don't make.
As a software developer for an open controls vendor for the last 10+ years, I would beg to differ that vendors have *NO* interest in interoperability. While automation lore has its share of legendary Big Automation Vendors using incompatibility to lock in customers, you can bet that the open controls movement (which is not insignificant) is a result of these customers wising up.
There are a substantial number of big-name customers that are very interested in open standards, and show their support through funding pilot projects, etc., so that open control technologies can have a fighting chance in the real world. Though economics and politics still represent formidable barriers to entry for many open control vendors, the tide *is* changing; just slower than many would like.
Witness the recent AB adoption of SERCOS. Even though their implementation defies the spirit of what SERCOS was supposed to be all about, they
nonetheless grasped the value of creating a drive family that was based on the IEC-1491 standard.
> <snip>
>
> When you *buy* free software, you are not paying for a product (you are given the product), you pay for the services. There's no lock in, *anyone* can develope Open Source Software, so they have to consentrate on *serving* you. Interoperability is a benefit to both the end user and the developer and the integrators. If they don't provide good service you can choose another developer/vendor/integrator with very little cost to you (no equipment to rip out, no people to retrain) because the product is the same, its only who provides the service that changes.
I hear this freedom of choice argument a lot when it comes to the service-based model of Open Source Software. While it is true that holding
the keys to the source affords one a level of security that sets it apart from traditional software products, to represent a switch to a new service provider as a cheap flick of the switch is, at best, inaccurate.
I am betting that by the time that company X has reached the conclusion that service provider Y is not meeting their needs, a significant amount money, time, etc. will have been lost by the time a glitchless switch is thrown. The model you describe seems to slowly erode the ability of any company to differentiate its services and/or products. Perhaps there is "good" differentiation and "bad" differentiation, but it seems that differentiation is a necessary fuel for healthy competition...
Regards,
Brian
-
Brian Martinicky
Manager, Software Development
Automation Intelligence, Inc.
Duluth, GA USA
I'll bite on a few of your statements...
> <snip>
>
> The problem you have isn't capitolism, its the product itself. Someone is selling you *software* and *hardware*, they have NO, let me repeat that, *NO* interest in helping thier competitors out by allowing you to interoperate with *anything* they don't make.
As a software developer for an open controls vendor for the last 10+ years, I would beg to differ that vendors have *NO* interest in interoperability. While automation lore has its share of legendary Big Automation Vendors using incompatibility to lock in customers, you can bet that the open controls movement (which is not insignificant) is a result of these customers wising up.
There are a substantial number of big-name customers that are very interested in open standards, and show their support through funding pilot projects, etc., so that open control technologies can have a fighting chance in the real world. Though economics and politics still represent formidable barriers to entry for many open control vendors, the tide *is* changing; just slower than many would like.
Witness the recent AB adoption of SERCOS. Even though their implementation defies the spirit of what SERCOS was supposed to be all about, they
nonetheless grasped the value of creating a drive family that was based on the IEC-1491 standard.
> <snip>
>
> When you *buy* free software, you are not paying for a product (you are given the product), you pay for the services. There's no lock in, *anyone* can develope Open Source Software, so they have to consentrate on *serving* you. Interoperability is a benefit to both the end user and the developer and the integrators. If they don't provide good service you can choose another developer/vendor/integrator with very little cost to you (no equipment to rip out, no people to retrain) because the product is the same, its only who provides the service that changes.
I hear this freedom of choice argument a lot when it comes to the service-based model of Open Source Software. While it is true that holding
the keys to the source affords one a level of security that sets it apart from traditional software products, to represent a switch to a new service provider as a cheap flick of the switch is, at best, inaccurate.
I am betting that by the time that company X has reached the conclusion that service provider Y is not meeting their needs, a significant amount money, time, etc. will have been lost by the time a glitchless switch is thrown. The model you describe seems to slowly erode the ability of any company to differentiate its services and/or products. Perhaps there is "good" differentiation and "bad" differentiation, but it seems that differentiation is a necessary fuel for healthy competition...
Regards,
Brian
-
Brian Martinicky
Manager, Software Development
Automation Intelligence, Inc.
Duluth, GA USA
M
Maguire, Kevin
OK Richard...
I don't know what happened between my post (where I agreed with what you said) and the response that apparently came from you.
I didn't say that free and open software was contrary to capitalism. I said that it explains the slow evolution of free and open software solutions for applications that typically are very complex and require support. If there isn't a way to recoup the investment, there tends to be little investment.
I'm glad that you were able to point out the folly of software support agreements for commercially-available software. I'm sure that many of the good folks on this list will recommend to their management that they abandon
the commercially-available software running their factories and begin funding their own custom software that is based on "truly" open platforms.
Their management will appreciate the creative thinking and likely support their effort.
After the conversion of the automation software, they could then move on to convert the remaining packages of commercially-available, non-open software that is at their company. The ERP system would be the next project.
Then, they could do the WMS, CAD, Labor Scheduling, Finite Capacity Scheduling, Asset Mgt. and WIP tracking systems...
I'll continue to support commercially-available systems as the most reasonable approach until the functionality and dependability of the open-source stuff comes close.
- And thanks for your concern about my ego blinding my perceptions. I'm confident that both my ego and my perceptions are fairly well-balanced.
Cheers!
I don't know what happened between my post (where I agreed with what you said) and the response that apparently came from you.
I didn't say that free and open software was contrary to capitalism. I said that it explains the slow evolution of free and open software solutions for applications that typically are very complex and require support. If there isn't a way to recoup the investment, there tends to be little investment.
I'm glad that you were able to point out the folly of software support agreements for commercially-available software. I'm sure that many of the good folks on this list will recommend to their management that they abandon
the commercially-available software running their factories and begin funding their own custom software that is based on "truly" open platforms.
Their management will appreciate the creative thinking and likely support their effort.
After the conversion of the automation software, they could then move on to convert the remaining packages of commercially-available, non-open software that is at their company. The ERP system would be the next project.
Then, they could do the WMS, CAD, Labor Scheduling, Finite Capacity Scheduling, Asset Mgt. and WIP tracking systems...
I'll continue to support commercially-available systems as the most reasonable approach until the functionality and dependability of the open-source stuff comes close.
- And thanks for your concern about my ego blinding my perceptions. I'm confident that both my ego and my perceptions are fairly well-balanced.
Cheers!
J
Jiri Baum
> I think Richard says it right here:
> <<Someones got to make a large initial investment, and they need a
> good reason to do it. Until then, its going to be a long time before
> theres an open *alternative* (not just in name only). Its many man
> years of work (20 to 30 maybe) to make something thats polished and
> competitive with whats out there now.>>
Kevin Maguire:
> Is it really a wonder why no one (or group) is willing to make the
> enormous investment required to develop and support a truly "Open"
> system that can compete functionally with the "non-Open" systems that
> are commercially available???
The other way of developing it, without the enormous investment, is by degrees: right now MAT doesn't do much, but it can already shuffle data
between Modbus/CANopen/Profibus/etc with a little processing (scaling, speed/accel limit, even digital logic if you'll countenance mnemonics).
If one person adopts it, even for a prototype or something, and in the process of using it contributes a man-week, then that's a man-week
that'll stay with the project forever.
As these small contributions add up, they'll bring the project to within the requirements of additional users, thus forming a cycle: users lead
to more users. Even just evaluating it and making the evaluation available to the project contributes, as a ``wishlist bug report''.
It's perhaps the slow way to do it, but a steady, sure way.
Jiri
--
Jiri Baum <[email protected]> http://www.csse.monash.edu.au/~jirib
MAT LinuxPLC project --- http://mat.sf.net --- Machine Automation Tools
> <<Someones got to make a large initial investment, and they need a
> good reason to do it. Until then, its going to be a long time before
> theres an open *alternative* (not just in name only). Its many man
> years of work (20 to 30 maybe) to make something thats polished and
> competitive with whats out there now.>>
Kevin Maguire:
> Is it really a wonder why no one (or group) is willing to make the
> enormous investment required to develop and support a truly "Open"
> system that can compete functionally with the "non-Open" systems that
> are commercially available???
The other way of developing it, without the enormous investment, is by degrees: right now MAT doesn't do much, but it can already shuffle data
between Modbus/CANopen/Profibus/etc with a little processing (scaling, speed/accel limit, even digital logic if you'll countenance mnemonics).
If one person adopts it, even for a prototype or something, and in the process of using it contributes a man-week, then that's a man-week
that'll stay with the project forever.
As these small contributions add up, they'll bring the project to within the requirements of additional users, thus forming a cycle: users lead
to more users. Even just evaluating it and making the evaluation available to the project contributes, as a ``wishlist bug report''.
It's perhaps the slow way to do it, but a steady, sure way.
Jiri
--
Jiri Baum <[email protected]> http://www.csse.monash.edu.au/~jirib
MAT LinuxPLC project --- http://mat.sf.net --- Machine Automation Tools
R
Richard Higginbotham
Brain:
>I'll bite on a few of your statements...
Hello, and Excellent.
Ricky:
> <snip>
>
> The problem you have isn't capitolism, its the product itself. Someone is selling you *software* and *hardware*, they have NO, let me repeat that, *NO* interest in helping thier competitors out by allowing you to interoperate with *anything* they don't make.
Brian:
>As a software developer for an open controls vendor for the last 10+ years, I would beg to differ that vendors have *NO* interest in interoperability. While
>automation lore has its share of legendary Big Automation Vendors using incompatibility to lock in customers, you can bet that the open controls movement
>(which is not insignificant) is a result of these customers wising up.
I didn't say they had no interest in interoperability (quite the opposite in fact), I said they had no interesest in *helping thier competitors* by interoperating with things they don't make. If I'm not in the business of making widgets of type X, I dont really care if all widgets of type X can talk to each other and freely exchange subwidgets, etc. However, I if I make a widget of type X, It behooves me to distinguish myself somehow so that other people will buy my product and as much of its secondary products from me as possible. Theres only so many ways you can distinguish yourself from the competition. In the automation market a tried and true method is "lock in". You said yourself the "Open Controls" (Open is twisted/misapplied so much, I'm not sure if what I consider open is what you consider "open") movement is a result of **customers** wising up, not Big Vendors drive to loose market share.
Brian:
>There are a substantial number of big-name customers that are very interested in open standards, and show their support through funding pilot projects,
>etc., so that open control technologies can have a fighting chance in the real world. Though economics and politics still represent formidable barriers to
>entry for many open control vendors, the tide *is* changing; just slower than many would like.
I wonder if the tide is really changing. I dont doubt theres some small "progress" is being made from a users standpoint, but I wonder how much the big vendors are really giving up. It amazing how much progress one can make, then stop, look around, and realize you're not really that far from where you started. I remember when IEC1131 was the next great standard and that PLC software would be totally transparent across brands...
>Witness the recent AB adoption of SERCOS. Even though their implementation defies the spirit of what SERCOS was supposed to be all about, they
>nonetheless grasped the value of creating a drive family that was based on the IEC-1491 standard.
Standards in an of themselves mean nothing. Standards can be good, bad, or largely in between. I dont know anything about SERCOS, but I would venture to guess "the value" had far more to do with marketing points (customer relations) than any desire to make it easier for another PLC maker to talk to thier drives. Standards are somewhat benefitial, but there are a lot of ways to lock people in to your implementation while still complying with the "standard". Not sure in this case.
Ricky
>> <snip>
>>
>> When you *buy* free software, you are not paying for a product (you are given the product), you pay for the services. There's no lock in, *anyone* can develope Open Source Software, so they have to consentrate on *serving* you. Interoperability is a benefit to both the end user and the developer and the integrators. If they don't provide good service you can choose another developer/vendor/integrator with very little cost to you (no equipment to rip out, no people to retrain) because the product is the same, its only who provides the service that changes.
Brian:
>I hear this freedom of choice argument a lot when it comes to the service-based model of Open Source Software. While it is true that holding
the keys to the source affords one a level of security that sets it apart from traditional software products, to represent a switch to a new service provider as a cheap flick of the switch is, at best, inaccurate.
heh, well, ok then. I'd agree that, generally, when you make a mistake you generally realize it after the fact and it costs you something. What I'm saying, and I dont think its too far of a leap, is that the fewer things that are affected by this "change" the less it will cost you. If i change my PLC brands, I've got potientally a lot of equipment to rip out. I've got to buy/install the new equipment(hardware and software), train my personel on the new equipment, etc. That is generally why customers dont do it. By contrast, If I simply decide to buy PLC brand A from a different supplier, I have probably reduced my costs *dramatically*. While not absolutely painless, it can be *relatively*, "a cheap flick of the switch."
Brain:
>I am betting that by the time that company X has reached the conclusion that service provider Y is not meeting their needs, a significant amount money, time, etc. will have been lost by the time a glitchless switch is thrown. The model you describe seems to slowly erode the ability of any company to differentiate its services and/or products. Perhaps there is "good" differentiation and "bad" differentiation, but it seems that differentiation is a necessary fuel for healthy competition...
Funnily enough, every time I look at different vendor offerings, I say to my self "its the same old stuff wrapped up in a different box".
The model I describe not only makes it more difficult to differentiate ones self from ones competitors, it drastically increases the importance of doing so simply by removing the walls (if I were a vendor I would probably call it a safety net ;-) ). How do you differentiate yourself? "Lock in", Price, Service, Specialization, etc. If I remove "lock in", suddenly the others are far more important. "Lock in" is no longer the big stick, to make the other ways of differentiation of very little importance. If anything "lock in" is anti-competitive and preventing us from having "healthy competition" now. There are still plenty of ways of distinguishing yourself from the competition. The hope is that they are will be of benefit to the consumer, whereas now, to their detriment.
regards,
Richard Higginbotham
>I'll bite on a few of your statements...
Hello, and Excellent.
Ricky:
> <snip>
>
> The problem you have isn't capitolism, its the product itself. Someone is selling you *software* and *hardware*, they have NO, let me repeat that, *NO* interest in helping thier competitors out by allowing you to interoperate with *anything* they don't make.
Brian:
>As a software developer for an open controls vendor for the last 10+ years, I would beg to differ that vendors have *NO* interest in interoperability. While
>automation lore has its share of legendary Big Automation Vendors using incompatibility to lock in customers, you can bet that the open controls movement
>(which is not insignificant) is a result of these customers wising up.
I didn't say they had no interest in interoperability (quite the opposite in fact), I said they had no interesest in *helping thier competitors* by interoperating with things they don't make. If I'm not in the business of making widgets of type X, I dont really care if all widgets of type X can talk to each other and freely exchange subwidgets, etc. However, I if I make a widget of type X, It behooves me to distinguish myself somehow so that other people will buy my product and as much of its secondary products from me as possible. Theres only so many ways you can distinguish yourself from the competition. In the automation market a tried and true method is "lock in". You said yourself the "Open Controls" (Open is twisted/misapplied so much, I'm not sure if what I consider open is what you consider "open") movement is a result of **customers** wising up, not Big Vendors drive to loose market share.
Brian:
>There are a substantial number of big-name customers that are very interested in open standards, and show their support through funding pilot projects,
>etc., so that open control technologies can have a fighting chance in the real world. Though economics and politics still represent formidable barriers to
>entry for many open control vendors, the tide *is* changing; just slower than many would like.
I wonder if the tide is really changing. I dont doubt theres some small "progress" is being made from a users standpoint, but I wonder how much the big vendors are really giving up. It amazing how much progress one can make, then stop, look around, and realize you're not really that far from where you started. I remember when IEC1131 was the next great standard and that PLC software would be totally transparent across brands...
>Witness the recent AB adoption of SERCOS. Even though their implementation defies the spirit of what SERCOS was supposed to be all about, they
>nonetheless grasped the value of creating a drive family that was based on the IEC-1491 standard.
Standards in an of themselves mean nothing. Standards can be good, bad, or largely in between. I dont know anything about SERCOS, but I would venture to guess "the value" had far more to do with marketing points (customer relations) than any desire to make it easier for another PLC maker to talk to thier drives. Standards are somewhat benefitial, but there are a lot of ways to lock people in to your implementation while still complying with the "standard". Not sure in this case.
Ricky
>> <snip>
>>
>> When you *buy* free software, you are not paying for a product (you are given the product), you pay for the services. There's no lock in, *anyone* can develope Open Source Software, so they have to consentrate on *serving* you. Interoperability is a benefit to both the end user and the developer and the integrators. If they don't provide good service you can choose another developer/vendor/integrator with very little cost to you (no equipment to rip out, no people to retrain) because the product is the same, its only who provides the service that changes.
Brian:
>I hear this freedom of choice argument a lot when it comes to the service-based model of Open Source Software. While it is true that holding
the keys to the source affords one a level of security that sets it apart from traditional software products, to represent a switch to a new service provider as a cheap flick of the switch is, at best, inaccurate.
heh, well, ok then. I'd agree that, generally, when you make a mistake you generally realize it after the fact and it costs you something. What I'm saying, and I dont think its too far of a leap, is that the fewer things that are affected by this "change" the less it will cost you. If i change my PLC brands, I've got potientally a lot of equipment to rip out. I've got to buy/install the new equipment(hardware and software), train my personel on the new equipment, etc. That is generally why customers dont do it. By contrast, If I simply decide to buy PLC brand A from a different supplier, I have probably reduced my costs *dramatically*. While not absolutely painless, it can be *relatively*, "a cheap flick of the switch."
Brain:
>I am betting that by the time that company X has reached the conclusion that service provider Y is not meeting their needs, a significant amount money, time, etc. will have been lost by the time a glitchless switch is thrown. The model you describe seems to slowly erode the ability of any company to differentiate its services and/or products. Perhaps there is "good" differentiation and "bad" differentiation, but it seems that differentiation is a necessary fuel for healthy competition...
Funnily enough, every time I look at different vendor offerings, I say to my self "its the same old stuff wrapped up in a different box".
The model I describe not only makes it more difficult to differentiate ones self from ones competitors, it drastically increases the importance of doing so simply by removing the walls (if I were a vendor I would probably call it a safety net ;-) ). How do you differentiate yourself? "Lock in", Price, Service, Specialization, etc. If I remove "lock in", suddenly the others are far more important. "Lock in" is no longer the big stick, to make the other ways of differentiation of very little importance. If anything "lock in" is anti-competitive and preventing us from having "healthy competition" now. There are still plenty of ways of distinguishing yourself from the competition. The hope is that they are will be of benefit to the consumer, whereas now, to their detriment.
regards,
Richard Higginbotham
H
Higginbotham Ricky
Hi Jiri,
Please forgive me while I speak to the choir ;-).
Jiri:
> The other way of developing it, without the enormous investment, is by
> degrees: right now MAT doesn't do much, but it can already
> shuffle data
> between Modbus/CANopen/Profibus/etc with a little processing (scaling,
> speed/accel limit, even digital logic if you'll countenance
> mnemonics).
While I agree in spirit, the point I wanted to make is thats its an enormous investment anyway you look at it. We can make it now, or we can make it slowly but theres still a lot of work to be done. The more resources that are devoted to it, the less time it will take. If people are impatient and see value in Open Automation projects, then an investment now will pay off
later. A lot of people sitting on the side lines saying "Are you done yet?", doesn't make the process any faster. A lot of people who stand to
benefit by contributing to the project, *will* make the process not only faster, better, but also more beneficial to them personally (by making sure their needs are taken to account in the development process). Even something as simple as feature requests can be helpful. If theres anything in your industry that would be useful to you but might not be on the mainstream "wish list", let us know. Its hard to build a foundation if you dont know what its going to hold.
Take source code control for example. Its a modern convenience programers are accustomed to having. You can get an excellent revision history of MAT using cvs. Its trivial to find out what the differences are between the current version and some other previous versions as well as who made those changes. As simple as it is to use, not to mention the many free version control packages, its noticably absent from most vendor products. Anyone who deals with government bodies like the FDA or has a lot of developers
working on the same equipment (or large complicated systems, etc.) could find a huge benefit in good Version Control. Why don't we have this as a standard part of every product?
Before I get any silly answers, No, I'm not talking about about being able to see the last ladder changes made to a PLC program (compared to PC version, thats cake), I'm talking an entire revision history (with ePaper Trail) that can't get "accidentally" altered and that is integrated
seamlessly into the programming environment and that will deal with multiple "branches".
If you want end users concerns to trumpet those of OEMs, then by all means, get involved. If you want higher level langages, Object Orientation,
support for particular hardware, whatever, now is the best time.
Jiri:
> As these small contributions add up, they'll bring the
> project to within
> the requirements of additional users, thus forming a cycle: users lead
> to more users. Even just evaluating it and making the evaluation
> available to the project contributes, as a ``wishlist bug report''.
Yes, once "critical mass" has been achieved (which is what a lot of people are afraid of, the very same people who get over a $1000 for an ethernet card), there won't be any way to even compete against an Open Solution. Price will be the smallest incentive (and in many cases it is now). The big payoff will be in productivity and functionality. There certainly won't be any shortage of people offering support. Hardware vendors won't die, but they won't be burdened (nor burden us) with doing things they aren't very
good at either.
OSS doesn't need to lie about its features, it doesn't have to spread false rumors (misinformation) about its competition (or itself), it has no money to "buy" favors so that you're stuck with a horrible product because someone in upper management wanted a free night out, it doesn't have to hide its flaws for fear potiential users might find out (it actually flaunts them, and *fixes* them quickly), it doesn't have salesmen to pressure or lie to you or "unique features" to lock you in. Best of all, its development done the way engineers would do it, and by some of the very people who use it
most. Diverse people with diverse goals can all work on it and find benefit, from large corporations to idealistic hobbiest. Most of us have different goals, different ideas of "sucess" and values, but we can all agree that a product based on the interest of Users and Developers is worth the price.
If theres any testiment to how good this will be, its the reaction on this list. When ever you have vendors pronouncing the virtues of standardization and throwing about straw men arguements (like I dont know, how its a silly
unworkable idea and anyone who likes it is against Capitolism ie. Free Software Communist) you know you are on to something good.
For anyone interested in substance over hype in a business discussion of Open Source Software, I suggest:
Magic Cauldron
"http://www.tuxedo.org/~esr/writings/magic-cauldron/magic-cauldron.html":http://www.tuxedo.org/~esr/writings/magic-cauldron/magic-cauldron.html
The Cathedral and the Bazaar
"http://www.tuxedo.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/":http://www.tuxedo.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/
regards
Richard Higginbotham
(speaking for me)
Please forgive me while I speak to the choir ;-).
Jiri:
> The other way of developing it, without the enormous investment, is by
> degrees: right now MAT doesn't do much, but it can already
> shuffle data
> between Modbus/CANopen/Profibus/etc with a little processing (scaling,
> speed/accel limit, even digital logic if you'll countenance
> mnemonics).
While I agree in spirit, the point I wanted to make is thats its an enormous investment anyway you look at it. We can make it now, or we can make it slowly but theres still a lot of work to be done. The more resources that are devoted to it, the less time it will take. If people are impatient and see value in Open Automation projects, then an investment now will pay off
later. A lot of people sitting on the side lines saying "Are you done yet?", doesn't make the process any faster. A lot of people who stand to
benefit by contributing to the project, *will* make the process not only faster, better, but also more beneficial to them personally (by making sure their needs are taken to account in the development process). Even something as simple as feature requests can be helpful. If theres anything in your industry that would be useful to you but might not be on the mainstream "wish list", let us know. Its hard to build a foundation if you dont know what its going to hold.
Take source code control for example. Its a modern convenience programers are accustomed to having. You can get an excellent revision history of MAT using cvs. Its trivial to find out what the differences are between the current version and some other previous versions as well as who made those changes. As simple as it is to use, not to mention the many free version control packages, its noticably absent from most vendor products. Anyone who deals with government bodies like the FDA or has a lot of developers
working on the same equipment (or large complicated systems, etc.) could find a huge benefit in good Version Control. Why don't we have this as a standard part of every product?
Before I get any silly answers, No, I'm not talking about about being able to see the last ladder changes made to a PLC program (compared to PC version, thats cake), I'm talking an entire revision history (with ePaper Trail) that can't get "accidentally" altered and that is integrated
seamlessly into the programming environment and that will deal with multiple "branches".
If you want end users concerns to trumpet those of OEMs, then by all means, get involved. If you want higher level langages, Object Orientation,
support for particular hardware, whatever, now is the best time.
Jiri:
> As these small contributions add up, they'll bring the
> project to within
> the requirements of additional users, thus forming a cycle: users lead
> to more users. Even just evaluating it and making the evaluation
> available to the project contributes, as a ``wishlist bug report''.
Yes, once "critical mass" has been achieved (which is what a lot of people are afraid of, the very same people who get over a $1000 for an ethernet card), there won't be any way to even compete against an Open Solution. Price will be the smallest incentive (and in many cases it is now). The big payoff will be in productivity and functionality. There certainly won't be any shortage of people offering support. Hardware vendors won't die, but they won't be burdened (nor burden us) with doing things they aren't very
good at either
.OSS doesn't need to lie about its features, it doesn't have to spread false rumors (misinformation) about its competition (or itself), it has no money to "buy" favors so that you're stuck with a horrible product because someone in upper management wanted a free night out, it doesn't have to hide its flaws for fear potiential users might find out (it actually flaunts them, and *fixes* them quickly), it doesn't have salesmen to pressure or lie to you or "unique features" to lock you in. Best of all, its development done the way engineers would do it, and by some of the very people who use it
most. Diverse people with diverse goals can all work on it and find benefit, from large corporations to idealistic hobbiest. Most of us have different goals, different ideas of "sucess" and values, but we can all agree that a product based on the interest of Users and Developers is worth the price.
If theres any testiment to how good this will be, its the reaction on this list. When ever you have vendors pronouncing the virtues of standardization and throwing about straw men arguements (like I dont know, how its a silly
unworkable idea and anyone who likes it is against Capitolism ie. Free Software Communist) you know you are on to something good.
For anyone interested in substance over hype in a business discussion of Open Source Software, I suggest:
Magic Cauldron
"http://www.tuxedo.org/~esr/writings/magic-cauldron/magic-cauldron.html":http://www.tuxedo.org/~esr/writings/magic-cauldron/magic-cauldron.html
The Cathedral and the Bazaar
"http://www.tuxedo.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/":http://www.tuxedo.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/
regards
Richard Higginbotham
(speaking for me)
C
Curt Wuollet
Hi Alex.
What you say may well be true. But you are putting the cart before the horse. Many of these folks, Linus included, worked on the kernel
first, before there was any company with the money to hire them to do it. It's nice that they now get paid to do it, and the support of those
companies should be appreciated by the community. but Linux was coming along just as nicely before the grab for Linux talent. In fact, the commercial pressure has been a hindrance to the effort with a few notable exceptions. And except for the superstars, most of the developers who show up in the distros do something else for a living. If I can find it, I'll post a recent study of developer demographics. Most of the money seems to be going to GUI development and porting. And as for BSD, look at the commercial BSDs They're going noplace. Sorry, I'm not buying that the old model is neccesary or superior. The investments have merely clouded the issue.
Regards
cww
What you say may well be true. But you are putting the cart before the horse. Many of these folks, Linus included, worked on the kernel
first, before there was any company with the money to hire them to do it. It's nice that they now get paid to do it, and the support of those
companies should be appreciated by the community. but Linux was coming along just as nicely before the grab for Linux talent. In fact, the commercial pressure has been a hindrance to the effort with a few notable exceptions. And except for the superstars, most of the developers who show up in the distros do something else for a living. If I can find it, I'll post a recent study of developer demographics. Most of the money seems to be going to GUI development and porting. And as for BSD, look at the commercial BSDs They're going noplace. Sorry, I'm not buying that the old model is neccesary or superior. The investments have merely clouded the issue.
Regards
cww
C
Curt Wuollet
Hi Kevin
Kevin Maguire wrote:
>
> OK Richard...
>
> I don't know what happened between my post (where I agreed with what you
> said) and the response that apparently came from you.
>
> I didn't say that free and open software was contrary to capitalism. I
> said that it explains the slow evolution of free and open software
> solutions for applications that typically are very complex and require
> support. If there isn't a way to recoup the investment, there tends to
> be little investment.
>
> I'm glad that you were able to point out the folly of software support
> agreements for commercially-available software. I'm sure that many of
> the good folks on this list will recommend to their management that they
> abandon the commercially-available software running their factories and
> begin funding their own custom software that is based on "truly" open
> platforms.
They don't have to roll their own. There will be plenty of free and Open choices from what I've seen so far. And for the most part they are from
deadly serious people of equal or greater caliber than any who build the commercial products.
> Their management will appreciate the creative thinking and likely
> support their effort.
The management will like the cost savings and decreased exposure to the policies and excess of others. The vastly increased versatility of software and hardware that is tweakable and free from artificial connectivity and interoperability boundaries will raise the success to failure ratio. The dependence on outside support will plummet and the knowledge will reside in the company. Licensing hassles will be just a bad memory.
> After the conversion of the automation software, they could then move on
> to convert the remaining packages of commercially-available, non-open
> software that is at their company. The ERP system would be the next
> project.
Can do. We reviewed sevaral packages that will run on Linux with at least one available as OSS.
> Then, they could do the WMS, CAD, Labor Scheduling, Finite Capacity
> Scheduling, Asset Mgt. and WIP tracking systems...
No problem. And at sharply reduced cost. Or you can use SAP on Linux if that gives you the warm fuzzies.
And you can put 9 of the 10 servers you needed with Windows to productive use somewhare else. Or you can cluster them for fun to have the fastest inventory updates in the business.
> I'll continue to support commercially-available systems as the most
> reasonable approach until the functionality and dependability of the
> open-source stuff comes close.
You should have quit a while ago then. As a standard platform for SAP, Oracle, and IBM, with many financial institutions and mission
critical E-Commerce sites, Linux has certainly met that standard. I'll be happy to cite examples if you wish. The last company I worked at has been mission critical on Linux for years. Of course, a lot of serious manufacturing software never left UNIX in the first place. I'd simply love to debate the functionality of Linux in a Linux environment. Especially what you can do "out of the box" without that big checkbook.
> - And thanks for your concern about my ego blinding my perceptions. I'm
> confident that both my ego and my perceptions are fairly well-balanced.
Most people who suffer from the malady do actually believe this. And most Microsoft Partners do their best to reinforce the notion.
But as "server software", manufacturing systems are great candidates and fit right in the center of the Linux envelope. It's only the very slow turnover of these large capital investments thats limiting uptake.
Regards
cww
Kevin Maguire wrote:
>
> OK Richard...
>
> I don't know what happened between my post (where I agreed with what you
> said) and the response that apparently came from you.
>
> I didn't say that free and open software was contrary to capitalism. I
> said that it explains the slow evolution of free and open software
> solutions for applications that typically are very complex and require
> support. If there isn't a way to recoup the investment, there tends to
> be little investment.
>
> I'm glad that you were able to point out the folly of software support
> agreements for commercially-available software. I'm sure that many of
> the good folks on this list will recommend to their management that they
> abandon the commercially-available software running their factories and
> begin funding their own custom software that is based on "truly" open
> platforms.
They don't have to roll their own. There will be plenty of free and Open choices from what I've seen so far. And for the most part they are from
deadly serious people of equal or greater caliber than any who build the commercial products.
> Their management will appreciate the creative thinking and likely
> support their effort.
The management will like the cost savings and decreased exposure to the policies and excess of others. The vastly increased versatility of software and hardware that is tweakable and free from artificial connectivity and interoperability boundaries will raise the success to failure ratio. The dependence on outside support will plummet and the knowledge will reside in the company. Licensing hassles will be just a bad memory.
> After the conversion of the automation software, they could then move on
> to convert the remaining packages of commercially-available, non-open
> software that is at their company. The ERP system would be the next
> project.
Can do. We reviewed sevaral packages that will run on Linux with at least one available as OSS.
> Then, they could do the WMS, CAD, Labor Scheduling, Finite Capacity
> Scheduling, Asset Mgt. and WIP tracking systems...
No problem. And at sharply reduced cost. Or you can use SAP on Linux if that gives you the warm fuzzies.
And you can put 9 of the 10 servers you needed with Windows to productive use somewhare else. Or you can cluster them for fun to have the fastest inventory updates in the business.
> I'll continue to support commercially-available systems as the most
> reasonable approach until the functionality and dependability of the
> open-source stuff comes close.
You should have quit a while ago then. As a standard platform for SAP, Oracle, and IBM, with many financial institutions and mission
critical E-Commerce sites, Linux has certainly met that standard. I'll be happy to cite examples if you wish. The last company I worked at has been mission critical on Linux for years. Of course, a lot of serious manufacturing software never left UNIX in the first place. I'd simply love to debate the functionality of Linux in a Linux environment. Especially what you can do "out of the box" without that big checkbook.
> - And thanks for your concern about my ego blinding my perceptions. I'm
> confident that both my ego and my perceptions are fairly well-balanced.
Most people who suffer from the malady do actually believe this. And most Microsoft Partners do their best to reinforce the notion.
But as "server software", manufacturing systems are great candidates and fit right in the center of the Linux envelope. It's only the very slow turnover of these large capital investments thats limiting uptake.
Regards
cww
A
Alex Pavloff
Curt said:
>What you say may well be true. But you are putting the cart before the
>horse. Many of these folks, Linus included, worked on the kernel first,
>before there was any company with the money to hire them to do it.
I am of the firm belief that to make a project sucessful, you've got to spend all your working hours on it.
Case in point -- your Puffin PLC project has been going since (I believe) December 1999, and yet you are still, according to your home page, in
pre-alpha. Imagine what one of your developers could have done if he could have spent all his time on developing the LinuxPLC/PuffinPLC/MAT.
Major projects cannot be done in "Spare Time".
>It's nice that they now get paid to do it, and the support of those
>companies should be appreciated by the community. but Linux was coming
>along just as nicely before the grab for Linux talent. In fact, the
>commercial pressure has been a hindrance to the effort with a few
>notable exceptions.
Would you care to elaborate on this? How has "commercial pressure" been a hindrance? Please back this up with links from "superstars" where they complain about this.
>And except for the superstars, most of the developers who show up in the
>distros do something else for a living.
Many device drivers have "people that do other things for a living" listed as their owners, rather than the manufacturers. This makes sense -- I would have no problems writing a device driver for a piece of hardware if I needed to get the job done.
Break device drivers out from the kernel and you'll see a very, very small group of people doing development. Its hard and very technical work, and these people are either independently wealthy or are being paid to do what they do. Average Joe developer is NOT qualified to work on guts of the Linux Kernel.
>If I can find it, I'll post a recent study of developer demographics. Most
>of the money seems to be going to GUI development and porting.
I would be interested in seeing this.
>And as for BSD, look at the commercial BSDs They're going noplace. Sorry,
>I'm not buying that the old model is neccesary or superior.
Linux has cannibalized market share from every other Unix-like OS on the market. Why? Simple -- a large amount of COMPANIES poured money into it.
The money poured into Linux went into paying developers what they like to do, which let them focus on their various projects, which led to very
capable software that everyone could use. How could any one company compete against ten or so major companies and hundreds of little companies in effect pooling their software development budgets? They couldn't. That's why the only places commercial UNIX flavors are still sucessful is in the far upper end of computing.
When I said the BSDs, I was referring to the Free BSDs. There was no investment there, hence (mainly) little hardware support, and therefore, it wasn't nearly as useful.
Alex Pavloff
Software Engineer
Eason Technology
>What you say may well be true. But you are putting the cart before the
>horse. Many of these folks, Linus included, worked on the kernel first,
>before there was any company with the money to hire them to do it.
I am of the firm belief that to make a project sucessful, you've got to spend all your working hours on it.
Case in point -- your Puffin PLC project has been going since (I believe) December 1999, and yet you are still, according to your home page, in
pre-alpha. Imagine what one of your developers could have done if he could have spent all his time on developing the LinuxPLC/PuffinPLC/MAT.
Major projects cannot be done in "Spare Time".
>It's nice that they now get paid to do it, and the support of those
>companies should be appreciated by the community. but Linux was coming
>along just as nicely before the grab for Linux talent. In fact, the
>commercial pressure has been a hindrance to the effort with a few
>notable exceptions.
Would you care to elaborate on this? How has "commercial pressure" been a hindrance? Please back this up with links from "superstars" where they complain about this.
>And except for the superstars, most of the developers who show up in the
>distros do something else for a living.
Many device drivers have "people that do other things for a living" listed as their owners, rather than the manufacturers. This makes sense -- I would have no problems writing a device driver for a piece of hardware if I needed to get the job done.
Break device drivers out from the kernel and you'll see a very, very small group of people doing development. Its hard and very technical work, and these people are either independently wealthy or are being paid to do what they do. Average Joe developer is NOT qualified to work on guts of the Linux Kernel.
>If I can find it, I'll post a recent study of developer demographics. Most
>of the money seems to be going to GUI development and porting.
I would be interested in seeing this.
>And as for BSD, look at the commercial BSDs They're going noplace. Sorry,
>I'm not buying that the old model is neccesary or superior.
Linux has cannibalized market share from every other Unix-like OS on the market. Why? Simple -- a large amount of COMPANIES poured money into it.
The money poured into Linux went into paying developers what they like to do, which let them focus on their various projects, which led to very
capable software that everyone could use. How could any one company compete against ten or so major companies and hundreds of little companies in effect pooling their software development budgets? They couldn't. That's why the only places commercial UNIX flavors are still sucessful is in the far upper end of computing.
When I said the BSDs, I was referring to the Free BSDs. There was no investment there, hence (mainly) little hardware support, and therefore, it wasn't nearly as useful.
Alex Pavloff
Software Engineer
Eason Technology
R
Ralph Mackiewicz
> > The problem you have isn't capitolism, its the product itself.
> > Someone is selling you *software* and *hardware*, they have NO, let
> > me repeat that, *NO* interest in helping thier competitors out by
> > allowing you to interoperate with *anything* they don't make. Thats
> > capitolism. Their purpose isn't to serve you (surely you don't
> > honestly believe those salesmen), its to get you to buy thier
> > product.
> > *Thats* how they make money. Not by selling you a *service* (like
> > *writing* good software), but by selling you a *product*. They have
> > no interest in making thier product all that great (support
> > contracts after all), operating with other equipment, or anything
> > else they dont feel like doing. As long as thier customers are dumb
> > enough to put up with it, and have no other choices, they can keep
> > on doing what they have always done.
This is the biggest pile of malarky that I have seen in quite a while. This sounds bitter and mean. I'm sorry that you've had some bad experiences with product vendors (apparently). But to paint all product vendors with this brush is unwarranted and downright wrong. There are plenty of companies out there that deliver *good* *products* based on what their customers tell them they want. *Thats* how they make money. Just because their customers aren't telling them that they want an open source solution that can be obtained anywhere doesn't mean that they are engaged in some kind of nefarious and under-handed scheme to force lousy junk onto their un-witting customers. I have personally worked with, worked for, cooperated with, competed with, socialized with, fired, and hired many different people that have worked for these big bad companies that sell proprietary solutions. I can tell you from first hand experience that, nearly to the person, they were all decent individuals with a genuine concern for the well being of their customers (in other words the salesmen were telling the truth). These are the kind of people that work at my company and we make products. We routinely help our customers (who are all very smart by the
way) interoperate with the inferior products of our competitors. So do most of our competitors for that matter. So do our customers with their customers. Just because a company doesn't do everything you think they should does not make them as bad as they were painted above. I've said it before, and I'll say it again: This approach is not going to win many converts to the open source solution approach. Nor will it stimulate investment in open source. You need a logical, rational, and unemotional argument grounded in a solid business case. Not unsupportable claims of good and evil.
Regards,
Ralph Mackiewicz
> > Someone is selling you *software* and *hardware*, they have NO, let
> > me repeat that, *NO* interest in helping thier competitors out by
> > allowing you to interoperate with *anything* they don't make. Thats
> > capitolism. Their purpose isn't to serve you (surely you don't
> > honestly believe those salesmen), its to get you to buy thier
> > product.
> > *Thats* how they make money. Not by selling you a *service* (like
> > *writing* good software), but by selling you a *product*. They have
> > no interest in making thier product all that great (support
> > contracts after all), operating with other equipment, or anything
> > else they dont feel like doing. As long as thier customers are dumb
> > enough to put up with it, and have no other choices, they can keep
> > on doing what they have always done.
This is the biggest pile of malarky that I have seen in quite a while. This sounds bitter and mean. I'm sorry that you've had some bad experiences with product vendors (apparently). But to paint all product vendors with this brush is unwarranted and downright wrong. There are plenty of companies out there that deliver *good* *products* based on what their customers tell them they want. *Thats* how they make money. Just because their customers aren't telling them that they want an open source solution that can be obtained anywhere doesn't mean that they are engaged in some kind of nefarious and under-handed scheme to force lousy junk onto their un-witting customers. I have personally worked with, worked for, cooperated with, competed with, socialized with, fired, and hired many different people that have worked for these big bad companies that sell proprietary solutions. I can tell you from first hand experience that, nearly to the person, they were all decent individuals with a genuine concern for the well being of their customers (in other words the salesmen were telling the truth). These are the kind of people that work at my company and we make products. We routinely help our customers (who are all very smart by the
way) interoperate with the inferior products of our competitors. So do most of our competitors for that matter. So do our customers with their customers. Just because a company doesn't do everything you think they should does not make them as bad as they were painted above. I've said it before, and I'll say it again: This approach is not going to win many converts to the open source solution approach. Nor will it stimulate investment in open source. You need a logical, rational, and unemotional argument grounded in a solid business case. Not unsupportable claims of good and evil.
Regards,
Ralph Mackiewicz
R
Richard Higginbotham
Ralph,
My arguement is without good or evil. Its just pragmatism (or at least as close as I can come as a human being). I actually haven't had any true
"bad" (nor "good") experiences with vendors. I'm a contractor so someone else is always paying for what ever problems I come across. If ABs software
is buggy and I sit for a week waiting on the fix, it doesn't cost me anything. If some Siemens stuff is clunky and inefficient to use, ditto
(doesn't cost me a dime). I learned a long time ago, that the best fit for me (as a lazy person) was to do as much as possible in the shortest amount of time with the least effort. I would rather be paid more to work less than be paid less to work more. So I'm very interested in tools with a high level of productivity for what I do (my particular bias). I understand that
I can see problems with a product that other people don't (and in fact both of us can be "right" because we have different POV), you know that whole beauty in the eye of the beholder thing. The subject is immaterial to those who are completely satisfied in their current situation so I don't/didn't address them. If you buy stuff from Vendor A and you feel like you're
treated pretty well, you're not searching for something better, its kind of a mute point, right? On the other hand, if you feel like you've gotten a raw deal or just want more, then I think my points have merit. Why do i think so? Because if I worked for a vendor (one of the "bad" ones) thats probably how I would feel. Even if you don't take action on it, if the
economy is tight and you are looking at laying off people you've worked with for years, you're gonna think that "proprietary" is not such a dirty word. You don't *have* to be evil for it to cross your mind. Implementation of such schemes, well, its obvious how I feel about that. I'll also point out Proprietary *can* be another word for innovation (its not always bad to be different so maybe theres no bad intention there), but I don't think thats generally the case in the automation world (regardless what some might say).
> experiences with product vendors (apparently). But to paint all
> product vendors with this brush is unwarranted and downright wrong.
> There are plenty of companies out there that deliver *good* *products*
> based on what their customers tell them they want. *Thats*
> how they make
> money.
Woa, I never said *all* vendors. Hope I didn't imply it. Remember, we were talking about dissatified customers who were being told to "support standards" *with* thier vendors as the best they could do (this whole OSS thing will never work). Nor is there a single person or local group that I would point to to lay blame for any defficiencies I've seen. By the same
token, I'm sure you wouldn't say that all companies deliever *good* *products* (as that is as much of a trap as saying they all do not). No one is perfect. For a select group of applications, I see the major offerings as being decidedly "uninspired". Thats my view, I neither desire nor require it to be yours. Actually, for those users who are satisfied, i'll be happy
for them.
> Just because their customers aren't telling them that they want
> an open source solution that can be obtained anywhere doesn't
> mean that
> they are engaged in some kind of nefarious and under-handed scheme to
> force lousy junk onto their un-witting customers.
I'll ignore the conspiracy theory... What *are* thier customers telling them? I'm interested. I've known times when they were screaming for
features they'd been "promised", but it fell on uncaring ears. I've also known times when there was a quick response, but as I work with the Siemens 505 line, I remember far more of the former. I know people who go to the users group meetings and beg/plead/threaten and get no results (or empty promises). So pardon me if I speak to them and try to address thier concerns.
I wouldn't be the least bit surprised if it (what vendors are being told) didn't have anything to do with "Open Source". I'm ok with that. Of
course, thats a perception I hope changes, but thats another topic.
> I have personally
> worked with, worked for, cooperated with, competed with, socialized
> with, fired, and hired many different people that have
> worked for these big bad companies that sell proprietary solutions.
I've worked for/with them too. Lots of good, skilled people I'd be happy to work with again. That doesn't mean I'm going to say I always like
everything thier company does, or that I must like the products they deliver if I think they could have done a better job. Good people do not
necessarily equal good company/products (and vise versa), decisions are made at many levels that can affect the "product" at the end users level. Its not always good, its not always bad. Its business as in, it just is.
> So do most of our competitors for that matter. So do our
> customers with their customers. Just because a company doesn't do
> everything you think they should does not make them as bad as
> they were
> painted above.
>This approach
> is not going to win many converts to the open source solution
> approach.
> Nor will it stimulate investment in open source. You need a logical,
> rational, and unemotional argument grounded in a solid
> business case. Not unsupportable claims of good and evil. Nor will it
> stimulate investment in open source. You need a logical,
> rational, and unemotional argument grounded in a solid
> business case. Not unsupportable claims of good and evil.
I agree emotionalism wont get us anywhere. Though your post sounded a lot like a good vs. evil arguement to me, only with vendors being the good guys.
For context, Lets do a quick recap. I say, dont give up on OSS yet, we just need to be able to put something in peoples hand and figure out ways to help them support it. Someone else (vendor) says, it wont work and its no surprise, users best bet is to get involve with standards comitees. I said thats a lost cause. If those vendors are pulling the strings of the standards commitees you probably wont get where you think you're going, and "demanding" from some vendors especially those the size of Siemens is a joke
for almost all users (plus general helpings of sarcasm ;-) ). I then point out reasons why OSS from a pure developer/supplier *motivation* standpoint can be better than the current model (which I think is a sound argument). You get insulted because you think I must mean you and your friends.
Well, I guess I do mean you, but probably not how you think. I don't think you have any nefarious plans, but do you not think you would make more money with a completely proprietary offering than one that was completely open? Is that too far of a reach? Its not that such a market *requires* all vendors to take advantage of customers, its that it enables too many of
them too (makes it easier). Vendors work hard to get the equipment in the door, then they act according to thier own (sometime local, sometimes not) whims. Some try hard to keep pleasing their customers, some mostly let it slide (only do what they feel they need to) because they're either to
egomanical to think their customers would switch or they realise the costs of doing so are too prohibitive (and maybe a couple reasons I haven't
thought of). There *are* users who support more than one system just to keep the vendors honest. This is of course all dependant on the particular
situations one finds oneselves in, YMMV.
OSS has benefits above and beyond that, those are just the concerns I happened to want to point out at the time. I'm sure you serve your customers with good will, as do I. That doesn't mean everyone does (no matter how many good people you know and work with, as do i).
regards,
Richard Higginbotham
My arguement is without good or evil. Its just pragmatism (or at least as close as I can come as a human being). I actually haven't had any true
"bad" (nor "good") experiences with vendors. I'm a contractor so someone else is always paying for what ever problems I come across. If ABs software
is buggy and I sit for a week waiting on the fix, it doesn't cost me anything. If some Siemens stuff is clunky and inefficient to use, ditto
(doesn't cost me a dime). I learned a long time ago, that the best fit for me (as a lazy person) was to do as much as possible in the shortest amount of time with the least effort. I would rather be paid more to work less than be paid less to work more. So I'm very interested in tools with a high level of productivity for what I do (my particular bias). I understand that
I can see problems with a product that other people don't (and in fact both of us can be "right" because we have different POV), you know that whole beauty in the eye of the beholder thing. The subject is immaterial to those who are completely satisfied in their current situation so I don't/didn't address them. If you buy stuff from Vendor A and you feel like you're
treated pretty well, you're not searching for something better, its kind of a mute point, right? On the other hand, if you feel like you've gotten a raw deal or just want more, then I think my points have merit. Why do i think so? Because if I worked for a vendor (one of the "bad" ones) thats probably how I would feel. Even if you don't take action on it, if the
economy is tight and you are looking at laying off people you've worked with for years, you're gonna think that "proprietary" is not such a dirty word. You don't *have* to be evil for it to cross your mind. Implementation of such schemes, well, its obvious how I feel about that. I'll also point out Proprietary *can* be another word for innovation (its not always bad to be different so maybe theres no bad intention there), but I don't think thats generally the case in the automation world (regardless what some might say).
> experiences with product vendors (apparently). But to paint all
> product vendors with this brush is unwarranted and downright wrong.
> There are plenty of companies out there that deliver *good* *products*
> based on what their customers tell them they want. *Thats*
> how they make
> money.
Woa, I never said *all* vendors. Hope I didn't imply it. Remember, we were talking about dissatified customers who were being told to "support standards" *with* thier vendors as the best they could do (this whole OSS thing will never work). Nor is there a single person or local group that I would point to to lay blame for any defficiencies I've seen. By the same
token, I'm sure you wouldn't say that all companies deliever *good* *products* (as that is as much of a trap as saying they all do not). No one is perfect. For a select group of applications, I see the major offerings as being decidedly "uninspired". Thats my view, I neither desire nor require it to be yours. Actually, for those users who are satisfied, i'll be happy
for them.
> Just because their customers aren't telling them that they want
> an open source solution that can be obtained anywhere doesn't
> mean that
> they are engaged in some kind of nefarious and under-handed scheme to
> force lousy junk onto their un-witting customers.
I'll ignore the conspiracy theory... What *are* thier customers telling them? I'm interested. I've known times when they were screaming for
features they'd been "promised", but it fell on uncaring ears. I've also known times when there was a quick response, but as I work with the Siemens 505 line, I remember far more of the former. I know people who go to the users group meetings and beg/plead/threaten and get no results (or empty promises). So pardon me if I speak to them and try to address thier concerns.
I wouldn't be the least bit surprised if it (what vendors are being told) didn't have anything to do with "Open Source". I'm ok with that. Of
course, thats a perception I hope changes, but thats another topic.
> I have personally
> worked with, worked for, cooperated with, competed with, socialized
> with, fired, and hired many different people that have
> worked for these big bad companies that sell proprietary solutions.
I've worked for/with them too. Lots of good, skilled people I'd be happy to work with again. That doesn't mean I'm going to say I always like
everything thier company does, or that I must like the products they deliver if I think they could have done a better job. Good people do not
necessarily equal good company/products (and vise versa), decisions are made at many levels that can affect the "product" at the end users level. Its not always good, its not always bad. Its business as in, it just is.
> So do most of our competitors for that matter. So do our
> customers with their customers. Just because a company doesn't do
> everything you think they should does not make them as bad as
> they were
> painted above.
>This approach
> is not going to win many converts to the open source solution
> approach.
> Nor will it stimulate investment in open source. You need a logical,
> rational, and unemotional argument grounded in a solid
> business case. Not unsupportable claims of good and evil. Nor will it
> stimulate investment in open source. You need a logical,
> rational, and unemotional argument grounded in a solid
> business case. Not unsupportable claims of good and evil.
I agree emotionalism wont get us anywhere. Though your post sounded a lot like a good vs. evil arguement to me, only with vendors being the good guys.
For context, Lets do a quick recap. I say, dont give up on OSS yet, we just need to be able to put something in peoples hand and figure out ways to help them support it. Someone else (vendor) says, it wont work and its no surprise, users best bet is to get involve with standards comitees. I said thats a lost cause. If those vendors are pulling the strings of the standards commitees you probably wont get where you think you're going, and "demanding" from some vendors especially those the size of Siemens is a joke
for almost all users (plus general helpings of sarcasm ;-) ). I then point out reasons why OSS from a pure developer/supplier *motivation* standpoint can be better than the current model (which I think is a sound argument). You get insulted because you think I must mean you and your friends.
Well, I guess I do mean you
, but probably not how you think. I don't think you have any nefarious plans, but do you not think you would make more money with a completely proprietary offering than one that was completely open? Is that too far of a reach? Its not that such a market *requires* all vendors to take advantage of customers, its that it enables too many ofthem too (makes it easier). Vendors work hard to get the equipment in the door, then they act according to thier own (sometime local, sometimes not) whims. Some try hard to keep pleasing their customers, some mostly let it slide (only do what they feel they need to) because they're either to
egomanical to think their customers would switch or they realise the costs of doing so are too prohibitive (and maybe a couple reasons I haven't
thought of). There *are* users who support more than one system just to keep the vendors honest. This is of course all dependant on the particular
situations one finds oneselves in, YMMV.
OSS has benefits above and beyond that, those are just the concerns I happened to want to point out at the time. I'm sure you serve your customers with good will, as do I. That doesn't mean everyone does (no matter how many good people you know and work with, as do i).
regards,
Richard Higginbotham
M
Martinicky, Brian
Hi Richard,
Me again...
> <snip>
>
> I didn't say they had no interest in interoperability (quite the
> opposite in fact), I said they had no interesest in *helping thier
> competitors* by interoperating with things they don't make.
> If I'm not in the business of making widgets of type X, I dont
> really care if all widgets of type X can talk to each other and
> freely exchange subwidgets, etc.
> However, I if I make a widget of type X, It behooves me to
> distinguish myself somehow so that other people will buy my
> product and as much of its secondary products from me as possible.
> Theres only so many ways you can distinguish yourself from the
> competition. In the automation market a tried and true method is
> "lock in". You said yourself the "Open Controls" (Open is
> twisted/misapplied so much, I'm not sure if what I consider open
> is what you consider "open") movement is a result of **customers**
> wising up, not Big Vendors drive to loose market share.
I guess that's what I was saying. It may be just a terminology game, but I do not consider interoperability within a single company's product families to be true interoperability. I consider that to be lock-in bait.
To me, interoperability means taking a leap of sorts and making products that seamlessly connect to those of other manufacturers, even if those other products compete with your own. For example, my company is owned by a motor/drive manufacturer, but we make a SERCOS-based motion controller that operates with many other manufacturer's drives. We would be blissfully happy if every controller we shipped also went out with our motors/drives, but that is not the case. Never once have we considered schemes to force customers to purchase our motors/drives in order to purchase our controller, despite the fact that the real money is in the drives/motors. An analogous situation exists with PLCs and I/O, with I/O being the money-maker.
My guess is that Big Automation Vendors stumbled upon the lock-in mechanism after they achieved a level of market penetration that made it possible.
While it is tempting to view the lock-in phenomena as an evil-minded offensive strategy, my sense is that it is often an artifact of trying to create products with increased value. For example, if I decide to create a widget, I can choose to embrace non-proprietary, widely supported technologies in its design. However, what if I think I can build a better mousetrap? I may decide to build a better mousetrap, forgoing available technologies, but still providing backward links to my old products. Before I know it, I have families of products that all work together, just not with other company's products, and people accusing me of some evil plot to
exploit consumers.
> <snip>
>
> ...I remember when IEC1131 was the next great
> standard and that PLC software would be totally transparent across
> brands...
True enough, but it seems to me that the initial "sputtering" of the IEC-1131 movement in terms of vendor neutrality has more to do with the
scope and complexity of the problem than a lack of desire for, or availability of, a solution. The problem took a long time to grow, and it will take a long time to solve...
> <snip>
>
> heh, well, ok then. I'd agree that, generally, when you make
> a mistake
> you generally realize it after the fact and it costs you something.
> What I'm saying, and I dont think its too far of a leap, is that the
> fewer things that are affected by this "change" the less it will cost
> you. If i change my PLC brands, I've got potientally a lot
> of equipment
> to rip out. I've got to buy/install the new equipment(hardware and
> software), train my personel on the new equipment, etc. That is
> generally why customers dont do it. By contrast, If I simply
> decide to
> buy PLC brand A from a different supplier, I have probably reduced my
> costs *dramatically*. While not absolutely painless, it can be
> *relatively*, "a cheap flick of the switch."
I guess this is where our viewpoints diverge. In the OSS model, the nature of PLCx is really an aggregation of the source and those who provide the services. In other words, I assert that if I hold the keys to the source and rely on a 3rd party to service me by customizing/maintaining it for me, then when I have changed service providers, am I still left with PLCx? I can't
help but think that with a new service provider I now have something like a PLCy, since the service provider is an integral part of PLCx. They still
look like two different PLCs to me in the end...
> <snip>
>
> Funnily enough, every time I look at different vendor offerings, I say
> to my self "its the same old stuff wrapped up in a different box".
>
> The model I describe not only makes it more difficult to differentiate
> ones self from ones competitors, it drastically increases the
> importance
> of doing so simply by removing the walls (if I were a vendor I would
> probably call it a safety net ;-) ).
This a difficult concept for me, since all markets eventually evolve into price-competitive ones. If it's the same old stuff in a different box, and you know enough to make that determination, are you likely to shop by price
at this point?
Is prospering from one's ability to create novel software mechanisms different from another's ability to provide service? While some "walls" are
no doubt up intentionally, doesn't labeling all walls as provide unfair advantage to service providers over product innovators?
At what point does creating a better mousetrap cease to be an opportunity to prosper from one's ability to innovate and become an anti-competitive plot?
> How do you differentiate yourself?
We differentiate on expertise, capability, and relationships with our customers. Getting to the right person does not take an involved journey
through a winding bureaucracy. Got a problem? Here, talk to the person directly responsible for X...
Regards,
Brian
Me again...
> <snip>
>
> I didn't say they had no interest in interoperability (quite the
> opposite in fact), I said they had no interesest in *helping thier
> competitors* by interoperating with things they don't make.
> If I'm not in the business of making widgets of type X, I dont
> really care if all widgets of type X can talk to each other and
> freely exchange subwidgets, etc.
> However, I if I make a widget of type X, It behooves me to
> distinguish myself somehow so that other people will buy my
> product and as much of its secondary products from me as possible.
> Theres only so many ways you can distinguish yourself from the
> competition. In the automation market a tried and true method is
> "lock in". You said yourself the "Open Controls" (Open is
> twisted/misapplied so much, I'm not sure if what I consider open
> is what you consider "open") movement is a result of **customers**
> wising up, not Big Vendors drive to loose market share.
I guess that's what I was saying. It may be just a terminology game, but I do not consider interoperability within a single company's product families to be true interoperability. I consider that to be lock-in bait.
To me, interoperability means taking a leap of sorts and making products that seamlessly connect to those of other manufacturers, even if those other products compete with your own. For example, my company is owned by a motor/drive manufacturer, but we make a SERCOS-based motion controller that operates with many other manufacturer's drives. We would be blissfully happy if every controller we shipped also went out with our motors/drives, but that is not the case. Never once have we considered schemes to force customers to purchase our motors/drives in order to purchase our controller, despite the fact that the real money is in the drives/motors. An analogous situation exists with PLCs and I/O, with I/O being the money-maker.
My guess is that Big Automation Vendors stumbled upon the lock-in mechanism after they achieved a level of market penetration that made it possible.
While it is tempting to view the lock-in phenomena as an evil-minded offensive strategy, my sense is that it is often an artifact of trying to create products with increased value. For example, if I decide to create a widget, I can choose to embrace non-proprietary, widely supported technologies in its design. However, what if I think I can build a better mousetrap? I may decide to build a better mousetrap, forgoing available technologies, but still providing backward links to my old products. Before I know it, I have families of products that all work together, just not with other company's products, and people accusing me of some evil plot to
exploit consumers.
> <snip>
>
> ...I remember when IEC1131 was the next great
> standard and that PLC software would be totally transparent across
> brands...
True enough, but it seems to me that the initial "sputtering" of the IEC-1131 movement in terms of vendor neutrality has more to do with the
scope and complexity of the problem than a lack of desire for, or availability of, a solution. The problem took a long time to grow, and it will take a long time to solve...
> <snip>
>
> heh, well, ok then. I'd agree that, generally, when you make
> a mistake
> you generally realize it after the fact and it costs you something.
> What I'm saying, and I dont think its too far of a leap, is that the
> fewer things that are affected by this "change" the less it will cost
> you. If i change my PLC brands, I've got potientally a lot
> of equipment
> to rip out. I've got to buy/install the new equipment(hardware and
> software), train my personel on the new equipment, etc. That is
> generally why customers dont do it. By contrast, If I simply
> decide to
> buy PLC brand A from a different supplier, I have probably reduced my
> costs *dramatically*. While not absolutely painless, it can be
> *relatively*, "a cheap flick of the switch."
I guess this is where our viewpoints diverge. In the OSS model, the nature of PLCx is really an aggregation of the source and those who provide the services. In other words, I assert that if I hold the keys to the source and rely on a 3rd party to service me by customizing/maintaining it for me, then when I have changed service providers, am I still left with PLCx? I can't
help but think that with a new service provider I now have something like a PLCy, since the service provider is an integral part of PLCx. They still
look like two different PLCs to me in the end...
> <snip>
>
> Funnily enough, every time I look at different vendor offerings, I say
> to my self "its the same old stuff wrapped up in a different box".
>
> The model I describe not only makes it more difficult to differentiate
> ones self from ones competitors, it drastically increases the
> importance
> of doing so simply by removing the walls (if I were a vendor I would
> probably call it a safety net ;-) ).
This a difficult concept for me, since all markets eventually evolve into price-competitive ones. If it's the same old stuff in a different box, and you know enough to make that determination, are you likely to shop by price
at this point?
Is prospering from one's ability to create novel software mechanisms different from another's ability to provide service? While some "walls" are
no doubt up intentionally, doesn't labeling all walls as provide unfair advantage to service providers over product innovators?
At what point does creating a better mousetrap cease to be an opportunity to prosper from one's ability to innovate and become an anti-competitive plot?
> How do you differentiate yourself?
We differentiate on expertise, capability, and relationships with our customers. Getting to the right person does not take an involved journey
through a winding bureaucracy. Got a problem? Here, talk to the person directly responsible for X...
Regards,
Brian
C
Curt Wuollet
Alex Pavloff wrote:
> Curt said:
>
>>What you say may well be true. But you are putting the cart before the
>>horse. Many of these folks, Linus included, worked on the kernel first,
>>before there was any company with the money to hire them to do it.
>
> I am of the firm belief that to make a project sucessful, you've got to
> spend all your working hours on it.
That's counter to the whole Linux experience. If you have small development group or a single individual that may well be true, particularly if you have a short window of opportunity. But an
awful lot of the crucial Linux code has been done by part time developers like Donald Becker, who wrote many of the networking drivers and countless others. Even Linus spends a lot of his time on microprocessors rather than Linux. The enabling factor is the Open Source. People are constantly dropping in and out of development and maintainership. In recent times, there are even
competing implementations, even on crucial subsystems like memory management. If someone needs to spend time on something else,(like a life) usually someone else picks it up and
development simply goes on. And patches come in from all over, often from people who have never contributed before. It would be very difficult to equate this model with full time, heads down,
coders. For every active (superstar) coder in the "official" crew, there are usually several in the wings who fully understand the code and would be happy to step in. They are obviously not
full time kernel developers. It's a whole different model, but it seems to work despite the occasional chaos and disagreement.
> Case in point -- your Puffin PLC project has been going since (I
> believe) December 1999, and yet you are still, according to your home
> page, in pre-alpha. Imagine what one of your developers could have done
> if he could have spent all his time on developing the
> LinuxPLC/PuffinPLC/MAT.
We simply lack the number of developers to make the model really work. But we define success differently as well. Fortunately, the rate of
advancement in automation is such that we don't have much to worry about. The only way we could be beat in "time to market" would be if the majors decided to open up all their stuff. Or another OSS group with more resources passes us up. But either one of those is still a win when success is defined as having Open alternatives for users. A win for us and a win for the users. Even if we get beat we can't lose. Taking money out of the equation really raises the odds for success.
> Major projects cannot be done in "Spare Time".
With enough participation, that's simply not true. The vast majority
of Linux developers are Spare Time developers. They may write code
for a living, but it's often not Linux related. I'll post a URL to the
study that was done recently.
>
>>It's nice that they now get paid to do it, and the support of those
>>companies should be appreciated by the community. but Linux was coming
>>along just as nicely before the grab for Linux talent. In fact, the
>>commercial pressure has been a hindrance to the effort with a few
>>notable exceptions.
>
> Would you care to elaborate on this? How has "commercial pressure" been
> a hindrance? Please back this up with links from "superstars" where
> they complain about this.
The superstars don't usually complain. Code that's other than GPL or tainted is simply dropped on the floor and closed drivers are
simply not supported. Outside the kernel, witness the momentum lost for KDE until Trolltech opened their licensing and the fact that all the big names are behind Gnome hasn't helped it compete. IBM has the biggest clue, they realize that the best way to help is by the rules and to provide marketing. Sun on the other hand, wants to make their own Linux and it's very difficult to see where that would help.
>
>>And except for the superstars, most of the developers who show up in
>>the distros do something else for a living.
>
> Many device drivers have "people that do other things for a living"
> listed as their owners, rather than the manufacturers. This makes sense
> -- I would have no problems writing a device driver for a piece of
> hardware if I needed to get the job done.
>
> Break device drivers out from the kernel and you'll see a very, very
> small group of people doing development. Its hard and very technical
> work, and these people are either independently wealthy or are being
> paid to do what they do. Average Joe developer is NOT qualified to work
> on guts of the Linux Kernel.
The group that is at any time is smaller than the group that can. And yes, it's more exclusive as time goes on. But with the job they are doing, Joe developer doesn't need to work on the kernel, you have to be pretty good to improve on what's there. But conversely, the kernel is a very small part of the phenomena known as Linux. And the list of names of folks who have contributed to a typical distribution is a very, very, large list. My name may even still be in there. Or, probably not, I haven't had to fix anything for a very long time. I do agree with you to this extent, I'd like to get paid for it:^) The closest I have come is developing automation software on Linux and getting paid for that. But, I have contributed what I could and it didn't affect my standard of living at all. And it would be silly to imply that the work I contributed was of any lower quality than what I got paid for. (Both
were equally mediocre, but it works. :^))
>
>>If I can find it, I'll post a recent study of developer demographics.
>>Most of the money seems to be going to GUI development and porting.
>
> I would be interested in seeing this.
I'll hunt it down. I've been kinda busy job hunting.
>
>>And as for BSD, look at the commercial BSDs They're going noplace.
>>Sorry, I'm not buying that the old model is neccesary or superior.
>
> Linux has cannibalized market share from every other Unix-like OS on the
> market. Why? Simple -- a large amount of COMPANIES poured money into
> it. The money poured into Linux went into paying developers what they
> like to do, which let them focus on their various projects, which led to
> very capable software that everyone could use. How could any one
> company compete against ten or so major companies and hundreds of little
> companies in effect pooling their software development budgets? They
> couldn't. That's why the only places commercial UNIX flavors are still
> sucessful is in the far upper end of computing.
I will, for the sake of argument, accept that. And I'll discount the success of Debian, which nobody has poured money into. Okay, what has
this done? The effect has been nothing but positive. We, _all of us_, have a state of the art, Free, Open, platform that is inherently a
level playing field for all. Even Microsoft is free to use it or contribute, or port their apps on equal terms with the smallest of ISVs. The overall UNIX market has grown, reversing a dismal trend. Soon, there will be competition again, in servers there already is. Where's the down side? Anything that IBM lost on AIX they've gained on Linux, Sun and HP are perfectly free to do the same. Small players can matter again. If you think it's unfair that these folks have found
a way to break the monopoly, you won't get much sympathy from me. I really, seriously, doubt that anyone is shedding crocodile tears for Bill Gates. If he can't compete with products he owns, he's free to compete on a level playing field that everyone owns. I just hope they don't contribute much code. Whether people paid or didn't pay to level the playing field, a level field and a common platform are good things, aren't they? It has all the good points of
standardizing on a platform, in fact, many more than standardizing on Microsoft. And, if everybody works on that one platform, it's sure
to get better, faster, than Microsoft has been willing to do. I might kinda miss the struggle, but it would be so much better for everyone that I could adapt. At least I could find work :^)
> When I said the BSDs, I was referring to the Free BSDs. There was no
> investment there, hence (mainly) little hardware support, and therefore,
> it wasn't nearly as useful.
They are perfectly free to use any and all hardware support available for Linux. All they have to do is change their licensing to keep the
code Open. In looking at the drivers, most of them are still third party anyway. Written in spite of the hardware vendors in many cases.
Cooperation, much less investment, has been a long time coming. Perhaps users have figured out that _can_ be Open is not as good for them as _must_ be Open. There is nothing technically wrong with the Free BSDs, it must be the philosophy.
In short, OSS is not going away. It doesn't require the commercial model, or it would never have existed at all. The currancy is time not money and the investment has come because it's a better deal for everyone but Microsoft. Money can certainly help in that it can buy time, but time exists with or without money and everybody's got some. It only hurts those who won't play on a level field and every contribution helps everybody. It is quite novel to see companies
investing money to help each other and everyone else. Automation could use a healthy dose of this to solve the problems that the other model has created and enforced. What's wrong with that? Am I missing something?
Regards
cww
> Curt said:
>
>>What you say may well be true. But you are putting the cart before the
>>horse. Many of these folks, Linus included, worked on the kernel first,
>>before there was any company with the money to hire them to do it.
>
> I am of the firm belief that to make a project sucessful, you've got to
> spend all your working hours on it.
That's counter to the whole Linux experience. If you have small development group or a single individual that may well be true, particularly if you have a short window of opportunity. But an
awful lot of the crucial Linux code has been done by part time developers like Donald Becker, who wrote many of the networking drivers and countless others. Even Linus spends a lot of his time on microprocessors rather than Linux. The enabling factor is the Open Source. People are constantly dropping in and out of development and maintainership. In recent times, there are even
competing implementations, even on crucial subsystems like memory management. If someone needs to spend time on something else,(like a life) usually someone else picks it up and
development simply goes on. And patches come in from all over, often from people who have never contributed before. It would be very difficult to equate this model with full time, heads down,
coders. For every active (superstar) coder in the "official" crew, there are usually several in the wings who fully understand the code and would be happy to step in. They are obviously not
full time kernel developers. It's a whole different model, but it seems to work despite the occasional chaos and disagreement.
> Case in point -- your Puffin PLC project has been going since (I
> believe) December 1999, and yet you are still, according to your home
> page, in pre-alpha. Imagine what one of your developers could have done
> if he could have spent all his time on developing the
> LinuxPLC/PuffinPLC/MAT.
We simply lack the number of developers to make the model really work. But we define success differently as well. Fortunately, the rate of
advancement in automation is such that we don't have much to worry about. The only way we could be beat in "time to market" would be if the majors decided to open up all their stuff. Or another OSS group with more resources passes us up. But either one of those is still a win when success is defined as having Open alternatives for users. A win for us and a win for the users. Even if we get beat we can't lose. Taking money out of the equation really raises the odds for success.
> Major projects cannot be done in "Spare Time".
With enough participation, that's simply not true. The vast majority
of Linux developers are Spare Time developers. They may write code
for a living, but it's often not Linux related. I'll post a URL to the
study that was done recently.
>
>>It's nice that they now get paid to do it, and the support of those
>>companies should be appreciated by the community. but Linux was coming
>>along just as nicely before the grab for Linux talent. In fact, the
>>commercial pressure has been a hindrance to the effort with a few
>>notable exceptions.
>
> Would you care to elaborate on this? How has "commercial pressure" been
> a hindrance? Please back this up with links from "superstars" where
> they complain about this.
The superstars don't usually complain. Code that's other than GPL or tainted is simply dropped on the floor and closed drivers are
simply not supported. Outside the kernel, witness the momentum lost for KDE until Trolltech opened their licensing and the fact that all the big names are behind Gnome hasn't helped it compete. IBM has the biggest clue, they realize that the best way to help is by the rules and to provide marketing. Sun on the other hand, wants to make their own Linux and it's very difficult to see where that would help.
>
>>And except for the superstars, most of the developers who show up in
>>the distros do something else for a living.
>
> Many device drivers have "people that do other things for a living"
> listed as their owners, rather than the manufacturers. This makes sense
> -- I would have no problems writing a device driver for a piece of
> hardware if I needed to get the job done.
>
> Break device drivers out from the kernel and you'll see a very, very
> small group of people doing development. Its hard and very technical
> work, and these people are either independently wealthy or are being
> paid to do what they do. Average Joe developer is NOT qualified to work
> on guts of the Linux Kernel.
The group that is at any time is smaller than the group that can. And yes, it's more exclusive as time goes on. But with the job they are doing, Joe developer doesn't need to work on the kernel, you have to be pretty good to improve on what's there. But conversely, the kernel is a very small part of the phenomena known as Linux. And the list of names of folks who have contributed to a typical distribution is a very, very, large list. My name may even still be in there. Or, probably not, I haven't had to fix anything for a very long time. I do agree with you to this extent, I'd like to get paid for it:^) The closest I have come is developing automation software on Linux and getting paid for that. But, I have contributed what I could and it didn't affect my standard of living at all. And it would be silly to imply that the work I contributed was of any lower quality than what I got paid for. (Both
were equally mediocre, but it works. :^))
>
>>If I can find it, I'll post a recent study of developer demographics.
>>Most of the money seems to be going to GUI development and porting.
>
> I would be interested in seeing this.
I'll hunt it down. I've been kinda busy job hunting.
>
>>And as for BSD, look at the commercial BSDs They're going noplace.
>>Sorry, I'm not buying that the old model is neccesary or superior.
>
> Linux has cannibalized market share from every other Unix-like OS on the
> market. Why? Simple -- a large amount of COMPANIES poured money into
> it. The money poured into Linux went into paying developers what they
> like to do, which let them focus on their various projects, which led to
> very capable software that everyone could use. How could any one
> company compete against ten or so major companies and hundreds of little
> companies in effect pooling their software development budgets? They
> couldn't. That's why the only places commercial UNIX flavors are still
> sucessful is in the far upper end of computing.
I will, for the sake of argument, accept that. And I'll discount the success of Debian, which nobody has poured money into. Okay, what has
this done? The effect has been nothing but positive. We, _all of us_, have a state of the art, Free, Open, platform that is inherently a
level playing field for all. Even Microsoft is free to use it or contribute, or port their apps on equal terms with the smallest of ISVs. The overall UNIX market has grown, reversing a dismal trend. Soon, there will be competition again, in servers there already is. Where's the down side? Anything that IBM lost on AIX they've gained on Linux, Sun and HP are perfectly free to do the same. Small players can matter again. If you think it's unfair that these folks have found
a way to break the monopoly, you won't get much sympathy from me. I really, seriously, doubt that anyone is shedding crocodile tears for Bill Gates. If he can't compete with products he owns, he's free to compete on a level playing field that everyone owns. I just hope they don't contribute much code. Whether people paid or didn't pay to level the playing field, a level field and a common platform are good things, aren't they? It has all the good points of
standardizing on a platform, in fact, many more than standardizing on Microsoft. And, if everybody works on that one platform, it's sure
to get better, faster, than Microsoft has been willing to do. I might kinda miss the struggle, but it would be so much better for everyone that I could adapt. At least I could find work :^)
> When I said the BSDs, I was referring to the Free BSDs. There was no
> investment there, hence (mainly) little hardware support, and therefore,
> it wasn't nearly as useful.
They are perfectly free to use any and all hardware support available for Linux. All they have to do is change their licensing to keep the
code Open. In looking at the drivers, most of them are still third party anyway. Written in spite of the hardware vendors in many cases.
Cooperation, much less investment, has been a long time coming. Perhaps users have figured out that _can_ be Open is not as good for them as _must_ be Open. There is nothing technically wrong with the Free BSDs, it must be the philosophy.
In short, OSS is not going away. It doesn't require the commercial model, or it would never have existed at all. The currancy is time not money and the investment has come because it's a better deal for everyone but Microsoft. Money can certainly help in that it can buy time, but time exists with or without money and everybody's got some. It only hurts those who won't play on a level field and every contribution helps everybody. It is quite novel to see companies
investing money to help each other and everyone else. Automation could use a healthy dose of this to solve the problems that the other model has created and enforced. What's wrong with that? Am I missing something?
Regards
cww
