Home AMX User Forum AMX General Discussion

Source Code Policies

More and more bids and customers specify that uncompiled control system program files must be delivered upon system completion.

I am interested in knowing what types of policies other programmers/integrators have concerning this issue.

Personally, I cant stand the fact of spending so much time on an excellent touch panel and processor programming, only to have another vendor get to use your hard work to gain some business.

I also dont really enjoy working on anybody elses programs either. As time goes on, programming methods are getting more varied than ever before. Sometimes I miss the days of basic AXCESS code.

Occasionally I will review some code from other vendors, and the first though in my head is "what in the world are they thinking?"

It's almost like a cop trying to get into the thought process of a serial killer.

Any system could probably be programmed 20 different ways to accomplish the same functionality.

I would appreciate any feedback.

Thanks.

Comments

  • frthomasfrthomas Posts: 176
    In our line of work, we do propose escrow for the "what happens if you go out of business ?" type of worries. Costs a bit but protects everybody.

    Customers are simply becoming educated I suppose.

    Fred
  • Chip MoodyChip Moody Posts: 727
    What a brilliant freakin' idea... Who keeps the escrow then?

    - Chip
  • frthomasfrthomas Posts: 176
    A lawyer. You write a contract between the three parties that describes in which conditions the lawyer releases the source to the customer. The typical condition is you going out of business, but the customer may want to add a clause about you failing to meet some agreed upon support performance (f.e. 99.8% availability or something).

    Of course the case of the lawyer going out of business has to be taken care of as well in the contract, but in practice it's very rare :-)

    We do extremely complicated ones given our business nature (security), but I guess something plain and simple should be reasonable cost wise for both parties.

    Fred
  • DHawthorneDHawthorne Posts: 4,584
    It has previously been an unwritten company policy to load all source code on the masters. This was mainly done for ease of service, so a tech could insure he had a current version before doing any on-site touchups. However, a few years ago we had several employees strike out on their own, and it is no secret they took many accounts with them...neither unusual nor unexpected. But for me, it personally wrankles that code I labored over has effectively been turned over to our new competition. So I have started password protecting all my source codes, and am in the process of prevailing upon sales to specify we are only licensing the use of software to customers. Some customers balk at this, and I make exceptions if the are adamant about it. But for the most part, I am trying to protect generic modules, not the actual code that runs the system that is tailored to that client.

    But the other side of the story is that I only rarely find it efficient to work with someone else's code. By the time I wrap myself around their way of thinking and doing things, making my adjustments, etc., it's easier to re-write from scratch. I also tell customers this. If they decide down the road they want to fire us, chances are any new dealer they get on the job is going to want to re-do it their way.
  • Thomas HayesThomas Hayes Posts: 1,164
    If the code is really special, that you put alot of time and effort into them why not set it up as a TOK file. I know of one such programmer that does this. The source code is pretty standard stuff but the real fancy stuff is protected from others. I know that our department has had more than one design used without our permission. The other solution is make your code so hard to follow that anyone trying to use it will get lost.
  • Source Code Policies

    This is a complex question and there is no single answer that fits all circumstances. Our perspective is that we sell a working system and not our intellectual property represented by the source code. Most of our systems involve a great deal of module re-use using modules that we have invested considerable time in building. While most customers feel they have paid for this software development effort, in fact this is not really the case. The cost of the development effort is really borne by multiple projects and customers realize the benefits of getting better code at a price much lower than if they had to pay for its development entirely. We are constantly building a module library of re-usable code and touchpanel templates and this is a benefit not only to us but to our customers. Recognizing however that customers want to protect themselves against us going out of business or failing to service their installation properly, we do use some of the following methods:

    - We first decide if there is anything to protect in the Netlinx source code or the Touchpanel files and if not, then we gladly provide it to the customer.

    Assuming there is something we care to protect, then we handle it a number of ways:

    - Utilize an escrow service to retain the source code for the project (the source is however copyrighted) and the customer agreement states that the purpose of the source is for maintenance only - if the source code is distributed for any reason, it is our perogative to pursue the customer and/or offending dealers for remedies. We also charge a source code fee in this case if the customer exercises the source code right for maintenance purposes (we are still in business).

    Note: In addition to lawyers, many banks have escrow/trust departments that are well equipped to provide this service and with most banks, you do not have to worry about them going out of business.

    - We provide the copyrighted source code to the customer directly with the same caveats from the escrow/3rd party case above regarding distribution and use. We apply the source code fee up front when it is provided to the customer.

    - In some cases where we have invested a considerable amount of time building a custom module or touchpanel file for an application that is used in many jobs, we take the AMX approach and only provide the TKO form of that module. This eliminates any issues associated with its distribution. This option also allows a customer to switch dealers if they choose for maintenance and that dealer can maintain and extend the system with the exception of course of the binary-only modules. This is often the most flexible method since it involves no agreements or special protections.

    - We also have to keep in mind that most if not all Netlinx systems we do have one or more binary (TKO) module that we can not provide source code for since we do not have it ourselves. We do not have an arrangement with AMX to get source code for those modules so this is naturally a limitation that the customer inherits as well. This is something we clearly state in any agreement regarding source code with our customer.

    - A final note, we use the Build with Password option and upload the source code to our Masters regardless of customer agreements. We do this as a service to ourselves for maintenance but to also ensure that source code is not inadvertantly retrieved and modified by the customer or another dealer. This is for source code protection but also to make sure that the binary version of the system is not modified without our knowledge creating a potential maintenance nightmare.

    I know a lot of this sounds overbearing but we do a lot of commercial projects or very sophisticated residential projects with some very unique devices that require significant module development. I am not trying to protect a TV, VCR, or DVD module as these are not that interesting. However, when we write custom interfaces for network devices, cameras, HVAC systems, security systems, etc., these are modules we take an interest in protecting. I realize we have some customers as well as dealers that were once customers participating in the forums and they are likely to have differing opinions on whether or not a customer is entitled to the source code as part of the project. That is a slightly different discussion from this one which might justify its own thread. Hope this helps provide another perspective.

    Reese
  • Chip MoodyChip Moody Posts: 727
    Originally posted by Thomas Hayes
    The other solution is make your code so hard to follow that anyone trying to use it will get lost.

    Thomas, are you saying that I should feel okay or even good about hardly ever commenting code? :)

    - Chip
  • jeffacojeffaco Posts: 121
    This has come up before in this forum. My thoughts haven't changed. Nice to know I'm consistent; consistent whacked out ideas are better than inconsistent whacked out ideas, right? ;-)

    I'm not the "normal customer". I'm a professional software developer, and (arguably) likely have coding skills as good or better than most that work on AMX systems. For goodness sakes, I've been writing computer code since 1975; you'd hope I've learned a thing or two through the years! ;-)

    As a developer, I want the source code, period. I would have booted my installer (the guy that did the original implementation) right out on his butt if he didn't agree with this. From my point of view, I'm paying him to write software for my system; that software is mine. I've paid for it. End of story.

    <The fact that I may or may not be able to get the software packages to develop my automation system is another story, but that's not the topic of discussion here.>

    This is actually common behavior in the computer industry. If I go and hire a consultant (or a company) to write some custom software for me (from scratch), I fully expect (and would) get full source rights to said software. That's what I paid the bucks for.

    Now, it's more interesting if you're using some common framework (i.e. .TKO files) that contain IP for my system, and use of that framework lowers the overall price for me. In that case, I'd likely not expect source to the .TKO files (or I'd need to sign some agreement that I'm legally liable to make sure nobody other than me sees the source to those modules, or whatever).

    But for the code that I paid somebody to write: Hey, that's mine. I paid for it. The fact that you might be able to use said code for some other customer in the future is a benefit for you, depending on exactly how the code was copyrighted.

    I can't imagine doing a professional consulting gig for some customer to write a custom software package for them, and then not give them the software. I guess you could do it (if it was spelled out in advance), but that's certainly not customary in the computer software industry.

    Most of the time, when you buy computer software, you're buying a previously developed package, so you're not buying the software, you're buying a license for the software. That's different.

    But that's NOT the case when you hire someone to write some custom business software package for you (which is roughly equivalent to hiring an AMX guy to write an automation system for your home or business).

    -- Jeff
  • Absolutely in whole hearted agreement with Jeff. I would prefer that the client calls back because they want to - not because they have to. As a rule, I structure my client contracts so it clearly states that ownership of the source code for any and all custom programming written specifically for that job is transferred immediately upon receipt of 50% of the agreed upon price (the required deposit also happens to be that same 50% level). Where I will be using application modules I have previously developed, the source code is again included and each component is line itemed invoiced and appropriately compensated for. The exception is device drivers where I may or may not have access to the source so for consistency that code is excluded. Part of the ongoing service includes ensuring that new drivers are updated on the project as they are available - same policy as applies for the control system hardware firmware updates.

    Ian
  • TurnipTruckTurnipTruck Posts: 1,485
    One thing that I have learned in many years of business is that it is difficult to have a specific policy on what you give or don't give to a customer. Sure it would be nice to give them nothing and retain all rights to anything and everything that you put into a system design, but here in the real world it simply doesn't work that way. If an opportunity comes along to do a job that is above the average of what you would typically do, and the customer demands more that you typically give, I'd bet my money that you would give in. So much for your tight retention policy.

    The idea is to give them as little as possible. The closer that you are to the drivers' seat in a particular contract, the less you can hand out. The more in DEMAND you are, the less you have to SUPPLY. Being better at what you do and being known for it, puts you further in control of your business practices.

    Be the best designer or programmer you can be. Unless you are Bill Gates, exclusivity will not protect you and your assets forever. He'll go down sooner or later too. You heard it here first!
  • Thomas HayesThomas Hayes Posts: 1,164
    Originally posted by Chip Moody
    Thomas, are you saying that I should feel okay or even good about hardly ever commenting code? :)

    - Chip
    What are comments? I rarely use comments for that very reason, if I do its only 1-2 words. Right or wrong thats one way I slow the next guy down and hopefully &^% him off enough so that he writes his own code. If I know the other programmer I will help him out as a favour though.
Sign In or Register to comment.