On June 20, 2003, Bob Pawley wrote:
> If the integrators own the code what's to stop them from charging the client
> ongoing licensing fees as do all proprietary software vendors? <

That happens all the time. If the integrator charges licensing fees, then he/she *is* (by definition) a proprietary software vendor.

A lot of integrators do cookie-cutter applications, building the same thing only different for a lot of different clients. Over time, the integrator amasses a body of expertise and builds a set of tools - or a complete application. Typically, the integrator retains the rights to the software, and charges each client a one-time non-exclusive license for installation, plus consulting fees for installation, configuration, customization, training, etc. (Actually, they usually just bid the job at some fixed lump sum - you don't necessarily know how they arrived at the number - but the software license specifies that they retain ownership.) The continuing revenue stream comes, not from yearly license fees, but from maintenance and support contracts.

When a client-specified customization is generally useful, and developed under a contract that lets the integrator re-use the code, the enhancements get folded back into the toolkit. (Of course, the client has the right to insist that the customization NOT be used elsewhere, but he can expect to pay significantly more for it.) If a customization is more work than a single client is willing to pay for, sometimes a User's Group will band together to fund the work jointly. And sometimes the integrator just has to develop an enhancement on his own nickel to stay competitive.

> If he wanted the right to resell
> for his profit I would expect that our deal would involve very favorable
> terms for me. <

That happens, too. The initial beta site for proprietary software very often gets favorable terms. Some of those terms can include reduced licensing costs and very high levels of support.

Another favorable term, less often explicitly stated but often the real reason for the deal, is that the initial customer gets a very large say in how the system works, and an uncommonly detailed knowledge of its inner workings. Subsequent licensees, on the other hand, get a packaged product that does what it does, and what they know about how it works is pretty much whatever the documentation says.

The initial client may pay a license fee lower than what subsequent customers will pay, but commits to providing significant effort to testing and bug reporting, and to putting up with frequent code changes and other interruptions. In the end (assuming a successful project), the initial client get what amounts to a custom application, but supported by the manufacturer as if it were a warranted product, with continuing development, bug fixes and feature enhancements.

If you're not the initial client, then you get the benefit of licensing code that the integrator can customize to your needs, but which has already undergone significant development, testing, and debugging.

That the integrator makes money on the same code more than once shouldn't be a problem for you, as long as the money (and other resources) you are asked to pay isn't more than the solution you get is worth to you.

My two cents,

Greg Goodman
Chiron Consulting

( Previous thread: http://www.control.com/1026171803/index_html
- Moderator )

 

On June 20, 2003, Bob Pawley wrote:
> > If the integrators own the code what's to stop them from charging
> > the client ongoing licensing fees as do all proprietary software
> > vendors?

On June 22, 2003, Greg Goodman (Chiron Consulting) wrote:
> That happens all the time. If the integrator charges licensing fees,
> then he/she *is* (by definition) a proprietary software vendor.

> A lot of integrators do cookie-cutter applications, building the same
> thing only different for a lot of different clients. Over time, the
> integrator amasses a body of expertise and builds a set of tools - or
> a complete application. Typically, the integrator retains the rights
> to the software, and charges each client a one-time non-exclusive
> license for installation, plus consulting fees for installation,
> configuration, customization, training, etc. (Actually, they usually
> just bid the job at some fixed lump sum - you don't necessarily know
> how they arrived at the number - but the software license specifies
> that they retain ownership.) The continuing revenue stream comes, not
> from yearly license fees, but from maintenance and support contracts.

You know, exactly the same would happen if the toolkit were GPL - except that many the integrators would use the same one, rather than each having their own. And because it'd be used by so many more people, it would probably have a breadth few single-integrator toolkits can match.

> When a client-specified customization is generally useful, and
> developed under a contract that lets the integrator re-use the code,
> the enhancements get folded back into the toolkit. (Of course, the
> client has the right to insist that the customization NOT be used
> elsewhere, but he can expect to pay significantly more for it.)

Yup, same with the GPL (both options).

> If a customization is more work than a single client is willing to pay
> for, sometimes a User's Group will band together to fund the work
> jointly.

Yup, same with the GPL.

> And sometimes the integrator just has to develop an enhancement on his
> own nickel to stay competitive.

This one would probably be much less common, but still a possibility.

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

 

You know, I've listen to the argument of free code, free development tools bla bla bla, but I think everyone is missing the point.

First, many people complain about the expense of the software tools, but why not the price of a Multi-meter, or a Screwdriver? Is there any difference? Not really, each are tools that controls people use to make money. Also, controls people always want the best tools with the most features. Lastly, I haven't met too many people that would not like to have a company to look to if there are major issues. Many times has large automation vendors come through for integrators that missapplied technology, or incorrectly implemented everything.

So when you look at Linux and open source as the solution to everything, realize that automation costs are at a maximum 13% of the cost of a project. The other is intangable development install troubleshooting tools. Wouldn't you rather have a company that you culd partner with that could help you reduce that other 87%?

 

Hi Michael

On June 26, 2003, Michael Brennan wrote:
> You know, I've listen to the argument of free code, free development
> tools bla bla bla, but I think everyone is missing the point. <

There are many points, I'm sure willing to listen to yours.

> First, many people complain about the expense of the software tools,
> but why not the price of a Multi-meter, or a Screwdriver? Is there
> any difference? Not really, each are tools that controls people use
> to make money. Also, controls people always want the best tools with
> the most features. Lastly, I haven't met too many people that would
> not like to have a company to look to if there are major issues.
> Many times has large automation vendors come through for integrators
> that missapplied technology, or incorrectly implemented everything. <

Why does that entity have to be a company? It is the customary way that such things get done, but is it the only possible way? And can we automatically assume that BigCorp will produce the best tools with the most features? There have been some phenomenally bad examples produced by some pretty prestigious companies. And some of the choices they make are very, very, dubious, driven by marketing rather than engineering. Multimeters and screwdrivers are a totally invalid comparison as they are sold in an entirely different manner snd are self explanitory for the most part. And you actually own them after paying for them once. PLC tools are never yours and they are the purchase that keeps on costing. But, you are right in that, for some reason, people are more comfortable thinking BigCorp is behind you. If you have problems, they can share what they didn't tell you up front for a fee. And if you are screwing up, that can help. But, if it's their fault, you seldom get satisfaction and your leverage with BigCorp isn't really very significant. Your greatest protection is that no one else can rationally think of suing BigCorp either. I was prone to this kind of thinking once upon a time. The nature of things that people have hired me for brought me into contact with many of the real problems with that model and I found out that I was mostly on my own with real problems. (Not RTFM) So I began doing things on my own with the tools and software best suited for that. I was worried that I might get stuck with no support and no help but, I wasn't doing well making BigCorp respond, and with this stuff I could at least do things myself if something went south. What I discovered is that I have many more friends and much better technical help than I had before. Yes, it's different and you are expected to RTFM, but with real problems,I can't complain at all. Close to 100% solution and even an apology or two. Now, If I can build robust, reliable solutions that way, (and I can supply references), and it's less costly, for me amd the customer, Why shoulsn't I be excited. And if we can make it so you can do it too. what's wrong with that? Why is it evil or missing a point somewhere? Is it entirely impossible that we might have found a batter way?

> So when you look at Linux and open source as the solution to
> everything, realize that automation costs are at a maximum 13% of the
> cost of a project. The other is intangable development install
> troubleshooting tools. Wouldn't you rather have a company that you
> culd partner with that could help you reduce that other 87%? <

And if you had a way to reduce, both wouldn't you consider it?

Sharing code and experiences is a huge factor here. This list does a little and has saved many people lots of time and effort. But imagine how much more could be done if the people who made the things frankly and fully cooperated. And if you could get in touch with not only the people who are solving the same problems but the authors and users as well? And if the effort was made to actually facilitate your understanding and provide as much information as possible without calling and bad muzak on hold, etc?. What if you could know all the answers because there aren't any secrets? That's what we are trying to do. And with some support, I don't see any real reason we can't. Manpower is our biggest limitation.

I get your point and I've tried that way. You might want to try depending on a community and deciding which is better. The status quo does work, but it's crazy to infer that other ways can't work or work better. The landfills are full of stuff that worked but was supplanted by better ideas.

Regards

cww

 

On June 26, 2003, Michael Brennan wrote:
> You know, I've listen to the argument of free code, free development
> tools bla bla bla, but I think everyone is missing the point.
...
> So when you look at Linux and open source as the solution to
> everything, realize that automation costs are at a maximum 13% of the
> cost of a project. The other is intangable development install
> troubleshooting tools. Wouldn't you rather have a company that you
> culd partner with that could help you reduce that other 87%? <

Sure; so contract with a company to do the 87% for you. Unbundle the support. And since it'll be a separate contract, it'll be much clearer who's expecting what from whom.

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

 

Sounds like you want something for nothing, no one writes code for free, it would be great, but heck, we all have families to feed and until the world is not monetray based, somebody has to pay somebody for the development time and effort. And partnering with another company will probably not help in reducing the supposed other 87% of the project cost, free is a relative term and I for one have yet to find anything which is truly free.

Matt

 

On June 29, 2003, Matt Hyatt wrote:
> Sounds like you want something for nothing, no one writes code for
> free, it would be great, but heck, we all have families to feed and
> until the world is not monetray based, somebody has to pay somebody
> for the development time and effort.

I'm not sure what you mean here - the existence of gcc, Linux, Apache, etc, is not really in question. How they came about might be interesting to sociologists and/or economists, but as computer professionals we don't really care: they exist, and they're free to use.

> And partnering with another company will probably not help in reducing
> the supposed other 87% of the project cost, free is a relative term
> and I for one have yet to find anything which is truly free.

Yeah; the bulk of programming (and programming project cost) is in custom code, customization, intstallation and support - items that will be there regardless of whether the supply of the foundation software is done for free or for razor-thin margins.

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

 

On June 26, 2003, Michael Brennan wrote:
> First, many people complain about the expense of the software tools,
> but why not the price of a Multi-meter, or a Screwdriver? Is there
> any difference? Not really, each are tools that controls people use
> to make money. Also, controls people always want the best tools with
> the most features. <

Not always. I have some clients who are very clear that they don't want latest-and-greatest fancy bells and whistles. They want something simple and reliable, that does exactly what they want it to do without undue hassle, and that is easy to support in the field.

> So when you look at Linux and open source as the solution to
> everything, realize that automation costs are at a maximum 13% of the
> cost of a project. The other is intangable development install
> troubleshooting tools. Wouldn't you rather have a company that you
> culd partner with that could help you reduce that other 87%? <

But I'm not a full-service integrator; I'm the software subcontractor on a bigger project. My bid is affected by what my tools will cost, the license fees I will have to pass on to the customer, the support contracts I will have to buy to get the project done. If I can use Open Source components in the project, then my time to implement is reduced, my costs are lower, and my chances of landing the project go up.

Yes, software represents a small-ish percentage of the overall cost of an automation project, but it's the piece I make my living providing, and the less costly I can make it for my customers, the more work I can get.

> Lastly, I haven't met too many people that would not like to have a
> company to look to if there are major issues. <

If an automation solution is provided under a contract that specifies a warranty, or that provides for support, then there's a company to look to if there are issues, whether they be major or minor. And I haven't met too many people that would buy an automation solution without insisting on a warranty period or some level of post-installation support.

Just one perspective among many,

Greg Goodman
Chiron Consulting