I have a LOT of custom logic modules to handle driving the UI and moving all the bits around.

Technically every job I do is CUSTOM, but I have a frame work so I drop in TSW Interface module, Audio Zone Module, Video Zone Module, STB module, ATV module etc. then can copy/paste and rename.

I am working on a more generic System Reset/Power module that will work with a Wattbox or Panamax or what ever and using a S# module send out an alert txt.

All of that and how it is used is my company's IP.

One can make an argument that even discussing how I lay out my systems like that is proprietary knowledge.

What should be discussed is if Control systems can act more like a computer.

So instead of embedding the IR codes or Serial strings, why can't the program access those from a database or a file.

Then all that has to happen is you upload a new database or file when you change a device.

If by custom you mean a custom, scalable, and extensible programming framework and UI, then yes. Many companies (including our own) have invested hundreds if not thousands of hours to develop proprietary and repeatable solutions that save us time and save our clients money. We do not start from scratch or re-invent the wheel on every project. Because of the amount of time and money invested on our end we do not release the full, unlocked source code to our clients. They have paid for 10-20 hours of commissioning time to deploy our programming framework into their system, not for the 1500+ hours it took to build it.

Now, that does not mean we hang our clients out to dry. Each client is granted a non-exclusive license to the software, and we will release an editable version of the source code and UI files upon request--assuming payment in full. The released versions contain locked modules that are coded to the project so they cannot be re-deployed or reverse engineered to the benefit of another company. Of course password protection alone is not going to stop some very experienced Crestron programmers from accessing them (although we've implemented some other tricks), but it's a fairly safe assumption programmers at that level have built frameworks of their own.

Outfits with small staffs or limited experience with Crestron that end up programming every system from scratch (or close to) would be much better off exploring Crestron's new Home Elements framework. It will save you A LOT of time and will allow you to complete more projects. More projects=more money.

This brings a compromise to mind. Over the years I've noticed something about equipment rentals: Under normal circumstances it seems by the time you're done, you've paid about a tenth of the price of the thing you're renting.

Why not offer to provide a copy of the source code to the client for one tenth the cost (at your retail programming rate) of that 1500 hours? Just disclosing that you're offering it at 10% of its cost, then quoting them the staggering sum that would be, would make the point that no matter what the client thinks, there is REALLY valuable stuff in there and you cannot simply give it away.

This would be done with a contract that restricts them to use only in the one system they now have. While this, in itself, really guarantees nothing, it may bias the customer in favor of you doing the further work. (Of course, now it's up to you not to be a jerk, nor to lose the files yourself, etc etc.)


I doubt that many Savant dealers are reading through these long paragraphs. I suggest you start a thread about this to catch the eye of the Savant dealer who couldn't care less about Crestron and Control4.

And, guys, it's hoard, not horde.


Every programmer I've ever run into will not deliver the code. What's the size of your survey base and what is the actual percentage of programmers who delivered the code in that survey?


The client depends on the skill, honesty and openness of the programmer to disclose the details. As someone just said, they'd be loath to sign a programming contract after being told they cannot have the code. Again, the dealers I've known simply do not tell the clients.


If that is an issue, then the programmer is going into the contract with the expectation that the client won't pay, and he should say so at the outset.


But the Crestron client has to vote with his wallet AGAIN, too.


What is there of value about the development part of a system that makes the average customer want to pay much more for that development? Isn't the final control product the issue? I can have a car custom made or I can buy off a lot. If my goal is ease of driving, safety, and normal auto issues, why would it impress me that I could get a custom-made car?


The only reasonable way not to be dumb on this subject is to be "cheated" once. Sure, everyone you know explains all about the code to the client ahead of time... really? Is it boilerplate in your contracts?


But it is reasonable for a customer to believe that he owns what he receives. He receives the programming.

Actually, the only place that you and I differ is that I do not believe Crestron programmers make a point of telling every client that the code will not belong to the client. Over and over, it's an astounding and outrageous surprise to people -- yes, consumers -- that the code belongs to the programmer.

Your comparison with Windows is not valid. Everybody buys Windows with the expectation that they are going to get a program that they have to tolerate and that they'll have to not only pay for, but pay for all over again just to put the same damn code on an additional computer.


No. Your family can't suddenly get a bright new kid because the old one got obsolete; or quit working and only a new model was available. Bad metaphor.



There should be a signature for it before you accept a contract (maybe you get this; you did not say). Once the system is done, the customer can hardly not "sign off" on this; that would mean all the work done would be wasted.


...and, good point. Again, though, it should be explained at the start. See, you have zero bargaining leverage now, since they have the working system. You only have leverage when they decide to make changes or sell the house.

If you had read the rest of my post and not just the first paragraph you'd have discovered that we do exactly that, except we don't charge any additional fee.

I did read the entire post. My proposition is for those who cannot consider "giving it away" for free.

That phrase just reminded me of the fictional 1970s Jewish hooker, Fanny Hillman, who said

Well, I am 5'2". Live in the North East US where we can get a lot of snow. I live in a place where you either live at the top of a hill or at the bottom of a hill or on a hill. I have to drive into NYC for job sites.

NYC garages charge an extra $10 for parking "oversized"

I sometimes have to run to Crestron and pack my trunk full of stuff or get a 55" LCD in my car.

So if I could get a custom car that was compact had a LOT of cargo space was great in the snow got 50+ MPG was a hybrid or used a fuel cell and had fully adjustable seats mirrors steering column and peddles or and a turbo and 0-60 in a nanosecond don't you think it'd be worth it if I could afford it?

Do you want to use a Personal Computer that has been developed since the 70's and has three fully developed and supported OS to pick from and hundreds of manufactures for parts or do you want a RaspberryPI and then have to learn computer architecture and programming to get all your software to work?

One will cost you hundreds to thousands of dollars, the other is about forty dollars.

Development costs are in EVERYTHING we use even drugs.

See, all of this is why Elan is the perfect solution. All of the configuration resides on the processor and the client has control of who can and can't access their system. Then, in a few years when their processor dies (all brands die at times) and that model is no longer available and the new processors use a different OS, you get to charge for full rebuilding the configuration and blame it on the manufacturer!


And now I'll wait for the phone calls...

On the subject of non paying clients, of course you would never hand over the code until you are paid in full, and of course getting paid in full is dependent on having provided the client with exactly what they wanted as per your agreement and without genuine faults in the system or programming.

Assuming the system is tip top and you have a client that just does not want to pay, how many of you build "encouragement to pay" into the system? I remember we had a client that would constantly delay payment until he was "satisfied" with the system and we bent over backwards for this guy. There was nothing wrong with his system and we made several visits that were well above and beyond the scope of the system to get the final cheque. We realised that he would never be "satisfied" and just didn't want to pay, so on a visit to make some bullshit change he wanted, we made a few changes that made life uncomfortable for him and his family including lighting operation, HVAC control and distributed audio. All of which started behaving in an annoying manner about a week after that visit (we allowed that week delay to see if we would get paid). He was "outraged" that we would not return to fix this issue until we were paid, but after a few nights of trying to sleep with the bedroom lights on full in an overly warm bedroom he got the message pretty quickly and relented. Amazingly all issues disappeared within 5 minutes of my arrival to pick up the cheque. As i was leaving i mentioned that in about 10 days the system would ask for a once only key (pin number) to be entered to continue normal operation. This was bullshit to make sure the cheque didn't bounce.

Since then the contract got changed to include that the program was a trial version that would expire 30 days after the completion of the job if not paid in full and customers who are unlikely to pay start getting messages on their screens when that 30 day time period is approaching warning of impending shutdown.

Actually, I answered his question on the first page already.


Sweet. As promised, here is a recent post from one of my Camaro Facebook groups for you to read through...

"I have a question for you tpi guys, is anybody here turning 6k+ rpm out of their motor? I have an aftermarket tach on my car and have had it for about 2 years, the other day I drove it and I turned it to a little over 6k. I thought somehow the tach got put on a different setting lol (ie v6) but it didn't. It didn't make full power the whole way but I couldn't believe it made it at all. I was able to do this several times in that drive and a couple times in another after that. Stock motor with bolt ons and very opened up intake and exhaust. Nothing crazy.... Idk how it is doing it lol"


Let me know when ya need some more.

WINNING

You sure did! And in less than eight hours. And thanks for doing so in 300 words or less ;)

I've heard about all the custom modules for this and that, and have read how you drop these custom modules in when programming Crestron.

Don't those pre-made custom modules change the setup of the system from programming to configuring, at least for those steps? Do you charge the same to every customer who uses those modules, or did the first guy pay what it cost to create it, and everyone else pays much less?

If you own the module and you don't charge the same to the first customer and to subsequent customers for the use of it, is that fair business?

If you're asking if the first client should pay more then subsequent ones; have you ever gone to an opening night of a movie vs. going to a $1 theater 2 months later?
Same movie, why the cost difference?

The only ones who own "the code" are the manufacturers of it. Crestron, Control4, Savant etc..... We take control protocols provided to us by the manufacturers of the items we want to control and make them work with the code provided to us by the code manufacturer. Those two things combined together make the system programming we use to integrate the items we either sell or take control of for our customers.

None of you, including myself, are creating anything. We are simply a bridge that have been trained in someone else's code.

GUI is something that we can create and it should be sold appropriately.

But quite obviously with the recent success of systems like Savant and Control4, customers don't give a crap about GUI they just want it to work. And integrators don't want to spend time having to create a GUI either.

There are way to many of us doing things just because we can, not profiting from it and then puffing our chest out to whoever will listen (which I assure you is just us).

I refer to the auto industry. You can't go order a custom dashboard from BMW or Mercedes. It looks and feels as it does, and it works. You may not like one over the other so you choose.

The client who buys the system owns the program that makes it work. You sold it to them as a working system and in order for that to be true, it needs the program. If they want to add, change or move anything in their system, they should be able to do so without hassle.

Leave it onsite and make them responsible for managing it. Of course you have a copy for changes etc...

This is yet another thing in our industry that hinders growth. Know one here has taken over a system without the client bad mouthing the original integrator for whatever reason.

Stop giving our customers reasons to bad mouth this industry. Provide them with the program.

Wait, WHAT?

Using this logic Dennis Ritchie owns all the code to every Playstation game since he invented C and PSX games were written in C.

All those games needed to use the API from Sony to interface with the sound processor and gfx processor, so you are saying that Dennis Ritchie owns the code for Castlevania: Symphony of the Night and not Konami?

I don't think you understand what programming/Computer Science is.