C
Hi All
I have looked at all the responses both public and private to the questions I posed and the general state of things. As is usual with
a request of this type, I have been left with more questions than answers: I will start with my statements and then, sigh, some more questions.
First, Hugh's Java PLC. I agree with Hugh that there is room for multiple approaches to fielding a Linux Automation Product. The first time I tried to explain this I got singed around the edges but, as I am relatively fire resistant and flames are nothing new for someone who seeks to change the status quo, I will persist.
This Linux PLC has different goals and purposes, not the least of which is to use Free Software tools and to be totally free to distribute. While there are rumors about Java being Open Sourced
it is not at this time. The efficiency tradeoffs with higher level languages are also a problem as another goal is for the core to be as small and fast as possible. There are also realtime and small machine considerations that, added to the fact that C is "the" systems programming language on Linux, make C the choice for this project. It is my sincere hope that at least one opproach reaches commodity status in the automation market. I truly admire Hugh's solitary accomplishment, but that brings us (conveniently) to the next issue, the one that concerns me most of all.
A major goal of this and other Open Source projects is to use the abilities of a group of people to make better software that better
serves the common need than can be produced by an entity purely for profit. I have argued endlessly to make choices that keep the prospective developer base as broad and democratic as possible. I want this to be a volksplc in concept and execution so that it would be routinely and continuously augmented and improved by the user base, with those improvements available to all via the GPL requirements.
I am a strong proponent of project ownership where each and every individual feels they are a part and can be proud of the group
accomplishment. This ideal has been extremely difficult to inspire in this group and may perhaps never be realized due to both the
diversity and uniqueness of the members.
The most significant remarks have been that the project has become too complex for the majority of people to follow and discouraged many who might otherwise contribute. I happen to be in the group that is so challanged. I have agonized over this for more time than I should admit to and have found no easy solution. We certainly can not fault Jiri amd Mario for their contribution,
to the contrary, they have kept the project alive when _no one_ else, my self included, has been contributing. That we can't work together at that level is certainly not their intent or fault either.
I started this project believing that I was fully capable of making a Linux PLC and I have not been shaken from that view yet. I wanted to harness the talent and skill of others in achieving that goal faster. What I could do myself would be
much less sophisticated than what is in the works from Jiri and Mario and crude by comparison. But, done entirely in Bonehead C (tm.) as I do no other, it would be more easily understood and argued about. More people could participate and
it would more closely approach the volksplc. It would have to be incrementally and repeatedly revised and rewritten to add needed features as they are discovered.
Jiri and Mario (and others I'm sure) are schooled and skilled to design for the final version and code once or at least many less times than I would as my approach was to use the skills of
the average hacker in the group, that is to say, a couple of notches better or worse than my own skills.
The compromise informally proposed is that the CS guys write the "hard stuff" and provide comprehensible API's for the others to write to. This is certainly plausible under the circumstances. The main problem is that it has been and will be a while before it can be done. Many have lost interest in the meantime.
I accepted Jiri's offer of help in good faith with reservations about just this problem. Thus, I take all responsibility for the waning of interest. It must be said we were on the prongs of a similar but different dilemma at the time, I couldn't get anyone to help me code in my fashion either.
When I asked the original questions in this thread, I had been thinking about OSS development in general. What we have is a microcosm of the "Cathedral and the Bazaar". This is quite by
accident as the "high priests" had no intention of being such. Indeed, it is the rarity of Linux programming skills and experience _in this group_ that elevate them to their lofty and unintended position.
Many times I have adamantly refused or at least argued against proposals that would include more skilled CS types at the expense of the "silent majority" of folks who have a little C experience
on a different platform perhaps or who are very willing but need help or coaching on their skills to contribute. This has turned off some high power people who think I am an idiot to insist on
simple and archaic tools and traditional values and inclusiveness. While I don't regret these choices, perhaps I am an idiot for not finding a way to include these high power folks.
I keep up with handgun Metallic Silhouette shooting. I don't compete anymore because there are no facilities close and I am too pressed for time and money. But I can compete (badly) if I
want to because they have a class for hackers with a production gun and other classes for exotic hardware and the good shooters. You'll see where I'm going with this in a minute.
I propose the same structure for our endeavor:
A "Hunter's Gun" division where I continue the thread of development I started with explanation and progress based on understanding with anyone welcome. The goal will be a light weight embedded class PLC compatible wherever possible.
An "Unlimited Class" Where anything goes to interest those who want C++, OOM, (object oriented mentality) and whatever they can successfully argue will get the job done with the proviso of course, that it run on Linux and be GPL compatible. I would ask those who I offended before to give it another look.
Some may see this as "Solomon's solution" that is suggest splitting the baby and see who cares the most or forking. I see this as addressing two applications areas optimally.
What do you think?
Does anyone else have a better solution?
Regards
cww
_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
I have looked at all the responses both public and private to the questions I posed and the general state of things. As is usual with
a request of this type, I have been left with more questions than answers: I will start with my statements and then, sigh, some more questions.
First, Hugh's Java PLC. I agree with Hugh that there is room for multiple approaches to fielding a Linux Automation Product. The first time I tried to explain this I got singed around the edges but, as I am relatively fire resistant and flames are nothing new for someone who seeks to change the status quo, I will persist.
This Linux PLC has different goals and purposes, not the least of which is to use Free Software tools and to be totally free to distribute. While there are rumors about Java being Open Sourced
it is not at this time. The efficiency tradeoffs with higher level languages are also a problem as another goal is for the core to be as small and fast as possible. There are also realtime and small machine considerations that, added to the fact that C is "the" systems programming language on Linux, make C the choice for this project. It is my sincere hope that at least one opproach reaches commodity status in the automation market. I truly admire Hugh's solitary accomplishment, but that brings us (conveniently) to the next issue, the one that concerns me most of all.
A major goal of this and other Open Source projects is to use the abilities of a group of people to make better software that better
serves the common need than can be produced by an entity purely for profit. I have argued endlessly to make choices that keep the prospective developer base as broad and democratic as possible. I want this to be a volksplc in concept and execution so that it would be routinely and continuously augmented and improved by the user base, with those improvements available to all via the GPL requirements.
I am a strong proponent of project ownership where each and every individual feels they are a part and can be proud of the group
accomplishment. This ideal has been extremely difficult to inspire in this group and may perhaps never be realized due to both the
diversity and uniqueness of the members.
The most significant remarks have been that the project has become too complex for the majority of people to follow and discouraged many who might otherwise contribute. I happen to be in the group that is so challanged. I have agonized over this for more time than I should admit to and have found no easy solution. We certainly can not fault Jiri amd Mario for their contribution,
to the contrary, they have kept the project alive when _no one_ else, my self included, has been contributing. That we can't work together at that level is certainly not their intent or fault either.
I started this project believing that I was fully capable of making a Linux PLC and I have not been shaken from that view yet. I wanted to harness the talent and skill of others in achieving that goal faster. What I could do myself would be
much less sophisticated than what is in the works from Jiri and Mario and crude by comparison. But, done entirely in Bonehead C (tm.) as I do no other, it would be more easily understood and argued about. More people could participate and
it would more closely approach the volksplc. It would have to be incrementally and repeatedly revised and rewritten to add needed features as they are discovered.
Jiri and Mario (and others I'm sure) are schooled and skilled to design for the final version and code once or at least many less times than I would as my approach was to use the skills of
the average hacker in the group, that is to say, a couple of notches better or worse than my own skills.
The compromise informally proposed is that the CS guys write the "hard stuff" and provide comprehensible API's for the others to write to. This is certainly plausible under the circumstances. The main problem is that it has been and will be a while before it can be done. Many have lost interest in the meantime.
I accepted Jiri's offer of help in good faith with reservations about just this problem. Thus, I take all responsibility for the waning of interest. It must be said we were on the prongs of a similar but different dilemma at the time, I couldn't get anyone to help me code in my fashion either.
When I asked the original questions in this thread, I had been thinking about OSS development in general. What we have is a microcosm of the "Cathedral and the Bazaar". This is quite by
accident as the "high priests" had no intention of being such. Indeed, it is the rarity of Linux programming skills and experience _in this group_ that elevate them to their lofty and unintended position.
Many times I have adamantly refused or at least argued against proposals that would include more skilled CS types at the expense of the "silent majority" of folks who have a little C experience
on a different platform perhaps or who are very willing but need help or coaching on their skills to contribute. This has turned off some high power people who think I am an idiot to insist on
simple and archaic tools and traditional values and inclusiveness. While I don't regret these choices, perhaps I am an idiot for not finding a way to include these high power folks.
I keep up with handgun Metallic Silhouette shooting. I don't compete anymore because there are no facilities close and I am too pressed for time and money. But I can compete (badly) if I
want to because they have a class for hackers with a production gun and other classes for exotic hardware and the good shooters. You'll see where I'm going with this in a minute.
I propose the same structure for our endeavor:
A "Hunter's Gun" division where I continue the thread of development I started with explanation and progress based on understanding with anyone welcome. The goal will be a light weight embedded class PLC compatible wherever possible.
An "Unlimited Class" Where anything goes to interest those who want C++, OOM, (object oriented mentality) and whatever they can successfully argue will get the job done with the proviso of course, that it run on Linux and be GPL compatible. I would ask those who I offended before to give it another look.
Some may see this as "Solomon's solution" that is suggest splitting the baby and see who cares the most or forking. I see this as addressing two applications areas optimally.
What do you think?
Does anyone else have a better solution?
Regards
cww
_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc