Potential quality problems when using Open Source components in your software product - Reduced level of control

Most software applications use components or services from teams that are external to them - these could be teams within the organization, or these could be from outside the organization. Many applications even use components that are built by Open source processes. These components can be very useful, but one needs to be mindful of the impact of using external components, especially if you are in the role of a project manager or a program manager. If a critical component is late or is of bad quality, it have a critical impact on the schedule of your project.
I remember a case where we had a component that was important, and we had just taken delivery of a new version of the component (it was available on the web page of the Open source project and the notes mentioned that this fixed a defect that was critical for us). This was incorporated in a development version of the product, which was sent out to beta testers after a quick application of some test cases. Unfortunately, in this case, Murphy's Law hit us bad. The quality of the external component was bad, it destroyed some of the test data that customers were using. Now, although we would warn the customers that they should not use their live data in Beta testing, the Beta customers had a certain expectation in terms of the quality of Beta software that they were using, and the release was less than that. We got chewed out by senior management that one time, although there was little that we could do.
This gets very tricky when you use Open Source software, since there is a reduced level of control in using such components. However, in most cases, you will be forced to use atleast some amount of open source software. Many components are available as Open Source, which are otherwise available for very expensive sums. Software companies do the trade-off between the cost of a controlled component from outside and the problems that may happen when you use an Open Source component, and invariably, better use can be made of the money, and you will end up using the Open Source software. This is even more so when the same component is being used by other groups within the company, as well as by other product in the same space.
One compromise that can be reached is about deciding which version of the Open Source component to be used, and deciding the amount of testing that needs to be done before and after integration of the component.   So, depending on the phrase of the project, if there is no real dependency such as Beta testing or other such delivery, you could take the latest version of the Open Source software and test the hell out of it, and then decide whether to proceed with the component. However, if you are still in a state where you have some dependencies, then it would be wiser to take an earlier version of the component, which has been well tested and is good for use. If there is a bug fix that is there in the latest version of the software, then you would need to make a decision about the software to use.
Overall, the stand that you need to take is no easy call - there are a lot of benefits of using an Open source component, but you need to review the attendant benefits and problems, and then take a call.

Different licensing situations in software development - Part 7

As a part of this series, I am writing on software licensing models (software licensing and open source), particularly when you use software components inside your software product. For example, you could be using an open source software for parsing XML, instead of writing your own software for this purpose. The same thing could be repeated for any such open source software product that you may want to use.
Now, if you want to use a service (such as providing an email service, or having an online photo editor, or some other similar service), then it is easier to use open source software than if you are distributing your product as a shrink wrapped software. So, in the previous post, we talked about how using a CopyLeft license put terms on the final software that any derivative work based on the copyleft license would also need to be released on the same license as the copyleft software. Further, these rights cannot be subjected to revocation at a later point. So, if a free software does not ensure that derivative works be distributed under the same license, then it is not a copyleft license.
In addition, copyleft itself has weak and strong provisions. A weak copyleft provision allows that if a commercial software uses a copyleft software component, then only if the component is changed, then the changed section of code will need to be available for re-distribution. The concept of a weak copyleft provision is provided under the GNU Lesser General Public License and the Mozilla Public License (so you can find commercial software that actually incorporates component software that is licensed under the LGPL and MPL); while there are strong licenses such as the GNU General Public License that enjoins the entire incorporating software to be released under the same terms as the component.
What this also means is that if you are working with a commercial software company, then any use of licenses which have terms such as copyleft, GPL, LGPL, etc needs to be looked at very carefully before you go ahead with using such software. Using GPL would in almost all cases be totally ruled out.
More in the next post ...

Different licensing situations in software development - Part 6

In the previous post, I was writing about easy availability of various items (software licenses), and ended up with a listing of the different kinds of open source licenses (the various names of the open source licenses were written down). In this post, I will continue on the subject of open source licenses, as well as the difference between closed source licenses and open source licenses. And open source software is a slightly vague term, which is in fact, further explained into free software and open source software (with the difference between them being that free software focuses on getting the software without charge into the hands of the user, while open source means that the focus is on ensuring that people have access to the source of the software and can make changes).
Here is a listing of all the open source licenses: http://www.opensource.org/licenses/category
Some of the terms used in the licensing debate cannot make sense unless you have read some explanations of them. For example, there is a term called "Copyleft". Copyleft is something that is very critical for makers of commercial software, since Copyleft not only insists that the software should be open source for anybody using that software, but if anybody uses the software and modifies it or extends it, these modified versions should also be made open source. So, if somebody uses that open source software, integrates it into their software, then the licenses compels them to release the modified version of the software as well. This restriction prevents most people who make commercial software to avoid the use of Copyleft software in their own software. If you are thinking of using Copyleft software, please be sure to check the exact terms of the license and also check with your legal team (most company legal teams I know are very hesitant in using copyleft software).
In Copyleft software, the initial owner of the software has not waived their rights, instead has ensured that there are some restrictions on the usage of that software in terms of commercial software. Read more at this Wiki: http://en.wikipedia.org/wiki/Copyleft

Read more in the next post ..

Different licensing situations in software development - Part 5

In previous posts (License conditions), I have been writing about the need for having the proper software licenses when you are developing a software product and you are using some external software components inside your software.
There are a large number of software components apparently available free for you to start using. Suppose you want to have a database inside your software and don't want to pay the large amounts needed for MS SQL Server, or Oracle Database. Or you could need a XML parser, or some software for running regular expressions, or many other such needs, and when you search for these software, you will find plenty of such software available in the market. When you are starting a software product, there is plenty of temptation to pick up a component that meets your needs, and just start using it. I hope that some of the previous posts have explained that there are a number of problems with going ahead with such an approach.
So, if you do want to pick up an open source component to use in your own software, you need to understand the terms under which the software has been released, and if you don't have a legal person to help you, then you can be in some problem. At the very least, you should be able to look at the type of license with the software component, and then be able to say whether the license meets your needs. Here is an explanation of what open source software is, and what are some of the common types of software licenses used in open source software:
Open source software means software that is available in the form of source code; also the license available with the software gives users the permission to modify / change / compile / and in some cases, distribute the software source code.
Using open source software (either in the form of the application, or using the source code inside your application) has resulted in a huge amount of savings for consumers, but there are some legal implications of using this code.
Some of the open source software in use are:
Apache License,
MIT License,
BSD license,
GNU Lesser General Public License,
GNU General Public License,
Eclipse Public License and
Mozilla Public License

I will continue on this subject in the next set of posts ..