There is a reason why the original program, Crestron/AMX/RTI and even URC, is a proprietary software and ONLY dealer accessible. What was their reason in the first place to make it dealer ONLY?
There are a few "snatch and grab" companies out there and they continue to come and go. Customers who buy into what they are selling is a shame but then again "you get what you pay for."
There are other reasons we could jump into where; "so and so pissed me off and I don't want them to finish this project, will you finish it for me?" Better yet the customer owes a few thousand and doesn't want to pay the original company so he hires a smaller company that rips into the system, finished the job for less and now has the program that the first company started.
Here is the bottom line to this! Accountablity! Responsiblity! Even if a company has to go under, I think it should be the responsibilty of said company to pass off the program to the customer when they close the doors. But this may be asking too much. Maybe we can do like Microsoft does with their software. 5 years and then they have to upgrade to the next "OS".
No one will ever win this thread. Both sides will continue to discuss or debate this until the end of time. Both the customer side and the business side have great points but I'm afraid that the human element will always win....... Whatever is best for me.

My response appeared meaningless because you unwilling or unable to read and comprehend the rest of the thread.


I know what the MS EULA says. Had you actually read my responses.. all of them.. you would know that im suggesting that Crestron programmers include one in their contract so that there will be no question or confusion about what the line item 'programming' means on an invoice.


I didnt think you did but thanks for the information. I have it incase i need it for anything.


It would suck.. just like it would suck if i invested 500k on a bunch of PC's only to find out MS went under. In every response i have in this thread i try to explain that this could be solved with a contract that explains what your getting in terms of programming.. if a client wants to pay extra for uncompiled code they get it and if they dont.. they dont.

In life.. you dont get what you deserve.. You get what you negotiate.. Put it in the contract.


I have said this in every way i possibly can thru this entire thread. Each time im quoted by people who arent reading my responses.


I agree. If you read Alan's last post it explains why were faced with this issue now more than ever. In the past we as CI's and programmers ate the true cost of programming the system so that we could make money on the gear. Now that were not making money on the gear things need to be adjusted so we make money on the programming.

The company i work for already does this. We bill for system design, we bill for GUI creation and we charge what it actually costs to program the system.

At the end of the project the client gets the scematics, drawings, gui's and uncompiled code. When we leave a project any CI firm or programmer can be called to update the system.


The CI who explains the code issue to the client is the CI whos going to lose the bidding war with the trunk slammer. Thats why so many respond with "be sure to educate the end user about both sides of the story and dont just hand them a torch and point them to the castle".

I agree.. The biggest issue is when people let the "whats fair" get in the way of what the contract says or in this case.. should say.

I once did an installation for someone I'll call the "thief." I was contacted by his IT who I will call the "enabler." I installed and programmed a working system. Indeed the basic system I signed on to install wound up being anything but basic once he got though changing it because "it was a Crestron system." There was no programming line item since it was supposed to be a "basic" system. Why don't you write about his not paying any of the installation labor despite getting a working system?

Why is this considered the price of doing business but the other is not? I have given so many examples in this thread of the hazards we installers/programmers face. We control very little but we assume responsibility for providing a working system. Cable box firmware changes? Tough. Make it work. HDMI port doesn't work? Tough make it work? Manufacturer screw ups? Tough make it work? Other trades screw up? Tough make it work. Client doesn't want to pay? Tough. You cannot sue for 10K unless you wish to pay 30-50K in legal fees.

Have the software placed in escrow. Client picks up the fees for this. If the business goes under the client gets the software. If he "dislikes" the firm he purchases the code from the dealer.

Here we have a solution and the problem ceases to be an issue. Neither client or dealer is screwed--though you can bet any cool macros will find its way into the public domain, irrespective of any contractual limitations to the contrary. Shall we not make an attempt to protect the dealer while trying to save your innocent "friend" from evil? Might it not also be the case that your friend was also a dirt bag, who did not pay his bill, insisted on more and more extras and that when the dealer finally called time, he cried foul? Yet you'd argue that he deserved the code so that he could go on to screw the next dealer. I'd happily name names but I'd wind up in court where truth in no defense. Any one recall Liberace suing because some journalist had the audacity to call him a homosexual?

Alan

This from a "consultant"......


Those who can .... do ...... Those who cant ..... consult

Yes, Alan, that is the logical solution I've proposed all along (so why are you yelling at me?!). There are some here who seem to object to parting with the code under any circumstance. As a consumer, I would not accept that risk.

And so, I would advise consumers that they should not necessarily expect to get full access to the source code once the job is complete and paid for .... and here is why...

But to protect yourself, you should request the dealer put the code in escrow -- on your own nickel -- in the event that the dealer goes out of business or something happens to the original.

You should include in your contract that if you have any grievances with the dealer -- after you have paid for their services -- you can pay for the source code so that another authorized dealer can take over.

There ... is that so bad?

Julie,
I totally respect your side of this story and I agree that there should be a back-up if you will of the program. As I stated before though, this is propietary software for programming. No customer is actually allowed to have this on their computer.
Now, back in the day of Landmark (ya'll remember those days) we had to place it on a local computer to work AMX. Alot of the time when there were calls for problems, the program had been tampered with by the customer. We had a tough time proving that and most of the time it ended in a "service" call. Lucky for the customer, we had a copy.
With that said, if you want to make sure that there are back-up copies of this program then I will accept leaving a copy on the customer's computer (hidden) for that rainy day when my laptop, external and sync'd desktop die. But I can't see leaving a copy for my competitor or give the customer ammunition to deceive or short change me. That just isn't a good idea.
Again, human element. What's best for me (them).
I believe that most of the integration companies with a few years in the business are truely trustworthy and are there to serve their customers. We do everything to keep our names and our industry top notch. I think that you might be speaking for those "out of trunk" installers who might not be around a few weeks from now. But it's up to the customer to take safety precautions and to check the references of their installation company.
If there is a problem between my company and the customer then I would agree to part ways and give them an exceptable program to use until the next company can program their system. There are alot of modules and tricks I use that other companies either don't know about or CAN'T program. Can't see giving my "secrets" away. Can you?

No, your response was meaningless, because a comment about what people would do with PC's if Microsoft goes out of business is a red herring. (By the way, PC's are useful with many other operating systems, Unix, Linix, etc...) Your comment does nothing but attempt to derail the discussion from the real issue.

In my mind the real issue, is educate people on what they may need at some point to insure they don't pay twice to have the same system.


You are jumping to conclusions. Wrong ones at that. I have read this entire thread. Your "red herring" was but one example. There are many others.

Again.. had you actually read the thread you would know that my comment was in response to Julie asking this ...

What happens if you go out of business or I just don't like you?

When i said.....

What happens if microsoft goes out of business. What will we do with all these PC's?

I was pointing out that sometimes companies go out of business and we find ourselves in a situation that may cause us to spend some money.

Oh and by the way.. just like you can pay to put linux or unix on your PC.. you can pay someone to come in and reprogram your crestron system. Just adding this incase you were not aware.


Most of the rest of us feel the same way.


Im jumping to a bunch of conclusions right now..

This is a prime example of the misinformation that has passed for fact in this thread. It may be logical but it is nonetheless inaccurate. The customer rarely, if ever, pays the real costs of programming or labor to complete the job. These costs are subsidized by other parts of the job.

A typical job is composed of equipment, labor and material, perhaps engineering, design and project management. In the old days when equipment could be sold for a profit it subsidized the other costs. Often a proposal is negotiated and prices adjusted. The bottom line is the bottom line and it didn't matter if you lost money in one line item so long as you made money on the job.

Perhaps in your world the cost of doing business is accurately reflected in all aspects of the business, from janitorial services through R&D on through manufacturing. It is not so in mine. We eat labor as the cost of doing business but labor in no way reflects the actual cost of what it takes to successfully complete a job. The client never pays the real cost of labor, which includes programming, in any job I've ever been involved.

The client rarely pays once, let alone twice for programming. He pays to have his job completed. The entire price of the job pays for its constituent parts, from equipment failures, installation, programming, testing and trouble shooting, project management, and such. You tend to lose your shirt on labor, as a function of its line item but you hope that the job as a whole will make up for it. I have long thought that firms survive only as a ponzi scheme as new jobs pay to complete current jobs. Once those new jobs dry up....................

The client almost never pays for the labor it takes to complete the job, let alone its programming. He does not pay once let alone twice for the same system. The only time he pays anything remotely approaching the real cost is the second time and, yes, he will scream at having to pay the unsubsidized price for the labor required to program his system. Your point may seem both rational and logical but it is still nonsense as it in no way reflects the reality. Worse, few firms track these factors with sufficient accuracy to even determine if they are profitable. Does a lie become true if you repeat it often enough? You and Julie continue to repeat half-truths and inaccuracies and gloss them in a rational framework that makes it appear real and valid.

You may argue that my argument has changed. I still believe that the code I write is intellectual property but it like arguing politics or religion and so after a simple declarative statement there is little reason to repeat it. The assumptions behind this thread are flawed and worse a small minority of cases are being used as justification to do great harm. Even the side show about software licenses does not in any way reflect what happens in the sales process. Clients are overwhelmed and somewhat fearful to begin with. Although it has changed a bit these past 3 years, there is still a great deal of ignorance and fear about a true custom automation system. Inaccurate statements such as the one I have quoted that you made or the ones Julie thinks are protecting her theoretical client will merely stoke fear rather then educate the public.

Alan

I'm curious what this has to do with anything...?

Lets pretend job "A"s programming is priced at T&M, and takes 20hrs.

Times change over the years and margins on equipment shrink.

Job "B" comes along and is for all intensive purposes the same as job "A". However the job is a quoted price. You'd use the the model of job "A" to develop your quote for programming, correct? If so, has not the cilent been hosed..? I would think that the developed code for job "A" would be just retooled for job "B"....yes/no? Therefore the cilent has overpaid your actual labour costs for programming.

What I'm getting at is, how do you claim that the cilent hasn't paid full price because he didn't pay for the hours you spent on a another job doing module R&D. You're not going to say that you never reuse modules on different job are you.?

Do programmers and auto mechanics use the same methodology for job based quotes.? The mechanic does a strut job on a car and the book says it takes 5 hrs. However the mechanic knows enough to cheat with torches and hoists to get the job done without tearing apart the front end, but still charges the book hourly value. Whereas the programmer sees X devices, Y controllers, and Z access points. From scratch it would take 20hrs, but he has all the base code and can do it in 8. However feels that the job didn't get paid in full because only 10hrs were billed..?

Haven't read the whole thing,but here goes. Local college hires firm to do a total of 50 rooms with crestron some duplicated, but a bunch of different systems. all are independant of each. mostly tabletop panels some inwalls.

so it is now 6 months after they moved in and there are some things they would like to fix that no one realized didn't work. original firm won't come out and fix, and won't hand over code at all. so now they are screwed.

One would think a college would have been smart enough to avoid this. ;-)

Very sad. Why won't the original firm fix it, even if they charge for it?

Ontario, CA. A Red State mind that somehow has been shoehorned into a Blue State still a mind with limitations and gaps. Of course you do not understand and naturally fall upon an example that has very little to do with what a CI does. While there are all sorts of differences between automobiles there is nothing like trying to code for a Sony LCD, a cable box, lighting, shades, UPS, "green programming", HVAC, Blu-ray players, HDMI,networks and so on. There is a vast panoply of systems foisted upon me over which I have no control and yet for which my receiving final payment demands I solve. To wrap your mind around this problem requires more then using all ten toes and all ten fingers to count to 20.

Clearly you have never done a real programming job or a large installation. The actual time it takes to code and install a job almost always exceeds the value for these services as line item. I am not, in this instance, even making the case for the time it took to build modules or draw and code the GUI. I am speaking of the known time it takes to perform the data entry and deal with any issues on site.

Let us make this simple for you. If I am paid 7500 to code a system and my hourly rate is 125/hr I am being paid for 60 hours of labor. That gives me somewhere between 6-8 days to do all the data entry and troubles shoot the code. The sort of system I am speaking about here often involves 2-3 days dealing with network issues unrelated to the code but necessary as there are devices sitting on that network with which I must talk. There may be testing of new drivers written for that drive or worse, stupid setup manufacturers impose on you in order to keep chip sets from going to sleep and losing communication.

There is more time lost to setup, addressing, firmware upgrades and code uploads. Finally, you have to solve any installation issues that may have entered the universe. HDMI may not work--thank you Sony. You have to deal with changes where the client originally asked for X but now wants to do Y. But since this involves coding secondary systems such as shades or lights, security or HVAC, you now have to completely redo your GUI, GUI code and control code. Sometimes you write a code work around to solve some physical issue in the system. Emitters fail, serial communication is lost, more network issues, Installation issues such as misterminated wires, mislabeled wires, ground loops, RF issues, WiFi issues, does the cable box support power on numeric or does it require current sensing, interface issues into sub-systems, power issues, HDMI issues, all crop up and need to be solved. IT IS NOT JUST CODE. The system needs to work and often the issues have nothing to do with the code. That firmware you spent hours upgrading now causes broke code that heretofore worked. The client doesn't care if the problem is in the installation, the product or the code. He wants it fixed. That job where 6-8 days are budgeted always takes 14-20 man days. It is known at the time the job is signed that the line item is too small but it is also known that if 21000 were placed on the line item for programming the client would balk. It is a dirty secret that is well known that the true costs of installing the job are paid for out of other line items. The only time this comes to the clients attention is if he ever needs to have his system recoded and there are no other items to subsidize the installation.


There client never pays the real costs to install and program his system. He never pays the first time but if he does have to have the code rewritten it is why he screams. For the first time he comes to terms with the real costs of installing and programming an automation system. Sure there is the issue of intellectual property. Sure there is the issue of copyrights. Sure there is the issue of the time it actually took to prefect a module. Sure there is the issue of the time it took the draw the GUI and code it. Leaving all of that aside, and just accounting for the number of days and hours it takes to complete a job and you discover that the real costs of bringing a system on line are not paid for by the client. Since other parts of the job are underwriting the costs of the installation the client has not paid for the code. He has paid to have a working system. Let us not even bring the R&D aspects of code writing into the equation. Just pay for the actual number of hours it took to make the system work and I'd be more susceptible to Julie's or our friend from Texas' point of view and be less argumentative about turning over the code.

Would that Julie would turn her considerable skills to educating the public about what hoops a CI needs to jump through to make his system work. With falling margins on equipment it is CI profits that are in fact funding many installations.

Alan