Alex Pavloff:
> The software is not a profit center.
> Releasing "the spec" assumes that there is a spec. There is now one
> programmer on this project -- me. I'm rather confident of my ability
> to get things done, and so are the people that run the company, so
> there really isn't a "spec" of any sort. Design docs, feature lists,
> bug lists, yes.
Open-source the code, then.

Doesn't cost you anything - it's already a sunk cost - and, who knows? it might help someone, or someone might help you.

> I also have little hope that Curt, Jiri, or any other volunteer
> programmers would be able to spend the time needed to actually do open
> source configuration software. I work on this project full time, and
> have been doing this for a couple years. I've got around ~110,000
> lines of code here -- which is small potatoes compared to some
> projects, but not insubstantial.
How did you get to 110,000 lines ???

In any case, I suspect the basic configuration tool could probably be ported fairly easily: replace the GUI with a simple text file (front end to come later, and probably not in C/C++), and port the comms. That gives a useful, usable tool, with not too much effort.

> If I thought I could make all my software open source and cooperate
> with a few developers to get more drivers or more things done than I
> can on my own, I'd do it. I just haven't seen any solid output from
> any developers so far that makes me reconsider the choice to do most
> all the automation-specific software in-house.
The two are not exclusive: you can do the software in-house, releasing it under the GPL. If you get contributions from others, great. If you don't, well, you're no worse off than you would be otherwise.

Jiri
--
Jiri Baum <[email protected]> http://www.csse.monash.edu.au/~jirib
MAT LinuxPLC project --- http://mat.sf.net --- Machine Automation Tools
Jiri

 

On October 25, 2003, Jiri Baum wrote:
> Open-source the code, then.
>
> Doesn't cost you anything - it's already a sunk cost - and,
> who knows? it might help someone, or someone might help you. <

Doesn't cost me anything? I have to spend some of my time stripping the code that I can't distribute out, packaging it, and putting it on the web.

By the time I'm done, you're left with a completely non-functioning piece of source code lying on a server whose main purpose, if you can get it to compile is to drag little GUI objects around on the screen, and then do absolutely nothing when someone hits the "compile" button.
The lexer/parser you see, that converts the BASIC code into interpreted bytecode, is a piece of software that I can't distribute.

As for communications to my target, guess what -- its all Modbus! Sure, I added a function code and some subfunctions for file download/upload and read/write via tagname, and if I became necessary, I would happily write a spec for those functions, but the Model 5000 is a Modbus RTU/TCP slave that (or Master) that can happily interface to any other device that talks Modbus.

> > I also have little hope that Curt, Jiri, or any other volunteer
> > programmers would be able to spend the time needed to
> actually do open
> > source configuration software. I work on this project full
> time, and
> > have been doing this for a couple years. I've got around ~110,000
> > lines of code here -- which is small potatoes compared to some
> > projects, but not insubstantial.
> How did you get to 110,000 lines ??? <

Let see here, I've got configuration dialogs and address validation functions for ~20 serial/Ethernet/PC104 drivers. I've got code to provide properties and draw 15 different highly configurable GUI widgets. I've got a BASIC parser that converts BASIC into interpreted bytecode. I've got a boilerplate ATL code to provide a COM interface to my object model so I can create entire programs and system and generate reports from VB apps. I've got the entire object persistence system that saves my program into a Jet database.

There are a lot of comments inflating that count too, but I was comparing to MAT, which also has a lot of comments. When you take out the comments, you get down to 82,000 lines of code. Its also a rather svelte code base compared to its predecessor from which it was derived.
That software has twice the lines of code, does less, and does it slower.

> In any case, I suspect the basic configuration tool could
> probably be ported fairly easily: replace the GUI with a
> simple text file (front end to come later, and probably not
> in C/C++), and port the comms. That gives a useful, usable
> tool, with not too much effort. <

Jiri, I don't think a simple text file is a useful or usable tool at all. Not for the people that buy the hardware.

> The two are not exclusive: you can do the software in-house,
> releasing it under the GPL. If you get contributions from
> others, great. If you don't, well, you're no worse off than
> you would be otherwise. <

Yes, I am worse off. As I previously pointed out, releasing my software under the GPL and making it available to other developers means that I am unable to take advantage of third party commercial libraries and
components. There are a huge amount of high quality and useful libraries and components available for Windows platforms at low cost. I'm not about to throw away that proven and definite resource for a "possible" resource.

Alex Pavloff - [email protected]
ESA Technology ---- www.esatechnology.com
------- Linux-based industrial HMI ------
-------- www.esatechnology.com/5k -------

 

Jiri Baum:
> > Open-source the code, then.

> > Doesn't cost you anything - it's already a sunk cost - and, who
> > knows? it might help someone, or someone might help you. <

Alex Pavloff:
> Doesn't cost me anything? I have to spend some of my time stripping
> the code that I can't distribute out, packaging it, and putting it on
> the web.

> By the time I'm done, you're left with a completely non-functioning

Right, not much point to that. Lots of work, and if it doesn't compile
nobody's going to look at it anyway.

> As for communications to my target, guess what -- its all Modbus!
> Sure, I added a function code and some subfunctions for file
> download/upload and read/write via tagname,

That sounds good... I guess the hardest bit in documenting that would be
documenting the bytecode.

> > > I also have little hope that Curt, Jiri, or any other volunteer
> > > programmers would be able to spend the time needed to actually do
> > > open source configuration software. I work on this project full
> > > time, and have been doing this for a couple years. I've got
> > > around ~110,000 lines of code here -- which is small potatoes
> > > compared to some projects, but not insubstantial.

> > How did you get to 110,000 lines ??? <

> Let see here, I've got
...

Still sounds like rather a lot of lines, but more reasonable. I guess
it's a larger piece of code and functionality than I expected under the
phrase "configuration tool".

> > In any case, I suspect the basic configuration tool could probably
> > be ported fairly easily: replace the GUI with a simple text file
> > (front end to come later, and probably not in C/C++), and port the
> > comms. That gives a useful, usable tool, with not too much effort. <

> Jiri, I don't think a simple text file is a useful or usable tool at
> all. Not for the people that buy the hardware.

You may be underestimating your customers... in any case, I did say
front end to come later, at which point it'll be point'n'click again.

(Best of both worlds: point'n'click for those who want it, and a text
file for those who need to do something you didn't expect, like
configure the box according to data from a database or some other
program.)

> > The two are not exclusive: you can do the software in-house,
> > releasing it under the GPL. If you get contributions from others,
> > great. If you don't, well, you're no worse off than you would be
> > otherwise. <

> Yes, I am worse off. As I previously pointed out, releasing my
> software under the GPL and making it available to other developers
> means that I am unable to take advantage of third party commercial
> libraries and components.

There's a lot of libraries and components available OSS, too - not
automation-specific ones, but I expect most of the libraries you need
are generic (GUI toolkits, parsers/lexers, etc). For an existing
program, it'd involve changing over to them, which would be a fair bit
of work. For new projects, however, they might be worth considering.

Jiri
--
Jiri Baum <[email protected]> http://www.csse.monash.edu.au/~jirib
MAT LinuxPLC project --- http://mat.sf.net --- Machine Automation Tools