Open Source Software - Good For Business?

M

Michael Griffin

On April 8, 2003 12:54, Alex Pavloff wrote: <clip>
> Michael Griffin wrote:
> > I suppose what we should be asking is what segments of the
> > automation software market look like they could become commoditised? Low
> > end MMI systems perhaps?

Alex Pavloff replied:
> I doubt it. Low end (sub $500 dollar range is my thinking) HMI hardware is
> about driving hardware costs down by picking low-end parts and driving up
> volume. When you pick low end hardware, you limit your programming
> choices. When you increase volume, you can afford to go with a custom
> solution.

I wasn't referring to "MMI Panels". I see that as a different market segment with a lot of differences between them and PCs besides just price. They are designed to be something any competent industrial electrician can troubleshoot and replace (just like a PLC). That's more of a "system" feature rather than something software alone can give you.

I was however referring to the segment at the bottom end of the market where an actual PC is required for some reason. You will notice that there is very regular discussion here on how to use VB (or Delphi), or even (shudder) Excel as an MMI development system. The usual reasons given are the need for a programmable system that has low capital costs for the development software and (often) royalty free run times.

There does seem to be a demand which isn't being met by existing systems for some reason and which an open source solution may fit. This isn't something I would have a need for myself, but I can't but help noticing people asking for something like it.

> Besides, the main hurdle to open source in automation is that there isn't
> any large body of open source automation code out that people want to use.
> Sure, there are dribs and drabs here and there, but not enough to make
> anyone go "Ooo! If I use this code it'll save me lots of time!"
<clip>

However, that isn't the only way for something to arise. I see a more likely origin to be where someone finds a software development system which was intended for another application but is fairly close to what is needed for a useful MMI development package. All that may be needed is to add on a few GUI widgets and other minor bits (strip chart, etc.) to get something that is good enough for a lot of purposes (or at least better than VB).

I can't give you an detailed example of how to do this, as I haven't been doing any research on something I don't need. However, building user interfaces quickly and easily is a fairly common software development task, so we shouldn't be surprised to find something that fits the bill.

************************
Michael Griffin
London, Ont. Canada
************************
 
M

Michael R. Batchelor

Most of this is because the engineers in the plan think of the custom portion for their problem. Not the generic portion that fits everyone's problem.

For example, suppose I have 3 customers who want an HMI on their lines. One line makes widgets, one makes whiz-bangers, and one makes cardboard boxes for the other two. All three customers use BrandX PLCs to control their line.

In the proprietary world I can use BrandX's in-house HMI, Intellution, Wonderware, CiTect, or others. But each choice has a custom component and a generic component. The generic component is the drivers for BrandX PLC and the development environment. The custom component is the application for that specific plant.

The body of code that's missing for an OSS solution is the generic part. Even if it all existed, I'd still have to do the work for the custom component at each plant.

So, the place where we are now is about where the OSS world stood when Richard Stallman first started the GNU project and was working on gcc. There is a little code out there - Ron Gage comes to mind - but not enough to make a complete replacement for the generic part of the solution.

In the Linux world, nothing really took off until three components were in place. GNU had a solid gcc for a while, the Linux kernel worked reasonable well, and then GNU released glibc. The release of glibc was the event where all the pieces fell into place to make a real freely distributable OS.

Analogously, what's required to make an OSS HMI take off is a good set of PLC drivers - unlikely while AB wants money for DH+ code[1], a good set of symbols for drawing pictorial representations of items in a production system, and an IDE to tie them together in a way comprehensible to most plant engineering staffs.

[1]I say this because, like it or not, AB has the lion's share of the PLC market (at least in the US) and in that subgroup the lion's share of "communication" is by DH+ using some variant of a KT or KTX card.

MB
 
H

Higginbotham Ricky

Nope. Its the ridiculous context that makes it so absurd. :)
I was being tongue in cheek, should have emphasised that little bit of craziness so it was more clear.

Richard Higginbotham
(speaking for me)
 
R

Ralph Mackiewicz

> > > As a software vendor, your entire business model would have to
> > > change; from that point of view, it may be quite painful, though
> > > you have the advantage that you already have a Consultancy arm.
> ...
> > > the consultancy arm would have to become dominant, with the
> > > software sale itself becoming pretty much negligible.
>
> > And, what if the whole purpose of your software product is to enable
> > your customers to accomplish useful tasks themselves, without
> > consultants?
>
> That's the painful 5% - in that case, your business will fold if you
> go Open Source, or if somebody else creates an equivalent Open Source
> project and brings it to maturity.

Good point, but I think the percentage is way low. I don't recall ever having bought a program for my own use (including professional use) that required any consulting to use. If it did, I probably wouldn't use it. I think that enabling people to do complex tasks without consulting is the primary benefit of the majority of software that is sold (or downloaded for free for that matter).

> > The "give away the software to sell consulting services" model
> > implies that the requirement for a profitable business model in a
> > commercial organization providing open source is that the software
> > must be so complicated that consulting is required to use it
> > properly.
>
> Open Source software doesn't have a requirement for a profitable
> business model; or, rather, not for a vendor-profitable model. It may
> have some other model, such as Apache group's customer-profitable one.

I never meant to imply that a vendor-profitable business model was a requirement. However, the question was: can a vendor-profitable business model be built on an open source product? With the exception of O/S companies and perhaps this Zope company (which is far out of any area of interest I have), I can't see how you can make a profitable business selling only consulting services for software unless the software is too complex for a typical user to apply for themselves and that you don't have to make your own investments in the engineering required to produce the software.

> A similar effect might happen with Francis Lovering's ControlDraw,
> upthread: a lot of people would do stuff simple stuff for themselves,
> but for high end or complex stuff, the expertise isn't in the drawing
> of the boxes themselves, but in knowing which boxes to draw. I don't
> think any software can help with that. And if they've drawn smaller
> projects and the prototypes in ControlDraw, who are they going to
> call?

ControlDraw, as an OSS project, might become successful but how can you build a for-profit company on a model where nobody pays anything for ControlDraw? Deciding what boxes to put in the drawing is a service that almost everybody on this list provides. The authors of ControlDraw won't have any special advantage (other than perhaps a minor marketing advantage of having their name on the software) in this well served market. Besides, developing ControlDraw is a different skill set than deciding what boxes to draw using ControlDraw.

Regards,
Ralph Mackiewicz
 
Michael Griffin:
> I see a more likely origin to be where someone finds a software
> development system which was intended for another application but is
> fairly close to what is needed for a useful MMI development package.
> All that may be needed is to add on a few GUI widgets and other minor
> bits (strip chart, etc.) to get something that is good enough for a
> lot of purposes (or at least better than VB).

> I can't give you an detailed example of how to do this, as I haven't
> been doing any research on something I don't need. However, building
> user interfaces quickly and easily is a fairly common software
> development task, so we shouldn't be surprised to find something that
> fits the bill.

To give an example, MatPLC uses the glade tool for this, without modification. A little wizard will give you things to quickpaste into glade (one thing per widget to be connected to a MatPLC register). Other than that, you can use anything in glade (menus to pop up windows, etc).

A couple of days ago, somebody added... a multi-channel plot widget. I haven't had a chance to play with it yet, though.

Jiri
--
Jiri Baum <[email protected]> http://www.csse.monash.edu.au/~jirib
MAT LinuxPLC project --- http://mat.sf.net --- Machine Automation Tools
 
> > > And, what if the whole purpose of your software product is to
> > > enable your customers to accomplish useful tasks themselves,
> > > without consultants?

Jiri Baum:
> > That's the painful 5% - in that case, your business will fold if you
> > go Open Source, or if somebody else creates an equivalent Open
> > Source project and brings it to maturity.

Ralph Mackiewicz:
> Good point, but I think the percentage is way low.

That percentage is from the programmers' point of view. 5% for-sale programs, 95% custom. Since the for-sale programs sell thousands of copies, they outnumber the custom stuff from the users' POV. However, the percentage may well be off; it doesn't affect the main argument, that programmers will still have jobs.

> I think that enabling people to do complex tasks without consulting is
> the primary benefit of the majority of software that is sold (or
> downloaded for free for that matter).

Yeah, programs (should) make complex tasks simple. Then people increase the demands on those tasks until they're complex again.

In any case, though, somebody has to do the tasks; either companies can develop in-house experience (and hire employees) or they can outsource (and hire consultants).

...
> I never meant to imply that a vendor-profitable business model was a
> requirement. However, the question was: can a vendor-profitable
> business model be built on an open source product? With the exception
> of O/S companies and perhaps this Zope company (which is far out of
> any area of interest I have), I can't see how you can make a
> profitable business selling only consulting services for software
> unless the software is too complex for a typical user to apply for
> themselves and that you don't have to make your own investments in the
> engineering required to produce the software.

The services would generally be those of an Integrator. Not every project needs the services of one, of course; but there's enough that do. Those that don't effectively do the same stuff in-house, anyway.

(Zope Corp. is basically in the same category; they build complicated websites for people, based on the zope suite. Simple websites based on zope people do for themselves, if they've got the time and know-how.)

> > A similar effect might happen with Francis Lovering's ControlDraw,
> > upthread: a lot of people would do stuff simple stuff for
> > themselves, but for high end or complex stuff, the expertise isn't
> > in the drawing of the boxes themselves, but in knowing which boxes
> > to draw. I don't think any software can help with that. And if
> > they've drawn smaller projects and the prototypes in ControlDraw,
> > who are they going to call?

> ControlDraw, as an OSS project, might become successful but how can
> you build a for-profit company on a model where nobody pays anything
> for ControlDraw?
...
> The authors of ControlDraw won't have any special advantage (other
> than perhaps a minor marketing advantage of having their name on the
> software) in this well served market.

That, which implies that they're very familiar with the product, and being the first, which has its own advantages. Marketing advantages count.

In general, though, the playing field will be much more level, with other consultants competing with them on a pretty much equal basis. Like I wrote, that's the painful 5%...

> Besides, developing ControlDraw is a different skill set than deciding
> what boxes to draw using ControlDraw.

It's a consultancy that the website already offers; but yes, it is.

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

Francis Lovering

<<I don't recall ever having bought a program for my own use (including
professional
use) that required any consulting to use. If it did, I probably wouldn't use
it. I think that enabling people to do complex tasks without consulting is
the primary benefit of the majority of software that is sold (or downloaded
for free for that matter).>>

Well, I have seen an awful lot of people using Word, Excel and Access that could do with a lot of consulting - or at least training.

<<the expertise isn't in the drawing of the boxes themselves, but in knowing
which boxes to draw. I don't think any software can help with that.>>

I agree the first sentence but I beg to differ with the second. Yes, there is expertise knowing what to put on a diagram, but examples and some
automated functions can help greatly. And there are ControlDraw users who have told me that they learned a lot about S88 from using the software. (Not that it gives you S88 in a box, there is no such thing.)

<<ControlDraw, as an OSS project, might become successful but how can
you build a for-profit company on a model where nobody pays anything
for ControlDraw?>>

Quite so.

As a consultant I often spend time developing models and functions (outside ControlDraw) that greatly speed up the production of DCS/PLC/HMI software from a ControlDraw model. That is paid directly as consulting charges. Suppose instead that I were to spend 1000 hours improving the software to add the capability to generate their automation software directly from a ControlDraw model without the users having to employ me as a consultant. How would I get paid for that other than by charging for the software?

Francis
 
Top