To give source code or not.

[Michael Aivaliotis]

I was discussing this issue with a colleague of mine lately and I was wondering what the consensus was out there on this issue. When you develop an application for a customer, do you give them the source code or do you only distribute executables?

[JohnRH]

I work for a company where we are contracting out some LabVIEW development work (since we can't seem to find anyone to hire). For the applications we need developed we REQUIRE the source code. The main reason for this is simply that we have programmers who are capable of supporting the software, and don't want to be dependant on an outside company for future support/upgrades. (The only reason for contracting out in the first place is due to lack of manpower.)

I'm not sure about other companies, but Data Science Automation seems to be very willing to provide source code for the applications they develope. Obviously there are agreements to sign for this kind of thing, but nothing that would prevent maintaining and upgrading the software on your own.

Keep in mind here, the software I am talking about is for in house use only - not for re-sale.

Just thought you might be interested in a customers perspective.

John H.

[Steve_Brooks]

I pretty much agree with John H. I have done a few contract programs in LabVIEW but all of my cases have been production testers so the customer always wants the source code to be able to update. In these cases I do not sell them the reusable libraries but lock them out.

If I were to do an application where the final product was for re-sale, I would not sell the source code unless they agreed to pay a substantial amount to own it and I didn

[Frank]

I give them the source code and executables and they can use it any way they choose.

There is a clause in the terms and conditions of my contract that says:

Upon full payment by customer, program, source code (if included) and any associated files created by programmer become the property of customer. However, programmer may reuse program code in other projects or create similar projects in the future for third parties. Programmer will provide the needed files on a CD Rom disk.

[Itchyzip]

I was discussing this issue with a colleague of mine lately and I was wondering what the consensus was out there on this issue. When you develop an application for a customer, do you give them the source code or do you only distribute executables?

[aledain]

Point being if I go to to an integrator and ask them to develop something for me then we get the source code.  If the integrator tells me that they have developed x product using x language, then they can sell only the executable.

1333[/snapback]

However this does not take into account the considerable time outside the current project that the integrator has spent developing re-usable libraries, gathering expertise, etc. I believe source code should be onsold to cover these "hidden" business costs which are not necessarily covered in a per hourly development rate by the integrator. Such costs include (but is not limited to): time spent researching programming structures, training costs, office costs, project management (if not included in the hourly rate), backup procedures, in-house company expertise in THEIR program (and it's requirements), documentation procedures, travel, computer hardware updating, and experience with hardware. The fact that greater experience leads to decreased risk for customer is another aspect not appreciated (or paid for) by the client. Also I believe that integration work often involves out of scope expertise (especially in measurement/science) and that this process is creative. Creative processes should yield higher payment than simple technical prowess.

Let's look at an example. If I charge $1K per day to develop a simple application it may take me 3-5 days. Another (less experienced programmer) might take 5-10days, but charge the same amount per day. Aside from the likelihood of completing the job faster (and winning the job in the first place), the customer saves $5k by going with me, rather than the less experienced guy. But shouldn't I be leveraging my experience in some fashion? Giving aeay source code would seem to be counter productive in this sense. I pefer to argue the business case about releasing the source code, how much will the client save over the long term by having better more maintainable code? Such a creative effort that yields a positive ROI for the client should be rewarded. If it's a test system, why not ask for a per unit payment for each test watch the reaction! Some systems I have written have saved companies literally thousands of dollars per annum, and never has that effort been back rewarded to the integrator. Certain clients still baulk at paying an hour or two at $A120 for systems that cost $100k to develop, and make $1000's per year.

I would argue that a good charge for software might be 20% per year as a percentage of the total cost of development. This is not unreasonable as you do not sell the source code, you are selling a license to use said code (it is your intellectual property after all) for a period up to 5 years. After that time the source code can either revert to the integrator or the client (your choice). I would argue this along the lines that after 5 years the OS, hardware, platform, comapny will/may have changed and there will be little need for the original source code anyway.

Perhaps we should consider other sorts of publishing, if an author writes a book (programmer creates a program), many people are allowed to read the book (use the software) but the author retains the copyright to the work. If you copyright your software, shouldn't you be the only one allowed to "change" it?

[Jack Kelledes]

We almost never send the source code along with the executables but in every contract that includes software we have a support section that provides a number of hours of free support, including simple upgrades and equipment changes, each year. Mostly that protects the customer from allowing someone without the necessary experience damage the end product. Since we make high technology batteries that could get messy.

[BChandler]

We almost never send the source code along with the executables but in every contract that includes software we have a support section that provides a number of hours of free support, including simple upgrades and equipment changes, each year.  Mostly that protects the customer from allowing someone without the necessary experience damage the end product.  Since we make high technology batteries that could get messy.

1434[/snapback]

Our companies policy is similar to the above. Only the exe is sold. With limited free support. If it is one of our standard products we will not sell the source. If it is a unique project, the device was developed for that customer, then we might sell the code. But try not to, since we have some of our own tools in it. But the main reason a company may require the source is just as protection if we disappear someday. In this case we can usually agree to set up an escrowl account with the source code in it, so if we disappear they get the code, otherwise they come back to us for updates. Or if we do sell it outright they can not re-sell it or even use it in-house on any other instument but ours.

Twice we did sell the code, to companies with no Labview experience. Then when they want a change I ended up giving them Labview lessons over the phone. And talking them through the change they wanted, while keeping my copy syncronized. A real pain with customers with no programing experience AND a thick accent!

But our case may be different than some, we make lab instruments not just the s/w.

[Steve Watts]

We nearly always give the source code. The only time I got a little twitchy was when a joint project with a competitor was proposed. Nearly lost my nerve!. Our point of view is that we are designers not source code salesmen.

[Louis Manfredi]

A good question, I'm interested to hear what others think too.

To date, my business model is pretty much that I'm a hired gun programmer. I charge the client a fair price for my time, and they've got the right to use whatever code I write for them however they please. Generally speaking what the client wants is an executable to work with some specific piece of one-off custom test equipment.

But if they want the source code they can have it too. They might want it either so they can maintain it themselves, or in case I croak :ninja: or do something else equally unbusinesslike.

I don't mind talking on the phone with a client to support them modifying or maintaining my code (or their own code, for that matter). Unless the call is related to making a program written on fixed-price quote work according to its original specification, I don't mind billing them for the time, either. If the client thinks its more efficient to modify a program themselves (for example if I'd have to ride a plane to get to the hardware to fix it myself) or if they simply want to learn LabView, I'm happy to help.

I re-use utility routines not specifically linked to a particular client's application. I tell the client that I'll be using previously developed utility routines for their application, and that I might use code I develop on their dime for other projects in the future (excluding, of course, anything that might expose their own proprietary interests). So far, none of my clients seem to mind this arrangement. Most of my clients are pretty focused on getting one particular task done, and none of my projects have had much potential for going into shrink-wrap.

To date, my utility routines are pretty simple-- make a filename that encodes date and time in a way that data files automatically sort in chronological order in a directory listing, or write a sub vi's location and size to an ini file, so that when closed and re-opened the subvi shows up in the same place on the screen-- that kind of stuff. Routine stuff with equivalents probably available in a bunch of different open G libraries, stuff I'd share freely, even with a non-client.

Lately however, I've developed some code that's pretty powerful and general, might be easily adapted for a variety of different applications, took a while to write, and might even be worth marketing as a toolkit library for others-- For that code, I suppose I'll lock the block diagram, and get involved with all those messy source code in escrow or licensing issues, so I'm curious what everyone else in the LabView community does & where the pitfalls are.

Best, Louis

[Mike Ashe]

It depends on the customer and contract they want. Most of my projects have required the source code, since I usually work with companies that already have LV programmers, OR, part of my services is that I not only developed code but have provided training to their personnel, sometimes formally, sometimes informally.

I usually have a clause in the contract explaining that part of what I bring to the project is code snippets, libraries, techniques, etc that I have developed from other projects and that they understand that I will use this in their project to save them time and money, but that they also agree that I will retain the right to reuse general purpose VIs, snippets, techniques that I develop in their project for some of my other future projects. If they balk at that, I do not argue, I simply change the terms to reflect developing everything from scratch for them and often the cost differential makes them see the light of reuse.

In all cases, unique code developed for their application to their specifications becomes the right and property of the client. I never try to retain that, although once I did put in a clause that restricted the client from distributing any version of their software without my say so, in return for a large price reduction. They owned and received all source and can use it internally for anything they want, but cannot give or sell it to anyone else. Special case.