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.
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.
No comments:
Post a Comment