Julie, clearly as such a complex topic the answer cannot be as simple as "if your not able to get all the code then buyer beware you may be better of with the likes of control 4/Liifeware".

There is a good deal of minutiae that when combined can make huge differences to the ultimate decision a client might make and if you exclude much of this from an article you are doing not only the CI's a disservice but you may oversimplify the information a client should be aware of.

Some things that a customer should ask:

How long has the CI been in business?

Can I see another working system at a client's home?

What does the contract state with regards to receipt of code?

What is the difference between modules and code and which do I get? (A very important point that if not defined clearly or understood could completely change a clients perception of a CI.)

Does the system include an up-to-date schematic? (Ours do, a very important item that would assist any programmer in generating new code)

Do I get the graphics? Are they template based, customised or purchased from a third party GUI vendor?

At what stage do I get my receivables - code, drawings, disks etc? At training, full payment, when...?

Are there arbitration agreements in the contract so that if things go wrong and the one of parties wants out there is still potential for the client to receive any code as part of a settlement?

What are the expected service costs of any system and when are these performed?

How much customisation do I require from my control system? Is the system I am looking at capable of such customisation?

How expandable is the system? Can I make adds and changes freely or am I restricted to a certain number of components or devices without making a major upgrade?

All of the above and more are important educational points for a customer and could dictate whether a client chooses AMX/Crestron or Control4/Lifeware but also ensures that they get the right CI for their job.

Simplifying the decision to just about code is to discount many other reasons that should be carefully considered.

I wanted to also point out the differences to anyone who is unaware of the difference between code and modules.

In, say, a thousand lines of code a couple of lines may refer to a module.

That module is another piece of code that is included when programming the controller.

A new programmer that has access to the code can readily and simply make changes to a lighting scene or other simple function. It would take essentially the same amount of time to do so as it would the original programmer.

If the client changes out a piece of equipment that is controlled by a module then the act of reprogramming is a simple as changing few lines of code that referred to that module and adding in a new module. If it is a commonly controlled piece then any programmer worth his salt will have such a module or it will be available from AMX/Crestron's website already.

Whether the original programmer or a new one makes the change it once again would take roughly the same amount of time.

Julie, you agreed with Spyeguy's "words of wisdom" that people that keep modules should get off their high horse. I say you clearly don't understand how a module works and that Spyeguy either doesn't use highly customised modules or doesn't understand them either.

For the record our company provides all code, touchpanels, as-builts and disks to our clients with the exception of custom modules that can be easily replaced by any competent programmer.

This thread should be subtitled, "How to create the thread that never ends; AKA 'which speaker wire is best?'"

This is so much more complicated then even my earlier post suggests. Someone above alluded to the fact that if you use other copywriten code, albeit graphics or modules you have purchased you have a for use license. Let's assume that license from those third parties is valid and legal for the sake of argument. Unless the client purchases that software legally from the company Julie is no advocating that I can use her copy without her permission or the permission of her employer.

I agree that this issue ought to be spelled out contractually and the client given the right to purchase it. But having been in these wars I've offered the software for a fee and most clients take the stand that they've payed for it as part of the job, when they have in fact paid for a working system.

The real solution is to have the client pay for the real development time of that software but that adds to the price of the system and few clients will pay for this. In the commercial world they do and the code is handed over.

So there are two solutions. Client pay for the code, the real development time of the code. 2. The client can pay to have the code placed in escrow.

What Julie is now advocating is that only her intellectual property cannot be used without her consent. But a CI's can be used so and more importantly, Clients have no obligation to pay for it. Every CI covers his programming labor with profits from other parts of the system. Only in commercial have I seen programming line items that actually reflect the time it takes to make the system work.



Alan

MonsterCable

I don't know the semantics -- just know that consumers need to be aware of any repurcussions of dealer goes out of business.

Today, the question of how long the dealer has been in business is moot.

[Link: ironmountain.com]

I am an AMX programmer who has written many modules. I freely share these modules with colleagues of mine and have posted some on various forums. I understand how long it takes to write these things and how much work goes into them. It just so happens that I learned to code from reverse engineering the code of others who were kind enough to share with me, so it would be in bad form to not share with others.

As I stated the new world of software development is more and more going to the open source model. Why? Because many minds are better than one. Some times when I share a module it comes back to me better than when it left.

However I understand the desire of people to protect their modules, and what do you know, with AMX you can do just that. You can compile the module and the end user or their hired gun will never be able to get at the inner workings.

The state of the modules in the code is less relevant to the end user than having the source code itself, why do they care if the module is locked or not, only that it works. And if the end user has the source code, than doing something like swapping out a piece of gear is hardly a massive undertaking.

Yes OK, times change. That doesn't moot all the other points though.


Our company actually has a plan if we were to go out of business that includes contacting other local CI's to transfer ownership of clients files, info and service history. As a new source of revenue for thin times this is a valuable connection to another company and consequently one they may be willing to pay for, a win-win for them, us and the client.

Fair enough, you get some of your modules from others and think share and share alike. We don't get ours from others and consequently don't have the same opinion.


If you are willing to share what modules you have with us then I will gladly join your ring of developers and share ours with you and yours. Seems fair to me, I'm happy to adapt and change company policy to suit!



My point exactly... you don't need the modules so why would it be a problem to not have their uncompiled code.

I agree. Some of these simple programs are akin to say, twenty-five years ago, removing the dials on an X-10 product so the client doesn't know which house code it's set at:-)

This is just not true, several of the posters here myself included that agree with Julie are indeed ether true blue or AMX guys.

a bit oversimplified, don't you think?

Julie, I understand the consumer rights that you are trying to protect, but it's painfully obvious that you are not open to protecting our intellectual property. Until you learn how to program these systems you will never be able to understand the time and knowledge necessary to write useful and repeatable code.

Any consumer that has paid their bill should not be locked out of modifying their system. However, it doesn't mean that they are entitled to every resource that was used in the development. There are very few companies that would hold the code hostage if the bill was paid. Even if I was out of business I would still give my clients whatever they needed. However, while in business I should not be expected to freely distribute the intellectual property that gives me an edge vs. my competitors.

When we program touchscreen remotes they are very similar to a web site. If I hire someone to design a web page for me, they will deliver all of the complied code to properly display in a browser. It would be rare for a company to offer their design files used to create custom fonts, flash modules, graphics layers and project planning materials.

Contractor's legal documents should specify exactly what the customer will be receiving. In nearly all cases it should be assumed that the client is purchasing a use license only for the devices originally programmed. A customer should ask the contractor if their proposed control system can be modified by another dealer of that product. My control system is RTI, the program for each device can easily be retrieved and it doesn't really matter if I go out of business.

Crestron and AMX are much more difficult to program, but that's a real a-hole comment. We can spends days or weeks on custom touchscreens too.