It is important to point out a possible conflict of interest that may come up if a custom software vendor does work for two customers who compete with each other. That conflict of interest can occur if one customer pays the vendor to develop a software solution and then the other customer who competes with the first customer asks for a very similar solution. In that case, is it ethical to provide the same code to the second customer, possibly at a discounted rate, when the first customer paid full price for that code?
This is particularly prevalent in software development because a vendor may be hired specifically they have expertise in a particular industry. In fact many software vendors, the smaller ones in particular, specialize in particular industries. Such vendors are almost bound to run into potential conflicts such as this.
A more complicated problem occurs if the software vendor assisted in developing the specifications for the solution. What happens if the vendor helps one customer devise some ingenious and innovative idea that provides that customer with a competitive advantage? Is the vendor allowed to suggest any aspect of that idea to a competitor of that first customer?
The answer: clearly not.
How do you avoid such conflicts? Some customers may request that the vendor sign a legally binding contract preventing them working with competitors, at least over some well-defined time period. In that case it is not a problem.
But if the vendor is, in fact, presented with this problem, I believe that there is only one solution. That solution is to prevent the same project managers, programmers and engineers from working for both customers.
If you instruct the technical staff to avoid discussing such ideas, you’re putting them into a very difficult and possibly impossible situation. How do you separate generic technical ideas from specific ideas?
So the only answer – separate your technical staff into different groups for each competitor.
Note that this is not necessary if the customers are not competitors. I worked for a company that provided ID card solutions. Some of the ideas that were developed for issuing employee ID cards for a telecommunications company were used for a large bank. Some enhancements paid for the large bank were proposed to the telecommunications company. Both companies benefited and neither company paid for any code development that also helped a competitor.
Tuesday, May 12, 2009
Friday, May 8, 2009
Who owns the source code?
For the non-technical reader, the “source code” can be one file but much more often multiple computer files containing text from which the binary files (consisting really of just ‘1’s and ‘0’s recognized by the computer) are created. This “text” is really, of course, the computer program itself. It is written following strict rules of syntax based on the particular language selected for developing the program. Though the source code files contain text, and can generally be read with Notepad or other text reader programs, they are not generally simple text files and are typically accessed only through the software development environment.
The binary files created from these program files are what the computer actually executes. Anyone who has the source code and the appropriate software development tools (primarily a compiler) can recreate the binary code that makes up the solution.
In summary, the “source code” provides in a human readable form the intellectual property that the software vendor is providing to the customer.
So the question of “who owns the source code” could be rephrased as “who owns the intellectual property”.
This question is relevant to any discussion of the reusability of custom software code.
Equally clearly this is not an issue with standard software programs. In those cases, the vendor pays for the development of the software so they own the intellectual property and, therefore, they own the source code. (Obviously I am ignoring open source code programs with that statement.)
But in the case of a custom software development project, the issue is a bit more complicated. In such cases the customer is paying for the custom code that is being developed. So shouldn’t they have a right to a copy of that code?
If you buy a custom-designed house directly from an architect, you are surely allowed to have a copy of the blueprints!
In my mind, the answer is “Yes!” The customer does have a right to a copy of the source code. I ran my own consulting company for a number of years and I never hesitated to give any customer who asked a copy of the source code that I developed. (I was only asked once to do so.)
While this is my opinion, other custom software developers have a different view.
It is important to note that there are some inherent dangers and genuine complications in giving this code to the customer.
The first danger is that the customer may make changes to the program, unknown to the vendor, but still expect the vendor to support it.
I personally saw an example of this.
In the early 1980’s, I provided consulting support for a number of small companies. That was back in the computer Dark Ages when personal computers were first becoming generally available. Much of what I provided used a program called dBase III. That program was “interpreted” meaning that it was compiled into ‘1’s and ‘0’s as it ran (during ‘run-time’). There are multiple disadvantages to such programs (including needing to purchase a copy of the dBase program for every workstation and the fact that such programs run much slower). But the biggest disadvantage of such programs, relative to the current discussion, is that the source code is readily available to the user (as long as they know a few basic rules about how to access it).
If they have access to it – then they can change it.
I had a customer call and complain about a problem that they were having with one of the programs that I wrote. I stopped into their office to fix it. I quickly found that someone had modified the source code that I provided! It was those modifications that weren’t working. I found out why they wanted those changes and repaired the program appropriately.
In a large corporate environment, there is a clear and present danger in allowing the customer to make such changes. Fortunately, most customers understand these dangers and don’t have any more desire than the vendor to allow such changes by the customer’s representatives. Moreover this sort of problem tends to be easy to spot (the size of and the date-and-time stamp on the binary files will be different, for example). In addition, I can’t imagine a customer who would argue with a vendor who billed for fixing a problem caused by someone working for the customer who modified the program.
A second potential danger in providing the customer with a copy of the source code is that you are possibly enabling the customer to become a competitor of yours. The customer can potentially take what you wrote and resell it, possibly making small changes as they do so but still using the intellectual property that the vendor created as the basis for what they sold. I believe this danger to be minimal. People interested in such custom software are probably people who compete with the customer who has the original code. The customer is unlikely to wish to enable their competitors.
But this possibility, however unlikely it is, can be handled by contract terms within the contract agreed to between the customer and the vendor.
A third problem is that the source code will generally include reused code that was developed initially for another customer. In that case portions of the source code were paid for by other customers. So if you provide all of the code for the customer, it is likely that you are giving the customer intellectual property that they didn’t pay for.
Once again, there is a solution. It takes a bit more work, but the source code that the customer did not pay for can be provided in a binary form rather than in the original source code form.
A final problem is that the source code can be given to another vendor and that vendor can take over the development and support of the program. Again I consider this to be a relatively small danger. The original vendor is bound to be much more familiar with that source code and should, therefore, be able to be very competitive with anything that any other vendor could provide.
But clearly there are dangers and complications in providing this source code to the customer. That is why many vendors believe that the customer should NOT be given that code.
But there is a legitimate reason for the customer to want a copy of the source code is that there is a dangerous situation: the customer needs to have some reassurance that their program can be modified if the vendor goes out of business.
How do you handle that situation?
There are companies that provide the ability to put the source code into escrow. The source code is hidden until (and unless) the vendor gets out of the business.
There is a cost associated with this. That cost should be built into the quotation provided to the customer.
The biggest danger of such escrow accounts that I have witnessed is that while the initial solution is safely put into escrow, any updates are not necessarily included. It should be the responsibility of the project manager to make sure that all updates are put into escrow if such an account has been established for a particular customer.
The binary files created from these program files are what the computer actually executes. Anyone who has the source code and the appropriate software development tools (primarily a compiler) can recreate the binary code that makes up the solution.
In summary, the “source code” provides in a human readable form the intellectual property that the software vendor is providing to the customer.
So the question of “who owns the source code” could be rephrased as “who owns the intellectual property”.
This question is relevant to any discussion of the reusability of custom software code.
Equally clearly this is not an issue with standard software programs. In those cases, the vendor pays for the development of the software so they own the intellectual property and, therefore, they own the source code. (Obviously I am ignoring open source code programs with that statement.)
But in the case of a custom software development project, the issue is a bit more complicated. In such cases the customer is paying for the custom code that is being developed. So shouldn’t they have a right to a copy of that code?
If you buy a custom-designed house directly from an architect, you are surely allowed to have a copy of the blueprints!
In my mind, the answer is “Yes!” The customer does have a right to a copy of the source code. I ran my own consulting company for a number of years and I never hesitated to give any customer who asked a copy of the source code that I developed. (I was only asked once to do so.)
While this is my opinion, other custom software developers have a different view.
It is important to note that there are some inherent dangers and genuine complications in giving this code to the customer.
The first danger is that the customer may make changes to the program, unknown to the vendor, but still expect the vendor to support it.
I personally saw an example of this.
In the early 1980’s, I provided consulting support for a number of small companies. That was back in the computer Dark Ages when personal computers were first becoming generally available. Much of what I provided used a program called dBase III. That program was “interpreted” meaning that it was compiled into ‘1’s and ‘0’s as it ran (during ‘run-time’). There are multiple disadvantages to such programs (including needing to purchase a copy of the dBase program for every workstation and the fact that such programs run much slower). But the biggest disadvantage of such programs, relative to the current discussion, is that the source code is readily available to the user (as long as they know a few basic rules about how to access it).
If they have access to it – then they can change it.
I had a customer call and complain about a problem that they were having with one of the programs that I wrote. I stopped into their office to fix it. I quickly found that someone had modified the source code that I provided! It was those modifications that weren’t working. I found out why they wanted those changes and repaired the program appropriately.
In a large corporate environment, there is a clear and present danger in allowing the customer to make such changes. Fortunately, most customers understand these dangers and don’t have any more desire than the vendor to allow such changes by the customer’s representatives. Moreover this sort of problem tends to be easy to spot (the size of and the date-and-time stamp on the binary files will be different, for example). In addition, I can’t imagine a customer who would argue with a vendor who billed for fixing a problem caused by someone working for the customer who modified the program.
A second potential danger in providing the customer with a copy of the source code is that you are possibly enabling the customer to become a competitor of yours. The customer can potentially take what you wrote and resell it, possibly making small changes as they do so but still using the intellectual property that the vendor created as the basis for what they sold. I believe this danger to be minimal. People interested in such custom software are probably people who compete with the customer who has the original code. The customer is unlikely to wish to enable their competitors.
But this possibility, however unlikely it is, can be handled by contract terms within the contract agreed to between the customer and the vendor.
A third problem is that the source code will generally include reused code that was developed initially for another customer. In that case portions of the source code were paid for by other customers. So if you provide all of the code for the customer, it is likely that you are giving the customer intellectual property that they didn’t pay for.
Once again, there is a solution. It takes a bit more work, but the source code that the customer did not pay for can be provided in a binary form rather than in the original source code form.
A final problem is that the source code can be given to another vendor and that vendor can take over the development and support of the program. Again I consider this to be a relatively small danger. The original vendor is bound to be much more familiar with that source code and should, therefore, be able to be very competitive with anything that any other vendor could provide.
But clearly there are dangers and complications in providing this source code to the customer. That is why many vendors believe that the customer should NOT be given that code.
But there is a legitimate reason for the customer to want a copy of the source code is that there is a dangerous situation: the customer needs to have some reassurance that their program can be modified if the vendor goes out of business.
How do you handle that situation?
There are companies that provide the ability to put the source code into escrow. The source code is hidden until (and unless) the vendor gets out of the business.
There is a cost associated with this. That cost should be built into the quotation provided to the customer.
The biggest danger of such escrow accounts that I have witnessed is that while the initial solution is safely put into escrow, any updates are not necessarily included. It should be the responsibility of the project manager to make sure that all updates are put into escrow if such an account has been established for a particular customer.
Friday, May 1, 2009
Code Reusability in Custom Software Projects
Without doubt the most appealing economic reason to get into the software development business is the extremely low cost of reproducing your product compared to the potential selling price.
An excellent example is the first significant database program for PCs – “dBase”.
In the mid-1980’s, a company called Ashton-Tate sold a version of their database management program called “dBase III-Plus”. The program was so popular that within a short time the company was able to write off all of their development costs. At that time, the manufacturer was receiving something like $325 per copy from dealers.
But because the development costs had been fully depreciated, their cost to produce each copy consisted of the cost of a box, a manual, a few floppy disks (yes, floppy disks) and for every few thousand new users probably a new technical support person. Total cost for producing each copy, probably about $25.
If your cost to produce something is $25 (or so) and you can sell it for $325, you are basically printing money.
Which is what we all want to do. I don’t have access to Microsoft’s costs but they undoubtedly have some software products that are in the same category.
But dBase was a “standard” product, not a custom software solution. Can similar things be done with custom software?
Partially, yes - you can do some of the same things. But it is much more difficult. Furthermore, the key word is “similar”. You can never do exactly the same thing for two different customers.
Probably the best examples showing the problems are the various Enterprise Resource Planning (ERP) systems that have developed. If you are unfamiliar with ERP software packages they basically run the company when they are fully implemented. They do no less than control all of the resources, information, and functions of the business.
The most well-known vendors for such software packages are Oracle, SAP and a few others. Those companies provide “standard packages”. But all of those packages require customization because no two companies work with identical processes and types of information.
What is the cost to customize it?
In nearly every case it is more than the cost of the basic package itself. Here’s a summary from Wikipedia:
“For most mid-sized companies, the cost of the implementation will range from around the list price of the ERP user licenses to up to twice this amount (depending on the level of customization required). Large companies, and especially those with multiple sites or countries, will often spend considerably more on the implementation than the cost of the user licenses -- three to five times more is not uncommon for a multi-site implementation[1].”
Any sort of custom software works in the same way.
However there is a difference in complexity. Existing companies, of necessity, already have functions, data and resources and processes built around those.
A new custom software package performing a completely new function within a company won’t have to be integrated with existing processes. In many cases, there will be fewer changes.
But you should expect that there will be some amount of customization. The reason that the customer is buying a custom software package in the first place is so that they can get something that matches, as closely as possible, the way that the company wishes to operate.
Some managers within software development companies don’t recognize that solutions delivered for different customers should always expect to be different from each other.
It is always a good idea to have managers responsible for developing custom software to have custom software development experience themselves. But that is not always the case.
Some such managers only have experience working on standard software development. That, by definition, does not require customization.
Other managers, surprisingly, have no software development experience.
But all of those managers have their eyes on the ultimate prize: the dBase example given above; reselling something for more than ten times its cost.
Furthermore, the extent to which you are going to develop reusable code is the extent to which you need to do market research on the features that should be included in the basic part of the product. When you are developing the initial database design and other features it is a good idea to have the final goal in mind.
As is the case with any business, it is important to understand the market and the product that you are selling.
Here is a true story example of how not to do it.
I worked for a company that developed systems using plastic cards. One set of applications for plastic cards are loyalty programs (like the airline “frequent flier” programs). If you reward people for using your products and services they will tend to prefer your products and services over those of a competitor that doesn’t offer rewards.
It turns out that even hospitals might have a reason to use such a program. I won’t go into the details except to say that such programs can be effective when dealing with expectant mothers in particular.
One sales person for this company recognized the existence of this market. He suggested a plan for developing such a system.
First, we would deliver a system at cost for one customer.
Second, we would deliver additional, identical systems at 50% of cost to other customers. With little or no development costs for those additional systems, we should make significant profits.
Right?
The problem was that we developed the first system while only talking to that first customer. We never had any discussions with the second customer. Then when we dealt with the second customer, that customer wanted something quite different. The applications were only similar at a high level. In fact, probably only about 60% of the code that we developed for the first customer was reusable in the application developed for the second customer.
That’s not an insignificant percentage. But it was still well below the expectations of the managers of the company where I worked. Simply put, the second project lost money because the cost of developing the application for the second customer far exceeded their expectations. So they lost interest in continuing down that path.
My guess is that if they would have sold the application to a third customer, the percentage of code that could have been reused might have been around 80%. Then it would have been continuously higher for each additional customer as new features were added by each new customer. In the long run it might have been a successful strategy.
The primary problems were that the sales people were not familiar with the specifics of what the customers wanted and that the managers were not familiar with custom software development. The managers were used to selling “boxes” – hardware. That’s not changeable. They didn’t understand that customers purchase custom software precisely because it is changeable.
[1] http://en.wikipedia.org/wiki/Enterprise_resource_planning, referenced on March 26, 2009
An excellent example is the first significant database program for PCs – “dBase”.
In the mid-1980’s, a company called Ashton-Tate sold a version of their database management program called “dBase III-Plus”. The program was so popular that within a short time the company was able to write off all of their development costs. At that time, the manufacturer was receiving something like $325 per copy from dealers.
But because the development costs had been fully depreciated, their cost to produce each copy consisted of the cost of a box, a manual, a few floppy disks (yes, floppy disks) and for every few thousand new users probably a new technical support person. Total cost for producing each copy, probably about $25.
If your cost to produce something is $25 (or so) and you can sell it for $325, you are basically printing money.
Which is what we all want to do. I don’t have access to Microsoft’s costs but they undoubtedly have some software products that are in the same category.
But dBase was a “standard” product, not a custom software solution. Can similar things be done with custom software?
Partially, yes - you can do some of the same things. But it is much more difficult. Furthermore, the key word is “similar”. You can never do exactly the same thing for two different customers.
Probably the best examples showing the problems are the various Enterprise Resource Planning (ERP) systems that have developed. If you are unfamiliar with ERP software packages they basically run the company when they are fully implemented. They do no less than control all of the resources, information, and functions of the business.
The most well-known vendors for such software packages are Oracle, SAP and a few others. Those companies provide “standard packages”. But all of those packages require customization because no two companies work with identical processes and types of information.
What is the cost to customize it?
In nearly every case it is more than the cost of the basic package itself. Here’s a summary from Wikipedia:
“For most mid-sized companies, the cost of the implementation will range from around the list price of the ERP user licenses to up to twice this amount (depending on the level of customization required). Large companies, and especially those with multiple sites or countries, will often spend considerably more on the implementation than the cost of the user licenses -- three to five times more is not uncommon for a multi-site implementation[1].”
Any sort of custom software works in the same way.
However there is a difference in complexity. Existing companies, of necessity, already have functions, data and resources and processes built around those.
A new custom software package performing a completely new function within a company won’t have to be integrated with existing processes. In many cases, there will be fewer changes.
But you should expect that there will be some amount of customization. The reason that the customer is buying a custom software package in the first place is so that they can get something that matches, as closely as possible, the way that the company wishes to operate.
Some managers within software development companies don’t recognize that solutions delivered for different customers should always expect to be different from each other.
It is always a good idea to have managers responsible for developing custom software to have custom software development experience themselves. But that is not always the case.
Some such managers only have experience working on standard software development. That, by definition, does not require customization.
Other managers, surprisingly, have no software development experience.
But all of those managers have their eyes on the ultimate prize: the dBase example given above; reselling something for more than ten times its cost.
Furthermore, the extent to which you are going to develop reusable code is the extent to which you need to do market research on the features that should be included in the basic part of the product. When you are developing the initial database design and other features it is a good idea to have the final goal in mind.
As is the case with any business, it is important to understand the market and the product that you are selling.
Here is a true story example of how not to do it.
I worked for a company that developed systems using plastic cards. One set of applications for plastic cards are loyalty programs (like the airline “frequent flier” programs). If you reward people for using your products and services they will tend to prefer your products and services over those of a competitor that doesn’t offer rewards.
It turns out that even hospitals might have a reason to use such a program. I won’t go into the details except to say that such programs can be effective when dealing with expectant mothers in particular.
One sales person for this company recognized the existence of this market. He suggested a plan for developing such a system.
First, we would deliver a system at cost for one customer.
Second, we would deliver additional, identical systems at 50% of cost to other customers. With little or no development costs for those additional systems, we should make significant profits.
Right?
The problem was that we developed the first system while only talking to that first customer. We never had any discussions with the second customer. Then when we dealt with the second customer, that customer wanted something quite different. The applications were only similar at a high level. In fact, probably only about 60% of the code that we developed for the first customer was reusable in the application developed for the second customer.
That’s not an insignificant percentage. But it was still well below the expectations of the managers of the company where I worked. Simply put, the second project lost money because the cost of developing the application for the second customer far exceeded their expectations. So they lost interest in continuing down that path.
My guess is that if they would have sold the application to a third customer, the percentage of code that could have been reused might have been around 80%. Then it would have been continuously higher for each additional customer as new features were added by each new customer. In the long run it might have been a successful strategy.
The primary problems were that the sales people were not familiar with the specifics of what the customers wanted and that the managers were not familiar with custom software development. The managers were used to selling “boxes” – hardware. That’s not changeable. They didn’t understand that customers purchase custom software precisely because it is changeable.
[1] http://en.wikipedia.org/wiki/Enterprise_resource_planning, referenced on March 26, 2009
Subscribe to:
Comments (Atom)